Tagged: #sessionquota #sessions
March 12, 2020 at 4:24 pm #27736
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.March 26, 2020 at 8:30 pm #27758
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.April 2, 2020 at 3:03 pm #27772
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.April 8, 2020 at 1:27 am #27806
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/revokeendpoint to revoke access tokens. You can observe this in action by visiting AM’s default
Dashboard > Authorized Apps.
Hope this helps!
April 14, 2020 at 6:49 pm #27818
- This reply was modified 2 months, 4 weeks ago by Jatinder Singh.
Thanks Jatinder. I am still studying your email. Let me see what we can do the best.April 16, 2020 at 5:33 pm #27823
If you plan to manually remove these tokens as part of your Logout process, I would try the following (assuming you are using
Register Logout Webhookas part of your tree;
* Create a
onLogoutwhich invokes an auth tree like below:
* In your
logoutTree, you can create a custom
Nodeto attempt to
Hope this helps!
You must be logged in to reply to this topic.