> On May 8, 2019, at 1:37 AM, Emond Papegaaij <emond.papega...@gmail.com> wrote:
>
> On maandag 6 mei 2019 22:42:09 CEST David Waite wrote:
>> On May 6, 2019, at 1:42 PM, Emond Papegaaij <emond.papega...@gmail.com>
>
>> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
