search

kaleidos / grails-security-stateless

Grails plugin to implement stateless authentication using Spring Security
Apache License 2.0
17 stars 8 forks source link

How is the token refresh handled? #36

Open ppazos opened 8 years ago

ppazos commented 8 years ago

From the guide, I can give a token to a user and I can set the expiration time, but it is not 100% how the token refresh is done when the token expires.

Can you clarify how this is done?

In other solutions I analyzed, when the authentication is done, the auth token is returned alongside a refresh token. So when the auth token expires, the refresh token is used to get a new one, instead of sending the user credentials again. The problem of sending the user credentials to refresh a token implies the need to 1. ask the user to login again, or 2. store the user credentials in the app (no good for mobile apps!). So to be 100% transparent to the user and avoid storing credentials on devices, the refresh token is needed.

Thanks!

pabloalba commented 8 years ago

Yes, we discuss that internally... Some of us think that an auto renewable token is basically the same as a never-expiring token, and other disagree... We haven't reach an agreement, but maybe on the future we implement the auto-renovation. For now, on our apps we ask the user for the credentials again when the token expires.

ppazos commented 8 years ago

I'm not sure if this is really auto renovation from the grails-security-stateless point of view, but from the app point of view, since the endpoint to refresh the token is given by the app, like the login endpoint from a controller.

What I think might be needed to provide from the plugin is some domain class to save the refresh token to the database, since that token never expires. IMO a memory cache won't be ideal to store the token.

niwinz commented 8 years ago

The token refresh process does not requires any additional centralized storage. With a simple endpoint that authenticates the incoming user and validates that its token is not expired, then return a new token that the client should use in the next requests.

This is the standard and widely accepted token renovation strategy, it does not requires store the user information and does not requires backend state for handling that.