While I generally agree with justin that moving everything to the back channel is good, I worry that checking user login state may be more important.
What if upon refresh of a javascript client the AS would like to check the validity of the current user session? Many implementers solve the user experience issue by using prompt none in the oidc authentication case. I seem to remember some oauth providers never implemented refresh and they were able to create a good experience. Phil > On Dec 6, 2018, at 10:09 AM, Vittorio Bertocci > <Vittorio=40auth0....@dmarc.ietf.org> wrote: > > Thank you Torsten. > I think that a lot of the considerations below need to be tempered with > concrete considerations about the features developers can actually rely on > today. > I agree with identifying the theoretical framework and north star we want to > aspire to, but if we are framing the recommendation here in form of practice, > we have to ensure it is actionable for developers. I am not pushing back on > ideas, but I just want to make sure that when customers hear this advice, > they are actually in the position to apply it. And if there are missing > pieces, perhaps we should consider this more as guidance to the vendors that > need to provide key enablers for this to become viable, and recommend it as > practice to customers only when that happened. > I add more details inline below, however I have a meta point to make: did all > the vendors on the list work on proof of concepts to ensure that the > practices recommended here can work with your product, end to end? > I don't mean just doing a code+PKCE demo in JS, I mean complying with things > like RT rotation and revocation end to end, using released features that your > customers can use today. If you did, it might really help to use them to make > those discussions more concrete. If you didn't, then calling the proposal a > practice might be premature. > inline: > > > > Regarding protection at rest: what’s the attacker model in those > > discussions? XSS? Local attacks on the device? > The main concern is XSS. You can just google token session storage to find an > onslaught of articles and forum threads on the topic. To pick one at random, > here's the one from Mozilla. > We can argue on what's worse between XSS and URL leaks, but I don't think we > can ignore the pervasive ongoing debate and perception that use of local > storage for sensitive data is bad. > > > > Much of the mechanisms are platform specific and need platform expertise. > I don't follow this one. We are targeting the browser, right? What are the > platform specific features you are thinking about? > > > > From the OAuth protocol perspective, impact of RT leakage can be limited > > through rotation. So I would argue RTs are better protected than ATs. > AFAIK relatively few providers today offer RT rotation (Microsoft is an > example of widely adopted provider who doesn't), and even if they do: if you > steal an RT and use it to get an AT you will enjoy full AT use until the > legitimate client attempts a refresh, which will be typically at near expiry > time, hence gaining very little. And given that even fewer providers offer > access token revocation as a consequence of attempted RT reuse, even more > frequent refresh attempts won't reduce the time the attacker has to use the > access token they obtained. Hence I am not sure I buy the argument that RTs > are better protected than ATs, both from the theoretical perspective and the > practical one. And in practical terms, if a developer is tied to a provider > that doesn't offer full RT rotation asking them to store RTs will make them > worse off than they are today. I am of course all for encouraging providers > to introduce proper RT rotation support, but until they do developers > receiving this guidance TODAY will be stuck between a rock and a hard place. > > > Interesting question :-) I think login and API access are quite different. > Once again, this is very theoretical :) you, myself and the cohort on this > lost can appreciate the difference between the two scenarios- but from most > practitioners without identity background, sign out is "the user can't use > the app anymore until they enter their credentials again". Whether they > implement a proper sign in or go straight to API calling, the visible effect > they want to achieve is that one. With implicit today, the access is all > predicated on a single artifact- the provider session cookie. If I have two > apps in two tabs, signing out from one automatically robs the other from the > ability to retain continued access. By introducing another artifact that can > provide continued access and whose existence is independent from the session > cookie, either I explicitly manage the lifecycle of that artifact (by > deleting it at the right time) or my app will simply be able to continue > accessing API regardless of the fact that my session with the OP ended. > > > In the API case, the AS can just revoke the RT when the logout happens. > That's just not how that works for many of the big providers, and without > introducing new switches I don't think it should. RTs are issued for offline > access purposes, hence their lifetime can (and often will) exceed the > lifetime of sessions. Borrowing from classic web scenarios, I can sign in and > out of twitter as much as I want- that should not affect twitter's ability to > call APIs even when I don't have a current session. That's the canonical use > case I think of when thinking of RTs. > The challenge with SPAs is that successfully calling APIs is often used in > lieu of proper sign in; we can repeat until we're blue in the face that this > leaves apps prone to confused deputy and the like, but in practice people > will keep doing it because to the non-initiated that makes intuitive sense. > Hence either we introduce a switch that tells the AS that the RT we are > asking for needs to be tied to the session, and manage revocation > accordingly, or we manage the persistence of the RT at the application side. > The latter seems much easier to achieve to me, and above all more immediately > actionable given that I doubt providers will be very prompt in introducing > new features like the one hypothesized here. > > >> On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> 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 >> >> >> > _______________________________________________ > 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
