Fwiw, this is something I thought about for Ozwillo but never ended up implementing (though that still could happen): always issuing a refresh token (vs. only when scope includes offline_access nowadays) but bind its lifetime to the session when not offline_access. I would then revoke the refresh token on logout (like I already do for access tokens), on session timeouts (this would mean, for me, extending the refresh tokens' expiry whenever I extend the session expiry), or whenever the session is terminated (e.g. password change). The reason I was contemplating this is that some clients/RPs find it hard to integrate their apps with OpenID Connect / OAuth because they need to redirect the users to "refresh" the access tokens, and this is not practical when processing a POST request (e.g. form submission). The reason I haven't done it yet is that it's been a while since I heard back from clients on that topic ;-) (though most of them actually simply use OpenID Connect, and don't make calls to protected resources afterwards). Others might be using Session Management (will have to check logs, though I doubt it), which means always having a valid access token as a side-effect.
On Thu, Nov 15, 2018 at 3:28 PM Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > Hi all, > > I‘m preparing a new section on Refresh Token best practices for the > Security BCP. I‘m wondering whether anyone has implemented a binding of the > refresh token‘s expiration/revocation with the state of the session the > refresh token was issued in/for. So do you revoke refresh tokens when the > user logs out from the AS or the session terminated for other reasons? > > kinds regards, > Torsten._______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
