OAuth2 – Default expiration time for Access token and refresh token

Tagged: ,

This topic has 7 replies, 5 voices, and was last updated 6 years, 1 month ago by Firos.

  • Author
    Posts
  • #7676
     nkarthik82
    Participant

    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?

    #7677
     Rajesh R
    Participant

    @nkarthik82 Please see if the default values that you are looking for are available at the documentation link below:

    https://backstage.forgerock.com/#!/docs/openam/current/reference/chap-config-ref#oauth2-provider-configuration

    #7678
     nkarthik82
    Participant

    @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?

    #7682
     Peter Major
    Moderator

    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.

    #7683
     nkarthik82
    Participant

    @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?

    #7688
     Peter Major
    Moderator

    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.

    #7709
     Bill Nelson
    Participant

    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.

    #12783
     Firos
    Participant

    Its a wonderful discussion and very helpful for us.
    Actually i was trying to increase access token expiry time.

Viewing 8 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?