Hi Vittorio, > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <vitto...@auth0.com>: > > 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.
Interesting, I’m much more concerned about tokens transmitted in URLs since those tokens are vulnerable to remote attacks. Regarding protection at rest: what’s the attacker model in those discussions? XSS? Local attacks on the device? Much of the mechanisms are platform specific and need platform expertise. From the OAuth protocol perspective, impact of RT leakage can be limited through rotation. So I would argue RTs are better protected than ATs. > The user experience bar (number of prompts, full page redirects) should be > the one afforded by implicit leveraging AS sessions via persistent cookies. sure. I don’t see any technical difference in the way the browser is utilized for both flows and therefore would be surprised to see differences in UX. > > - 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 Interesting question :-) I think login and API access are quite different. In login the client potentially wants to tightly couple its session lifecycle to the AS/OP session, simply because it relies on the user id attested by the OP’s for its local user/session management. For API access, this is not needed. The client „just“ obtains a credential to access certain APIs on behalf of the resource owner. The identity of the resource owner on the AS side and the identity of the client user don’t necessary have a relationship. As you know, OAuth was intentionally built to hide the resource owner identity from the client. I think in this case the resource owner or the AS might have an interest to terminate API access in case of logout at the AS. Protocol-wize this result in huge differences: In the login case, the client can check the session with the OP periodically and terminate its own session in case the identity changed or there is no longer a session. This typically requires frontend interactions and OpenID Connect (session mgmt or logout). In the API case, the AS can just revoke the RT when the logout happens. kind regards, Torsten. > > 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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
