I would like to implement OAuth 2.0 authorization on my JAX-RS RESTful services.
After some researches, I've found Apache CXF to do that. However, I haven't found any examples about it and it's unclear for me. Where can I find some examples of JAX-RS with OAuth 2.0?
Disclaimer: This answer doesn't really provide a solution for securing a JAX-RS with OAuth 2.0. But it aims to give some insights to Mohasin Ali, who started a bounty on my question. Maybe, the solution I used can be useful for him.
Regarding the bounty:
The question is widely applicable to a large audience. A detailed canonical answer is required to address all the concerns.
After asking this question a while ago, I realized that OAuth 2.0 would be too complex for my requirements. Even Basic Authentication would be enough for my requirements. But I ended up using an authentication scheme based on JWT tokens signed on server side. I described my solution in this answer.
Apache CXF provides an implementation of OAuth 2.0. It may worth looking at it if you want to use OAuth for securing you API. Apache CXF also supports OAuth 1.0.
It doesn't matter the authentication method you decide to use, do it on the top of a HTTPS connection. You'll need a certificate for that. As a suggestion, have a look at Let's Encrypt. They claim to be a free, automated, and open Certificate Authority, currently sponsored by Mozilla, Akamai, Cisco, Chrome, Facebook and others.
Regarding the following situation, mentioned in the comments:
[...] a malicious user visits someone's computer, open the browser, see the access token and copies the access token to his own browser [...]
If a malicious user have physical access to a computer, HTTPS won't prevent this malicious user from stealing an authentication token from someone's computer. Actually, if it happens, I think you should have bigger concerns...
For an additional layer of security, you could consider storing the token along with the IP address of the user you issued the token for. For each request that hits your API, compare the IP of the incoming request with the IP of the user you issued the token for. If the IPs don't match, refuse the request.
If you go for JWT tokens, instead of storing the whole token, store only the JWT ID claim (jti). Just ensure this value is unique (java.util.UUID should be enough for generating the jti value).
For a completely stateless authentication (not storing the whole token neither storing token ID), you could store the IP address in a JWT token claim, but mind the token will be a few bytes longer.
Please see https://github.com/Talend/tesb-rt-se/tree/master/examples/cxf/jaxrs-oauth2 for one example, it has a collocated example (all endpoints in the same container) and more complex one with the endpoints distributed, with SAML SSO Web profile supporting SSO.
Related
I am developing a REST API using Java Spring Boot framework. Purpose of this API is to connect mobile and web applications so they can work together.
My question is, what are the best practices to develop login functions or the login process. Shall I generate a token or what should I do?
You could follow the best practices as described in OWASP, here.
Most APIs nowadays use token based security. Here are a few guidelines:
You need one service (which is itself public) that authenticates the user.
In order to authenticate the user, it might use a username and a password, and/or other means.
As the result of authenticating the user, this service returns an authorization token.
Your backend should keep track of issued tokens.
Each token will have an expiration time.
Every time the client uses an API, it should send along the token. Usually, the token is sent as an HTTP header.
Every service in the API should validate the token before anything else. If the token is invalid, it should return an appropiate HTTP code.
All communications should be sent over SSL.
OAuth and OAuth2 are two very well known protocols for this very goal. OAuth is a little more complicated than OAuth2.
This is a very high level description, not technically deep, but it should get you started.
I am searching for the best approach of authenticating users of mobile clients when accessing my RESTful API. For example, how approximately AirBnb uses it's auth module.
Should the authentication be different for RESTful and basic session-based resource, working with the same data?
I am not a mobile developer therefore, I am interested in what is the best way to provide authentication from server-side, so the mobile-platform developers could use it simply.
I googled for few approaches using OAuth, OAuth2, HTTPBasic authentication and still wonder how the mobile developers can use such API, how they will store this token (cookie is stored by browser in browser-oriented apps).
Could you please suggest me some links/code samples/techiques that you used in production or pet-projects or something?
An easy and manageable alternative to OAuth(2) for authentication is JWT.
You don't need additional infrastructure, the workflow and use is straightforward and there are ready to use libraries for all major languages already available.
Compared to HTTP Basic Authentication JWT is more flexible by transmitting additional information not just credentials, you can store the JWT token as JSON or you can use cookies, you don't need to store the credentials on client side and you don't transmit the credentials on every request.
Also based on JWT you can realize very easy a single sign on function. So if you need more than just a simple system user then you should definitely try JWT.
I am currently in the early stages of creating a web application (HTML5, JS, etc.) that uses a REST API on the backend (Java, specifically Jersey v1.18). The nature of the data that will be stored is highly sensitive, so security is something that I’ve started looking at, even though the application is only in the early stages. The eventual goal will be to have native mobile applications as well, and to potentially provide access to the data for external clients via the same API.
In my research thus far, I have identified a variety of authentication methods, including HTTP Basic, token-based, session cookie, OAuth, HMAC, etc. The key component here is that the REST API will be primarily accessed by users, rather than other applications or backends. Thus, having a “login/logout” equivalent is important, and this boils down to user level authentication.
So far, HMAC authentication looks to be the most promising, as we have no plans to integrate with any OAuth provider at this moment.
I have already read through dozens of SO posts, as well as articles such as:
http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
http://www.errant.me.uk/blog/2013/04/authenticating-restful-web-applications/ (note: this is clearly bad, as salting with the username is not recommended)
Ideally, HMAC seems like the way to go, but I have yet to see a recommended approach to handling the shared secret. The idea of using a resource to validate credentials, which then provides a token/nonce to be used with the HMAC scheme, seems to be an option, but I’m questioning the advantages over just using this token/nonce strictly as a token.
I know that HMAC authentication for a REST API has been discussed at length, but when used in conjunction with the authentication details that users have come to expect (username, email, password, etc.), is there any recommended approach that doesn’t require a pre-shared secret key?
This is primarily an opinion-based question, but I'll offer my two cents: just go for a session cookie.
If your primary audience is humans, and you don't need to integrate with third parties, don't bother with OAuth. Just make sure your API is only available over HTTPS, and issue a session token that the server can revoke after login. Strictly speaking it doesn't need to be a cookie; I've seen APIs that stash the token in HTML5 session storage and provide it in the Authorization header or as a query param.
If you have SSL set up properly, your users will get the expected padlock in the browser, and you'll be safe from anyone in between you and the client. If the client is compromised, you're screwed anyways. And since the client can't keep a secret, there aren't a lot of advantages to more complex HMAC schemes.
I'm trying to understand the concept and benefits of implementing OpenID in your project. And, since I'm a Java developer, I'm more or less equally interested in understanding its main Java implementation, openid4java.
My understanding is that OpenID is a standard for provisioning decentralized IDs in a uniform way. Now, if that is totally (or even slightly) incorrect, please correct me!
Assuming I'm still on track, I see that all sorts or organizations have been using OpenID, such as MySpace, who identifies each of their users with a URL matching http://www.myspace.com/username.
So how does OpenID work as a system? Does it just manifest itself as a network of "OpenID Servers" that, like DNS machines, coordinate and make sure all IDs in their system are unique and match a certain pattern? Or, is it just an algorithm to be used which, like GUID, produces globally-unique IDs for each client domain (such as MySpace).
I'm just not understanding how OpenID actually manifests itself, and how frameworks like openid4java ineract with that "manifestation". (What their uses are).
First, there are two sides of the OpenID communication - the provider and the consumer. The consumer is the application that tries to authenticate using OpenID, and the provider is the server to which the authentication request is sent.
Each provider has a so-called Endpoint - url that accepts authentication requests. You should know that URL in advance when supporting an OpenID provider. First you have to discover what is the endpoint for a given openId, and then exchange messages with that provider. This is all wrapped in openid4java ConsumerManager.
Then happens the authentication - you redirect the user to a provider url, where the user confirms he wants to login using his account (should be logged in), then the provider redirects back to you, and then you can get the requested information about the user (through another request)
I am developing a web service using Spring framework for Java and deploy on JBoss AS. This web service needs authentication and authorization and security solution so that some method user A can execute and some other user B can execute. At client side, there will be an application calling to the web service and people may log in using either user account A or B.
I have been digging out the Internet, searching for web service authentication, researching on WS-Security but all that I can see is using WS-Security. WS-Security generally supplies 4 kinds of authentication:
UsernameToken
X.509 Token
SAML Token
Kerberos Token
But all those things are usually pre-configured and I find no example that suggest I should provide login/logout methods in the web service (by using stateful web service). Note that in case we use login methods then there are security risks even if the underlying is SSL transport.
So my question is:
What should I do to satisfy my requirements?
If using UsernameToken or Kerberos Token ... and we provide some privileges per user, i.e authorization, then for each incoming request, we must get the user information and get all its privileges. This process seems take time and decrease performance of the system. Do you agree? So I guess this is not recommended?
I would thank you so much for any response and will vote for any reasonable answer.
Your scenario mirrors that of EBay Trading API's.
Basically, it works as follow.
Provide a intial WS call (Ebay case: FetchToken) which confirms user's identity and return back authorization key (unique key for each logged in user). Store the authorization key along with user profile information in a cache/distributed cache .
Any subsequent call required client to pass the authorization key along with the data for the call. You will use the authorization key to get user profile information.
Provide the log out WS call. This invalidates the authorization key.
All the WS invocations should happen over SSL for security.
If your service is point to point, ssl is enough. Mutual ssl (Mutual_authentication) is widely used for client authN and authZ.
If you concert about performance of system, looking at SAML. SAML is a signed XML document that contains authN and authZ for client, that means you do not need to loop up on the server for client authN and authZ.