configure session lifetime with session quota

This topic has 5 replies, 2 voices, and was last updated 2 months, 2 weeks ago by Jatinder Singh.

  • Author
    Posts
  • #27736
     ranjit
    Participant

    Hi,

    My mobile app has gotten 3 tokens (id, access and refresh) from FR after authenticating with FR through web-view opened from mobile-app with the help of AppAuth library.
    This resulted into server-side session in FR whose expiry time is 120 min.

    Once 120 min. are elapsed my understanding is FR does not have any information about this session.
    However, my mobile app will still keep working and keep getting new access-tokens by exchanging refresh tokens without any problem as long as those tokens are not expired. All tokens are CTS-based (i.e., server-side)

    If I am correct so far then I have one question.
    If I have configured the session limit of 1 session per user, then is it fair to say that after 120 min. (when the session expires) I am free to open the same mobile app from another phone and sign-into using the SAME ID ?
    Basically, now user can work from 2 phones.

    Thanks.

    #27758
     Jatinder Singh
    Participant

    Yes, after 120 mins the user would be able to sign-in using the same user id on a different device. That said, the same user can still login from a different device within the 120 mins window – but in that case a new session will be created destroying the old session. There are different configurations available for the session quota feature.

    Deny Access. New session creation requests will be denied.
    Destroy Next Expiring. The session that would expire next will be destroyed.
    Destroy Oldest. The oldest session will be destroyed.
    Destroy All. All previous sessions will be destroyed.

    #27772
     ranjit
    Participant

    Got it. Thanks Jatinder. Looks like we are on the same page.

    So the only question is, is there any way we can restrict and stop the creation of the second session until the access-token and refresh-token attached with the first session are totally wiped out from FR

    I understand, out-of-the box FR does not provide solution, but is there any custom plug-in (similar to pre/post auth plugin) that we can develop which
    Logically will check if there is already any unexpired refresh token in CTS attached with that user for whom a new session is getting created. If yes, just deny that request.

    Thanks.

    #27806
     Jatinder Singh
    Participant

    It seems like you want the access_token to live short lifespan. If that indeed is the case, I would suggest to set shorter lifetime for your access_token and perhaps not issue a refresh token at all. IMHO – coupling the revocation of OAuth2 tokens with logout is opening a can of worms (and leading to security issues). For example, how would you handle a scenario where there are multiple clients, your logout would need to know all of the client ids along with their secret (security issue) or bearer tokens (based on your configuration). And if you issue an LDAP modify operation to delete these tokens manually – you may not be able to audit these events leading to compliance issues.

    The token can either be revoked by the client or resource owner itself. With that in mind – user via your app or client can call AM’s oauth2/token/revoke endpoint to revoke access tokens. You can observe this in action by visiting AM’s default Dashboard > Authorized Apps.

    Hope this helps!

    #27818
     ranjit
    Participant

    Thanks Jatinder. I am still studying your email. Let me see what we can do the best.

    #27823
     Jatinder Singh
    Participant

    No worries.

    If you plan to manually remove these tokens as part of your Logout process, I would try the following (assuming you are using Auth Trees):

    * Configure Register Logout Webhook as part of your tree;
    * Create a Webhook called onLogout which invokes an auth tree like below:

    https://identity.forge.local:8443/openam/json/realms/root/realms/ciam/authenticate?authIndexType=service&authIndexValue=logoutTree

    * In your logoutTree, you can create a custom Node to attempt to delete CTS entries.

    Hope this helps!

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

You must be logged in to reply to this topic.

©2020 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?