Hi Aaron,
We don't issue refresh_tokens for any implicit flow. So if a browser
based app were to use the code flow, we would issue a refresh_token.
Restricting which clients can receive refresh_tokens (or based on some
other policy) is not a significant addition. However, for most browser
apps, we have a module the relying party can deploy that handles all the
code flow semantics on the server side and then the SPA can just request
a new access_token from the server side module. The module also handles
sessions management.
Personally, I'm not crazy about refresh_tokens being present in
browsers. Browsers should just re-authorize if they can't use a
server-side component for tokens management. OIDC provides a
"prompt=none" mechanism that allows the browser app to request a new
token in a hidden iframe. OAuth2 doesn't describe this flow. Note that
full authentications of users should NOT happen in iframes due to
click-jacking attacks.
Thanks,
George
On 11/20/18 3:56 PM, Aaron Parecki wrote:
Hi George,
Reading this description, am I understanding correctly that you
*always* return a refresh token to every client? Are there any
situations in which a refresh token would not be returned?
Specifically I'm wondering about how this applies to browser-based
apps using the authorization code flow and refresh tokens.
----
Aaron Parecki
aaronparecki.com <http://aaronparecki.com>
On Tue, Nov 20, 2018 at 12:38 PM George Fletcher
<gffletch=40aol....@dmarc.ietf.org <mailto:40aol....@dmarc.ietf.org>>
wrote:
Hi Torsten,
This is the model I much prefer. By default all refresh_tokens are
bound to the user's authenticated session. When the authentication
session is terminated, the refresh_tokens are invalidated. If a
client wants to get a refresh_token that is NOT bound to an
authentication session, then it much explicitly request the
"offline_access" scope which then provides a consent interaction
with the user which allows the user to know that this client wants
to access their resources even when the user isn't logged in
(present). This also provides the AS with the ability to control
which clients are authorized to request "offline_access" and hence
restrict that capability to know/approved clients.
We've implemented this module in two different Authorization Servers.
Thanks,
George
On 11/15/18 9:28 AM, Torsten Lodderstedt 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 <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
