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

[Vittorio Bertocci <[e-mail]>]

Thanks Torsten.
As another meta comment, in general I am not disagreeing with the guidance-
I just think that the language we use should make it easier for
practitioners to understand what they are supposed to do to put this
guidance in concrete terms. That includes better clarifying risks, opening
acknowledging when the recommended remedies aren't likely to be viable in
the short term (as we do with TB) and emphasizing guidance that can be
widely applied today (for example, mentioning both the use of hidden
frame+code for token renewals and use of RTs, but highlighting the factors
that make the latter hard to use at this time).
Also; I apologize for the length. I think we are approaching the point in
which using email as collaboration tool might become inadequate. I am happy
to hop on a call if that helps.

> This requires the respective solutions to support response type
code/grant type authorization code (lib & AS), PKCE (lib & AS) and CORS
(AS) for public clients.

I am not as worried about those, as support for those is already widespread
(as they are required for other scenarios). The thing I was focusing in
that mail in particular was the features required for making the use (and
above all, storing) of RTs in the browser. As discussed, those features
aren't widely available hence I feel any guidance to app developers (as
opposed to provider) should warn them about it and probably emphasize more
the risks associated to it (eg XSS). The scenario I am worried about is
people feeling this gives them license to use RTs in the browser even when
those mitigations aren't available.


>  The reality is, most people don’t care about security and most practices
I have seen are more on the bad practice end. So what shall we do? Sit on
our hands?

Again, I am not suggesting inaction. I am only concerned about ensuring
that developers reading this have a clear idea of what's directional (where
we think the world should go) and what's practical (what is achievable with
the mainstream feature set today). Vendors verifying that what is being
proposed here can be achieved with their feature set is the first step to
distinguish between the two, and help setting the right expectations on how
actionable the guidance is today. Those findings won't change what we
suggest as directional, but might change expectations on what developers
can do today, hence the tone and the language we use.


> The measures I propose have been implemented and used in production for
years at Deutsche Telekom (consumer services, millions of unique users).

I am not saying that those features are not implementable. I am saying that
they might not be available for developers. The fact that DT implemented
those measures will not help at all the developer maintaining a SPA app
that must work with the Google or Microsoft AS because that's the API
ecosystem they took a dependency on. Either the new guidance they receive
is feasible on those platforms, or they are stranded in no man's land where
they can't keep their current approach (ignoring for a second the
urgency/why now discussion we had earlier) AND they can't implement the new
one because they can't change vendor ecosystem overnight.
In practical term, the above for me means prototyping the new guidance and
incorporating the finding in the document. To pick on the same example, if
we find that most vendors can use code+hidden iframe for token renewal
while few support rotating RTs, guidance should clarify that.


> I don’t ignore XSS. I want to solve the problems one after the other
focussing on OAuth related stuff first. Switching from implicit to code
solves leakage and injection in OAuth protocol messages.

I don't think the two things are mutually exclusive or need sequencing. We
can recommend switching to code without necessarily bringing RTs into the
picture.
My main point is, if we do bring them in the picture, we should be careful
to list the caveats that come with it.


> Browser-based clients are just one client categories. Ensuring the
confidentiality of tokens is always a very client platform specific
matter.

I see. Non browser platforms already store refresh tokens locally, I
personally spent a good decade dealing with that on multiple OSes and the
approach is in use in many of the most used applicaitons on the planet.
For Occam razor, in this discussion I am mostly concerned about doing that
in the browser as it is a scenario as the guidance has always been to never
use RTs in Javascript, hence that's the area where I feel clarification is
needed. That doesn't mean that the rest is uninteresting: but again for
Occam razor, the existence of keychain on iOS or of DPAPI on Windows does
little to mitigate the discussion on XSS.


> Can you give a concrete example? To me it feels like you are explaining
scenarios where OAuth is used for login.

That's one of the scenarios of interest here. We can debate on whether
that's proper or not, but the practical consequence is that if I have two
(or N) apps that can call APIs via tokens obtained with the implicit flow,
eliminating AS the session cookie will prevent them from getting new tokens
automatically, without the developer having to write any code for "signout".
The moment in which apps switch to code and hold on to RTs, the sheer fact
that the AS session cookie is gone will NOT stop individual apps from being
able to get new access tokens and call API.
That would be an unintended consequence of the switch to code, and
regardless of whether it's a consequence of people abusing the protocol or
not, I think this scenario should be documented and people should be warned
against it.


> Are you assuming the AS revokes the AT on logout? Otherwise the other app
will realize the session termination when it attempts to obtain a new AT in
another authorization flow.

All the ASes I have worked on try to be as stateless as possible, and won't
revoke ASes in logouts.


> Revoking the RT on logout is the proper solution for OAuth.

Perhaps, but again in my experience with mainstream providers, that doesn't
happen. The fact that it would be the correct behavior in theory doesn't
change the risk in the wild, and what i am most concerned about is to help
developers avoid suffering unintended consequences as we exercise existing
products in new ways and those discrepancies come out.


>Are those RT’s request for offline_access? Then I would argue this
behavior is just fine and inline with the way OAuth is intended to work.

This is another excellent example of differences between theory and
practice. Products providing AS functionality won't typically make a very
crisp subdivision between OAuth2 and OIDC features- it's the same
endpoints, solving similar scenarios. For some of the mainstream providers,
requesting offline_access is the ONLY way to get a refresh token, no matter
whether you are trying to use OAuth2 or OIDC. That means that the offline
usage (as opposed to session) is the ONLY semantic attributed to refresh
tokens issued by those providers. Once again we can argue about the sins of
the product designers who crafted things that way, but our first
responsibility, I believe, should be toward the developers and toward
helping them to do the right thing in the environment they operate. Not
saying we need to give guidance for each vendor (that's the vendor's job)
but I do think we need to think through those details and give the proper
headsup ("beware: your AS might issue RTs that keep working even when the
session originating them is long gone, hence please make sure to keep an
eye on the session status (checkSession etc) and to dispose of all the RTs
when you detect that the session is gone" or "make sure that, when you
request an RT from a SPA, you use whatever switch your vendor requires to
have session bound RTs rather than offline_access ones. Your vendor don;t
offer that option? See the other sentence").


> You mean discard the RT or revoke it explicitly on the app side?

I mean discard the RT on the app side.


>The scope offline access exists (although in the OIDC universe). Don’t you
think it could be used for that purpose?

See above. For various vendors, offline_access is the only way of
requesting a RT hence it can;t be used as a differentiation between offline
and session RTs.


On Sat, Dec 8, 2018 at 5:12 AM Torsten Lodderstedt <[e-mail]>
wrote:

> Hi Vittorio,
>
> > Am 06.12.2018 um 19:09 schrieb 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 agree. That’s what basically happened with mTLS and Token Binding. We
> realized the need to find a reasonable way to prevent token replay in the
> course of our in-depth security analysis. Out of the two options (audience
> restriction and sender constrained tokens), we selected sender constrained
> tokens because they are the most appropriate measure (or just "build for
> that purpose" as Dirk Balfanz pointed out at that time). Token Binding
> unfortunately lost some traction but mTLS can be used instead and is being
> used in the open banking space by all initiatives I’m aware of (UK OB,
> STET, BerlinGroup). So we were right on time.
>
> I see the same happening with respect to implicit and SPAs now. I think
> the baseline is clear: implicit is replaced by code+PKCE, so SPAs need to
> be extended to handle PKCE and exchange the code for an access token. This
> step is a huge security improvement since it closes the attack angle of
> leakage and injection/replay via the URL.
>
> This requires the respective solutions to support response type code/grant
> type authorization code (lib & AS), PKCE (lib & AS) and CORS (AS) for
> public clients.
>
> > 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.
>
> I understand your argument and I would be happy to just document best
> security practices. The reality is, most people don’t care about security
> and most practices I have seen are more on the bad practice end. So what
> shall we do? Sit on our hands?
>
> In my observation, the SPA OAuth universe to a large extend developed
> completely independent of the rest of the OAuth universe. For example, I
> saw SPA libraries recommending implicit and the resource owner credential
> grant. Wow! What a mixture when combined with XSS!
>
> I think we can transfer some proven techniques from the general OAuth
> world into the SPA OAuth world, e.g. code & PKCE. Add CORS to that and we
> have a reasonable baseline for SPAs, which copes with the particular
> threats implicit is vulnerable to. One hole closed, great!
>
> Opening the picture a bit, we must realize token leakage also happens at
> resource servers, that's why we included the recommendation for sender
> constrained tokens to the BCP (for _all_ kinds of clients!).
>
> mTLS works well for native and web apps. It won’t work well for SPA’s
> simply because the SPA cannot automatically setup a cert in the browser, so
> it would need an external enrollment process. It will also result in a poor
> UX due to selection dialogs etc. Token binding would be the much better
> solution but lacks adoption.
>
> That’s why I think refresh tokens should be considered at least as a means
> to limit the impact of access token leakage at RSs. The measures I propose
> have been implemented and used in production for years at Deutsche Telekom
> (consumer services, millions of unique users). I also think Oath
> implemented RT revocation on logout. But I also realized commercial vendors
> and other deployments seem to have less sophisticated implementations in
> place. So where does this leave us? Running code exists but more vendors
> must support these features. One could also say: What are ideas for some
> people is proven practice for others.
>
>

>
> > 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.
>
> I don’t ignore XSS. I want to solve the problems one after the other
> focussing on OAuth related stuff first. Switching from implicit to code
> solves leakage and injection in OAuth protocol messages.
>
> XSS can be solved in a sustained fashion using browser features only. If
> an app includes code from untrusted locations then this code can access all
> browser APIs from the SPAs origin. Nothing will stop an attacker from
> accessing local storage, web crypto API etc on behalf of the API. So yes,
> SPAs need to implement proper XSS protection - independent of OAuth. Jim
> already posted an advice on this topic.
>
> >
> >
> > >  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?
>
> In this discussion, the platform is the browser.
>
> But my focus is not on browser clients only. I’m editing (along with John,
> Daniel and Andrey) the OAuth Security BCP. So I’m looking into
> recommendations for all sorts of OAuth clients/deployments and want to make
> sure a reasonable common security level. That’s why the place where the
> access tokens are ultimately used (the RS) and can leak and be replayed
> also concerns me.
>
> Browser-based clients are just one client categories. Ensuring the
> confidentiality of tokens is always a very client platform specific matter.
> It works differently on iOS than on Windows 10 and requires platform
> expertise and dedicated documentation (which would bloat the Security BCP).
> That’s why there is need for client type specific BCPs. We have one for
> native apps and now work is being done towards a SPA BCP. That’s where this
> kind of consideration should land.
>
> >
> >
> > > 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.
>
> Depends on AT lifetime. With RTs you can have  very short ATs lifetime
> further reducing the attack window. The AT lifetime should be determined by
> the respective RSs sensitivity.
>
> > 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.
>
> It’s a good idea to conduct a survey regarding existing RT implementation
> practices. I’m under the impression vendors so far underestimated the value
> of RT when it comes to limiting the impact of token leakage. That’s one
> reason why I added the RT section to the Security BCP.
>
> >
> > > Interesting question :-) I think login and API access are quite
> different.
> > Once again, this is very theoretical :)
>
> Oh, I just tried to address your arguments with what I consider a
> substantial answers :-).
>
> > 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“.
>
> Can you give a concrete example? To me it feels like you are explaining
> scenarios where OAuth is used for login.
>
> > 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.
>
> Are you assuming the AS revokes the AT on logout? Otherwise the other app
> will realize the session termination when it attempts to obtain a new AT in
> another authorization flow.
>
> > 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.
>
> Revoking the RT on logout is the proper solution for OAuth.
>
> >
> > > 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.
>
> Are those RT’s request for offline_access? Then I would argue this
> behavior is just fine and inline with the way OAuth is intended to work.
>
> > 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.
>
> You mean discard the RT or revoke it explicitly on the app 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.
>
> The scope offline access exists (although in the OIDC universe). Don’t you
> think it could be used for that purpose?
>
> kind regards,
> Torsten.
>
> >
> >
> > 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
> > >>
> >
>
>