Handling Token Expiration

[OhadR]

Hi,

What is the best way to handle token-expiration in the Authentication provider?
Short description of what I've done: In my Authentication server, I have a props-file that configures the expiration time of the token ( for how long it is valid). I use this property when I create the token (in my implementation of AuthorizationServerTokenServices.createAccessToken () .

In the resource server, I have my MyResourceSrvTokenServices implements ResourceServerTokenServices, that is called by the OAuth2ProtectedResourceFilter. There, (in the loadAuthentication()). I make a validation-check if the token has expired. If expired - I throw "InvalidTokenException".

I see that this exception is caught by OAuth2ExceptionHandlerFilter.

My Questions:
1. Is this the best practice?
2. what suppose to happen on expiration? I thought that I would be redirected to the login screen and asked to enter credentials again.
3. what is exactly "refresh-token" and what is its part in this specific scenario?

I use M6...

thanks!

[Dave Syer]

1. I'm not sure it is necessary to check for expiration in the resource server token services, but it probably doesn't hurt.

2. It's up to you how to handle it from the point of view of the client. Normally you wouldn't connect access token expiry directly to authentication session though (a user might log out of the authentication server but still expect the authorization represented by the access token to be valid).

3. The purpose and operation of refresh tokens is covered by the spec. You don't have to use them, either server or client side, but if you use Spring Security Oauth for your client, and a refresh token is available, it will be used to obtain a new access token without needing to ask the user for authorization.

[OhadR]

1. I'm not sure it is necessary to check for expiration in the resource server token services, but it probably doesn't hurt.

If the resource server does not check for the expiry of the token, who does? I don't wanna do unnecessary things in my code :-) I thought that this way the resource server protects the data by checking the token. Otherwise, what else the loadAuthentication() does with the given token?

2. It's up to you how to handle it from the point of view of the client. Normally you wouldn't connect access token expiry directly to authentication session though (a user might log out of the authentication server but still expect the authorization represented by the access token to be valid).

What do you suggest? what you think is the best practice, the best thing to do on expiration?

3. The purpose and operation of refresh tokens is covered by the spec. You don't have to use them, either server or client side, but if you use Spring Security Oauth for your client, and a refresh token is available, it will be used to obtain a new access token without needing to ask the user for authorization.

AFAIU, the use of refresh token is to make life better for the client: when the token has expired, instead of making the user enter his credentials again, the client gets a 'refresh token' he can use. How can I make refresh token "available" in my client ? (all my components are using Spring Sec OAuth)

thanks a lot!

[Dave Syer]

If the resource server does not check for the expiry of the token, who does?

For sure the resource server has to do the check. I wasn't (and am not) in front of the code so I can't remember whether the filter or authentication manager or token services does it in the default implementation. You can find out by looking in the source code.

AFAIU, the use of refresh token is to make life better for the client: when the token has expired, instead of making the user enter his credentials again, the client gets a 'refresh token' he can use.

Sort of. But just to be clear: access token grants and user authentication (i.e. credentials) are orthogonal concerns. The refresh token gives the Authorization Server some control over when and how often an authenticated user is prompted for approval of the grant.

How can I make refresh token "available" in my client ? (all my components are using Spring Sec OAuth)

Your client needs to have an authorized_grant_types including "refresh_token", and your Authorization Server has to be able to issue refresh tokens (usually on by default but if you write your own token services it's up to you), and to be able to accept token requests with grant_type=refresh_token (as per the <oauth:authorization-server/> configuration).

[OhadR]

For sure the resource server has to do the check. I wasn't (and am not) in front of the code so I can't remember whether the filter or authentication manager or token services does it in the default implementation. You can find out by looking in the source code.

So I've looked in the code and found DefaultTokenServices. (this TokenServices implementation does not exist in M6, I guess only in later versions...). This class makes the check "isExpired()". However, AFAIU, this token services is in the authorization-server side, not in the resource server... the auth-server does the check on the refresh-token, when it is issued for a new access-token. But i did not find any implementation in the resource-server that makes the check. So it gets me back to my previous question: Is there a default implemetation for the access-token expiration in the resource server? or do I have to handle this check with my own impl? (I just wanna make sure I understand the Spring's oAuth impl...)

and: what is your suggestion as a "best practice" for checking the expiration of access token?

many thanks,
Ohad

PS:

But just to be clear: access token grants and user authentication (i.e. credentials) are orthogonal concerns. The refresh token gives the Authorization Server some control over when and how often an authenticated user is prompted for approval of the grant.

-so as far as I see things: access token has an expiration; when it is expired the user is prompted to re-identify himself, unless he has "refresh token", which gives him more time till he is prompted.
(and if the auth-server implements "remember-me", so the user enjoys the cookie and will not be prompted as long as the cookie exists...)

[Dave Syer]

and: what is your suggestion as a "best practice" for checking the expiration of access token?

The DefaultTokenServices checks for expiry in loadAuthentication (called indirectly by the filter that protects a resource). I would say that is the best practice, and I'm not sure why you didn't think that it would be checked automatically (possibly because your custom token services does not, or maybe you are looking at old code).

-so as far as I see things: access token has an expiration; when it is expired the user is prompted to re-identify himself, unless he has "refresh token", which gives him more time till he is prompted.

Sort of. When an access token expires, if there is no refresh token, a user might be prompted for approval of the scope of a new token (if the authorization server wishes to prompt - see UserApprovalHandler). He will only be prompted to identify himself if necessary (i.e. he is not currently already authenticated).

[OhadR]

The DefaultTokenServices checks for expiry in loadAuthentication (called indirectly by the filter that protects a resource). I would say that is the best practice, and I'm not sure why you didn't think that it would be checked automatically (possibly because your custom token services does not, or maybe you are looking at old code).

Yep. As I mentioned, I don't see that DefaultTokenServices exists in M6. I guess it was born it a later version (correct me if I'm wrong...)

Thanks a lot!