Token storage?

[jotpal]

Hi Guys,

I've just started working with Spring oAuth2 few days back. I have successfully installed the tonr and sparkler webapps on tomcat. I think i have got some understanding of how everything(well most of them) hang together.

My question is related to how the token is stored. I had a bit of dig around the source code(TokenEndpoint, AbstractTokenGranter, DefaultTokenServices and InMemoryTokenStore)

If I'm not wrong, the token is stored in the ConcurrentHashMap(token, OAuth2Authentication). Now in the OAuth2Authentication instance, we are setting the AuthorizationRequest, but Authentication is set to null. I need to somehow set the authentication(end-user details). So, when we validate the access token in subsequent request, I'll have the end user details as well.

Is there something out of the box which I can use? Otherwise Can you advise what will be the best way to implement?

Thanks
JP

[Dave Syer]

Now in the OAuth2Authentication instance, we are setting the AuthorizationRequest, but Authentication is set to null.

That would be for a client credentials grant. If there is a user then the Authentication is not null and represents the user. For an auth code or implicit grant it would be created by a Spring Security authentication filter and passed into the authorization endpoint. For a password grant it is created by the TokenGranter. The sparklr sample should have everything you need.

[jotpal]

Great, Thanks Dave for a quick reply. I have now got into more inner details - all good.

Another question - Scenario - the client now has an access token and sends a request to auth server to retrieve the end-users content. Before the content is returned, the auth-server validates the token. Now the resourceServerFilter kicks in i.e. OAuth2AuthenticationProcessingFilter. OAuth2AuthenticationManager is being injected in the filter which authenticates the token.

If I want to create a customAuthenticationManager which has couple of more validation rules. What's the best possible option to implement it? Will that be another filter?

Thanks

[Dave Syer]

If I want to create a customAuthenticationManager which has couple of more validation rules. What's the best possible option to implement it? Will that be another filter?

Entirely up to you I would say. If I were you I'd use the existing filters and extension points unless that was awkward in some way, but I don't think I can tell from your description what you intend to do.

[jotpal]

Thanks Dave.

I'll try to explain what I'm trying to implement here. I have an application which is working as Authorization server. It works as expected. No issues.

Now once the client gets hold of access token, the next request is something like http://localhost:8080/app/getDetails?id=name@host.com. Here 'id' is the end-user's login, which is stored in the tokenstore along with the key. My requirement is to check the token is being used by the same 'id' and not by some other id. Does that make any sense?

I'm planning to extend OAuth2AuthenticationManager, but not sure how can I inject this class into the OAuth2AuthenticationProcessingFilter? Please advise.

Thanks
JP

[Dave Syer]

OAuth2AuthenticationProcessingFilter has a setter for an authentication manager (not exposed in the XSD, so you'd have to use normal bean configuration, but that's not hard). Or you could simply parse out the request parameter in your controller, which seems like a pretty resonable thing to do really (no need for custom filter or authentication manager).

However I'm not really sure why you need to do this, since the user's identity can be carried in the bearer token and decoded by the resource server.

[jotpal]

Thanks Dave for your help.

OAuth2AuthenticationProcessingFilter has a setter for an authentication manager (not exposed in the XSD, so you'd have to use normal bean configuration, but that's not hard). Or you could simply parse out the request parameter in your controller, which seems like a pretty resonable thing to do really (no need for custom filter or authentication manager).

Yep, that makes sense. Thanks.

the user's identity can be carried in the bearer token and decoded by the resource server.

Sorry, I'm not sure if I understand how identity can be carried in the bearer token? If you don't mind, Can you please put some more details. Thanks once again.

[Dave Syer]

Sorry, I'm not sure if I understand how identity can be carried in the bearer token? If you don't mind, Can you please put some more details. Thanks once again.

Look at ResourceServerTokenServices.

[pulapura]

I would assume the identity is stored against the token. Hence, when a token is received, we should be able to look up the identity associated with the token. I guess thats what the ResourceServerTokenServices does, it has a method to load the authentication from the access token value.