[SECOAUTH-374] Support additional/custom token parameters

[dsyer]

Priority: Major
Original Assignee: Dave Syer
Reporter: Alex Rau
Created At: Sat, 15 Dec 2012 18:57:48 +0000
Last Updated on Jira: Fri, 12 Jul 2013 10:30:36 +0100

Google's OAuth2 implementation requires explicit parameters to reliably receive refresh tokens:

access_type=offline&approval_prompt=force

If these parameters are undefined access tokens will not be refreshable as no refresh token will be provided at all.

The behaviour can be simulated here: https://developers.google.com/oauthplayground

I think these parameters are not covered in the OAuth2 spec (yet?) so probably it would make sense to provide some kind of generic mechanism for providing any additional parameters to better support "extended" OAuth2 providers.

Comments:

david_syer on Fri, 12 Jul 2013 07:41:21 +0100

I seem to remember using Spring OAuth2 with Google (or am I imagining it?), so presumably they support standard the protocol as well? Having said that I think there is definitely a case for adding some custom form handler to the OAuth2RestTemplate or the AccessTokenProviders. Where this feature lives probably depends largely on whether the custom parameters are static, or change for every request. the ones you listed are static, so they could live in an AccessTokenProvider?

david_syer on Fri, 12 Jul 2013 07:47:18 +0100

SECOAUTH-410 seems to be the same problem (with a dynamic extra parameter) and it's google again.

A workaround might would be to add an interceptor to the AccessTokenProvider.

yogeshnehra on Fri, 12 Jul 2013 09:06:45 +0100

When custom parameters are dynamic then we can use ThreadLocal and set custom parameter as threadlocal variable before calling api and use same thread local to construct custom token parameters as given below. Code is written in AuthorizationCodeAccessTokenProvider.java file's getRedirectForAuthorization method -

String currentUser = ThreadLocalContext.get();
if(currentUser != null && !"".equals(currentUser.trim())) { requestParameters.put("user_id", currentUser); }

I have done this workaround for my requirement and if others agree I can submit a patch for the same, which will be more generic then above.

david_syer on Fri, 12 Jul 2013 10:30:36 +0100

I would be interested in a pull request with a test case that shows how to do it. I'm not sure I like the idea of the thread local much, unless it can be tied to the SecurityContext, but it would certainly be good to try it out and get a feel for it.