Thank you! On the RT, more questions: - where would you save the RT? Iam thinking of the no-backend case in particular. There’s a lot of heartburn in the community on where to save access tokens already, given the larger scope of refresh tokens I would expect objections there would be exacerbated. The user experience bar (number of prompts, full page redirects) should be the one afforded by implicit leveraging AS sessions via persistent cookies.
- how would we advise developers about handling distributed sign out? If the session cookie with the AS is no longer the only artifact representing the effective session, it looks like we should be prescriptive on what signals an app should listen for (OIDC checkSession?) and what the expected actions are (e.g. remove the cached RTs). I realize this isn’t strictly OAuth2, but it remains an important difference in end to end scenarios people use implicit for today Thx V. On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <tors...@lodderstedt.net> wrote: > > > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci < > vittorio.berto...@auth0.com>: > > Hey Torsten/Tomek, > Can I ask a clarification on the below? > Torsten, you mentioned that an AS doesn't need to issue a RT- the browser > code can just repeat an authorization request. Did I get it right? > But in order to preserve the user experience, that cannot really happen as > a full page redirect; right? That wouldn't fly for any kind of background > update, or for retrieving new ATs for different resources based on the same > session. So would we now use a hidden frame to retrieve a code in the same > way in which we used fragments to get new ATs? > > > That’s what I meant. I also think the RT-based approach is better suited > in terms of UX and security. > > Thx > V. > > On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt < > tors...@lodderstedt.net> wrote: > >> Hi Tomek, >> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <tstoje...@yahoo.com>: >> > >> > Hi Torsten, >> > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> > >> > >> > >> So if I am putting myself in the shoes of somebody who sets out to >> do that - switch an existing SPA client (no backend) >> > >> > > I would like to ask you a question: how many SPAs w/o a backend have >> you seen in your projects? >> > >> > SPA (html+js) utilizing a 3rd party api that requires authorization? >> > If you do have a backend, aren't you better of handling the token >> request on the backend as pointed out here >> > >> https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component >> >> I agree. >> >> > My point of putting (no backend) in parenthesis was to not derail this >> discussion and of course it had the opposite effect. >> > >> >> You know, I you says „don’t look at the green car“ will cause everyone >> looking for it :-) It asked just out of curiosity. >> >> > >> Is that fair or is that too much of a shortcut? I am familiar with >> the specs you've referenced and have looked at them again, but dealing with >> a SPA, some of the recommendations are not feasible (can't authenticate the >> client, >> > >> > > You could using dynamic registration (see other thread). The >> protection would only differ from refresh token rotation if you would use >> public key crypto for client authentication. >> > >> > Good point. How well is dynamic registration supported across AS? >> >> I leave that to the vendors :-) >> >> > >> > >> confidentiality in storage? - not sure how to read that in the >> context of a browser) >> > >> > > How do you ensure confidentiality of session cookies? >> > >> > All I am trying to say is that I think context is important here. So >> when you point out these best practices, some of them will get people >> confused as far as what it means in the browser based app scenario. >> >> That’s why we have the more general Security BCP and client-specific >> BCPs, like for native apps (https://tools.ietf.org/html/rfc8252) and the >> new BCP for SPAs Aaron started to work on. >> >> > Maybe it is just me :) >> >> thanks for raising the question! We need this kind of input to govern the >> development of our specs. >> >> kind regards, >> Torsten. >> >> > >> > > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt < >> tors...@lodderstedt.net> wrote: >> > > >> > > >> > > Hi Tomek, >> > > >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki= >> 40yahoo....@dmarc.ietf.org>: >> > > > >> > > > I agree with Vittorio, Dominick et al. >> > > > >> > > >> I disagree. >> > > > >> > > >> Existing deployments that have not mitigated against the concerns >> with implicit should be ripped up and updated. >> > > > >> > > > Yes, just like future deployments that will not mitigate against >> the concerns of code in the browser should be a concern. >> > > >> > > I agree. That’s why I pointed point yesterday that the Security BCP >> also defines obligations for clients using code. >> > > >> > > >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1 >> > > >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1 >> > > >> > > > >> > > > Can somebody on the other side of the argument (and I hate to make >> it sound like there are two sides, because we're on the same side as far as >> Implicit's AT in front-channel is a real issue) address Dominic's comment: >> > > > >> > > >> Also - simply saying “implicit is evil - switch to code” means for >> most people also using refresh token - so we are treating access tokens in >> the URL with refresh tokens in session storage (over simplified - but you >> get the idea). >> > > > >> > > > Does the group agree|disagree that a recommendation to switch to >> code should be made as long as it is followed by an explanation and >> guidance on what to do with RTs? The ideas that were floated around >> > > > - Token bound RTs (even though it was pointed out that token >> binding is still considered an emerging standard). So should the >> recommendation than say "switch to code and MUST use token bound RTs"? >> > > > - Have AS not release RTs. "Switch to code and DO NOT request RTs"? >> Or switch to code and configure AT to not release RTs for this type of >> client (not sure what that even looks like in a form of a 3rd party >> clients)? >> > > > - RTs short lived and bound to a session - "Switch to code as long >> as AT can bind and revoke RTs when you log out“ >> > > >> > > Basically, the AS does not need to issue refresh tokens. If the AS >> does not issue refresh tokens, the integration pattern for SPAs does not >> change (beside the code exchange). If the client needs a new access token, >> it will perform another authorization request. >> > > >> > > If it does, this adds another layer of security because it allows the >> client to frequently obtain new access tokens, which can be short-lived and >> scope restricted. >> > > >> > > The refresh tokens should be replay protected by issuing new refresh >> tokens with every refresh and detect replay for refresh tokens belonging to >> the same grant. >> > > >> > > The AS may additionally bind refresh tokens to AS sessions, but as it >> was pointed out by Annabelle and others, there are some implications to be >> understood and managed in that context. >> > > >> > > You may find more text about refresh tokens in the Security BCP >> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12 >> > > >> > > kind regards, >> > > Torsten. >> > > >> > > >> > > > >> > > > Sorry if I have missed an important detail from the list above, >> people who have proposed these ideas, feel free to clarify. >> > > >> > > > >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt < >> dick.ha...@gmail.com> wrote: >> > > > >> > > > I disagree. >> > > > >> > > > Existing deployments that have not mitigated against the concerns >> with implicit should be ripped up and updated. >> > > > >> > > > For example, at one time, I think it was Instagram that had >> deployed implicit because it was easier to do. Once the understood the >> security implications, they changed the implementation. >> > > > >> > > > BCPs are rarely a response to a new threat, their are capturing >> Best Current Practices so that they become widely deployed. >> > > > >> > > > >> > > > >> > > > >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell= >> 40pingidentity....@dmarc.ietf.org> wrote: >> > > >> FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are >> saying here. And that was kind of behind the comment I made, or tired to >> make, about this in Bangkok, which was (more or less) that I don't think >> the WG should be killing implicit outright but rather that it should begin >> to recommend against it. >> > > >> >> > > >> I'm not exactly sure what that looks like in this document but >> maybe toning down some of the scarier language a bit, favoring SHOULDs vs. >> MUSTs, and including language that helps a reader understand the >> recommendations as being more considerations for new >> applications/deployments than as a mandate to rip up existing ones. >> > > >> >> > > >> >> > > >> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <ve7...@ve7jtb.com> >> wrote: >> > > >>> >> > > >>> We just need to be sensitive to the spin on this. >> > > >>> >> > > >> >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and >> privileged material for the sole use of the intended recipient(s). Any >> review, use, distribution or disclosure by others is strictly >> prohibited... If you have received this communication in error, please >> notify the sender immediately by e-mail and delete the message and any file >> attachments from your computer. Thank >> you._______________________________________________ >> > > >> OAuth mailing list >> > > >> OAuth@ietf.org >> > > >> https://www.ietf.org/mailman/listinfo/oauth >> > > >> >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > OAuth@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/oauth >> > > > >> > > > _______________________________________________ >> > > > OAuth mailing list >> > > > OAuth@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ >> > > OAuth mailing list >> > > OAuth@ietf.org >> > > https://www.ietf.org/mailman/listinfo/oauth >> >>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
