Re: [OAUTH-WG] Recommendations for OAuth 2.0 with Browser-Based Apps

[Emond Papegaaij <[e-mail]>]

On woensdag 8 mei 2019 22:55:47 CEST David Waite wrote:
> > How would you tie a refresh token to a user session on the AS? This would
> > depend on the user visiting the AS on a regular basis and using a logout
> > button when done. Most people simply close their browser when they're
> > done,
> > leaving the session open. Also, when making a call to the token endpoint
> > to
> > refresh the access token, there is no way of knowing that this call is
> > actually initiated by the user, because it's done on a back channel.
> > Perhaps this can be solved with DPOP with a keypair per browser, but this
> > would really complicate the whole solution.
> 
> Yes, there are still no standard solutions for session keep-alive. There’s
> also not AFAIK a clear solution by the browsers on how to do an implicit
> logout on browser closed, now that browsers may persist sessions cookies.
> 
> I did pitch something about session keep-alive two years ago around this as
> part of DTVA (see
> https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402dd
> 6e8c47/distributed-token-validity-api.txt
> <https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402d
> d6e8c47/distributed-token-validity-api.txt> ), which unfortunately didn’t go
> anyplace. For pure API apps participating in a session keep-alive system, a
> separate “user activity present” API to periodically poke is probably the
> best way to go. For managed devices running enterprise applications, you
> can just have a screen lock rather than tracking session activity at all.

This spec seems to make it possible to keep an active session. However, it is 
bound to OIDC, which will not work in our case. Many of the application we are 
IdP for use SAML. The spec relies on all parties communicating session 
activity. For now, OIDC session management seems to be the best way to go.

> >> Given the choice between an 8 hour access token, or a 10 minute access
> >> token and a refresh token that will expire at a maximum of 8 hours, the
> >> second provides quite a few more options to be more secure. (eg.
> >> checking backing user session and revocation, checking for updates to
> >> client blacklist, the rotation of the access token, rotating refresh
> >> tokens to prevent use by more than one client, expiring access on
> >> inactivity based on lag in refreshing, and so on).
> > 
> > I agree with you on this, but the spec currently states clearly that the
> > AS
> > should not issue refresh tokens to an SPA. Do you think this should be
> > changed to something like: Authorization servers SHOULD NOT issue
> > *offline* refresh tokens to browser-based applications. A refresh token
> > should be tied to a user session on the AS.
> 
> I would like this language changed as well. It is complex due to so little
> existing token lifetime/policy guidance to reference. Previous
> conversations went a bit circular IMHO because of a lack of ground rules.

I can understand. This also highly depend on your use case. Something that 
might work for one application might be totally inappropriate for another.

Best regards,
Emond Papegaaij