You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I created a pull request that enables auto-refreshing tokens (#38).
While this addition adds convenience, it worsens the application security. Having a token that expires within a reasonable amount of time gives a potential attacker less time to do damage.
The client gets the token expiry when logging in. It should be the responsibility of the client-application to issue a token refresh when the token is about to expire.
Issuing a token-refresh should not use the regular access-token, since it would enable the attacker to completely take over access.
So there are two approaches for a token-refresh:
Use the user credentials (this would mean that user credentials have to be stored client-side which is not optimal)
Use a special refresh-token
I would propose the following changes to the RESTful API
Add an additional field RefreshToken to RESTfulAPI_TokenAuthExtension
When a user logs in (api/auth/login), generate a RefreshToken and the regular access-token and pass both back to the client.
Introduce an action api/auth/refreshToken which has to be called by the client when the access-token is about to expire. The client has to submit the obtained RefreshToken and gets a new access-token in return.
I'd gladly create a PR for this if you agree that this would be a worthwhile addition.
The text was updated successfully, but these errors were encountered:
bummzack
added a commit
to bummzack/silverstripe-restfulapi
that referenced
this issue
Jun 19, 2015
ADD colymba#44: Implement API method to refresh token.
- Reverted to non-unique indexes on `RESTfulAPI_TokenAuthExtension` since there's an issue with MsSQL DBs.
- Implemented token refresh methods.
- Updated documentation.
- Added test for "refreshToken".
- Updated token uniqueness test.
Yes, you can use the login method, but that would mean that I'll have to persist username and password on the client, which I don't like at all.
The refresh-token approach is inspired by OAuth refresh-tokens. And since this is a purely optional addition to the current API, I deemed it worthwhile.
A developer can still choose to:
use the RESTfulAPI and refresh token using login
use autoRefreshLifetime to create auto-refreshing tokens
set the token lifetime to a very high value, so it basically won't expire
or use the slightly more secure refresh-token approach
It's just about giving more options to the developer.
I created a pull request that enables auto-refreshing tokens (#38).
While this addition adds convenience, it worsens the application security. Having a token that expires within a reasonable amount of time gives a potential attacker less time to do damage.
The client gets the token expiry when logging in. It should be the responsibility of the client-application to issue a token refresh when the token is about to expire.
Issuing a token-refresh should not use the regular access-token, since it would enable the attacker to completely take over access.
So there are two approaches for a token-refresh:
I would propose the following changes to the RESTful API
RefreshToken
toRESTfulAPI_TokenAuthExtension
api/auth/login
), generate aRefreshToken
and the regular access-token and pass both back to the client.api/auth/refreshToken
which has to be called by the client when the access-token is about to expire. The client has to submit the obtainedRefreshToken
and gets a new access-token in return.I'd gladly create a PR for this if you agree that this would be a worthwhile addition.
The text was updated successfully, but these errors were encountered: