Hi, Thanks for your detailed reply. I've replied inline.
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> wrote: > > For a browser-based app, we try to follow the recommendations set in > > draft- > > ietf-oauth-browser-based-apps-01. This does allow us to create a secure > > OAuth 2.0 browser-based application, but at the moment it comes at a cost > > wrt. user experience when the access token expires. Our current solution > > forces us to redirect the user to the authorization server for a new > > authorization code. This will destroy most state the browser-based app > > has, causing the user to loose data. We are looking for a way to get a > > new access token in a secure way without disrupting the user. > > As a refresh token is not issued to the app (as it should be), the > > application is forced to do a front-channel re-authentication for an > > authorization code. We are thinking of letting this front-channel > > communication happen in a hidden iframe. Naturally, this can only be done > > if no user interaction is required, hence we want to use the OIDC > > prompt=none. Is this a viable way of doing this re-authentication? Can it > > hurt to open up our authorization server for non- interactive > > authorization requests inside an iframe? At the moment we do not allow > > iframes at all. > > Some AS implementations will block authentication in an iframe, but will > allow you to use the OIDC prompt=none. This is already used quite often > today by implicit apps. It is possible that AS implementations may allow > iframes in the future, by detecting the frame is not covered with any > buttons, and having the authentication be based on phishing-resistant > authentication methods like W3C Web Authentication. Fortunately for us, we build the AS as well, so we are in control here. It is a bit unfortunate that this does depend on OIDC. Doing user interaction in an iframe seems like a snake pit I'd rather not go into. I think it's also bad wrt the user interaction. We do not want user to enter their credentials on any site that looks like our AS. Users should only enter their credentials when the URL matches or AS. > 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. > 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. > 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. > If the refresh token is tied to the AS concept of user session, then it > mostly replaces the ‘hidden iframe’ use above - you’ll only have your > refresh token expire when the AS is asking for user presence on the front > channel, presumably for interaction. Although, I suppose in some > environments there could be a non-interactive reauthentication/factor as > well (such as kerberos, MTLS, or re-verifying user location via geoip) > where a hidden iframe might still provide UX benefit. In our case or AS might have to federate the authentication to some other AS, that would only work in an iframe. Therefore, I think we will go for the OIDC prompt=none in a hidden iframe. I'm not sure what to do if the AS reports that interaction is required, but at least the majority of the cases will be covered. Best regards, Emond Papegaaij _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
