Adding additional data to the access token

I need to pass additional data back in my access tokens so that our clients are able to receive additional data when the user/client is authorized.

It appears that the OAuth2AccessToken class supports setting additional data via the setAdditionalInformation setter, however, I don't see a hook anywhere in the oauth2 call stack to inject additional data.

Do I need to implement my own TokenGranter. If so is there a way to extend the CompositeTokenGranter class, and get the registered set of token granters as it does?

Thanks,
Chris

Writing your own token granter is one option. That extension point is mainly there for registered OAuth2 token types though, so if you aren't implementing an official extension it might be better to look at another option. The best way to provide additional information to a resource server is to encode it in the access token value itself and provide your resource server with a way to decode it (e.g. using JWT or a token info endpoint on the authorization server). Does that fit your use case (you used the word "client" and OAuth clients are *not* suppose dto be able to decode tokens, but maybe you were using the term loosely)?

I guess I was using incorrect terminology. Hopefully what I've written below makes more sense.

The JSON response from the token endpoint is below

{"access_token": "<token>",
"token_type":"bearer",
"expires_in":<time>,
"scope":"<scope>"}

I'm attempting to add an additional attribute that is specific to our app, we want to pass data in the original token grant instead of having to make a second hop to another endpoint that given the token can pass back the needed attributes. (I know it's not within the OAuth2 spec)

{"access_token": "<token>",
"token_type":"bearer",
"expires_in":<time>,
"scope":"<scope>",
"app_attr1" : <app attr> }

It appears that the OAuth2AccessTokenSerializer supports serialization of arbitrary data into the JSON, however, I don't see a way to add that info to the OAuth2AccessToken instance that is used by the response short of writing my own granter.

Does this make sense?

Yes it makes sense and implementing your own granter shouldn't be a big deal. It's just that your auth server will not interop with any standard-compliant clients if you do this. It's better IMO to encode additional information in the access_token value and then the clients that know how to decode it can do that, and the ones that don't won't need it.

I thought that if we changed the return payload that it might break standards compliant clients. Thanks for confirming that.

Thanks for all your help, and all your work on this framework!

Hi,

I am in exactly the same position and was wondering if you can remember what you did to resolve this?

Thanks

We solved this by using implementing TokenEnhancer

http://static.springsource.org/sprin...nEnhancer.html

Using this you can modify the AccessToken, and add items to the "additional information" which is output when the token is converted to JSON