Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

[Vittorio Bertocci <[e-mail]>]

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
<https://medium.com/@saivicky2015/why-jwt-shouldnt-be-stored-in-local-storage-aa9aeacc46a0>
.
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 <[e-mail]>
wrote:

> Hi Vittorio,
>
> > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <[e-mail]>:
> >
> > 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 <
> [e-mail]> wrote:
> >
> >
> > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <
> [e-mail]>:
> >
> >> 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 <
> [e-mail]> wrote:
> >> Hi Tomek,
> >>
> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <[e-mail]>:
> >> >
> >> > Hi Torsten,
> >> >
> >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt
> <[e-mail]> 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
> <[e-mail]> wrote:
> >> > >
> >> > >
> >> > > Hi Tomek,
> >> > >
> >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki=
> [e-mail]>:
> >> > > >
> >> > > > 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 <
> [e-mail]> 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=
> [e-mail]> 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 <[e-mail]>
> 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
> >> > > >> [e-mail]
> >> > > >> https://www.ietf.org/mailman/listinfo/oauth
> >> > > >>
> >> > > > _______________________________________________
> >> > > > OAuth mailing list
> >> > > > [e-mail]
> >> > > > https://www.ietf.org/mailman/listinfo/oauth
> >> > > >
> >> > > > _______________________________________________
> >> > > > OAuth mailing list
> >> > > > [e-mail]
> >> > > > https://www.ietf.org/mailman/listinfo/oauth
> >> > > _______________________________________________
> >> > > OAuth mailing list
> >> > > [e-mail]
> >> > > https://www.ietf.org/mailman/listinfo/oauth
> >>
>
>