I have a scenario where I would like to limit the lifetime of a refresh token.
So my initial thought was to store a reference to the refresh token on the users meta-data including an expiry time.
If the user uses the refresh token before the expiry time the meta-data is updated with a new expiry time.
If the user uses the refresh token after the expiry time then the token should be revoked and the meta-data reference deleted.
When getting a new refresh token a device credential is created with a unique id.
This Id is also used when revoking a refresh token
A solution could be to store this Id with an expiry time during the “get refresh token” call via rules, but I haven’t found a way to retrieve this Id.
The issue is that I don’t know which refresh token from the list of device credentials that a current token exchange is about. So, the only solution is to revoke all refresh tokens or none
My question is then - is it possible to get the device credential Id associated with the refresh token during the authorize call via rules? Or is there better ways to achieve this refresh token expiry time functionality?
Currently, Auth0 refresh tokens have no expiry and are opaque (it seems you have already figured this out ). We use sessions to track user login and inactivity, and it sounds like you are working on something similar. Does the user session lifetime feature not cover your use-case?
Hi @dan.woda,
I dont think this applies to refresh tokens, at least that’s my experience. The other day I used a 2 month old token to get a new access token - no problem!
From the documentation it says that refresh tokens lives forever until activity revoked! And that’s what I’m trying to do! But I have no reference to the actual refresh token during authorization flow in rules.
That is correct, the user session is via a browser cookie. To clarify, you are not using a browser based flow? Just checking, as this would be a pre-built solution if that were the case.
Looking further into the implementation you described- getting the device credentials in rules -I am not sure that is possible. I can’t find any reference to it, and I don’t see it available in the data coming into rules. At this point, it would probably be best to submit a feedback ticket. I apologize for not having a more robust workaround for you.
Hi @dan.woda,
Well you can say that we initially are using a browser based flow - we are using PKCE to authorize and get a refresh token (and an access token) . After that we only use refresh token to get a new access tokens.
I guess we have to create an enhancement request for some kind of refresh token inactive timeout - similar to the Session Inactivity timeout that you linked to!
Thanks for your time!
). We use sessions to track user login and inactivity, and it sounds like you are working on something similar. Does the