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

[David Waite <[e-mail]>]

> On May 8, 2019, at 1:37 AM, Emond Papegaaij <[e-mail]> wrote:
> 
> On maandag 6 mei 2019 22:42:09 CEST David Waite wrote:
>> On May 6, 2019, at 1:42 PM, Emond Papegaaij <[e-mail]> 
> 
>> You could also trigger re-authorization with a user click, thus allowing
>> opening the AS in a new window or tab. Once back on the site via callback,
>> the temporary/pop-up window can do things like exchange the code for an
>> access token, persist it, postMessage the original window, do window.close,
>> etc.
> 
> This would work, but would really be a nuisance to the user. Especially with a 
> token timeout of just one hour. Also, most of the times there would be no 
> interaction, the user would just have to click a button. As a user I wouldn't 
> understand why I have to do that all the time.

You do have this for native apps as well, however: app-auth-sso-ios-11-blog.png <https://www.pingidentity.com/content/dam/pic/images/managed/app-auth-sso-ios-11-blog.png>

> 
>> On the other hand, refresh tokens IMHO are given quite a bit more fear in
>> browser apps than warranted. It really depends on the AS - whether it can
>> tie refresh tokens to the user’s authentication, or if they are tied to a
>> long-term / persisted / "offline” authorization independent of an active
>> user authentication. Currently, the latter is more common in
>> implementations, and doesn’t make sense for browser applications. This
>> doesn’t mean refresh tokens are automatically discounted for all
>> environments.
> 
> 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/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/distributed-token-validity-api.txt <https://bitbucket.org/openid/connect/src/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/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.

For handling browsers in shared user environments which lack non-persistent cookies, you typically have to rely on session keep-alive/inactivity timeout and logout (which in OAuth would map to a token revocation)
 
>> 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.

-DW