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

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 1 Dec 2018 09:06:24 +0000

I agree with Aaron here and I think Section 3.8.1.2<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2> of draft-ietf-oauth-security-topics-10  already does a pretty good job.
I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don’t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*.

Am I misunderstanding it?

Ciao
Hannes

PS: The IoT case is likely different.

From: OAuth <[email-masked]> On Behalf Of Aaron Parecki
Sent: Saturday, December 1, 2018 3:18 AM
To: Torsten Lodderstedt <[email-masked]>
Cc: Daniel Fett <[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1

I would also like to ensure there is a clear definition of "sender constrained" tokens in this BCP.

Aaron

On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

based on your feedback on the list and off list, Daniel and I polished the text. That’s our proposal:

—
In order to avoid these issues, clients MUST NOT use the implicit
grant (response type "token") or any other response type issuing access
tokens in the authorization response, such as "token id_token" and "code token id_token“,
unless the issued access tokens are sender-constrained and access token injection in
the authorization response is prevented.
—

Explantation:
- we wanted to have the right balance between a generic definition of the response types we do not recommend/allow to be used and a concrete/actionable list of the affected response types.
- we changed from SHOULD NOT to MUST NOT as suggested by Nat and supported by William

We look forward to seeing your feedback.

kind regards,
Torsten.

> Am 29.11.2018 um 15:15 schrieb John Bradley <[email-masked]<mailto:[email-masked]>>:
>
> I am ok with that.
>
> On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]> wrote:
>
> > Am 28.11.2018 um 23:50 schrieb n-sakimura <[email-masked]<mailto:[email-masked]>>:
> >
> > That works.
>
> Good!
>
> I just realized this text has an issue with „token“ (only). It would allow „token“ to be used if the token would sender constrained. This completely ignores the fact implicit also shall be abandoned because of its vulnerability for access token injection.
>
> I therefore propose a modified text:
>
>    In order to avoid these issues, Clients SHOULD NOT use the implicit
>    grant. Furthermore, clients SHOULD only use other response types causing the authorization server to
>    issue an access token in the authorization response, if the particular response type detects access token
>    injection and the issued access tokens are sender-constrained.
>
> Or we just state:
>
>   In order to avoid these issues, Clients SHOULD NOT use the response type „token". The response types
> „token id_token“ and „code token id_token“ SOULD NOT be used, if the issued access tokens are not
> sender-constrained.
>
> >
> > In fact, I would further go and say MUST NOT but that probably is too much for a security consideration.
> >
>
> Mike suggested to go with a SHOULD NOT to get the message out but give implementors time to move/change.
>
> > Best,
> >
> > Nat
> >
> > Nat Sakimura / [email-masked]<mailto:[email-masked]> / +81-90-6013-6276
> >
> > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。
> >
> > PLEASE READ :This e-mail is confidential and intended for the named recipient only.
> > If you are not an intended recipient, please notify the sender and delete this e-mail.
> >
> > 差出人: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
> > 送信日時: 水曜日, 11月 28, 2018 11:38 午後
> > 宛先: n-sakimura
> > Cc: Dick Hardt; Hannes Tschofenig; [email-masked]<mailto:[email-masked]>
> > 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> >
> > Hi Nat,
> >
> >> Am 28.11.2018 um 21:10 schrieb n-sakimura <[email-masked]<mailto:[email-masked]>>:
> >>
> >> I would support
> >>
> >> 1) clearly defining Implicit as the flow that returns access token from the authorization endpoint ( some people confuses implicit as the flow that returns ID Token in the front channel)
> >
> > That’s the current text:
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response.
> >
> > What would you like to modify?
> >
> >>
> >> 2) Banning the returning of the access token that are not sender constrained from the authorization endpoint
> >
> > In order to avoid these issues, Clients SHOULD NOT use the implicit
> >    grant or any other response type causing the authorization server to
> >    issue an access token in the authorization response, if this access tokens is not sender-constraint.
> >
> > What about this?
> >
> > kind regards,
> > Torsten.
> >
> >>
> >> Best,
> >>
> >> Nat
> >>
> >>
> >> Outlook for iOS を入手
> >>
> >> 差出人: OAuth <[email-masked]<mailto:[email-masked]>> (Dick Hardt <[email-masked]<mailto:[email-masked]>> の代理)
> >> 送信日時: 水曜日, 11月 28, 2018 8:58 午後
> >> 宛先: Hannes Tschofenig
> >> Cc: [email-masked]<mailto:[email-masked]>
> >> 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit
> >>
> >> +1
> >>
> >> While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic.
> >>
> >> How about we recommend against using implicit alone?
> >>
> >>
> >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
> >> Hi all,
> >>
> >> The authors of the OAuth Security Topics draft came to the conclusion that it is not possible to adequately secure the implicit flow against token injection since potential solutions like token binding or JARM are in an early stage of adoption. For this reason, and since CORS allows browser-based apps to send requests to the token endpoint, Torsten suggested to use the authorization code instead of the implicit grant in call cases in his presentation (see https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
> >>
> >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list.
> >>
> >> Please provide a response by December 3rd.
> >>
> >> Ciao
> >>
> >> Hannes & Rifaat
> >>
> >>
> >>
> >> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> >> _______________________________________________
> >> OAuth mailing list
> >> [email-masked]<mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >> _______________________________________________
> >> OAuth mailing list
> >> [email-masked]<mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
>
> _______________________________________________
> OAuth mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth
--
----
Aaron Parecki
aaronparecki.com<http://aaronparecki.com>
@aaronpk<http://twitter.com/aaronpk>

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: n-sakimura <[email-masked]>
Date: Sat, 1 Dec 2018 09:43:41 +0000

OAuth MTLS has been implemented in Banking industry so we have at least an alternative.

Sender Constrained includes cases where it is not key bound but name bound as I understand and it may have some utility so we f there are doubts, mentioning the both may be good.

Outlook for iOS<https://aka.ms/o0ukef> を入手

________________________________
差出人: OAuth <[email-masked]> (Hannes Tschofenig <[email-masked]> の代理)
送信日時: 土曜日, 12月 1, 2018 6:07 午後
宛先: Aaron Parecki; Torsten Lodderstedt
Cc: Daniel Fett; IETF oauth WG
件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Ciao
Hannes

+1

Aaron

—

Explantation:

kind regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 1 Dec 2018 13:01:11 +0100

Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <[email-masked]>:
> 
> I agree with Aaron here and I think Section 3.8.1.2 of draft-ietf-oauth-security-topics-10  already does a pretty good job. 

my proposal is to add the following definition (based on 3.8.1.2) to a new „Terminology" section or to section 2.1.2:

A sender constrained access token scopes the applicability of an access token to a certain sender.  This sender is
obliged to demonstrate knowledge of a certain secret as prerequisite for the acceptance of that token at the recipient (e.g. a resource server).

> I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender…

The text shall convey that implicit must not be used at all. The main reason being it is unprotected against token injection and additionally also cannot sender constrain tokens. 

The second part of the statement relates to other response types and conditionally opens the MUST NOT in case they are protected against injection (which is true for the listed response types) and can issue sender constrained tokens (which does not work today but might work in the future). 

kind regards,
Torsten. 

> On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt <[email-masked]> wrote:
> Hi all, 
> 
> > Am 29.11.2018 um 15:15 schrieb John Bradley <[email-masked]>:
> > 
> > I am ok with that.  
> > 
> > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt <[email-masked] wrote:
> > 
> > > Am 28.11.2018 um 23:50 schrieb n-sakimura <[email-masked]>:
> > > 
> > > That works.
> > 
> > Good!
> > 
> > > Nat Sakimura / [email-masked] / +81-90-6013-6276
> > > 
> > > 差出人: Torsten Lodderstedt <[email-masked]>
> > > Cc: Dick Hardt; Hannes Tschofenig; [email-masked]
> > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <[email-masked]>:
> > >> 
> > >> I would support
> > >> 
> > >> 差出人: OAuth <[email-masked]> (Dick Hardt <[email-masked]> の代理)
> > >> Cc: [email-masked]
> > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig <[email-masked]> wrote:
> > >> Hi all,
> > >> 
> > >> [email-masked]
> > >> [email-masked]
> > [email-masked]
> [email-masked]
> aaronparecki.com
> @aaronpk

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 3 Dec 2018 09:00:35 +0000

(chair hat off)

I believe many in this group had concerns with the implicit grant already for a long time but thought it was necessary for use with JavaScript-based apps in the browser. Two things have happened in the meanwhile

  *   Attempts to secure the implicit grant, for example with token binding, weren’t successful
  *   CORS is widely deployed making the authorization code usage possible

Since we are now trying to make recommendations for OAuth 2.0 security in the document Thorsten is editing we obviously have to make a recommendation.
Additionally, Aaron started <draft-parecki-oauth-browser-based-apps>, which is a document we should have been working on for along time already.

Ciao
Hannes

From: Vittorio Bertocci <[email-masked]>
Sent: Monday, December 3, 2018 5:14 AM
To: Torsten Lodderstedt <[email-masked]>
Cc: Daniel Fett <[email-masked]>; Hannes Tschofenig <[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi all,
Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative.

I have a number of customers that are reacting to the news with distress. The language used in some of the communications associated with this initiative made them feel like some new vulnerability was discovered, calling for immediate action.
The fact is that as far as I can tell, no new, previously unknown fact informed this decision: no new vulnerability, nor any new technology that wasn’t available before (the sender constrain is still not actionable for most customers). The risks of the implicit flow aren’t bigger now than they were in October.
That doesn’t mean that we cannot improve guidance, of course- and now is as good as any other moment to do so: but at the same time, I think we need to be cognizant of the *immense* investment in existence today in form of SDKs and applications built on those SDKs that are predicated on implicit flow, with our blessing: until very recently the official position was “implicit is bad but it’s the best we have noawadays”.
To me, being cognizant of that means that we should help people to formulate action proportionate to the risk. And if until yesterday we were ok with them using implicit, we cannot realistically expect anyone to start changing all of their apps today, but that’s the message many customers are getting.
TL;DR, I think the community would be well served by clarifying in the security document that there is no new risk and their existing codebase didn’t suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache with milder side effects than the one we were prescribing them until now, but that doesn’t mean that they should throw away all the stash they have of the older drug. The old drug will keep working as it worked until now. Once they run out of their stash, they should get the new one; or if the old side effects were particularly bad for them, perhaps they should consider switching today. But this isn’t a recall.

And if in fact this group thinks it should be a recall and get everyone off the old one right now, I think we’ll need to make a much stronger case than we have done so far.

Thoughts?

Thanks
V.

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi Hannes,

> Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>:
>

kind regards,
Torsten.

> From: OAuth <[email-masked]<mailto:[email-masked]>> On Behalf Of Aaron Parecki
> To: Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
> Cc: Daniel Fett <[email-masked]<mailto:[email-masked]>>; IETF oauth WG <[email-masked]<mailto:[email-masked]>>

---

From: Daniel Fett <[email-masked]>
Date: Mon, 3 Dec 2018 10:16:38 +0100

We also are talking about a stronger attacker model than what was
assumed before, and there are good reasons for that:

  * We see more dynamic setups now which enable new kinds of attacks.
With the AS Mix-Up attack, for example, we have seen that tokens and
codes can leak in unexpected ways. PKCE comes to the rescue of the auth
code grant, but there's no such thing for implicit, as Hannes said. In
these dynamic setups, we also have to assume that endpoints can be
misconfigured etc. which is why it makes sense to use a strong attacker
model (as we see in the FAPI working group, for example).

  * OAuth nowadays is used in high-stakes environments such as financial
transactions. We should have multiple lines of defense in place in such
environments, and the implicit mode just gives us one (with regards to
access token leakage).

So, while the text in RFC6749 has not changed, the world around it has
changed quite a lot.

-Daniel

Am 03.12.18 um 10:00 schrieb Hannes Tschofenig:
>
> (chair hat off)
>
>  
>
> I believe many in this group had concerns with the implicit grant
> already for a long time but thought it was necessary for use with
> JavaScript-based apps in the browser. Two things have happened in the
> meanwhile
>
> Since we are now trying to make recommendations for OAuth 2.0 security
> in the document Thorsten is editing we obviously have to make a
> recommendation.
>
> Additionally, Aaron started <draft-parecki-oauth-browser-based-apps>,
> which is a document we should have been working on for along time
> already.
>
>  
>
> Ciao
>
> Hannes
>
>  
>
> *From:*Vittorio Bertocci <[email-masked]>
> *Sent:* Monday, December 3, 2018 5:14 AM
> *To:* Torsten Lodderstedt <[email-masked]>
> *Cc:* Daniel Fett <[email-masked]>; Hannes Tschofenig
> <[email-masked]>; IETF oauth WG <[email-masked]>
> *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend
> authorization code instead of implicit
>
>  
>
> Hi all,
>
> Sorry for stepping a bit back from the level of detail the discussion
> already reached. I do have some specific comments on the document, but
> before bringing those up I wanted to raise a general problem I am
> experiencing with this initiative.
>
>  
>
> I have a number of customers that are reacting to the news with
> distress. The language used in some of the communications associated
> with this initiative made them feel like some new vulnerability was
> discovered, calling for immediate action.
>
> The fact is that as far as I can tell, no new, previously unknown fact
> informed this decision: no new vulnerability, nor any new technology
> that wasn’t available before (the sender constrain is still not
> actionable for most customers). The risks of the implicit flow aren’t
> bigger now than they were in October.
>
> That doesn’t mean that we cannot improve guidance, of course- and now
> is as good as any other moment to do so: but at the same time, I think
> we need to be cognizant of the *immense* investment in existence today
> in form of SDKs and applications built on those SDKs that are
> predicated on implicit flow, with our blessing: until very recently
> the official position was “implicit is bad but it’s the best we have
> noawadays”.
>
> To me, being cognizant of that means that we should help people to
> formulate action proportionate to the risk. And if until yesterday we
> were ok with them using implicit, we cannot realistically expect
> anyone to start changing all of their apps today, but that’s the
> message many customers are getting. 
>
> TL;DR, I think the community would be well served by clarifying in the
> security document that there is no new risk and their existing
> codebase didn’t suddenly become less secure and in *urgent* need to
> update.
>
> To attempt a metaphor. We discovered a new drug against headache with
> milder side effects than the one we were prescribing them until now,
> but that doesn’t mean that they should throw away all the stash they
> have of the older drug. The old drug will keep working as it worked
> until now. Once they run out of their stash, they should get the new
> one; or if the old side effects were particularly bad for them,
> perhaps they should consider switching today. But this isn’t a recall. 
>
>  
>
> And if in fact this group thinks it should be a recall and get
> everyone off the old one right now, I think we’ll need to make a much
> stronger case than we have done so far.
>
>  
>
> Thoughts?
>
>  
>
> Thanks
>
> V.
>
>  
>
>  
>
> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Hannes,
>
>     > Am 01.12.2018 um 10:06 schrieb Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>>:
>     >
>     > I agree with Aaron here and I think Section 3.8.1.2 of
>     draft-ietf-oauth-security-topics-10  already does a pretty good job.
>
>     my proposal is to add the following definition (based on 3.8.1.2)
>     to a new „Terminology" section or to section 2.1.2:
>
>     A sender constrained access token scopes the applicability of an
>     access token to a certain sender.  This sender is
>     obliged to demonstrate knowledge of a certain secret as
>     prerequisite for the acceptance of that token at the recipient
>     (e.g. a resource server).
>
>     >
>     > I was, however, wondering about the subtle implication of the
>     requirement for sender constrained tokens. My understanding of the
>     token binding discussion, which is one of the ways to provide
>     sender-constrained tokens, is that we don’t have good faith in
>     seeing deployment anytime soon. Hence, we are essentially (reading
>     in between the lines of Section 3.8.1.2) saying that you cannot
>     use implicit grant in a practical setup for the web*.
>
>     The text shall convey that implicit must not be used at all. The
>     main reason being it is unprotected against token injection and
>     additionally also cannot sender constrain tokens.
>
>     The second part of the statement relates to other response types
>     and conditionally opens the MUST NOT in case they are protected
>     against injection (which is true for the listed response types)
>     and can issue sender constrained tokens (which does not work today
>     but might work in the future).
>
>     kind regards,
>     Torsten.
>
>     > 
>     > From: OAuth <[email-masked]
>     <mailto:[email-masked]>> On Behalf Of Aaron Parecki
>     > Cc: Daniel Fett <[email-masked]
>     <mailto:[email-masked]>>; IETF oauth WG <[email-masked]
>     <mailto:[email-masked]>>
>     > On Thu, Nov 29, 2018 at 10:06 AM Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > Hi all,
>     >
>     > - we wanted to have the right balance between a generic
>     definition of the response types we do not recommend/allow to be
>     used and a concrete/actionable list of the affected response types.
>     > > On Wed, Nov 28, 2018, 8:03 PM Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]> wrote:
>     > >
>     > > > Am 28.11.2018 um 23:50 schrieb n-sakimura
>     <[email-masked] <mailto:[email-masked]>>:
>     > > >
>     > > > That works.
>     > >
>     > > Good!
>     > >
>     > > I just realized this text has an issue with „token“ (only). It
>     would allow „token“ to be used if the token would sender
>     constrained. This completely ignores the fact implicit also shall
>     be abandoned because of its vulnerability for access token injection.
>     > >
>     > >    grant. Furthermore, clients SHOULD only use other response
>     types causing the authorization server to
>     > >    issue an access token in the authorization response, if the
>     particular response type detects access token
>     > >   In order to avoid these issues, Clients SHOULD NOT use the
>     response type „token". The response types
>     > > > In fact, I would further go and say MUST NOT but that
>     probably is too much for a security consideration.
>     > > >
>     > >
>     > > Mike suggested to go with a SHOULD NOT to get the message out
>     but give implementors time to move/change.
>     > >
>     > > > Best,
>     > > >
>     > > > Nat
>     > > >
>     > > > Nat Sakimura / [email-masked]
>     <mailto:[email-masked]> / +81-90-6013-6276
>     > > >
>     > > >
>     <mailto:[email-masked]>
>     > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura
>     <[email-masked] <mailto:[email-masked]>>:
>     > > >>
>     > > >> I would support
>     > > >>
>     > > >> 1) clearly defining Implicit as the flow that returns
>     access token from the authorization endpoint ( some people
>     confuses implicit as the flow that returns ID Token in the front
>     channel)
>     > > >
>     > > > That’s the current text:
>     > > >
>     > > >> 2) Banning the returning of the access token that are not
>     sender constrained from the authorization endpoint
>     > > >
>     > > >    issue an access token in the authorization response, if
>     this access tokens is not sender-constraint.
>     > > >
>     > > > What about this?
>     > > >
>     > > > kind regards,
>     > > > Torsten.
>     > > >
>     > > >>
>     > > >> Best,
>     > > >>
>     > > >> Nat
>     > > >>
>     > > >>
>     > > >> Outlook for iOS を入手
>     > > >> 
>     > > >> 差出人: OAuth <[email-masked]
>     <mailto:[email-masked]>> (Dick Hardt <[email-masked]
>     <mailto:[email-masked]>> の代理)
>     > > >> Cc: [email-masked] <mailto:[email-masked]>
>     > > >> While there are various mechanisms to alleviate some of the
>     issues of implicit, I don't think we can recommend specifics, and
>     there may be future ones in the future. I think we all agree that
>     implicit without any mitigation is problematic.
>     > > >>
>     > > >> On Mon, Nov 19, 2018 at 2:34 AM Hannes Tschofenig
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     > > >> Hi all,
>     > > >>
>     > > >> The authors of the OAuth Security Topics draft came to the
>     conclusion that it is not possible to adequately secure the
>     implicit flow against token injection since potential solutions
>     like token binding or JARM are in an early stage of adoption. For
>     this reason, and since CORS allows browser-based apps to send
>     requests to the token endpoint, Torsten suggested to use the
>     authorization code instead of the implicit grant in call cases in
>     his presentation (see
>     https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessb-draft-ietf-oauth-security-topics-01).
>     > > >>
>     > > >> A hum in the room at IETF#103 concluded strong support for
>     his recommendations. We would like to confirm the discussion on
>     the list.
>     > > >>
>     > > >> IMPORTANT NOTICE: The contents of this email and any
>     attachments are confidential and may also be privileged. If you
>     are not the intended recipient, please notify the sender
>     immediately and do not disclose the contents to any other person,
>     use it for any purpose, or store or copy the information in any
>     medium. Thank you.
>     > > >> [email-masked] <mailto:[email-masked]>
>     > > >> [email-masked] <mailto:[email-masked]>
>     > > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     > aaronparecki.com <http://aaronparecki.com>
>     > @aaronpk
>     > 
>     > IMPORTANT NOTICE: The contents of this email and any attachments
>     are confidential and may also be privileged. If you are not the
>     intended recipient, please notify the sender immediately and do
>     not disclose the contents to any other person, use it for any
>     purpose, or store or copy the information in any medium. Thank you.
>
>     [email-masked] <mailto:[email-masked]>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 3 Dec 2018 09:39:17 +0000

(chair hat off)

Hi Nat,

Section 3.8.1.2<https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2> of draft-ietf-oauth-security-topics-10  lists the following options for implementing sender constraint tokens:

  *   Token Binding
  *   MTLS
  *   Signed HTTP Requests
  *   JPOP

JPOP is an individual submission. The work on signed HTTP requests stalled. Token Binding, as we learned at the last IETF meeting, has serious deployment problems.
That essentially leaves us with MTLS. I am, however, not entirely sure MTLS works well with the implicit grant.

My conclusion so far from the discussion is that implicit grant cannot be secured practically.

For IoT, as I mentioned, the story does not look so grim since with IoT protocols, CoAP or MQTT, one can still use TLS as well as application layer security. (At least that’s the current understanding.)

I am happy to get corrected.

Ciao
Hannes

From: n-sakimura <[email-masked]>
Sent: Saturday, December 1, 2018 10:44 AM
To: Hannes Tschofenig <[email-masked]>; Aaron Parecki <[email-masked]>; Torsten Lodderstedt <[email-masked]>
Cc: Daniel Fett <[email-masked]>; IETF oauth WG <[email-masked]>
Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

差出人: OAuth <[email-masked]<mailto:[email-masked]>> (Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> の代理)

Ciao
Hannes

+1

Aaron

—

Explantation:

kind regards,
Torsten.

---

From: Vittorio Bertocci <[email-masked]>
Date: Sun, 2 Dec 2018 20:14:19 -0800

Hi all,

I have a number of customers that are reacting to the news with distress.
The language used in some of the communications associated with this
initiative made them feel like some new vulnerability was discovered,
calling for immediate action.
The fact is that as far as I can tell, no new, previously unknown fact
informed this decision: no new vulnerability, nor any new technology that
wasn’t available before (the sender constrain is still not actionable for
most customers). The risks of the implicit flow aren’t bigger now than they
were in October.
That doesn’t mean that we cannot improve guidance, of course- and now is as
good as any other moment to do so: but at the same time, I think we need to
be cognizant of the *immense* investment in existence today in form of SDKs
and applications built on those SDKs that are predicated on implicit flow,
with our blessing: until very recently the official position was “implicit
is bad but it’s the best we have noawadays”.
To me, being cognizant of that means that we should help people to
formulate action proportionate to the risk. And if until yesterday we were
ok with them using implicit, we cannot realistically expect anyone to start
changing all of their apps today, but that’s the message many customers are
getting.
TL;DR, I think the community would be well served by clarifying in the
security document that there is no new risk and their existing codebase
didn’t suddenly become less secure and in *urgent* need to update.
To attempt a metaphor. We discovered a new drug against headache with
milder side effects than the one we were prescribing them until now, but
that doesn’t mean that they should throw away all the stash they have of
the older drug. The old drug will keep working as it worked until now. Once
they run out of their stash, they should get the new one; or if the old
side effects were particularly bad for them, perhaps they should consider
switching today. But this isn’t a recall.

And if in fact this group thinks it should be a recall and get everyone off
the old one right now, I think we’ll need to make a much stronger case than
we have done so far.

Thoughts?

Thanks
V.

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <[email-masked]>
wrote:

> my proposal is to add the following definition (based on 3.8.1.2) to a new
> „Terminology" section or to section 2.1.2:
>
> A sender constrained access token scopes the applicability of an access
> token to a certain sender.  This sender is
> obliged to demonstrate knowledge of a certain secret as prerequisite for
> the acceptance of that token at the recipient (e.g. a resource server).
>
> >
> requirement for sender constrained tokens. My understanding of the token
> binding discussion, which is one of the ways to provide sender-constrained
> tokens, is that we don’t have good faith in seeing deployment anytime soon.
> Hence, we are essentially (reading in between the lines of Section 3.8.1.2)
> saying that you cannot use implicit grant in a practical setup for the web*.
>
> The text shall convey that implicit must not be used at all. The main
> reason being it is unprotected against token injection and additionally
> also cannot sender constrain tokens.
>
> The second part of the statement relates to other response types and
> conditionally opens the MUST NOT in case they are protected against
> injection (which is true for the listed response types) and can issue
> sender constrained tokens (which does not work today but might work in the
> future).
>
> kind regards,
> Torsten.
>
> >
> > - we wanted to have the right balance between a generic definition of
> the response types we do not recommend/allow to be used and a
> concrete/actionable list of the affected response types.
> > > I just realized this text has an issue with „token“ (only). It would
> allow „token“ to be used if the token would sender constrained. This
> completely ignores the fact implicit also shall be abandoned because of its
> vulnerability for access token injection.
> > >
> > > >> 1) clearly defining Implicit as the flow that returns access token
> from the authorization endpoint ( some people confuses implicit as the flow
> that returns ID Token in the front channel)
> > > >
> > > > That’s the current text:
> > > >
> > > >> 2) Banning the returning of the access token that are not sender
> constrained from the authorization endpoint
> > > >
> > > >> While there are various mechanisms to alleviate some of the issues
> of implicit, I don't think we can recommend specifics, and there may be
> future ones in the future. I think we all agree that implicit without any
> mitigation is problematic.
> > > >>
> conclusion that it is not possible to adequately secure the implicit flow
> against token injection since potential solutions like token binding or
> JARM are in an early stage of adoption. For this reason, and since CORS
> allows browser-based apps to send requests to the token endpoint, Torsten
> suggested to use the authorization code instead of the implicit grant in
> call cases in his presentation (see
> > > >> A hum in the room at IETF#103 concluded strong support for his
> recommendations. We would like to confirm the discussion on the list.
> > > >>
> are confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>

---

From: Dominick Baier <[email-masked]>
Date: Mon, 3 Dec 2018 03:49:53 -0800

I agree with Vittorio -

While we all agree that implicit is outdated and we can do better (and it
is indeed good that this discussion has finally started for real) - the
communication around the (preliminary) results of the BCP was unfortunate
and not very responsible - quoting:

“Simply put, the implicit grant’s security is broken beyond repair. It is
vulnerable to access token leakage, meaning an attacker can exfiltrate
valid access tokens and use it to his own benefit. This might for example
result in the attacker accessing the legit user’s health record or
initiating a payment, from her bank account."

This indeed, as Vittorio pointed out, sounds like a new vulnerability has
been found. This spreads FUD ;)

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).

Again we all agree that implicit can be improved - but there are some
issues to be sorted first to make this a smooth transition.

My 2c

———
Dominick

On 3. December 2018 at 11:59:44, Vittorio Bertocci (
vittorio.bertocci=[email-masked]) wrote:

Hi all,
Sorry for stepping a bit back from the level of detail the discussion
already reached. I do have some specific comments on the document, but
before bringing those up I wanted to raise a general problem I am
experiencing with this initiative..

Thoughts?

Thanks
V.

On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <[email-masked]>
wrote:

> saying that you cannot use implicit grant in a practical setup for the
> web*..
>
> recommendations. We would like to confirm the discussion on the list..
> > > >>

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2018 12:59:14 +0100

I agree that the hair on fire messaging is over stated.

This is still a document in development and not yet a BCP.   No new
vunerable have been found, but attackers are evolving.

These are security best practices for new implimentations.   Not a
recommendation to rip things out.    As applications are updated they need
to consider the BCP recommendations.

We do need to be careful about how our discussions are interpreted.

There are also worse things people could do than implicit if we scare them
back to proprietary solutions.

John B.

On Mon, Dec 3, 2018, 12:50 PM Dominick Baier <[email-masked]
wrote:

> vittorio.bertocci=[email-masked]
> <vittorio.bertocci=[email-masked]>) wrote:
>
> Hi all,
> That doesn’t mean that we cannot improve guidance, of course- and now is
> as good as any other moment to do so: but at the same time, I think we need
> to be cognizant of the *immense* investment in existence today in form of
> SDKs and applications built on those SDKs that are predicated on implicit
> flow, with our blessing: until very recently the official position was
> “implicit is bad but it’s the best we have noawadays”.
> And if in fact this group thinks it should be a recall and get everyone
> off the old one right now, I think we’ll need to make a much stronger case
> than we have done so far.
>
> Thoughts?
>
> Thanks
> V.
>
>
>> my proposal is to add the following definition (based on 3.8.1.2) to a
>> new „Terminology" section or to section 2.1.2:
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 3 Dec 2018 15:43:26 +0100

> Am 03.12.2018 um 12:59 schrieb John Bradley <[email-masked]>:
> 
> This is still a document in development and not yet a BCP.   No new vunerable have been found, but attackers are evolving.  

You are right. Basically, RFC 6749’s security consideration section already states the vulnerabilities:

§ 10.3

„When using the implicit grant type, the access token is transmitted
   in the URI fragment, which can expose it to unauthorized parties.“

§ 10.16

„In the implicit flow (response_type=token), the attacker can easily
   switch the token in the response from the authorization server,
   replacing the real access token with the one previously issued to the
   attacker."

Retrospectively, I’m asking myself why we ever agreed to move the spec forward given these issues at hand.

Why the change now?

Not only attackers are evolving, also the use cases for OAuth and the dynamics of the respective deployments have changed significantly. Just to give some example, open banking was not a topic in 2012. The discovery of the mix up attack was kind of a wake up call in late 2015. We realized token leakage and replay is becoming a major issue.

That are the reasons why we started working on the Security BCP as an update of RFC 6749/4750 security considerations and also RFC 6819.

The BCP, by the way, deprecates several other practices: For example, it introduces exact URI matching, one time use CSRF tokens in state, and obliges implementors to use code in conjunction with PKCE or nonce, effectively deprecating the pure code flow. No one every complaint about this.

We also recommend use of sender constraint access tokens simply because we came to the conclusion focussing on token leakage prevention only would be a rather thin defense.

> 
> These are security best practices for new implimentations.   Not a recommendation to rip things out.    As applications are updated they need to consider the BCP recommendations.  

I would go one step further. Given the fact we pointed out the risk associated with implicit in RFC 6749, implementors should have conducted a risk assessment before they implemented implicit. If they haven’t, they should do now using the information we provide in the BCP. If they conclude by finding application specific mitigations or just assume the risk, that fine with me. 

But I don’t want to give implementors the „blessing“ (as Vittorio called it) of this working group to use a flow with such know security issues, especially since a simpler and more secure option is available. 

BTW: I would be ok with making the respective text a SHOULD NOT again since that would serve the purpose just fine. 

> We do need to be careful about how our discussions are interpreted.  

That’s certainly true. On the other hand, most developers don’t know anything about the current state of OAuth. What I have seen in the wild makes me nervous. People think implicit is the „lightweight and easy to use“ version of OAuth and don’t ask for the security implications. That’s why I think we need to find ways to get developers and API designers educated on how to properly use OAuth.

> 
> There are also worse things people could do than implicit if we scare them back to proprietary solutions.  

Why do you see that risk? We offer an alternative solution, which is simple to use, secure, and versatile.  

kind regards,
Torsten. 

> 
> John B.  
> 
> On Mon, Dec 3, 2018, 12:50 PM Dominick Baier <[email-masked] wrote:
> I agree with Vittorio - 
> 
> While we all agree that implicit is outdated and we can do better (and it is indeed good that this discussion has finally started for real) - the communication around the (preliminary) results of the BCP was unfortunate and not very responsible - quoting:
> 
> “Simply put, the implicit grant’s security is broken beyond repair. It is vulnerable to access token leakage, meaning an attacker can exfiltrate valid access tokens and use it to his own benefit. This might for example result in the attacker accessing the legit user’s health record or initiating a payment, from her bank account."
> 
> This indeed, as Vittorio pointed out, sounds like a new vulnerability has been found. This spreads FUD ;)
> 
> 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).
> 
> Again we all agree that implicit can be improved - but there are some issues to be sorted first to make this a smooth transition.
> 
> My 2c
> 
> ———
> Dominick
> 
> On 3. December 2018 at 11:59:44, Vittorio Bertocci (vittorio.bertocci=[email-masked]) wrote:
> 
>> Hi all,
>> Sorry for stepping a bit back from the level of detail the discussion already reached. I do have some specific comments on the document, but before bringing those up I wanted to raise a general problem I am experiencing with this initiative..
>> 
>> On Sat, Dec 1, 2018 at 04:01 Torsten Lodderstedt <[email-masked]> wrote:
>> Hi Hannes,
>> 
>> > I was, however, wondering about the subtle implication of the requirement for sender constrained tokens. My understanding of the token binding discussion, which is one of the ways to provide sender-constrained tokens, is that we don’t have good faith in seeing deployment anytime soon. Hence, we are essentially (reading in between the lines of Section 3.8.1.2) saying that you cannot use implicit grant in a practical setup for the web*..
>> 
>> > > >> A hum in the room at IETF#103 concluded strong support for his recommendations. We would like to confirm the discussion on the list..
>> > > >>

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2018 16:38:36 +0100

Not everyone loves OAuth.  Sometimes our discussions on how to make it more
secure can be taken out of context and used as reasons to move back to
proprietary solutions.

We just need to be sensitive to the spin on this.

John B.

On Mon, Dec 3, 2018, 3:43 PM Torsten Lodderstedt <[email-masked]
wrote:

> Not only attackers are evolving, also the use cases for OAuth and the
> dynamics of the respective deployments have changed significantly. Just to
> give some example, open banking was not a topic in 2012. The discovery of
> the mix up attack was kind of a wake up call in late 2015. We realized
> token leakage and replay is becoming a major issue.
>
> That are the reasons why we started working on the Security BCP as an
> update of RFC 6749/4750 security considerations and also RFC 6819.
>
> The BCP, by the way, deprecates several other practices: For example, it
> introduces exact URI matching, one time use CSRF tokens in state, and
> obliges implementors to use code in conjunction with PKCE or nonce,
> effectively deprecating the pure code flow. No one every complaint about
> this.
>
> We also recommend use of sender constraint access tokens simply because we
> came to the conclusion focussing on token leakage prevention only would be
> a rather thin defense.
>
> >
> I would go one step further. Given the fact we pointed out the risk
> associated with implicit in RFC 6749, implementors should have conducted a
> risk assessment before they implemented implicit. If they haven’t, they
> should do now using the information we provide in the BCP. If they conclude
> by finding application specific mitigations or just assume the risk, that
> fine with me.
>
> But I don’t want to give implementors the „blessing“ (as Vittorio called
> it) of this working group to use a flow with such know security issues,
> especially since a simpler and more secure option is available.
>
> BTW: I would be ok with making the respective text a SHOULD NOT again
> since that would serve the purpose just fine.
>
> >
> That’s certainly true. On the other hand, most developers don’t know
> anything about the current state of OAuth. What I have seen in the wild
> makes me nervous. People think implicit is the „lightweight and easy to
> use“ version of OAuth and don’t ask for the security implications. That’s
> why I think we need to find ways to get developers and API designers
> educated on how to properly use OAuth.
>
> >
> > While we all agree that implicit is outdated and we can do better (and
> it is indeed good that this discussion has finally started for real) - the
> > “Simply put, the implicit grant’s security is broken beyond repair. It
> is vulnerable to access token leakage, meaning an attacker can exfiltrate
> distress. The language used in some of the communications associated with
> this initiative made them feel like some new vulnerability was discovered,
> is as good as any other moment to do so: but at the same time, I think we
> need to be cognizant of the *immense* investment in existence today in form
> of SDKs and applications built on those SDKs that are predicated on
> implicit flow, with our blessing: until very recently the official position
> was “implicit is bad but it’s the best we have noawadays”.
> >> obliged to demonstrate knowledge of a certain secret as prerequisite
> for the acceptance of that token at the recipient (e.g. a resource server).
> >>
> >> >
> would allow „token“ to be used if the token would sender constrained. This
> implicit
> >> > > >> Am 28.11.2018 um 21:10 schrieb n-sakimura <[email-masked]
> >:
> >> > > >>
> >> > > >> I would support
> >> > > >>
> >> > > >> 1) clearly defining Implicit as the flow that returns access
> token from the authorization endpoint ( some people confuses implicit as
> the flow that returns ID Token in the front channel)
> >> > > >
> >> > > > That’s the current text:
> >> > > >
> implicit
> implicit
> issues of implicit, I don't think we can recommend specifics, and there may
> be future ones in the future. I think we all agree that implicit without
> any mitigation is problematic.
> >> > > >>

---

From: Brian Campbell <[email-masked]>
Date: Mon, 3 Dec 2018 11:03:22 -0700

> the acceptance of that token at the recipient (e.g. a resource server).

I think that would be sufficient to avoid reading too much into "sender
constrained" based on how it is used elsewhere. Thanks.

-- 
_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._

---

From: Brian Campbell <[email-masked]>
Date: Mon, 3 Dec 2018 11:41:08 -0700

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.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 3 Dec 2018 13:50:43 -0800

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=
[email-masked]> wrote:

> 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
> *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
> [email-masked]

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 3 Dec 2018 16:42:21 -0800

+1 for the proposed change

Providing context around the change and to clarify that this is not a
reaction to some emergency would be useful IMO.

On Mon, Dec 3, 2018 at 1:50 PM Dick Hardt <[email-masked]> 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.
>>
>> 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.*

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Dec 2018 09:59:15 +0900

Hannes,

As long as the client is a server-based application, MTLS works fine, and
my use-case is exactly that.

On the side note: perhaps we may want to take the remaining portion of JPOP
up in the near future, as its usefulness is there as Tony pointed out at
the time we ported the certs based sender constraint to MTLS in the WG,
e.g., when the network after TLS has been terminated cannot be entirely
trusted.

Best,

Nat

On Mon, Dec 3, 2018 at 6:39 PM Hannes Tschofenig <[email-masked]>
wrote:

> (chair hat off)
>
>
>
> Hi Nat,
>
>
>
> Section 3.8.1.2
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2>
> of draft-ietf-oauth-security-topics-10  lists the following options for
> implementing sender constraint tokens:
>
>    - Token Binding
>    - MTLS
>    - Signed HTTP Requests
>    - JPOP
>
>
>
> JPOP is an individual submission. The work on signed HTTP requests
> stalled. Token Binding, as we learned at the last IETF meeting, has serious
> deployment problems.
>
> For IoT, as I mentioned, the story does not look so grim since with IoT
> protocols, CoAP or MQTT, one can still use TLS as well as application layer
> security. (At least that’s the current understanding.)
>
>
>
> *From:* n-sakimura <[email-masked]>
> *Sent:* Saturday, December 1, 2018 10:44 AM
> *To:* Hannes Tschofenig <[email-masked]>; Aaron Parecki <
> [email-masked]>; Torsten Lodderstedt <[email-masked]>
> *Cc:* Daniel Fett <[email-masked]>; IETF oauth WG <[email-masked]>
> Sender Constrained includes cases where it is not key bound but name bound
> as I understand and it may have some utility so we f there are doubts,
> mentioning the both may be good.
>
>
>
> Outlook for iOS <https://aka.ms/o0ukef> を入手
>
>
> ------------------------------
>
> *差出人**:* OAuth <[email-masked]> (Hannes Tschofenig <
> [email-masked]> の代理)
> *送信日時**:* 土曜日, 12月 1, 2018 6:07 午後
> *宛先**:* Aaron Parecki; Torsten Lodderstedt
> *Cc:* Daniel Fett; IETF oauth WG
> *件名**:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization
> code instead of implicit
>
>
> I agree with Aaron here and I think Section 3.8.1.2
> <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.8.1.2>
> of draft-ietf-oauth-security-topics-10  already does a pretty good job.
>
> I was, however, wondering about the subtle implication of the requirement
> for sender constrained tokens. My understanding of the token binding
> discussion, which is one of the ways to provide sender-constrained tokens,
> is that we don’t have good faith in seeing deployment anytime soon. Hence,
> we are essentially (reading in between the lines of Section 3.8.1.2) saying
> that you cannot use implicit grant in a practical setup for the web*.
>
>
>
> *From:* OAuth <[email-masked]> *On Behalf Of *Aaron Parecki
> *Sent:* Saturday, December 1, 2018 3:18 AM
> *Cc:* Daniel Fett <[email-masked]>; IETF oauth WG <[email-masked]>
> - we wanted to have the right balance between a generic definition of the
> response types we do not recommend/allow to be used and a
> > >> While there are various mechanisms to alleviate some of the issues of
> implicit, I don't think we can recommend specifics, and there may be future
> ones in the future. I think we all agree that implicit without any
> > >> The authors of the OAuth Security Topics draft came to the conclusion
> that it is not possible to adequately secure the implicit flow against
> token injection since potential solutions like token binding or JARM are in
> an early stage of adoption. For this reason, and since CORS allows
> browser-based apps to send requests to the token endpoint, Torsten
> @aaronpk <http://twitter.com/aaronpk>
>
>
>

-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 4 Dec 2018 10:08:20 +0900

Belated +1 to this.  "sender or key constrained" is good.

Also, the new definition of "sender constrained" per Torsten states
"knowledge of" but that is only applicable to "key constrained" variant I
guess, besides "knowledge" is a bit "fluffy". I feel that just saying as
suggested by Brian safer. My 2c.

Nat

On Sat, Dec 1, 2018 at 7:24 AM Brian Campbell <bcampbell=
[email-masked]> wrote:

> Kind of, yes. I guess so. I think. It's just semantics. But yeah. Key
> constrained might be more appropriate. But the Security Topics document
> probably should allow for both/either.
>
> I don't think that these are necessarily terms with widely agreed upon or
> understood meaning. But it was pointed out to me that the OAuth 2.0 Pop
> Architecture draft defines sender constraint and key confirmation as
> different things (
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.2
> and
> https://tools.ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-6.3
> <https://tools.ietf..org/html/draft-ietf-oauth-pop-architecture-08#section-6.3>).
> And the definitions their do kind of make sense when thinking about the
> words used. The line between sender and key constrained isn't exactly clear
> but it seems MTLS and token binding access tokens are more key constrained
> than sender. The -08 version of the MTLS draft dropped the use of the
> "sender constrained" terminology based on that feedback.
>
> I dunno. Maybe the Security Topics could say something in a terminology
> section that says when sender or key constrained is used within they can be
> taken to mean the same concept. Or something like that.
>
> On Fri, Nov 30, 2018 at 1:42 PM Torsten Lodderstedt <
> [email-masked]> wrote:
>
>> Hi Brian,
>>
>> we use „sender constrained tokens“ throughout the BCP to denote tokens
>> bound to a sender in possession of a certain key/secret and I thought that
>> was established terminology in the group. Are you suggesting „key
>> constrained” would be more appropriate?
>>
>> kind regards,
>> Torsten.
>>
>> Am 30.11.2018 um 21:02 schrieb Brian Campbell <[email-masked]
>> >:
>>
>> As was pointed out to me in WGLC review of the MTLS document,
>> "sender-constrained" has or is likely to be interpreted with a pretty
>> specific meaning of the token being bound to the client and the client
>> authenticating itself to the resource and the resource checking all that
>> matches up. That makes the text more restrictive than is likely intended.
>> Perhaps the text should say something like "sender or key constrained" to
>> allow for different variants of PoP access tokens?
>>
>>
>>
>> On Thu, Nov 29, 2018 at 11:06 AM Torsten Lodderstedt <
>> [email-masked]> wrote:
>>
>>> Hi all,
>>>
>> your computer. Thank you.*
>>
>>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Tomek Stojecki <[email-masked]>
Date: Tue, 4 Dec 2018 08:50:04 +0000 (UTC)

I agree with Vittorio, Dominick et al. 

> 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.

> 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 si…

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"

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 <[email-masked]> 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=[email-masked]> 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. 
> 
> 
> 
> 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
> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 4 Dec 2018 14:08:18 +0100

Hi Tomek,

> Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki=[email-masked]>:
> 

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

> - 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.

---

From: Tomek Stojecki <[email-masked]>
Date: Tue, 4 Dec 2018 18:03:01 +0000 (UTC)

Thanks Torsten!So if I am putting myself in the shoes of somebody who sets out to do that - switch an existing SPA client (no backend) from Implicit to Code, the options to think through can be summed up more or less as following:
1. Do not use RTs2. If you're using RTs, rotate on every refresh AND implement RT token binding (is that stable enough?). Also consider binding RT to AS session.
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, confidentiality in storage? - not sure how to read that in the context of a browser)
    On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt <[email-masked]> wrote:  
 
 Hi Tomek,

kind regards,
Torsten.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 5 Dec 2018 13:16:42 +0100

Hi Tomek, 

> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki <[email-masked]>:
> 
> Thanks Torsten!
> 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?

> from Implicit to Code,

> the options to think through can be summed up more or less as following:
> 
> 1. Do not use RTs

That’s what I stated. 

> 2. If you're using RTs, rotate on every refresh AND implement RT token binding (is that stable enough?).

Refresh token rotation and sender constrained refresh tokens are alternative methods to replay detection. I think RT rotation is the more actionable approach. 

> Also consider binding RT to AS session.

yes.

> 
> 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.

> confidentiality in storage? - not sure how to read that in the context of a browser)

How do you ensure confidentiality of session cookies?

kind regards,
Torsten.

---

From: Tomek Stojecki <[email-masked]>
Date: Wed, 5 Dec 2018 14:27:31 +0000 (UTC)

Hi Torsten,

> 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 herehttps://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component
My point of putting (no backend) in parenthesis was to not derail this discussion and of course it had the opposite effect.

> 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? 

> 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. Maybe it is just me :)

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 5 Dec 2018 16:17:09 +0100

Hi Tomek, 

> Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <[email-masked]>:
> 
> Hi Torsten,
> 
> 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. 

> Good point. How well is dynamic registration supported across AS? 

I leave that to the vendors :-)

> 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.

---

From: David Waite <[email-masked]>
Date: Wed, 5 Dec 2018 10:29:47 -0700

> On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Tomek, 
> 

Pivoting to apps with local domain business logic (aka a backend):

Setup - the developer is building a browser-targeted app and at least one mobile app - their backend would likely be identical across all three. 

In that case, would they want client access to that backend to be secured with access tokens? Or should that backend to be the client to the AS, and communication from the javascript to the backend be secured with some non-OAuth method like cookies or API keys? 

I push for OAuth in most of these cases, unless their strategy for mobile apps is to “wrap” the browser code and content into a native app - in which case more flexible access to that backend can be deferred if desired until there is stronger business need.

-DW

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 5 Dec 2018 11:33:03 -0800

David, I think you are hitting on something really important here.
For non-identity experts, the SPA umbrella covers every app updating the UX
via JS instead of postbacks- regardless of the underlying topology. Does
the app have its own backend and that backend has no other clients? Does it
call its own backend AND other APIs? Does it call 3rd party APIs only? Is
the current set of requirement stable for the foreseeable future, or will
the app evolve to change its use case?
Those are all questions that can be dismissed by advising the developer to
use the most generic approach possible, e.g. getting tokens in the browser,
however that comes at a complexity price that might be unnecessary if in
their particular case just using cookies against their own backed (an
extremely common setup, in my experience) would be enough. Even when
wrapped in SDKs, that complexity is not entirely free- think ITP and the
like.
Per the above, just giving a blanket advice for all SPA subtypes might not
be the simplest solution for a large number of developers.

The question I don't have a good answer for is- how do we help developers
with no identity experience (and no interest in acquiring it) to determine
in what pattern they fall into, and pick the guidance relevant to their
scenario? Maybe by formally enumerating those topologies and giving them
names? Do you guys have ideas?

On Wed, Dec 5, 2018 at 9:29 AM David Waite <[email-masked]>
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)
> >
> Setup - the developer is building a browser-targeted app and at least one
> mobile app - their backend would likely be identical across all three.
>
> In that case, would they want client access to that backend to be secured
> with access tokens? Or should that backend to be the client to the AS, and
> communication from the javascript to the backend be secured with some
> non-OAuth method like cookies or API keys?
>
> I push for OAuth in most of these cases, unless their strategy for mobile
> apps is to “wrap” the browser code and content into a native app - in which
> case more flexible access to that backend can be deferred if desired until
> there is stronger business need.
>
> -DW
>
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 5 Dec 2018 17:31:46 -0800

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?
Thx
V.

On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <[email-masked]>
wrote:

> > If you do have a backend, aren't you better of handling the token
> request on the backend as pointed out here
> >
> > 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.
> >
> > 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 :)
>
> > > >> 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.
> > >
> > >
> > > > 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.
> > >
> > > >
> > > > Existing deployments that have not mitigated against the concerns
> with implicit should be ripped up and updated.
> > > >
> > > >> 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.
> > > >>
> > > >>
> > > >>
> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential and
> attachments from your computer. Thank
> you._______________________________________________
> > > >> OAuth mailing list
> > > >> [email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 6 Dec 2018 08:27:30 +0100

> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <[email-masked]>:
> 
> Hey Torsten/Tomek,
> 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 <[email-masked]> wrote:
>> Hi Tomek, 
>>

---

From: Vittorio Bertocci <[email-masked]>
Date: Wed, 5 Dec 2018 23:40:31 -0800

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. The user experience bar
(number of prompts, full page redirects) should be the one afforded by
implicit leveraging AS sessions via persistent cookies.

- 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

Thx
V.

On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <[email-masked]>
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)
>> >
>> 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 :)
>>
>> > > > Yes, just like future deployments that will not mitigate against
>> the concerns of code in the browser should be a concern.
>> > >
>> > > > - 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"?
>> > > > 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.
>> > > >
>> > > >
>> > > >
>> > > >

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 6 Dec 2018 13:49:18 +0100

Hi Vittorio,

> Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <[email-masked]>:
> 
> Thank you!
> - 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 <[email-masked]> wrote:
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 6 Dec 2018 14:47:28 +0000

I support the move away from the implicit flow toward using the authorization code flow (with PKCE and CORS)  for JavaScript applications. The limitations and assumptions that surrounded the design of the implicit flow back when we started no longer apply today. It was an optimization for a different time. Technology and platforms have moved forward, and our advice should move them forward as well. Furthermore, the ease of using the implicit flow incorrectly, and the damage that doing so can cause, has driven me to telling people to stop using it.

There are a number of hacks that can patch the implicit flow to be slightly better in various ways — if you tack on the “hybrid” flow from OIDC or JARM plus post messages and a bunch of other stuff, then it can be better. But if you’re doing all of that, I think you really need to ask yourself: why? What do you gain from jumping through all of those hoops when a viable alternative sits there? Is it pride? I don’t see why we cling to it. To me, it’s like saying “hey sure my leg gets cut off when I do this, but I can stitch it back on!”, when you could simply avoid cutting your leg off in the first place. The best cure is prevention, and what’s being argued here is prevention.

So many of OAuth’s problems in the wild come from over-use of the front channel, and any place we can move away from that is a good move.

— Justin

On Nov 19, 2018, at 5:34 AM, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:

Hi all,

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 6 Dec 2018 10:09:50 -0800

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 <[email-masked]>
wrote:

> 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?
>
> 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.
>
> >
> 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).
>
> >> 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?
> >
> >> > My point of putting (no backend) in parenthesis was to not derail
> this discussion and of course it had the opposite effect.
> >> >
> >>
> >> > > >> Existing deployments that have not mitigated against the
> concerns with implicit should be ripped up and updated.
> >> > > >
> >> > > > 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).
> >> > > >
> >> > > > - 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“
> >> > >
> >> > > 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.
> >> > >
> >> > > >> 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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Dec 2018 10:51:46 -0800

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=[email-masked]> 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:
>  
> 
> 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 follow this one. We are targeting the browser, right? What are the platform specific features you are thinking about?
> 
> 
> 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.
> 
> 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.
> 
> 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 <[email-masked]> wrote:
>> Hi Vittorio,
>>

---

From: David Waite <[email-masked]>
Date: Thu, 6 Dec 2018 13:24:01 -0700

One benefit of moving to code flow is that the refresh token can be used to check the validity of the user session (or rather, it allows the AS another avenue to force authentication events if the AS considers the user session to be expired (or has a drop in confidence).

There are indeed several ASs which, possibly because of an interpretation of OIDC, assume refresh tokens mean offline access and are mutually exclusive with public clients.

The ability to have refresh tokens track a user session is an AS implementation detail, and something that these ASs could choose to change to over time. In the meantime, there shouldn’t be anything preventing a client from doing the iframe and prompt=none step that they are doing today with implicit. Even if the AS is implemented in terms of stateless sessions, such functionality can be implemented by encoding user session information into the “code token".

-DW

> On Dec 6, 2018, at 11:51 AM, Phil Hunt <[email-masked]> wrote:
> 

> On Dec 6, 2018, at 7:47 AM, Justin Richer <[email-masked]> wrote:
>

---

From: Vittorio Bertocci <[email-masked]>
Date: Thu, 6 Dec 2018 12:42:21 -0800

> There are indeed several ASs which, possibly because of an interpretation
of OIDC, assume refresh tokens mean offline access and are mutually
exclusive with public clients.
AFAIK both Microsoft and Google do support RTs with public clients, but
their lifecycle is independent from the session with the AS (which is
represented by an artifact that is only indirectly accessible from
traditions public clients such as mobile and desktop apps).

As you say, the hidden iframe for retrieving a code via prompt=none remain
viable - and if at this time that is the only approach universally
available (forgetting ITP2 for a moment) that should be emphasized
accordingly in the document.

On Thu, Dec 6, 2018 at 12:24 PM David Waite <[email-masked]>
wrote:

> One benefit of moving to code flow is that the refresh token can be used
> to check the validity of the user session (or rather, it allows the AS
> another avenue to force authentication events if the AS considers the user
> session to be expired (or has a drop in confidence).
>
> There are indeed several ASs which, possibly because of an interpretation
> of OIDC, assume refresh tokens mean offline access and are mutually
> exclusive with public clients.
>
> The ability to have refresh tokens track a user session is an AS
> implementation detail, and something that these ASs could choose to change
> to over time. In the meantime, there shouldn’t be anything preventing a
> client from doing the iframe and prompt=none step that they are doing today
> with implicit. Even if the AS is implemented in terms of stateless
> sessions, such functionality can be implemented by encoding user session
> information into the “code token".
>
> -DW
>
> 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.
>
> 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
>
>
> I support the move away from the implicit flow toward using the
> authorization code flow (with PKCE and CORS)  for JavaScript applications.
> The limitations and assumptions that surrounded the design of the implicit
> flow back when we started no longer apply today. It was an optimization for
> a different time. Technology and platforms have moved forward, and our
> advice should move them forward as well. Furthermore, the ease of using the
> implicit flow incorrectly, and the damage that doing so can cause, has
> driven me to telling people to stop using it.
>
> There are a number of hacks that can patch the implicit flow to be
> slightly better in various ways — if you tack on the “hybrid” flow from
> OIDC or JARM plus post messages and a bunch of other stuff, then it can be
> better. But if you’re doing all of that, I think you really need to ask
> yourself: why? What do you gain from jumping through all of those hoops
> when a viable alternative sits there? Is it pride? I don’t see why we cling
> to it. To me, it’s like saying “hey sure my leg gets cut off when I do
> this, but I can stitch it back on!”, when you could simply avoid cutting
> your leg off in the first place. The best cure is prevention, and what’s
> being argued here is prevention.
>
> So many of OAuth’s problems in the wild come from over-use of the front
> channel, and any place we can move away from that is a good move.
>
> — Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 6 Dec 2018 12:53:57 -0800

How would the token endpoint detect login status of the user?

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Dec 6, 2018, at 12:24 PM, David Waite <[email-masked]> wrote:
> 
>> On Dec 6, 2018, at 11:51 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> On Dec 6, 2018, at 7:47 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: David Waite <[email-masked]>
Date: Thu, 6 Dec 2018 18:36:35 -0700

For systems with stateful sessions, you could reference that via the refresh token. If the access tokens are opaque to protected resources and meant to be used via introspection, you could also reference the state there as well.

For systems with stateteless sessions (e.g. JWT cookies), you have fewer options. A non-exhaustive list:
1. The refresh token can be modeled after a static user session policy, e.g. refresh will fail in four hours
2. Refresh tokens may have a sliding window within that policy, e.g. this refresh token is good for 30 minutes, but on refresh one will be issued good for another 30 minutes or the end of the four hour window, whichever is sooner
3. You can have a stateful system just for token revocations. This could reference a single session, or all sessions for the user (possibly under a specific client) generated before a particular time. The refresh (and possibly access) tokens would also have the same information in them for lookup. Logout could add an entry to this revocation list.

An aside:

This is kinda/sorta a  similar line of thinking that lead to DTVA ( https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/distributed-token-validity-api.txt <https://bitbucket.org/openid/connect/raw/f76ffe99c47d4698bc2995c32dc7a402dd6e8c47/distributed-token-validity-api.txt> ). The “Distributed” part was about pushing the ability to validate access and id_tokens close to the protected resources/RPs. The goal was also to build an API that supported this sort of token validation by otherwise stateless apps.

It wasn’t expected that refresh tokens were based on this system - we envisioned most AS/IDP instances to be built for authentication, and therefore already have requirements and business processes that would require more complex / stateful sessions.

-DW

> On Dec 6, 2018, at 1:53 PM, Phil Hunt <[email-masked]> wrote:
> 
>> On Dec 6, 2018, at 12:24 PM, David Waite <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Jim Manico <[email-masked]>
Date: Fri, 7 Dec 2018 07:50:51 -0500

I wanted to address Vittorio’s comment on XSS and LocalStorage.

One XSS attack can extract all of LocalStorage in one line of code. It’s trivial. And after studying XSS for years, I believe that most developers are not capable of building good XSS defense into complex UI’s and the trends to use Angular and React are not helping the situation; they just move the problem around.

Sure, few dev teams who have VERY specialized and rare developer resources can build XSS resistant apps, if they know how to properly escape, sanitize, validate, use safe JS, embed JSON properly, use sandboxing properly, and build unique CSP policies per page. And for most, good luck with that.

This is why I still hold onto the belief that OAuth solutions that store tokens in the browser for high risk apps is a bad idea. 

I still encourage developers who are not XSS guru’s to stick to cookie based sessions or stateless artifacts to talk to the back end and keep OAuth tokens only flying intra-server. It’s an unpopular opinion, but even moderately good XSS defense is equally unpopular.

At OWASP there are •several• guides you need to master to understand XSS defense. And this does not even scratch the surface of what is needed to master XSS defense in React/Angular, not to mention the complexity of CSP which requires per-page policies.

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Unpopularity yours,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

> On Dec 6, 2018, at 1:09 PM, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> Thank you Torsten.

---

From: David Waite <[email-masked]>
Date: Fri, 7 Dec 2018 15:27:01 -0700

> On Dec 7, 2018, at 5:50 AM, Jim Manico <[email-masked]> wrote:

<snip>
> I still encourage developers who are not XSS guru’s to stick to cookie based sessions or stateless artifacts to talk to the back end and keep OAuth tokens only flying intra-server. It’s an unpopular opinion, but even moderately good XSS defense is equally unpopular

Is this a matter of saying they should have an API for these clients which exposes less of the risky activities? That cookies provide a defense against XSS exfiltration? And/or other?

-DW

---

From: Nov Matake <[email-masked]>
Date: Sat, 8 Dec 2018 08:20:45 +0900

Hi Vittorio,

> 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’m not currently working on SPA apps nor apps using implicit flow.
However, my previous client is using hybrid flow to fetch access tokens both for JS App and its backend server in single OAuth dance transaction.

So I imagined how to use code flow for such case.
It would probably be using code in backend server and get narrower scoped token using RT, then pass it to JS app.

Then I added MTLS/TB bound feature in that flow as below.
https://www.websequencediagrams.com/?lz=bm90ZSBvdmVyIFNQQSwgUG9wdXAgV2luZG93LCBCYWNrZW5kLCBBdXRoWiBFUCwgVG9rZW4ABQVSZXNvdXJjZSBFUAplbmQgbm90ZQpTUEEtPgAwBzogSW5pdAoAPgctPlNQQToAQwdSZXEKYWx0IHcvIFRCCiAgADIFAHAMOiBPcGVuAFcNIACBEA0tPgB1CwBLDCAAgQ0MAEUQAHUJIHcvIFJlZmZlcmVkIFRCSUQAThEAgWsIABgdZWxzZSB3L28AgS0ZAIEMDAA_IQplbmQKAIJjCDwAgSgUTiAmIENvbnNlbnQAIAkAgikQQ29kZQoAgh0OAIMICQAXBQCDCAkAg0QIAC4GIChNVExTKQoAg1oIAIM9C0FUIGZvcgCEBwgAIwYtYm91bmQpICYgUlQABQ0ATBQAGwgARhgoVEIASgY_ADQLAIQqBgAYBQALDACDag5QSSBSZXF1ZXMAhEgFQQBfCQCFBAUACyAAVAU&s=earth <https://www.websequencediagrams.com/?lz=bm90ZSBvdmVyIFNQQSwgUG9wdXAgV2luZG93LCBCYWNrZW5kLCBBdXRoWiBFUCwgVG9rZW4ABQVSZXNvdXJjZSBFUAplbmQgbm90ZQpTUEEtPgAwBzogSW5pdAoAPgctPlNQQToAQwdSZXEKYWx0IHcvIFRCCiAgADIFAHAMOiBPcGVuAFcNIACBEA0tPgB1CwBLDCAAgQ0MAEUQAHUJIHcvIFJlZmZlcmVkIFRCSUQAThEAgWsIABgdZWxzZSB3L28AgS0ZAIEMDAA_IQplbmQKAIJjCDwAgSgUTiAmIENvbnNlbnQAIAkAgikQQ29kZQoAgh0OAIMICQAXBQCDCAkAg0QIAC4GIChNVExTKQoAg1oIAIM9C0FUIGZvcgCEBwgAIwYtYm91bmQpICYgUlQABQ0ATBQAGwgARhgoVEIASgY_ADQLAIQqBgAYBQALDACDag5QSSBSZXF1ZXMAhEgFQQBfCQCFBAUACyAAVAU&s=earth>

For me,  it seems very hard to issue TB-bound token for JS app and MTLS-bound token for its backend server at same time.

Do someone has workable recommendation for such case?

Thanks

nov

> On Dec 7, 2018, at 3:09, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> Thank you Torsten.
> 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>.
> On Thu, Dec 6, 2018 at 4:49 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Vittorio,
> 
> > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci <[email-masked] <mailto:[email-masked]>>:
> > 
> > Thank you!
> > On Wed, Dec 5, 2018 at 23:27 Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci <[email-masked] <mailto:[email-masked]>>:
> > 
> >> Hey Torsten/Tomek,
> >> On Wed, Dec 5, 2018 at 7:17 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >> Hi Tomek, 
> >> 
> >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <[email-masked] <mailto:[email-masked]>>:
> >> > 
> >> > Hi Torsten,
> >> > 
> >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >> > 
> >> > 
> >> > https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component <https://github.com/aaronpk/oauth-browser-based-apps/blob/master/oauth-browser-based-apps.md#javascript-app-with-a-backend-component>
> >> 
> >> I agree. 
> >> 
> >> That’s why we have the more general Security BCP and client-specific BCPs, like for native apps (https://tools.ietf.org/html/rfc8252 <https://tools.ietf.org/html/rfc8252>) and the new BCP for SPAs Aaron started to work on.
> >> 
> >> > Maybe it is just me :)
> >> 
> >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> >> > > 
> >> > > 
> >> > > Hi Tomek,
> >> > > 
> >> > > > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki <tstojecki=[email-masked] <mailto:[email-masked]>>:
> >> > > > 
> >> > > 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>
> >> > > https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-2.1.1>
> >> > > 
> >> > > > 
> >> > > 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 <https://tools.ietf.org/html/draft-ietf-oauth-security-topics-10#section-3.12>
> >> > > 
> >> > > kind regards,
> >> > > Torsten.
> >> > > 
> >> > > 
> >> > > > 
> >> > > > On Monday, December 3, 2018, 10:51:00 PM GMT+1, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote: 
> >> > > > 
> >> > > > I disagree. 
> >> > > > 
> >> > > > On Mon, Dec 3, 2018 at 10:41 AM Brian Campbell <bcampbell=[email-masked] <mailto:[email-masked]>> wrote:
> >> > > >> On Mon, Dec 3, 2018 at 8:39 AM John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
> >> > > >>> 
> >> > > >> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >> > > >> 
> >> > > > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >> > > > 
> >> > > > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >> > > https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> >> 
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 8 Dec 2018 14:12:21 +0100

Hi Vittorio,

> Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci <[email-masked]>:
> 
> Thank you Torsten.

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 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 mi…

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.

> 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. 

> 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. 

> 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.

> 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. 

> 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 8 Dec 2018 14:20:44 +0100

Hi Nov,

> Am 08.12.2018 um 00:20 schrieb Nov Matake <[email-masked]>:
> 

Issuing TB tokens in case of implicit is anyway hard. You need to issue a HTTP redirect to the RS and the RS must respond by HTTP redirecting the user agent to the AS (including the referred TBID). This is a new flow requiring an additional security analysis. Obviously, the RS would see the state value and could modify the request. And the RS endpoint must be protected against open redirection. 

> Do someone has workable recommendation for such case?

Why do you need to issue access tokens to both parties, the frontend and the backend? I would assume a clear layering would either let the SPA or the backend perform the calls towards Resource EP.

kind regards,
Torsten.

---

From: Nov Matake <[email-masked]>
Date: Sun, 9 Dec 2018 00:55:26 +0900

Hi Torsten,

> On Dec 8, 2018, at 22:20, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Nov,
> 

I understood.

But even using code flow, issuing TB-bound access token has same difficulty, doesn't it?
I don’t think this issue is relate to implicit flow.

> Why do you need to issue access tokens to both parties, the frontend and the backend? I would assume a clear layering would either let the SPA or the backend perform the calls towards Resource EP.

My client wanted to access Facebook API both from SPA (for realtime use case) and its backend (for batch processing).
This is normal motivation for developers using "response_type=code+token" today.

Using backend server as the API gateway for all API calls causes performance issue.

---

From: Jim Manico <[email-masked]>
Date: Sat, 8 Dec 2018 12:50:29 -0500

>  Is this a matter of saying they should have an API for these clients
which exposes less of the risky activities? That cookies provide a
defense against XSS exfiltration? And/or other?

HTTPOnly cookies prevent exfiltration of session or token data stored in
cookies. Those cookies can be REPLAYED via XSS (stored request forgery
via XSS) but they indeed cannot be stolen.

I also reject serverless SPA architectures that store tokens from a wide
variety of services, especially for high risk apps that use complex web
UI's. The chance of building such things securely for most teams is
painfully low.

- Jim

-- 
Jim Manico
Manicode Security
https://www.manicode.com

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 8 Dec 2018 22:29:51 +0100

> Am 08.12.2018 um 16:55 schrieb Nov Matake <[email-masked]>:
> 

Determining the referred token binding id and proving ownership of the key isn’t easy. Brian is the expert on that topic.

---

From: "Brock Allen" <[email-masked]>
Date: Sat, 08 Dec 2018 21:51:37 -0500

> How would the token endpoint detect login status of the user?

Oddball idea: why not use the cookie? If the assumption is that the RT is being used from a client-side browser-based app, and CORS allows for credentials, then perhaps this is a way to bind the RT to the user's browser session. The spec does say that alternative credentials are allowed at the token endpoint...

Sounds icky, but compared to iframes back to the authorize endpoint?

-Brock

---

From: Vittorio Bertocci <[email-masked]>
Date: Sat, 8 Dec 2018 19:27:47 -0800

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 <[email-masked]>
wrote:

> > 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
> 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 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.
>
>

> > The main concern is XSS. You can just google token session storage to
> 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.
>
> >
> >
> > I don't follow this one. We are targeting the browser, right? What are
> the platform specific features you are thinking about?
>
> 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.
> 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.
>
> >
> > 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.
>
> 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.
>
> > 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
> 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
> > > The user experience bar (number of prompts, full page redirects)
> should be the one afforded by implicit leveraging AS sessions via
> persistent cookies.
> >
> > > - 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
> >
> > 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.
> >
> > >> 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
> > >> > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki <[email-masked]
> >:
> > >> >
> > >> > Hi Torsten,
> > >> >
> > >> > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten
> Lodderstedt <[email-masked]> 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)
> > >> >
> > >> 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,
> > >> >
> > >> > 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
> > >> > > On Tuesday, December 4, 2018, 2:08:55 PM GMT+1, Torsten
> Lodderstedt <[email-masked]> wrote:
> > >> > >
> > >> > >
> > >> > > Hi Tomek,
> > >> > >
> > >> > > > 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.
> > >> > >
> > >> > >
> > >> > > > 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
> > >> > > 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
> > >> > > 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.
> > >> > >
> > >> > > >> CONFIDENTIALITY NOTICE: This email may contain confidential
> and privileged material for the sole use of the intended recipient(s). Any

---

From: David Waite <[email-masked]>
Date: Sun, 9 Dec 2018 01:57:27 -0700

> On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci <Vittorio=[email-masked]> wrote:
> 
> 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.

The AS is ultimately responsible for the security policy, though - if the AS policy isn’t supposed to allow my application access after the user hits log out, it should either:
1. Tie my application refresh tokens to be revoked at the logout event
2. Not give out refresh tokens to my application

Note that the session cookie is fulfilling the role of the refresh token in the second case. Also note that telling a browser to discard the cookie is not as good as supporting revoking it - if there is no revocation mechanism, a third party who gets the cookie/refresh token can use it for as long as policy allows.

I don’t expect application developers to use libraries that locally enforce more restrictive policy just because the operators of the AS aren’t doing their job setting appropriate policy for their clients. So this is really more of something that the AS needs to understand about their own policy.

-DW

---

From: Vittorio Bertocci <[email-masked]>
Date: Sun, 9 Dec 2018 03:10:15 -0800

I think we are running in circles. I am not talking about what provides
should do in an ideal world, I am describing something that some providers
do today that can impact developers in unintended ways if not take into
account. We can agree that in the ideal world providers would take steps to
fix the situation, and we should encourage to do so; but in the meanwhile
if we don't warn people of those potential issues, some people might end up
having issues. Let me try to rephrase one more time to see if I manage to
explain the issue I am concerned about here.

If you don't issue refresh tokens, the problem I am discussing doesn't
occur hence we can ignore that case.
I think that the point getting lost is: if you issue refresh tokens, per
the longer description in my mail many widely adopted providers will issue
refresh tokens whose validity doesn't end when the auth session from which
they originated is disposed of. I am not debating whether that's the way it
should be or not: it's a reality developers need to deal with today and
that they are powerless to change overnight.
The result is that if SPA apps are instructed to use refresh tokens as a
way of getting new tokens, as opposed to the usual implicit trick, they'll
now have a mean to get new tokens that is NOT tied to the session.
Whereas with implicit every app relying on the auth session with the AS
instantly loses the ability to call APIs, if developers use refresh tokens
that aren't revoked with the session (and as established, with some
providers they might not have a choice) they will have to perform explicit
steps to probe whether the auth session is still ongoing, and dispose of
the RTs themselves when it's not.

I already suggested how I think this could be handled in the document:
either not using RTs in the browser at all (for this potential problem,
plus the lack of support for rotating RTs, plus the discussions about the
difficulties storing them in XSS resistant fashion), or if we advise using
RTs at least giving specific warnings about this scenario (making sure that
the RTs issued by the provider of choice are session bound, and if they
aren't suggest to developers to take measures like deleting RTs explicitly
upon deletion of the auth session w the AS).(*)
This doesn't absolve the providers from aligning their capabilities to the
bar the scenario requires, but at least saves developers from introducing
new issues in their apps as they move away from implicit.

Some specific notes:

>Note that the session cookie is fulfilling the role of the refresh token
in the second case.

Yep. That's what I was suggesting with only retrieving the code in the
hidden browser and prompt=none for background renewals, no strict need for
RTs.
Note that I'd *love* to be able to use RTs in the browser as it would work
around the issues with ITP2; but it seems there are issues to iron out
before they can be adopted mainstream, or at least more guidance is
necessary than the one we've been giving so far.

> Also note that telling a browser to discard the cookie is not as good as
supporting revoking it - if there is no revocation mechanism, a third party
who gets the cookie/refresh token can use it for as long as policy allows.

Of course. I am not saying I don't want providers to support revocation, I
am saying today some important ones do not today. The fact that the
mitigation a developer can do when explicitly managing artifacts lifecycle
isn't as good as the one the provider could eventually do doesn't mean it's
worthless, especially when it's the only mitigation available.

>I don’t expect application developers to use libraries that locally
enforce more restrictive policy just because the operators of the AS aren’t
doing their job setting appropriate policy for their clients. So this is
really more of something that the AS needs to understand about their own
policy.

I don't understand this. Put yourself in the shoes of a developer using one
of those providers. For those developers, the feature set of their AS is an
externality- like the weather. They can make feature requests, fill survey,
send angry tweets- but if their entire codebase depend on tokens issued by
the AS and that AS only issues RTs with offline_access semantic, knowing
that the identirati don't agree with that limitation won't help them one
bit to update their app to code flow from implicit. Given that there are
things we can tell them (*) to either sidestep the problem altogether, or
at least handle it, I am not sure I understand the pushback on providing
that level of clarity.

On Sun, Dec 9, 2018 at 12:57 AM David Waite <[email-masked]>
wrote:

>
>
> On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci <
> Vittorio=[email-masked]> wrote:
>
> The AS is ultimately responsible for the security policy, though - if the
> AS policy isn’t supposed to allow my application access after the user hits
> log out, it should either:
> Note that the session cookie is fulfilling the role of the refresh token
> in the second case. Also note that telling a browser to discard the cookie
> is not as good as supporting revoking it - if there is no revocation
> mechanism, a third party who gets the cookie/refresh token can use it for
> as long as policy allows.
>
> I don’t expect application developers to use libraries that locally
> enforce more restrictive policy just because the operators of the AS aren’t
> doing their job setting appropriate policy for their clients. So this is
> really more of something that the AS needs to understand about their own
> policy.
>
> -DW
>

---

From: Phil Hunt <[email-masked]>
Date: Sun, 9 Dec 2018 08:53:03 -0800

Yes. This was my worry. 

Unless the oauth server is also an OIDC OP, it has no notion the user login state. That state is held in cookies belonging to a federated provider. 

The notion that javascript acting as a client and depends to the user login state is what sets these cases apart.  We have to be able to co-ordinate between resource api, AS authorization which builds off of some form of federation/sso. 

Phil

> On Dec 8, 2018, at 6:51 PM, Brock Allen <[email-masked]> wrote:
>