OAuth support in Jersey 2
By mfuksa on Nov 15, 2013
OAuth with Jersey 2
In the Jersey release 2.3 the OAuth support was added. The OAuth support is described with examples in the Jersey documentation (OAuth).
OAuth 1 was migrated from Jersey 1.x. Server API for OAuth 1 was not changed too much and basic principles of usage stays the same as in Jersey 1.x. It supports authorization flow and authentication using OAuth 1 authorization headers (including OAuth 1 signatures). You ca register your own implementation of OAuth1Provider which will manage access and request tokens and consumer credentials. The implementation will be responsible for creating tokens and storing them (for example in the database). The rest of work will be done by Jersey.
The client API was changed significantly in the way how the authorization flow (user authorization process) is performed. Authorization flow is no longer part of the client filter but is separated into a standalone tool. The reason for the API change was to simplify the usage of the authorization flow in cases when the client is a part of a web application. In the previous API version the redirection of the user was only possible by throwing an exception from the client filter, handling it by the user code, redirecting the user and then invoking the request again (which again invokes the filter that finished the authorization flow). Currently the filter is used only to add OAuth signatures to the Authorization header and authorization flow is completely separated. This allows to perform authorization flows many times for different users reusing one client instance. Additionally, the API of authorization flow do not require to throw and catch the exception in the middle of the authorization process.
You can check the OAuth 1 client sample that uses client OAuth support to connect to Twitter.
OAuth 2 support in Jersey 2 is currently implemented only for the client (current version of writing this blog post is 2.4.1). The API for OAuth 2 client support is similar to OAuth 1 client support in Jersey 2.
This is the example of OAuth 2 API usage:
Auth2CodeGrantFlow flow = OAuth2ClientSupport .authorizationCodeGrantFlowBuilder(clientId, authUri, accessTokenUri) .scope("contact") .build();
Authorization flow is built using static method of the OAuth2ClientSupport which is the main class to access OAuth 2 client API. You need to supply credentials of you client application (clientId) and URIs used during the authorization flow process. All these parameters are issued by the service provider. Service provider is the party to which we want to get an access with user's consent.
Now we can use the flow object to start the authorization flow by generating the authorization URI:
String finalAuthorizationUri = flow.start();
finalAuthorizationUri is the URI to which we should redirect the user. It contains query parameters (one of them is the clientId). Now we need to redirect the user to the authorization URI. In the case that our application is used on the server, we must store the flow object (in some cache) and respond to the user request with the 303 HTTP status and supply the URI in a location header. User will be redirected to the service provider and will be presented with the page asking the user to grant permissions to our application. After approval, the user is redirected back to our application. We need to extract parameters code and state from the request and use them to finish the authorization:
TokenResult result = flow.finish(code, state);
The method will internally request the access token from the service provider which will be returned in the TokenResult. Then we can finally use this token in Authorization headers in requests to authenticate our client application to the service provider (Jersey provides filter that adds OAuth 2 authorization headers).
Jersey contains OAuth 2 sample which uses OAuth 2 client support in the web application to get tasks from the Google account.
To try the OAuth support in Jersey, see instructions in Jersey documentation (OAuth).