OAuth 2.0 access token advice

Copies OAuth 2.0 access tokens from message headers to the OAuth 2.0 context and vice versa.

A message handler advice implementation that reads an authorization code or OAuth2AccessToken from the request message and places it in the correct OAuth2ClientContext and/or AccessTokenRequest before the request handler is executed. This enables the specified OAuth2RestTemplate to be used in a message flow, instead of requiring a web application context.

This advice will also temporarily add a DummyAuthentication to the current security context, because the OAuth2RestTemplate expects to run in an authenticated (web) session.

This class uses the following two pre-defined message headers:

• emagiz_oauth2_accessToken: Should contain an OAuth2AccessToken that is serialized, gzipped and base64-encoded to a string value. If found on the request message, this OAuth2AccessToken will be placed in the OAuth2ClientContext before executing the request handler. After executing the request handler, the current OAuth2AccessToken will be obtained from the OAuth2ClientContext and placed as a header on the reply message.
• emagiz_oauth2_authorizationCode: If found on the request message, this authorization code (a string) will be added to the AccessTokenRequest before executing the request handler. This header is ignored when a OAuth2AccessToken is available (see above).

OAuth 2.0 REST template

The OAuth2RestTemplate this advice will prepare the OAuth2ClientContext for.

The intended use is to add this advice to a request handler that in turn uses this OAuth2RestTemplate, like a Spring Integration <http:outbound-gateway> configured with a custom RestTemplate.

Required

Use dummy authentication

Whether this advice should use a temporary DummyAuthentication while executing the request handler in cases where authentication is required and hasn't been established yet.

Default is true.

Remove context from scope

Whether this advice should remove the OAuth2ClientContext from scope after executing the request handler. This basically clears any "session" state after each call, assuming all state information is available on the request message.

Note that this only works when the OAuth2ClientContext is an instance of ScopedObject, which usually is achieved by adding <aop:scoped-proxy/> to the bean definition. Both the eMagiz <emagiz:oauth2-rest-template> and the Spring Security OAuth <oauth:rest-template> bean definition parsers already do this implicitly.

Default is true.

Remove request from scope

Whether this advice should remove the AccessTokenRequest from scope after executing the request handler. This basically clears any "request" state after each call, assuming all state information is available on the request message.

Note that this only works when the AccessTokenRequest is an instance of ScopedObject, which usually is achieved by adding <aop:scoped-proxy/> to the bean definition. Both the eMagiz <emagiz:oauth2-rest-template> and the Spring Security OAuth <oauth:rest-template> bean definition parsers already do this implicitly.

Default is true.

Additional request parameters that will be added to any UserRedirectRequiredException that occurs while executing the request handler.

For example, when using the Google API you might want to add the parameters "access_type=offline" and "approval_prompt=auto" to the redirect URL.

Note that any parameter specified this way might overwrite an existing parameter, so you should probably not use any of the OAuth 2.0 default parameters (e.g. client_id, redirect_uri, response_type, scope).

Default is empty.