> 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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
