February 10, 2016 at 7:37 am #7676
What is the default expiration set for Access Token and Refresh Token in OpenAM?
Generally, refresh tokens are not supposed to expire. So, I want to know whether OpenAM has any limit on the number of refresh tokens or any expiration is set.
In case, we have millions of users and if each user has generated a access token and refresh token, will OpenAM store all the refresh tokens for a long time?February 10, 2016 at 7:56 am #7677Rajesh RParticipant
@nkarthik82 Please see if the default values that you are looking for are available at the documentation link below:February 10, 2016 at 8:03 am #7678
@rajeshr Yes. It has all the values. I hope same guidelines are applicable for OpenAM 12 as well.
Coming back to my question, If I set the refresh token expiration to -1 (never expire), is it a good practice? In case the user count is in millions, its going to store millions of tokens that will never expire. Is there any recommended time?February 10, 2016 at 9:03 am #7682Peter MajorModerator
https://bugster.forgerock.org/jira/browse/OPENAM-5477 was only resolved in 13, 12 will not accept -1 value.
Yes, the tokens will remain in CTS for a really long while. IMO a slightly more secure approach would be instead to use the “Issue new refresh tokens on refresh” setting and have a reasonably long expiration time for refresh tokens.February 10, 2016 at 9:06 am #7683
@peter-major Thanks for the suggestion.
Are these tokens stored in memory or DB/file system? If we restart the servers for some production deployment, will these tokens get cleared forcing the users to login again?February 10, 2016 at 9:56 am #7688Peter MajorModerator
The OAuth2 tokens are stored in the CTS store (OpenDJ). It’s a persistent store, so server restarts will not get rid of the tokens.February 10, 2016 at 1:34 pm #7709Bill NelsonParticipant
The thing to keep in mind, @nkarthik82, is that the access token is a “bearer token” and you should protect it as you would credentials. If the access token is somehow stolen, then the person (or application) that possesses the access token is essentially the original token owner and can use it in the same manner as the token owner. For all intents and purposes, they are the token owner.
The intent of the refresh token is to periodically invalidate the access token thus forcing the bearer to use the refresh token to obtain a new access token. In order to do that, they must use their own set of credentials to log in to the authorization server (i.e. OpenAM) to make the swap. So even if the access token were to fall into the wrong hands, it is short lived and the compromise would be minor.
I totally agree with you, @peter-major, regarding shorter access tokens and longer refresh tokens. Access token lifetimes are typically set in seconds (or minutes). Refresh token lifetimes can then be set at days, weeks, months, or sometimes even years. Making an access token never expire is a high risk; one that I would never take, myself.August 29, 2016 at 8:22 am #12783FirosParticipant
Its a wonderful discussion and very helpful for us.
Actually i was trying to increase access token expiry time.
You must be logged in to reply to this topic.