Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Vittorio Bertocci]

gt;>>> Implementations MAY consider to move authorization code exchange and
>>>> handling of access and refresh tokens to a backend component in order to
>>>> fulfill their security goals.
>>>>
>>>> Security of the connection between code running in the browser and this
>>>> backend component is assumed to utilize browser-level protection
>>>> mechanisms. Details are out of scope of this document.
>>>> —
>>>>
>>>> > Am 03.12.2018 um 11:19 schrieb John Bradley :
>>>> >
>>>> > This is my point.
>>>> >
>>>> > From a security perspective we have a server based confidential
>>>> client...   The fact that it has a angular or other JS UI protected by a
>>>> cookie seems to not be especially relucent to OAuth.
>>>> >
>>>> > Perhaps from the developer point of view they have a JS SPA and the
>>>> only difference to them is in one case they are including the OAuth client
>>>> and in the other they are using a server based proxy. So they see it as the
>>>> same.
>>>> >
>>>> > Perhaps it is perspective.
>>>> >
>>>> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki >>> > In this type of deployment, as far as OAuth is concerned, isn't the
>>>> backend web server a confidential client? Is there even anything unique to
>>>> this situation as far as OAuth security goes?
>>>> >
>>>> > I wouldn't have expected an Angular app that talks to its own server
>>>> backend that's managing OAuth credentials to fall under the umbrella of
>>>> this BCP.
>>>> >
>>>> > 
>>>> > Aaron Parecki
>>>> > aaronparecki.com
>>>> >
>>>> >
>>>> >
>>>> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <
>>>> tors...@lodderstedt.net> wrote:
>>>> > the UI is rendered in the frontend, UI control flow is in the
>>>> frontend... just a different cut through the web app’s layering
>>>> >
>>>> > All Angular apps I have seen so far work that way. And it makes a lot
>>>> of sense to me. The backend can aggregate and optimize access to the
>>>> underlying services without the need to fully expose them.
>>>> >
>>>> > Am 02.12.2018 um 00:44 schrieb John Bradley :
>>>> >
>>>> >> How is that different from a regular server client with a web
>>>> interface if the backed is doing the API calls to the RS?
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>> >>> I forgot to mention another (architectural) option: split an
>>>> application into frontend provided by JS in the browser and a backend,
>>>> which takes care of the business logic and handles tokens and API access.
>>>> Replay detection at the interface between SPA and backend can utilize
>>>> standard web techniques (see OWASP). The backend in turn can use mTLS for
>>>> sender constraining.
>>>> >>>
>>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>>>> tors...@lodderstedt.net>:
>>>> >>>
>>>> >>>> IMHO the best mechanism at hand currently to cope with token
>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>>>> detection) and issue short living and privilege restricted access tokens.
>>>> >>>>
>>>> >>>> Sender constrained access tokens in SPAs need adoption of token
>>>> binding or alternative mechanism. mtls could potentially work in
>>>> deployments with automated cert rollout but browser UX and interplay with
>>>> fetch needs some work. We potentially must consider to warm up application
>>>> level PoP mechanisms in conjunction with web crypto. Another path to be
>>>> evaluated could be web auth.
>>>> >>>>
>>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>>>> hannes.tschofe...@arm.com>:
>>>> >>>>
>>>> >>>>> I share the concern Brian has, which is also the conclusion I
>>>> came up with in my other email sent a few minutes ago.
>>>> >>>>>
>>>> >>>>>
>>&

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Aaron Parecki]

e access to the
>>> underlying services without the need to fully expose them.
>>> >
>>> > Am 02.12.2018 um 00:44 schrieb John Bradley :
>>> >
>>> >> How is that different from a regular server client with a web
>>> interface if the backed is doing the API calls to the RS?
>>> >>
>>> >>
>>> >>
>>> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> >>> I forgot to mention another (architectural) option: split an
>>> application into frontend provided by JS in the browser and a backend,
>>> which takes care of the business logic and handles tokens and API access.
>>> Replay detection at the interface between SPA and backend can utilize
>>> standard web techniques (see OWASP). The backend in turn can use mTLS for
>>> sender constraining.
>>> >>>
>>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>>> tors...@lodderstedt.net>:
>>> >>>
>>> >>>> IMHO the best mechanism at hand currently to cope with token
>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>>> detection) and issue short living and privilege restricted access tokens.
>>> >>>>
>>> >>>> Sender constrained access tokens in SPAs need adoption of token
>>> binding or alternative mechanism. mtls could potentially work in
>>> deployments with automated cert rollout but browser UX and interplay with
>>> fetch needs some work. We potentially must consider to warm up application
>>> level PoP mechanisms in conjunction with web crypto. Another path to be
>>> evaluated could be web auth.
>>> >>>>
>>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>>> hannes.tschofe...@arm.com>:
>>> >>>>
>>> >>>>> I share the concern Brian has, which is also the conclusion I came
>>> up with in my other email sent a few minutes ago.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> From: OAuth  On Behalf Of Brian Campbell
>>> >>>>> Sent: Friday, November 30, 2018 11:43 PM
>>> >>>>> To: Torsten Lodderstedt 
>>> >>>>> Cc: oauth 
>>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
>>> tors...@lodderstedt.net> wrote:
>>> >>>>>
>>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >> >:
>>> >>>>> >
>>> >>>>> > So you mean at the resource server ensuring the token was really
>>> issued to the client? Isn't that an inherent limitation of all bearer
>>> tokens (modulo HTTP token binding, which is still some time off)?
>>> >>>>>
>>> >>>>> Sure. That’s why the Security BCP recommends use of TLS-based
>>> methods for sender constraining access tokens (
>>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>> Token Binding for OAuth (
>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well
>>> as Mutual TLS for OAuth (
>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
>>> available.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> Unfortunately even when using the token endpoint, for SPA /
>>> in-browser client applications, the potential mechanisms for
>>> sender/key-constraining access tokens don't work very well or maybe don't
>>> work at all. So I don't know that the recommendation is very realistic.
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> 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.
>>> >>>>>
>>> >>>>> 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
>>> >>>> OAuth@ietf.org
>>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>>> >>>
>>> >>>
>>> >>> ___
>>> >>> OAuth mailing list
>>> >>>
>>> >>> oa...@ietf..org 
>>> >>> https://www.ietf.org/mailman/listinfo/oauth
>>> >> ___
>>> >> OAuth mailing list
>>> >> OAuth@ietf.org
>>> >> https://www.ietf.org/mailman/listinfo/oauth
>>> > ___
>>> > OAuth mailing list
>>> > OAuth@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> --
>> 
>> Aaron Parecki
>> aaronparecki.com
>> @aaronpk <http://twitter.com/aaronpk>
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brian Campbell]

 in turn can use mTLS for
>> sender constraining.
>> >>>
>> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>> tors...@lodderstedt.net>:
>> >>>
>> >>>> IMHO the best mechanism at hand currently to cope with token
>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>> detection) and issue short living and privilege restricted access tokens..
>> >>>>
>> >>>> Sender constrained access tokens in SPAs need adoption of token
>> binding or alternative mechanism. mtls could potentially work in
>> deployments with automated cert rollout but browser UX and interplay with
>> fetch needs some work. We potentially must consider to warm up application
>> level PoP mechanisms in conjunction with web crypto. Another path to be
>> evaluated could be web auth.
>> >>>>
>> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.com>:
>> >>>>
>> >>>>> I share the concern Brian has, which is also the conclusion I came
>> up with in my other email sent a few minutes ago.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> From: OAuth  On Behalf Of Brian Campbell
>> >>>>> Sent: Friday, November 30, 2018 11:43 PM
>> >>>>> To: Torsten Lodderstedt 
>> >>>>> Cc: oauth 
>> >>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>> >>>>>
>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen > >:
>> >>>>> >
>> >>>>> > So you mean at the resource server ensuring the token was really
>> issued to the client? Isn't that an inherent limitation of all bearer
>> tokens (modulo HTTP token binding, which is still some time off)?
>> >>>>>
>> >>>>> Sure. That’s why the Security BCP recommends use of TLS-based
>> methods for sender constraining access tokens (
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>> Token Binding for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well
>> as Mutual TLS for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
>> available.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Unfortunately even when using the token endpoint, for SPA /
>> in-browser client applications, the potential mechanisms for
>> sender/key-constraining access tokens don't work very well or maybe don't
>> work at all. So I don't know that the recommendation is very realistic.
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> 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.
>> >>>>>
>> >>>>> 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
>> >>>> OAuth@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>
>> >>>
>> >>> ___
>> >>> OAuth mailing list
>> >>>
>> >>> oa...@ietf..org 
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >> ___
>> >> OAuth mailing list
>> >> OAuth@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/oauth
>> > ___
>> > OAuth mailing list
>> > OAuth@ietf.org
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>> --
> 
> Aaron Parecki
> aaronparecki.com
> @aaronpk <http://twitter.com/aaronpk>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Aaron Parecki]

I support adding something to that effect, but would like to make it clear
that this removes the app from being covered under this BCP. How about:

---
Implementations MAY consider moving the authorization code exchange and
handling of access and refresh tokens to a backend component in order to
avoid the risks inherent in handling access tokens from a purely browser
based app. In this case, the backend component can be a confidential client
and can be secured accordingly.

Security of the connection between code running in the browser and this
backend component is assumed to utilize browser-level protection
mechanisms. Details are out of scope of this document.
---




On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt 
wrote:

> Interesting. Even on this list people felt to see that moving some logic
> to a backend could solve some of the problems raised. What I want to convey
> is: the solution to a problem in the OAuth space does not necessarily need
> to be found on the OAuth protocol level. That’s a best practice in the same
> way as some OAuth pattern.
>
> What I’m suggesting is a statement in the BCP like
>
> —
> Implementations MAY consider to move authorization code exchange and
> handling of access and refresh tokens to a backend component in order to
> fulfill their security goals.
>
> Security of the connection between code running in the browser and this
> backend component is assumed to utilize browser-level protection
> mechanisms. Details are out of scope of this document.
> —
>
> > Am 03.12.2018 um 11:19 schrieb John Bradley :
> >
> > This is my point.
> >
> > From a security perspective we have a server based confidential client.
>  The fact that it has a angular or other JS UI protected by a cookie seems
> to not be especially relucent to OAuth.
> >
> > Perhaps from the developer point of view they have a JS SPA and the only
> difference to them is in one case they are including the OAuth client and
> in the other they are using a server based proxy. So they see it as the
> same.
> >
> > Perhaps it is perspective.
> >
> > On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki  > In this type of deployment, as far as OAuth is concerned, isn't the
> backend web server a confidential client? Is there even anything unique to
> this situation as far as OAuth security goes?
> >
> > I wouldn't have expected an Angular app that talks to its own server
> backend that's managing OAuth credentials to fall under the umbrella of
> this BCP.
> >
> > 
> > Aaron Parecki
> > aaronparecki.com
> >
> >
> >
> > On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
> > the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
> >
> > All Angular apps I have seen so far work that way. And it makes a lot of
> sense to me. The backend can aggregate and optimize access to the
> underlying services without the need to fully expose them.
> >
> > Am 02.12.2018 um 00:44 schrieb John Bradley :
> >
> >> How is that different from a regular server client with a web interface
> if the backed is doing the API calls to the RS?
> >>
> >>
> >>
> >> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
> >>> I forgot to mention another (architectural) option: split an
> application into frontend provided by JS in the browser and a backend,
> which takes care of the business logic and handles tokens and API access.
> Replay detection at the interface between SPA and backend can utilize
> standard web techniques (see OWASP). The backend in turn can use mTLS for
> sender constraining.
> >>>
> >>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
> tors...@lodderstedt.net>:
> >>>
> >>>> IMHO the best mechanism at hand currently to cope with token
> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
> detection) and issue short living and privilege restricted access tokens.
> >>>>
> >>>> Sender constrained access tokens in SPAs need adoption of token
> binding or alternative mechanism. mtls could potentially work in
> deployments with automated cert rollout but browser UX and interplay with
> fetch needs some work. We potentially must consider to warm up application
> level PoP mechanisms in conjunction with web crypto. Another path to be
> evaluated could be web auth.
> >>>>
> >>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
> >>>>
> >>>>> I share the concern Brian has

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Interesting. Even on this list people felt to see that moving some logic to a 
backend could solve some of the problems raised. What I want to convey is: the 
solution to a problem in the OAuth space does not necessarily need to be found 
on the OAuth protocol level. That’s a best practice in the same way as some 
OAuth pattern. 

What I’m suggesting is a statement in the BCP like

—
Implementations MAY consider to move authorization code exchange and handling 
of access and refresh tokens to a backend component in order to fulfill their 
security goals. 

Security of the connection between code running in the browser and this backend 
component is assumed to utilize browser-level protection mechanisms. Details 
are out of scope of this document. 
—

> Am 03.12.2018 um 11:19 schrieb John Bradley :
> 
> This is my point.  
> 
> From a security perspective we have a server based confidential client.   The 
> fact that it has a angular or other JS UI protected by a cookie seems to not 
> be especially relucent to OAuth.  
> 
> Perhaps from the developer point of view they have a JS SPA and the only 
> difference to them is in one case they are including the OAuth client and in 
> the other they are using a server based proxy. So they see it as the same.
> 
> Perhaps it is perspective. 
> 
> On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki  In this type of deployment, as far as OAuth is concerned, isn't the backend 
> web server a confidential client? Is there even anything unique to this 
> situation as far as OAuth security goes? 
> 
> I wouldn't have expected an Angular app that talks to its own server backend 
> that's managing OAuth credentials to fall under the umbrella of this BCP.
> 
> 
> Aaron Parecki
> aaronparecki.com
> 
> 
> 
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt  
> wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend. just 
> a different cut through the web app’s layering 
> 
> All Angular apps I have seen so far work that way. And it makes a lot of 
> sense to me. The backend can aggregate and optimize access to the underlying 
> services without the need to fully expose them.
> 
> Am 02.12.2018 um 00:44 schrieb John Bradley :
> 
>> How is that different from a regular server client with a web interface if 
>> the backed is doing the API calls to the RS?
>> 
>> 
>> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an application 
>>> into frontend provided by JS in the browser and a backend, which takes care 
>>> of the business logic and handles tokens and API access. Replay detection 
>>> at the interface between SPA and backend can utilize standard web 
>>> techniques (see OWASP). The backend in turn can use mTLS for sender 
>>> constraining.
>>> 
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>> :
>>> 
>>>> IMHO the best mechanism at hand currently to cope with token 
>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>> detection) and issue short living and privilege restricted access tokens.
>>>> 
>>>> Sender constrained access tokens in SPAs need adoption of token binding or 
>>>> alternative mechanism. mtls could potentially work in deployments with 
>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>> work. We potentially must consider to warm up application level PoP 
>>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>>> could be web auth.
>>>> 
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>> :
>>>> 
>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>> with in my other email sent a few minutes ago.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: OAuth  On Behalf Of Brian Campbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt 
>>>>> Cc: oauth 
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>>  wrote:
>>>>> 
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>>> > 
>>>>> > So you mean at the resource server ensuring the token was really issued 
>>>>> > to the 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[John Bradley]

This is my point.

>From a security perspective we have a server based confidential client.
 The fact that it has a angular or other JS UI protected by a cookie seems
to not be especially relucent to OAuth.

Perhaps from the developer point of view they have a JS SPA and the only
difference to them is in one case they are including the OAuth client and
in the other they are using a server based proxy. So they see it as the
same.

Perhaps it is perspective.

On Mon, Dec 3, 2018, 12:44 AM Aaron Parecki  In this type of deployment, as far as OAuth is concerned, isn't the
> backend web server a confidential client? Is there even anything unique to
> this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own server
> backend that's managing OAuth credentials to fall under the umbrella of
> this BCP.
>
> 
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> the UI is rendered in the frontend, UI control flow is in the frontend.
>> just a different cut through the web app’s layering
>>
>> All Angular apps I have seen so far work that way. And it makes a lot of
>> sense to me. The backend can aggregate and optimize access to the
>> underlying services without the need to fully expose them.
>>
>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>
>> How is that different from a regular server client with a web interface
>> if the backed is doing the API calls to the RS?
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>
>> I forgot to mention another (architectural) option: split an application
>> into frontend provided by JS in the browser and a backend, which takes care
>> of the business logic and handles tokens and API access. Replay detection
>> at the interface between SPA and backend can utilize standard web
>> techniques (see OWASP). The backend in turn can use mTLS for sender
>> constraining.
>>
>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>> tors...@lodderstedt.net>:
>>
>> IMHO the best mechanism at hand currently to cope with token
>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>> detection) and issue short living and privilege restricted access tokens..
>>
>> Sender constrained access tokens in SPAs need adoption of token binding
>> or alternative mechanism. mtls could potentially work in deployments with
>> automated cert rollout but browser UX and interplay with fetch needs some
>> work. We potentially must consider to warm up application level PoP
>> mechanisms in conjunction with web crypto. Another path to be evaluated
>> could be web auth.
>>
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.com>:
>>
>> I share the concern Brian has, which is also the conclusion I came up
>> with in my other email sent a few minutes ago.
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Brian Campbell
>> *Sent:* Friday, November 30, 2018 11:43 PM
>> *To:* Torsten Lodderstedt 
>> *Cc:* oauth 
>> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>
>>
>>
>>
>>
>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>> >
>> > So you mean at the resource server ensuring the token was really issued
>> to the client? Isn't that an inherent limitation of all bearer tokens
>> (modulo HTTP token binding, which is still some time off)?
>>
>> Sure. That’s why the Security BCP recommends use of TLS-based methods for
>> sender constraining access tokens (
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>> Token Binding for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
>> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as
>> well as Mutual TLS for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
>> available.
>>
>>
>>
>> Unfortunately even when using the token endpoint, for SPA / in-browser
>> client applications, the potential mechanisms for sender/key-constraining
>> access tokens don't work very well or maybe don't work at all. So I don't
>> know that the recommendation is very realistic.
>>
>>
>>
>>
>> *CONFIDENTIALITY NOTICE: This email may contain confidential and
>> privileged material for the sole use of the int

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt  
> wrote:
> 
> I think the BCP needs to point out there are solutions beyond an app directly 
> interacting with AS and RSs from the browser. Otherwise people get the wrong 
> impression this is the only way to go. To the contrary and as I pointed out, 
> there are a lot of SPAs working as UI of a larger application. 

My feeling is different - these applications all _could_ be 
expressed/implemented in terms of OAuth 2/OpenID Connect. Instead of 
authorization being done via opaque access tokens, the non-OAuth application 
has authorization tracked via opaque cookies.

I think we can state this, and that many of the rules given could be used
> 
> Any multi user app needs a database. Will this database be directly exposed 
> to the frontend? I don’t think so. There will be a backend, exposing relevant 
> capabilities to the SPA.

Sure, but this doesn’t change the interface being exposed around the database 
as being a protected resource - just one protected by a token acquired via a 
different non-OAuth manner

> And if this app also uses external services, where do you want to store the 
> respective refresh tokens? In the browser’s local storage? I don’t believe 
> so. They will go into the same backend & database.

> And there are other reasons: No one will ever be able to implement a PSD2 TPP 
> as a stand-alone SPA, obviously because it requires a confidential client but 
> there are more aspects. 

You could have your AS also be responsible for fetching/maintaining remote 
tokens, and issue local environment tokens. It could expose either local 
protected resources which use these remote resources, or provide a reverse 
proxy that translates the calls directly, including applying the remote access 
token. This also looks very similar whether you are talking about the 
javascript being OAuth or using a proprietary cookie-based system.

> Moreover, some security objectives can only be achieved if a backend is used. 
> That’s how the discussion started (token binding and the like).

Cookies have browser-level support, so they can have browser-level protections 
asked for (SameSite, HttpOnly, Secure, separate path/domain limiting). IMHO, 
the other differences are apples-to-oranges comparing different protected 
resources, not access-vs-other-tokens.

Is there value in defining “official” recommendations around access tokens 
within cookies?

> IMHO omitting this option significantly reduces the relevance of the BCP.
> I’m not saying we shall describe the interaction between frontend and backend 
> in detail. I advocate for pointing out this option and its benefits. That’s 
> it.

Again, I think a significant portion of recommendations would have value for 
non-oauth-client javascript. But I think we should focus on defining solely in 
terms of OAuth clients. I agree we should point out the option in the sense 
that it will help people understand that it doesn’t significantly affect the 
security requirements. The rest seem points around protected resources and 
cases for a local AS to house business logic.

A lot of the above might be recommendations around protected resources and 
multi-level authorization (for example: having clients interact with a local 
environment which may behind-the-scenes be using OAuth itself with remote 
services). I’m unsure how you would rein in scope on something like this, 
though.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I think the BCP needs to point out there are solutions beyond an app directly 
interacting with AS and RSs from the browser. Otherwise people get the wrong 
impression this is the only way to go. To the contrary and as I pointed out, 
there are a lot of SPAs working as UI of a larger application. 

Any multi user app needs a database. Will this database be directly exposed to 
the frontend? I don’t think so. There will be a backend, exposing relevant 
capabilities to the SPA.

And if this app also uses external services, where do you want to store the 
respective refresh tokens? In the browser’s local storage? I don’t believe so. 
They will go into the same backend & database.

And there are other reasons: No one will ever be able to implement a PSD2 TPP 
as a stand-alone SPA, obviously because it requires a confidential client but 
there are more aspects. 

Moreover, some security objectives can only be achieved if a backend is used.. 
That’s how the discussion started (token binding and the like).

IMHO omitting this option significantly reduces the relevance of the BCP.

I’m not saying we shall describe the interaction between frontend and backend 
in detail. I advocate for pointing out this option and its benefits. That’s it.

> Am 03.12.2018 um 08:30 schrieb Hans Zandbelt :
> 
> 
>> On Mon, Dec 3, 2018 at 4:18 AM David Waite  
>> wrote:
>> If (as Hans proposed) there was a mechanism for javascript to get access 
>> tokens to interact with protected resources in lieu of the client, there 
>> could be BCP around managing that (which would likely also overlap with a 
>> genuine javascript-in-browser client), but unfortunately there aren’t 
>> technical specs to support that sort of architecture yet.
> 
> I agree with Aaron and David that this should be written up elsewhere and 
> hopefully be referred to from this BCP as it is relevant; anyone willing to 
> contribute and/or suggest where "elsewhere" is?
> 
> Hans.
> 
>> 
>> -DW
>> 
>>> On Dec 2, 2018, at 4:43 PM, Aaron Parecki  wrote:
>>> 
>>> In this type of deployment, as far as OAuth is concerned, isn't the backend 
>>> web server a confidential client? Is there even anything unique to this 
>>> situation as far as OAuth security goes? 
>>> 
>>> I wouldn't have expected an Angular app that talks to its own server 
>>> backend that's managing OAuth credentials to fall under the umbrella of 
>>> this BCP.
>>> 
>>> 
>>> Aaron Parecki
>>> aaronparecki.com
>>> 
>>> 
>>> 
>>>> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt 
>>>>  wrote:
>>>> the UI is rendered in the frontend, UI control flow is in the frontend. 
>>>> just a different cut through the web app’s layering 
>>>> 
>>>> All Angular apps I have seen so far work that way. And it makes a lot of 
>>>> sense to me. The backend can aggregate and optimize access to the 
>>>> underlying services without the need to fully expose them.
>>>> 
>>>>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>>>> 
>>>>> How is that different from a regular server client with a web interface 
>>>>> if the backed is doing the API calls to the RS?
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>>>> I forgot to mention another (architectural) option: split an application 
>>>>>> into frontend provided by JS in the browser and a backend, which takes 
>>>>>> care of the business logic and handles tokens and API access. Replay 
>>>>>> detection at the interface between SPA and backend can utilize standard 
>>>>>> web techniques (see OWASP). The backend in turn can use mTLS for sender 
>>>>>> constraining.
>>>>>> 
>>>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>>>>> :
>>>>>> 
>>>>>>> IMHO the best mechanism at hand currently to cope with token 
>>>>>>> leakage/replay in SPAs is to use refresh tokens (rotating 
>>>>>>> w/ replay detection) and issue short living and privilege restricted 
>>>>>>> access tokens.
>>>>>>> 
>>>>>>> Sender constrained access tokens in SPAs need adoption of token binding 
>>>>>>> or alternative mechanism. mtls could potentially work in deployments 
>>>>>>> with automated cert rollout but browser UX and in

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Hans Zandbelt]

On Mon, Dec 3, 2018 at 4:18 AM David Waite 
wrote:

> If (as Hans proposed) there was a mechanism for javascript to get access
> tokens to interact with protected resources in lieu of the client, there
> could be BCP around managing that (which would likely also overlap with a
> genuine javascript-in-browser client), but unfortunately there aren’t
> technical specs to support that sort of architecture yet.
>

I agree with Aaron and David that this should be written up elsewhere and
hopefully be referred to from this BCP as it is relevant; anyone willing to
contribute and/or suggest where "elsewhere" is?

Hans.


> -DW
>
> On Dec 2, 2018, at 4:43 PM, Aaron Parecki  wrote:
>
> In this type of deployment, as far as OAuth is concerned, isn't the
> backend web server a confidential client? Is there even anything unique to
> this situation as far as OAuth security goes?
>
> I wouldn't have expected an Angular app that talks to its own server
> backend that's managing OAuth credentials to fall under the umbrella of
> this BCP.
>
> 
> Aaron Parecki
> aaronparecki.com
>
>
>
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
>> the UI is rendered in the frontend, UI control flow is in the frontend.
>> just a different cut through the web app’s layering
>>
>> All Angular apps I have seen so far work that way. And it makes a lot of
>> sense to me. The backend can aggregate and optimize access to the
>> underlying services without the need to fully expose them.
>>
>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>
>> How is that different from a regular server client with a web interface
>> if the backed is doing the API calls to the RS?
>>
>>
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>
>> I forgot to mention another (architectural) option: split an application
>> into frontend provided by JS in the browser and a backend, which takes care
>> of the business logic and handles tokens and API access. Replay detection
>> at the interface between SPA and backend can utilize standard web
>> techniques (see OWASP). The backend in turn can use mTLS for sender
>> constraining.
>>
>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
>> tors...@lodderstedt.net>:
>>
>> IMHO the best mechanism at hand currently to cope with token
>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
>> detection) and issue short living and privilege restricted access tokens..
>>
>> Sender constrained access tokens in SPAs need adoption of token binding
>> or alternative mechanism. mtls could potentially work in deployments with
>> automated cert rollout but browser UX and interplay with fetch needs some
>> work. We potentially must consider to warm up application level PoP
>> mechanisms in conjunction with web crypto. Another path to be evaluated
>> could be web auth.
>>
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
>> hannes.tschofe...@arm.com>:
>>
>> I share the concern Brian has, which is also the conclusion I came up
>> with in my other email sent a few minutes ago.
>>
>>
>>
>> *From:* OAuth  *On Behalf Of *Brian Campbell
>> *Sent:* Friday, November 30, 2018 11:43 PM
>> *To:* Torsten Lodderstedt 
>> *Cc:* oauth 
>> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>
>>
>>
>>
>>
>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
>> tors...@lodderstedt.net> wrote:
>>
>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>> >
>> > So you mean at the resource server ensuring the token was really issued
>> to the client? Isn't that an inherent limitation of all bearer tokens
>> (modulo HTTP token binding, which is still some time off)?
>>
>> Sure. That’s why the Security BCP recommends use of TLS-based methods for
>> sender constraining access tokens (
>> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>> Token Binding for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
>> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as
>> well as Mutual TLS for OAuth (
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
>> available.
>>
>>
>>
>> Unfortunately even when using the token endpoint, for SPA / in-browser
>> client applications, the potential mechanisms for sender/key-constraining
>> access tokens don't work very well or maybe don't work at all. So I 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

Agreed, if the BCP is meant to describe javascript behavior for best practices 
as respect to being an OAuth client, I’m unsure what would belong in this 
document for javascript which is instead interacting over non-standard 
mechanisms with an OAuth client. 

Instead, it would be generalized browser javascript security practices. It 
would be sure to overlap with some of the recommendations made to a client 
managing OAuth in the browser, but such a spec wouldn’t be under the umbrella 
of the OAuth WG - would it? We would be talking about general non-OAuth browser 
security practices around important cookies.

If (as Hans proposed) there was a mechanism for javascript to get access tokens 
to interact with protected resources in lieu of the client, there could be BCP 
around managing that (which would likely also overlap with a genuine 
javascript-in-browser client), but unfortunately there aren’t technical specs 
to support that sort of architecture yet.

-DW

> On Dec 2, 2018, at 4:43 PM, Aaron Parecki  wrote:
> 
> In this type of deployment, as far as OAuth is concerned, isn't the backend 
> web server a confidential client? Is there even anything unique to this 
> situation as far as OAuth security goes? 
> 
> I wouldn't have expected an Angular app that talks to its own server backend 
> that's managing OAuth credentials to fall under the umbrella of this BCP.
> 
> 
> Aaron Parecki
> aaronparecki.com <http://aaronparecki.com/>
> 
> 
> 
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt  <mailto:tors...@lodderstedt.net>> wrote:
> the UI is rendered in the frontend, UI control flow is in the frontend. just 
> a different cut through the web app’s layering 
> 
> All Angular apps I have seen so far work that way. And it makes a lot of 
> sense to me. The backend can aggregate and optimize access to the underlying 
> services without the need to fully expose them.
> 
> Am 02.12.2018 um 00:44 schrieb John Bradley  <mailto:ve7...@ve7jtb.com>>:
> 
>> How is that different from a regular server client with a web interface if 
>> the backed is doing the API calls to the RS?
>> 
>> 
>> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>> I forgot to mention another (architectural) option: split an application 
>>> into frontend provided by JS in the browser and a backend, which takes care 
>>> of the business logic and handles tokens and API access. Replay detection 
>>> at the interface between SPA and backend can utilize standard web 
>>> techniques (see OWASP). The backend in turn can use mTLS for sender 
>>> constraining.
>>> 
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt >> <mailto:tors...@lodderstedt.net>>:
>>> 
>>>> IMHO the best mechanism at hand currently to cope with token 
>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>> detection) and issue short living and privilege restricted access tokens.
>>>> 
>>>> Sender constrained access tokens in SPAs need adoption of token binding or 
>>>> alternative mechanism. mtls could potentially work in deployments with 
>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>> work. We potentially must consider to warm up application level PoP 
>>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>>> could be web auth.
>>>> 
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>> mailto:hannes.tschofe...@arm.com>>:
>>>> 
>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>> with in my other email sent a few minutes ago.
>>>>> 
>>>>>  
>>>>> 
>>>>> From: OAuth mailto:oauth-boun...@ietf.org>> On 
>>>>> Behalf Of Brian Campbell
>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>> To: Torsten Lodderstedt >>>> <mailto:tors...@lodderstedt.net>>
>>>>> Cc: oauth mailto:oauth@ietf.org>>
>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>> 
>>>>>  
>>>>> 
>>>>>  
>>>>> 
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>> mailto:tors...@lodderstedt.net>> wrote:
>>>>> 
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen >>>> > <mailto:brockal...@gmail.com>>:
>>>>> > 
>>>>> > So you mean at the resource server en

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Phil Hunt]

You may be placing undue confidence in that gateway acting as a confidential 
client but having no real security of its own and which could be easily duped. 

Phil

> On Dec 2, 2018, at 3:43 PM, Aaron Parecki  wrote:
> 
> In this type of deployment, as far as OAuth is concerned, isn't the backend 
> web server a confidential client? Is there even anything unique to this 
> situation as far as OAuth security goes? 
> 
> I wouldn't have expected an Angular app that talks to its own server backend 
> that's managing OAuth credentials to fall under the umbrella of this BCP.
> 
> 
> Aaron Parecki
> aaronparecki.com
> 
> 
> 
>> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt 
>>  wrote:
>> the UI is rendered in the frontend, UI control flow is in the frontend. just 
>> a different cut through the web app’s layering 
>> 
>> All Angular apps I have seen so far work that way. And it makes a lot of 
>> sense to me. The backend can aggregate and optimize access to the underlying 
>> services without the need to fully expose them.
>> 
>>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>> 
>>> How is that different from a regular server client with a web interface if 
>>> the backed is doing the API calls to the RS?
>>> 
>>> 
>>> 
>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>> I forgot to mention another (architectural) option: split an application 
>>>> into frontend provided by JS in the browser and a backend, which takes 
>>>> care of the business logic and handles tokens and API access. Replay 
>>>> detection at the interface between SPA and backend can utilize standard 
>>>> web techniques (see OWASP). The backend in turn can use mTLS for sender 
>>>> constraining.
>>>> 
>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>>> :
>>>> 
>>>>> IMHO the best mechanism at hand currently to cope with token 
>>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>>> detection) and issue short living and privilege restricted access tokens.
>>>>> 
>>>>> Sender constrained access tokens in SPAs need adoption of token binding 
>>>>> or alternative mechanism. mtls could potentially work in deployments with 
>>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>>> work. We potentially must consider to warm up application level PoP 
>>>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>>>> could be web auth.
>>>>> 
>>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>>> :
>>>>> 
>>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>>> with in my other email sent a few minutes ago.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> From: OAuth  On Behalf Of Brian Campbell
>>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>>> To: Torsten Lodderstedt 
>>>>>> Cc: oauth 
>>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> 
>>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>>>> > 
>>>>>> > So you mean at the resource server ensuring the token was really 
>>>>>> > issued to the client? Isn't that an inherent 
>>>>>> > limitation of all bearer tokens (modulo HTTP token binding, which is 
>>>>>> > still some time off)?
>>>>>> 
>>>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods 
>>>>>> for sender constraining access tokens 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>>>>  Token Binding for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well 
>>>>>> as Mutual TLS for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
>>>>>> available.
>>>>>> 
>>>>>>  
>>>>>&

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Aaron Parecki]

In this type of deployment, as far as OAuth is concerned, isn't the backend
web server a confidential client? Is there even anything unique to this
situation as far as OAuth security goes?

I wouldn't have expected an Angular app that talks to its own server
backend that's managing OAuth credentials to fall under the umbrella of
this BCP.


Aaron Parecki
aaronparecki.com



On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt 
wrote:

> the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot of
> sense to me. The backend can aggregate and optimize access to the
> underlying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley :
>
> How is that different from a regular server client with a web interface if
> the backed is doing the API calls to the RS?
>
>
> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>
> I forgot to mention another (architectural) option: split an application
> into frontend provided by JS in the browser and a backend, which takes care
> of the business logic and handles tokens and API access. Replay detection
> at the interface between SPA and backend can utilize standard web
> techniques (see OWASP). The backend in turn can use mTLS for sender
> constraining.
>
> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
> tors...@lodderstedt.net>:
>
> IMHO the best mechanism at hand currently to cope with token
> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
> detection) and issue short living and privilege restricted access tokens.
>
> Sender constrained access tokens in SPAs need adoption of token binding or
> alternative mechanism. mtls could potentially work in deployments with
> automated cert rollout but browser UX and interplay with fetch needs some
> work. We potentially must consider to warm up application level PoP
> mechanisms in conjunction with web crypto. Another path to be evaluated
> could be web auth.
>
> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
>
> I share the concern Brian has, which is also the conclusion I came up with
> in my other email sent a few minutes ago.
>
>
>
> *From:* OAuth  *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2018 11:43 PM
> *To:* Torsten Lodderstedt 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>
>
>
>
>
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as well
> as Mutual TLS for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
> available.
>
>
>
> Unfortunately even when using the token endpoint, for SPA / in-browser
> client applications, the potential mechanisms for sender/key-constraining
> access tokens don't work very well or maybe don't work at all. So I don't
> know that the recommendation is very realistic.
>
>
>
>
> *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.*
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> _

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I assume via the session context, carried 
as cookie, token or part of the URL.

> Am 02.12.2018 um 12:54 schrieb Rob Otto :
> 
> Apologies if I'm being dim (it wouldn't be the first time!) but how, in this 
> scenario, do we identify the browser client and authenticate it to the 
> backend, to associate it with the correct token(s)? 
> 
> Cheers (and really interesting discussion so far)
> 
> Rob 
> 
>> On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt  
>> wrote:
>> the UI is rendered in the frontend, UI control flow is in the frontend. just 
>> a different cut through the web app’s layering 
>> 
>> All Angular apps I have seen so far work that way. And it makes a lot of 
>> sense to me. The backend can aggregate and optimize access to the underlying 
>> services without the need to fully expose them.
>> 
>>> Am 02.12.2018 um 00:44 schrieb John Bradley :
>>> 
>>> How is that different from a regular server client with a web interface if 
>>> the backed is doing the API calls to the RS?
>>> 
>>> 
>>> 
>>>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>>>> I forgot to mention another (architectural) option: split an application 
>>>> into frontend provided by JS in the browser and a backend, which takes 
>>>> care of the business logic and handles tokens and API access. Replay 
>>>> detection at the interface between SPA and backend can utilize standard 
>>>> web techniques (see OWASP). The backend in turn can use mTLS for sender 
>>>> constraining.
>>>> 
>>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
>>>> :
>>>> 
>>>>> IMHO the best mechanism at hand currently to cope with token 
>>>>> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
>>>>> detection) and issue short living and privilege restricted access tokens.
>>>>> 
>>>>> Sender constrained access tokens in SPAs need adoption of token binding 
>>>>> or alternative mechanism. mtls could potentially work in deployments with 
>>>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>>>> work. We potentially must consider to warm up application level PoP 
>>>>> mechanisms in conjunction with web crypto. Another path to be 
>>>>> evaluated could be web auth.
>>>>> 
>>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>>>> :
>>>>> 
>>>>>> I share the concern Brian has, which is also the conclusion I came up 
>>>>>> with in my other email sent a few minutes ago.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> From: OAuth  On Behalf Of Brian Campbell
>>>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>>>> To: Torsten Lodderstedt 
>>>>>> Cc: oauth 
>>>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>>>  wrote:
>>>>>> 
>>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>>>> > 
>>>>>> > So you mean at the resource server ensuring the token was really 
>>>>>> > issued to the client? Isn't that an inherent limitation of all bearer 
>>>>>> > tokens (modulo HTTP token binding, which is still some time off)?
>>>>>> 
>>>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods 
>>>>>> for sender constraining access tokens 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>>>>  Token Binding for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well 
>>>>>> as Mutual TLS for OAuth 
>>>>>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
>>>>>> available.
>>>>>> 
>>>>>>  
>>>>>> 
>>>>>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>>>>>> client applications, the potential mechanisms for 
>>>>>> sender/key-constraining access tokens don't work very well or maybe 
>>>

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Rob Otto]

Apologies if I'm being dim (it wouldn't be the first time!) but how, in
this scenario, do we identify the browser client and authenticate it to the
backend, to associate it with the correct token(s)?

Cheers (and really interesting discussion so far)

Rob

On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt 
wrote:

> the UI is rendered in the frontend, UI control flow is in the frontend.
> just a different cut through the web app’s layering
>
> All Angular apps I have seen so far work that way. And it makes a lot of
> sense to me. The backend can aggregate and optimize access to the
> underlying services without the need to fully expose them.
>
> Am 02.12.2018 um 00:44 schrieb John Bradley :
>
> How is that different from a regular server client with a web interface if
> the backed is doing the API calls to the RS?
>
>
> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>
> I forgot to mention another (architectural) option: split an application
> into frontend provided by JS in the browser and a backend, which takes care
> of the business logic and handles tokens and API access. Replay detection
> at the interface between SPA and backend can utilize standard web
> techniques (see OWASP). The backend in turn can use mTLS for sender
> constraining.
>
> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <
> tors...@lodderstedt.net>:
>
> IMHO the best mechanism at hand currently to cope with token
> leakage/replay in SPAs is to use refresh tokens (rotating w/ replay
> detection) and issue short living and privilege restricted access tokens.
>
> Sender constrained access tokens in SPAs need adoption of token binding or
> alternative mechanism. mtls could potentially work in deployments with
> automated cert rollout but browser UX and interplay with fetch needs some
> work. We potentially must consider to warm up application level PoP
> mechanisms in conjunction with web crypto. Another path to be evaluated
> could be web auth.
>
> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <
> hannes.tschofe...@arm.com>:
>
> I share the concern Brian has, which is also the conclusion I came up with
> in my other email sent a few minutes ago.
>
>
>
> *From:* OAuth  *On Behalf Of *Brian Campbell
> *Sent:* Friday, November 30, 2018 11:43 PM
> *To:* Torsten Lodderstedt 
> *Cc:* oauth 
> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>
>
>
>
>
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <
> tors...@lodderstedt.net> wrote:
>
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as well
> as Mutual TLS for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options
> available.
>
>
>
> Unfortunately even when using the token endpoint, for SPA / in-browser
> client applications, the potential mechanisms for sender/key-constraining
> access tokens don't work very well or maybe don't work at all. So I don't
> know that the recommendation is very realistic.
>
>
>
>
> *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.*
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/lis

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

the UI is rendered in the frontend, UI control flow is in the frontend. just a 
different cut through the web app’s layering 

All Angular apps I have seen so far work that way. And it makes a lot of sense 
to me. The backend can aggregate and optimize access to the underlying services 
without the need to fully expose them.

> Am 02.12.2018 um 00:44 schrieb John Bradley :
> 
> How is that different from a regular server client with a web interface if 
> the backed is doing the API calls to the RS?
> 
> 
> 
>> On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
>> I forgot to mention another (architectural) option: split an application 
>> into frontend provided by JS in the browser and a backend, which takes care 
>> of the business logic and handles tokens and API access. Replay detection at 
>> the interface between SPA and backend can utilize standard web techniques 
>> (see OWASP). The backend in turn can use mTLS for sender constraining.
>> 
>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt :
>> 
>>> IMHO the best mechanism at hand currently to cope with token leakage/replay 
>>> in SPAs is to use refresh tokens (rotating w/ replay detection) and issue 
>>> short living and privilege restricted access tokens.
>>> 
>>> Sender constrained access tokens in SPAs need adoption of token binding or 
>>> alternative mechanism. mtls could potentially work in deployments with 
>>> automated cert rollout but browser UX and interplay with fetch needs some 
>>> work. We potentially must consider to warm up application level PoP 
>>> mechanisms in conjunction with web crypto. Another path to be evaluated 
>>> could be web auth..
>>> 
>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
>>> :
>>> 
>>>> I share the concern Brian has, which is also the conclusion I came up with 
>>>> in my other email sent a few minutes ago.
>>>>  
>>>> From: OAuth  On Behalf Of Brian Campbell
>>>> Sent: Friday, November 30, 2018 11:43 PM
>>>> To: Torsten Lodderstedt 
>>>> Cc: oauth 
>>>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>>  
>>>>  
>>>> 
>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>>>  wrote:
>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>>>> > 
>>>> > So you mean at the resource server ensuring the token was really issued 
>>>> > to the client? Isn't that an inherent limitation of all bearer tokens 
>>>> > (modulo HTTP token binding, which is still some time off)?
>>>> 
>>>> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
>>>> sender constraining access tokens 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>>>  Token Binding for OAuth 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
>>>> Mutual TLS for OAuth 
>>>> (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
>>>> available.
>>>>  
>>>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>>>> client applications, the potential mechanisms for sender/key-constraining 
>>>> access tokens don't work very well or maybe don't work at all. So I don't 
>>>> know that the recommendation is very realistic.
>>>>  
>>>> 
>>>> 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.
>>>> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[John Bradley]

How is that different from a regular server client with a web interface 
if the backed is doing the API calls to the RS?



On 12/1/2018 12:25 PM, Torsten Lodderstedt wrote:
I forgot to mention another (architectural) option: split an 
application into frontend provided by JS in the browser and a backend, 
which takes care of the business logic and handles tokens and API 
access. Replay detection at the interface between SPA and backend can 
utilize standard web techniques (see OWASP). The backend in turn can 
use mTLS for sender constraining.


Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>>:


IMHO the best mechanism at hand currently to cope with token 
leakage/replay in SPAs is to use refresh tokens (rotating w/ replay 
detection) and issue short living and privilege restricted access tokens.


Sender constrained access tokens in SPAs need adoption of token 
binding or alternative mechanism. mtls could potentially work in 
deployments with automated cert rollout but browser UX and interplay 
with fetch needs some work. We potentially must consider to warm up 
application level PoP mechanisms in conjunction with web crypto. 
Another path to be evaluated could be web auth.


Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>:


I share the concern Brian has, which is also the conclusion I came 
up with in my other email sent a few minutes ago.


*From:*OAuth <mailto:oauth-boun...@ietf.org>> *On Behalf Of *Brian Campbell

*Sent:* Friday, November 30, 2018 11:43 PM
*To:* Torsten Lodderstedt <mailto:tors...@lodderstedt.net>>

*Cc:* oauth mailto:oauth@ietf.org>>
*Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:


> Am 15.11.2018 um 23:01 schrieb Brock Allen
mailto:brockal...@gmail.com>>:
>
> So you mean at the resource server ensuring the token was
really issued to the client? Isn't that an inherent limitation
of all bearer tokens (modulo HTTP token binding, which is still
some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based
methods for sender constraining access tokens

(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
Token Binding for OAuth
(https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08
<https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>)
as well as Mutual TLS for OAuth
(https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the
options available.

Unfortunately even when using the token endpoint, for SPA / 
in-browser client applications, the potential mechanisms for 
sender/key-constraining access tokens don't work very well or maybe 
don't work at all. So I don't know that the recommendation is very 
realistic.



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


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
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

I forgot to mention another (architectural) option: split an application into 
frontend provided by JS in the browser and a backend, which takes care of the 
business logic and handles tokens and API access. Replay detection at the 
interface between SPA and backend can utilize standard web techniques (see 
OWASP). The backend in turn can use mTLS for sender constraining.

> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt :
> 
> IMHO the best mechanism at hand currently to cope with token leakage/replay 
> in SPAs is to use refresh tokens (rotating w/ replay detection) and issue 
> short living and privilege restricted access tokens.
> 
> Sender constrained access tokens in SPAs need adoption of token binding or 
> alternative mechanism. mtls could potentially work in deployments with 
> automated cert rollout but browser UX and interplay with fetch needs some 
> work. We potentially must consider to warm up application level PoP 
> mechanisms in conjunction with web crypto. Another path to be evaluated could 
> be web auth.
> 
>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig :
>> 
>> I share the concern Brian has, which is also the conclusion I came up with 
>> in my other email sent a few minutes ago.
>>  
>> From: OAuth  On Behalf Of Brian Campbell
>> Sent: Friday, November 30, 2018 11:43 PM
>> To: Torsten Lodderstedt 
>> Cc: oauth 
>> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>  
>>  
>> 
>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>  wrote:
>> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
>> > 
>> > So you mean at the resource server ensuring the token was really issued to 
>> > the client? Isn't that an inherent limitation of all bearer tokens (modulo 
>> > HTTP token binding, which is still some time off)?
>> 
>> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
>> sender constraining access tokens 
>> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>>  Token Binding for OAuth 
>> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
>> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) 
>> are the options available.
>>  
>> Unfortunately even when using the token endpoint, for SPA / in-browser 
>> client applications, the potential mechanisms for sender/key-constraining 
>> access tokens don't work very well or maybe don't work at all. So I don't 
>> know that the recommendation is very realistic.
>>  
>> 
>> 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.
>> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

IMHO the best mechanism at hand currently to cope with token leakage/replay in 
SPAs is to use refresh tokens (rotating w/ replay detection) and issue short 
living and privilege restricted access tokens.

Sender constrained access tokens in SPAs need adoption of token binding or 
alternative mechanism. mtls could potentially work in deployments with 
automated cert rollout but browser UX and interplay with fetch needs some work. 
We potentially must consider to warm up application level PoP mechanisms in 
conjunction with web crypto. Another path to be evaluated could be web auth.

> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig :
> 
> I share the concern Brian has, which is also the conclusion I came up with in 
> my other email sent a few minutes ago.
>  
> From: OAuth  On Behalf Of Brian Campbell
> Sent: Friday, November 30, 2018 11:43 PM
> To: Torsten Lodderstedt 
> Cc: oauth 
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>  
>  
> 
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt  
> wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> > 
> > So you mean at the resource server ensuring the token was really issued to 
> > the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> > HTTP token binding, which is still some time off)?
> 
> Sure. That’s why the Security BCP recommends use of TLS-based methods for 
> sender constraining access tokens 
> (https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2).
>  Token Binding for OAuth 
> (https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) 
> are the options available.
>  
> Unfortunately even when using the token endpoint, for SPA / in-browser client 
> applications, the potential mechanisms for sender/key-constraining access 
> tokens don't work very well or maybe don't work at all. So I don't know that 
> the recommendation is very realistic.
>  
> 
> 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.
> 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.


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Hannes Tschofenig]

I share the concern Brian has, which is also the conclusion I came up with in 
my other email sent a few minutes ago.

From: OAuth  On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt 
Cc: oauth 
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00


On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
> Am 15.11.2018 um 23:01 schrieb Brock Allen 
> mailto:brockal...@gmail.com>>:
>
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for 
sender constraining access tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). 
Token Binding for OAuth 
(https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08<https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>)
 as well as Mutual TLS for OAuth 
(https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are the options 
available.

Unfortunately even when using the token endpoint, for SPA / in-browser client 
applications, the potential mechanisms for sender/key-constraining access 
tokens don't work very well or maybe don't work at all. So I don't know that 
the recommendation is very realistic.


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.
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brian Campbell]

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
wrote:

> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12)
> are the options available.
>

Unfortunately even when using the token endpoint, for SPA / in-browser
client applications, the potential mechanisms for sender/key-constraining
access tokens don't work very well or maybe don't work at all. So I don't
know that the recommendation is very realistic.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

> On Nov 21, 2018, at 12:08 AM, Hans Zandbelt  
> wrote:
> 
> I think of this as somewhat similar to:
> a)  a grant type where a cookie grant is exchanged at an "RP token endpoint" 
> for an associated access and refresh token; the protocol between SPA and the 
> API to do so would benefit from standardization e.g. into SDKs and server 
> side frameworks
> b) an "RP token introspection endpoint" where the cookie is introspected at 
> the RP and associated tokens are returned
> 
> if anyone comes up with a better name for this model and endpoint (and 
> probably less overloading of AS endpoint names...) and/or is willing to help 
> writing this down, please come forward and we'll pick it up on a new 
> thread/doc 

Hand waving follows :-)

This sounds like the RP environment as two pieces, a javascript application and 
back-end infrastructure. The RP infrastructure maintains local tokens which it 
derives from remote tokens issued by a single upstream AS/IdP, which it 
interacts with as a confidential client.

This RP infrastructure separately manages authentication/authorization for a 
javascript application. In this use case, this infrastructure allows the 
javascript application to get the access token issued by the upstream AS, so 
that the javascript application may then act as the client to interact with 
protected resources associated with that AS. (For protected resources within 
the RP environment, a separate local token is used for authorization; possibly 
a non-OAuth token such as the cookie)

The first requirement of access token exposure sounds like a fit for token 
exchange, with the RP exposing its own authorization service token endpoint for 
this purpose, and the javascript acting as a public client to the RP and not to 
the upstream OAuth AS. The “cookie token” would have a specific token type for 
this use case. Multiple exchanges would potentially return the same upstream 
access token, or could silently use the refresh token if needed to acquire and 
return a fresh access token.

In this scenario I would not expose the refresh token, as the javascript 
application should not have a direct relationship with the upstream AS, nor 
should it have credentials to perform the refresh.  Likewise, the id_token was 
addressed to the RP infrastructure and not the javascript application - I would 
expect authentication interactions to be between the RP infrastructure and the 
javascript application, indirectly based on the RP infrastructure’s 
relationship upstream service.

Once the javascript app has the access token, it should be able to use it to 
interact with a user info endpoint. This might be a RP user info endpoint, or 
the upstream user info endpoint, depending on RP requirements.

FWIW, if there are multiple upstream AS’s, I would expect the local RP 
environment to be a ‘full fledged’ AS issuing its own local access tokens, and 
to provide its own local protected resources which then may dispatch to the 
protected resources of the various upstream AS’s as needed. Everything above 
could be reused in this scenario, although you might just decide to have the 
local protected resources accept the cookie directly in addition to the local 
RP environment access tokens.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Hans Zandbelt]

I think of this as somewhat similar to:
a)  a grant type where a cookie grant is exchanged at an "RP token
endpoint" for an associated access and refresh token; the protocol between
SPA and the API to do so would benefit from standardization e.g. into SDKs
and server side frameworks
b) an "RP token introspection endpoint" where the cookie is introspected at
the RP and associated tokens are returned

if anyone comes up with a better name for this model and endpoint (and
probably less overloading of AS endpoint names...) and/or is willing to
help writing this down, please come forward and we'll pick it up on a new
thread/doc

Hans.

On Tue, Nov 20, 2018 at 11:00 PM George Fletcher  wrote:

> +1
>
> This model is useful and should be documented in its own right. Once
> documented it could possibly be referenced in the BCP.
>
> On 11/9/18 1:44 PM, David Waite wrote:
>
> Hi Hans, I hope it is acceptable to reply to your message on-list.
>
> Others could correct me if I am wrong, but I believe the purpose of this
> document is to recommend uses of other OAuth/OIDC specifications, not to
> include its own technologies.
>
> In terms of being another spec to be referenced, I think it would be
> useful but I wonder hypothetically how to best write that specification.
> This method seems to be relying on standards-defined tokens and converting
> them to an application server session, which isn’t defined by behavior
> other than HTTP cookies. The session info hook then lets you use those
> proprietary session tokens to retrieve the access/id token.
>
> As such, it is closer to an architecture for implementing a client - as a
> confidential client backend with an associated SPA frontend that needs to
> make OAuth-protected calls. It is not describing the communication between
> existing OAuth roles, such as between the client and AS.
>
> There’s obvious value here, and it's one of several architectures for
> browser-based apps using a confidential client rather than a public one
> (another example being a reverse proxy which maps remote OAuth endpoints
> into local, session-token-protected ones). I personally am just not sure
> how you would define the communication between back-end and front-end
> portions of the client in these architectures as a standard within OAuth.
>
> -DW
>
> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt 
> wrote:
>
> Hi Aaron, DW,
>
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the
> standardization of a "session info" endpoint (I'm open for better naming
> ;-)) as described in:
>
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>
> this approach is not just something that I cooked up; it is based on real
> world requests & deployments at Netflix and OAth.
>
> Let me know what you think,
>
> Hans.
>
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
>> Hi all,
>>
>> Today we were not able to talk about
>> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for
>> Browser-Based Apps".
>>
>> Aaron put a few slides together, which can be found here:
>>
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>>
>> Your review of this new draft is highly appreciated.
>>
>> Ciao
>> Hannes
>> 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
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>
> --
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[George Fletcher]

+1

This model is useful and should be documented in its own right. Once 
documented it could possibly be referenced in the BCP.


On 11/9/18 1:44 PM, David Waite wrote:

Hi Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me if I am wrong, but I believe the purpose of 
this document is to recommend uses of other OAuth/OIDC specifications, 
not to include its own technologies.


In terms of being another spec to be referenced, I think it would be 
useful but I wonder hypothetically how to best write that 
specification. This method seems to be relying on standards-defined 
tokens and converting them to an application server session, which 
isn’t defined by behavior other than HTTP cookies. The session info 
hook then lets you use those proprietary session tokens to retrieve 
the access/id token.


As such, it is closer to an architecture for implementing a client - 
as a confidential client backend with an associated SPA frontend that 
needs to make OAuth-protected calls. It is not describing the 
communication between existing OAuth roles, such as between the client 
and AS.


There’s obvious value here, and it's one of several architectures for 
browser-based apps using a confidential client rather than a public 
one (another example being a reverse proxy which maps remote OAuth 
endpoints into local, session-token-protected ones). I personally am 
just not sure how you would define the communication between back-end 
and front-end portions of the client in these architectures as a 
standard within OAuth.


-DW

On Nov 6, 2018, at 3:03 AM, Hans Zandbelt > wrote:


Hi Aaron, DW,

About draft-parecki-oauth-browser-based-apps:
would you consider including a recommendation about and the 
standardization of a "session info" endpoint (I'm open for better 
naming ;-)) as described in:

https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/

this approach is not just something that I cooked up; it is based on 
real world requests & deployments at Netflix and OAth.


Let me know what you think,

Hans.

On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:


Hi all,

Today we were not able to talk about
draft-parecki-oauth-browser-based-apps-00, which describes 
"OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:

https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
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
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth



--
hans.zandb...@zmartzone.eu 
ZmartZone IAM - www.zmartzone.eu 




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Aaron Parecki]

On Wed, Nov 7, 2018 at 7:20 AM Joseph Heenan  wrote:


> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in mobile
> apps being dynamically (per-install) registered oauth2 private clients, and
> that model has a lot of advantages. (I’m not sure if we might see a similar
> model evolving for web apps.)
>

That's a great point, thanks. I've removed the reference to native apps
being public clients since it doesn't really add anything to this spec if I
have to caveat the description.

On Thu, Nov 15, 2018 at 12:58 PM Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:

> > First of all the AS decides whether it issues refresh tokens or not.
> Having the ability does not mean the AS must do it. If you feel it’s safer
> to not do it. Fine.
> > Sure, and this should be mentioned then somewhere (either in the threats
> doc or in this proposed best practice doc). Not all end developers using
> these protocols fully understand the ramifications.
> @Aaron: I suggest this goes to the SPA BCP since this is client specific.


Thanks, I agree that this document should include some recommendations
around refresh token handling. Looking at the discussion in this thread, it
seems there are a few different strategies folks are taking. Since it seems
like there isn't a strong consensus, it sounds like this would be better
suited for the "Security Considerations" section, and to not make
MUST/SHOULD recommendations, but rather just point out the issues. Any
thoughts on that before I take a stab at writing something?

I've incorporated some of the other feedback here and published an updated
version:

https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-01

Thanks for the feedback so far.

---
Aaron Parecki
https://aaronparecki.com
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

You mean the binding between refresh tokens and sessions?

> Am 19.11.2018 um 11:03 schrieb Hans Zandbelt :
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of 
> requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov 
>>  wrote:
>>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with 
>>> automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and 
>>> invalidate the old one. This restricts the lifetime of a refresh token. If 
>>> someone (might be the legit client or an attacker) submits one of the 
>>> older, invalidated refresh token, the AS might interpret this as a signal 
>>> indicating token leakage and revoke the valid refresh token as well. We 
>>> used this technique at Deutsche Telekom since our first OAuth 2.0 
>>> implementation back in 2012.
>> This is a clever solution. Did you experience any false positives, e.g. due 
>> to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the 
>> end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Jim Manico]

I want to +1 this as well. This really got my attention as an impressive and 
straightforward defense technique.

Jim


> On Nov 19, 2018, at 3:48 PM, Hans Zandbelt  wrote:
> 
> +1 to the suggestions that Vladimir raises; I've seen a fair number of 
> requests  in the field for exactly that
> 
> Hans.
> 
>> On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov 
>>  wrote:
>>> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>>> To start with, the AS may use refresh token rotation in combination with 
>>> automatic revocation in case of detected replay attempts. 
>>> 
>>> How does it work? The AS issues a new refresh token with every refresh and 
>>> invalidate the old one. This restricts the lifetime of a refresh token. If 
>>> someone (might be the legit client or an attacker) submits one of the 
>>> older, invalidated refresh token, the AS might interpret this as a signal 
>>> indicating token leakage and revoke the valid refresh token as well. We 
>>> used this technique at Deutsche Telekom since our first OAuth 2.0 
>>> implementation back in 2012.
>> This is a clever solution. Did you experience any false positives, e.g. due 
>> to HTTP response timeouts on slow / poor connections?
>> 
>> We were also thinking of additionally binding the refresh token to the 
>> end-user session at the AS / OP:
>> 
>> A valid refresh causing the session to be refreshed too
>> AS / OP logout or session expiration invalidating the refresh token
>> 
>> 
>> Vladimir
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> -- 
> hans.zandb...@zmartzone.eu
> ZmartZone IAM - www.zmartzone.eu
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Hans Zandbelt]

+1 to the suggestions that Vladimir raises; I've seen a fair number of
requests  in the field for exactly that

Hans.

On Mon, Nov 19, 2018 at 10:59 AM Vladimir Dzhuvinov 
wrote:

> On 17/11/2018 13:26, Torsten Lodderstedt wrote:
>
> To start with, the AS may use refresh token rotation in combination with 
> automatic revocation in case of detected replay attempts.
>
> How does it work? The AS issues a new refresh token with every refresh and 
> invalidate the old one. This restricts the lifetime of a refresh token. If 
> someone (might be the legit client or an attacker) submits one of the older, 
> invalidated refresh token, the AS might interpret this as a signal indicating 
> token leakage and revoke the valid refresh token as well. We used this 
> technique at Deutsche Telekom since our first OAuth 2.0 implementation back 
> in 2012.
>
> This is a clever solution. Did you experience any false positives, e.g.
> due to HTTP response timeouts on slow / poor connections?
>
> We were also thinking of additionally binding the refresh token to the
> end-user session at the AS / OP:
>
>- A valid refresh causing the session to be refreshed too
>- AS / OP logout or session expiration invalidating the refresh token
>
>
> Vladimir
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>


-- 
hans.zandb...@zmartzone.eu
ZmartZone IAM - www.zmartzone.eu
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Vladimir Dzhuvinov]

Hi everyone,

On 17/11/2018 13:07, Torsten Lodderstedt wrote:
>
>> The alternative, as you mentioned, is to not issue refresh tokens and do 
>> token renewal the "same old way" via iframe with prompt=none, while still 
>> using code flow.
> yes. 
>
> Have you ever experienced issues with the latter approach and the browser’s 
> 3rd party cookie policy?

I expect that what's ultimately going to drive people away from
"implicit" and to "code" is blocked 3rd party cookies in browsers
breaking renewal for clients via an iframe.

IMO this policy is only more likely to spread out in browsers than
getting rolled back.

Vladimir




smime.p7s
Description: S/MIME Cryptographic Signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brian Campbell]

I might suggest that neither of those are really best current practice per
se. Using key constrained tokens is more of an aspirational recommendation
for what would be good security practice than it is something that's done
much for real in practice today.

On Sat, Nov 17, 2018, 4:07 AM Torsten Lodderstedt 
> > Am 15.11.2018 um 23:01 schrieb Brock Allen :
> >
> > So you mean at the resource server ensuring the token was really issued
> to the client? Isn't that an inherent limitation of all bearer tokens
> (modulo HTTP token binding, which is still some time off)?
>
> Sure. That’s why the Security BCP recommends use of TLS-based methods for
> sender constraining access tokens (
> https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2...2).
> Token Binding for OAuth (
> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as
> Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12)
> are the options available.
>
>
>
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Tomek,

> Am 16.11.2018 um 13:59 schrieb Tomek Stojecki :
> 
> >> The AS can bind the lifetime of the refresh tokens to the session 
> >> lifetime, i.e. automatically revoke it on logout. 
> 
> > Yea, I saw your other email asking about refresh token revocation relating 
> > to session management. Obviously for certain clients, this won't make 
> > sense, but for implicit/browser-based ones it's a nice feature to have.
> 
> I agree that this can be useful, however with where we are today, is this 
> supported by auth servers such that it can distinguish offline from 
> renewable-online clients and only revoke the latter when logging out? 

See other thread on refresh token revocation on logout. There seems to be some 
implementations. Basically, I don’t think the clients needs to now because it 
always needs to be prepared to handle invalid (invalidated) refresh tokens (see 
https://tools.ietf.org/html/rfc6749#section-5.2). 

> 
> > The alternative, as you mentioned, is to not issue refresh tokens and do 
> > token renewal the "same old way" via iframe with prompt=none, while still 
> > using code flow.
> 
> Going from Implicit to Code deals with the problem of sending RT in the URL, 
> which I agree is a plus.

Have you taken a look at 
https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2.1.2? 
It gives all the justification. 

> Is there anything else in a way of an improvement? I still am not comfortable 
> enough with the idea of releasing RTs to the browser clients where it can't 
> be encrypted, prone to xss, etc… 

As already stated. The AS is not required to issue refresh tokens.

If the AS decides to issue refresh tokens, there are ways to protect the 
refresh token from replay even for public clients. 

To start with, the AS may use refresh token rotation in combination with 
automatic revocation in case of detected replay attempts. 

How does it work? The AS issues a new refresh token with every refresh and 
invalidate the old one. This restricts the lifetime of a refresh token. If 
someone (might be the legit client or an attacker) submits one of the older, 
invalidated refresh token, the AS might interpret this as a signal indicating 
token leakage and revoke the valid refresh token as well. We used this 
technique at Deutsche Telekom since our first OAuth 2.0 implementation back in 
2012.

An emerging alternative is to use Token Binding (in browser) or Mutual TLS 
(other clients) to bind the refresh token to the client’s key key pair.

kind regards,
Torsten. 

> 
> 
> -Tomek
> 
> On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen 
>  wrote:
> 
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)? Resource servers don't 
> know the flow the clients might use, especially if/when they have many 
> clients.
> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout. 
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.
> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.
> 
> 
> -Brock
> 
> ___
> OAuth 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Nat, 

> Am 16.11.2018 um 10:12 schrieb n-sakimura :
> 
> Good points.
> 
>  
> 
> Also, while it may be off-topic, I do see values in implicit flows. In some 
> cases, such as when the AS is inside the firewall or on a localhost (e.g., 
> smartphone), “code flow” is not possible as the client cannot reach the AS 
> directly.

are you saying the browser can send the HTTP GET to the authorization endpoint 
but the JS in the browser cannot send the HTTP POST to the token endpoint? 

> Banning implicit (and thus “token id_token” as well) has this repercussion

First of all we are not banning anything. The OAuth WG does no longer recommend 
to use the implicit for very good reasons, which can be found here 
https://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi#rfc.section.2.1.2

I would appreciate your comments. 

> and I would not agree to it.

As you were always on the „make it secure“ side, I’m a bit surprised. 

kind regards,
Torsten. 

> 
>  
> 
> Best,
> 
>  
> 
> Nat Sakimura
> 
>  
> 
> From: OAuth  On Behalf Of Brock Allen
> Sent: Friday, November 16, 2018 7:01 AM
> To: Torsten Lodderstedt 
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
> 
>  
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
>  
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)? Resource servers don't 
> know the flow the clients might use, especially if/when they have many 
> clients.
> 
>  
> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout.
> 
>  
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
>  
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.
> 
>  
> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
>  
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.
> 
>  
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.
> 
>  
> 
>  
> 
> -Brock
> 
>  
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock,

> Am 15.11.2018 um 23:01 schrieb Brock Allen :
> 
> > It still lacks the ability to issue sender constraint access tokens.
> 
> So you mean at the resource server ensuring the token was really issued to 
> the client? Isn't that an inherent limitation of all bearer tokens (modulo 
> HTTP token binding, which is still some time off)?

Sure. That’s why the Security BCP recommends use of TLS-based methods for 
sender constraining access tokens 
(https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-2..2). 
Token Binding for OAuth 
(https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well as 
Mutual TLS for OAuth (https://tools.ietf.org/html/draft-ietf-oauth-mtls-12) are 
the options available. 


> Resource servers don't know the flow the clients might use, especially 
> if/when they have many clients.

They don’t need to. All they need to know is how to determine whether the 
sender of the token is the legit client. This is achieved by comparing the hash 
of the token binding id or the cert of the client conveyed in the access token 
with the respective data from the TLS handshake. 

> 
> > The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> > i.e. automatically revoke it on logout. 
> 
> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
> 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.

yes. 

Have you ever experienced issues with the latter approach and the browser’s 3rd 
party cookie policy?

> 
> > The only potential „baby step“ I would see is to move towards „token 
> > id_token“. Since this requires signature/at_hash checks etc. I doubt this 
> > is really easier than moving to code and exchange the code for an access 
> > token. What’s your opinion?
> 
> Even since OIDC arrived, this is the only flow I use for JS/browser-based 
> clients (anything less has always seemed so obviously inferior). So for me 
> and my customers, all browser-based clients I am involved in are already 
> there. Perhaps this is the reason for all of my questions/comments about the 
> recent BCP doc. Given "id_token token", CSP, and using the browser history 
> API to wipe the access token from browser history, we already have a decent 
> set of tools to mitigate attacks. As I already conceded, the only remaining 
> issue (IMO) is the short window of time the access token is in the URL.

There are two angles to approach access token leakage and replay from two 
angles, (a) preventing leakage (that’s what you can do with the browser history 
API, TLS, ...) or (b) detecting replay (that’s what one can do with sender 
constraint access tokens). 

The focus of OAuth/OIDC was on (a) but experiences have shown this is of 
limited effectivity, especially in dynamic/open scenarios, which we are seeing 
increasingly due to open banking, eHealth, eID, …. So sealing the problem from 
both ends seems reasonable.  
 
> 
> Given that it seems to me that OIDC and OAuth2 are typically used together 
> (at least when a user is involved with authentication), I always wonder why 
> the OAuth and OIDC WGs are separate. Given that so much effort of the two 
> sets of specs overlap, it seems odd to keep adding onto the OAuth specs and 
> ignoring the added features that OIDC provides. I don't mean to derail this 
> thread, or step on any political toes, so apologies in advance.

No problem. As already stated, OIDC, esp. FAPI, and OAuth need to be aligned on 
that point. 

Thanks for the insights you shared. We will be publishing another revision of 
the OAuth Security BCP soon, which also adds recommendation and justification 
based on our discussions. 

kind regards, 
Torsten. 

> 
> 
> -Brock
> 



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

> Going from Implicit to Code deals with the problem of sending RT in the URL, 
>which I agree is a plus. Is there anything else in a way of an improvement? 

As far as I can tell, that's the only additional security feature (beyond what 
we already use for mitigations today) that code flow adds. That's why I was 
hoping for the proposed BCP to explicitly point this out, which means all the 
other mitigations and guidance in the document are valid and useful for 
implicit flow.

-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

> Could you please expand on what you are achieving with replacing the URL 
>using the history API? Removing the token from the browser's history, or any 
>protection beyond that?

Just this block of code which would be run on the redirect_uri page loaded in 
the client (after id_token/token validation is complete):

https://github.com/IdentityServer/IdentityServer4.Samples/blob/release/Clients/src/JsOidc/wwwroot/callback.js#L4-L6

-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Tomek Stojecki]

 >> The AS can bind the lifetime of the refresh tokens to the session lifetime, 
 >>i.e. automatically revoke it on logout. 

> Yea, I saw your other email asking about refresh token revocation relating to 
> session management. Obviously for certain clients, this won't make sense, but 
> for implicit/browser-based ones it's a nice feature to have.
I agree that this can be useful, however with where we are today, is this 
supported by auth servers such that it can distinguish offline from 
renewable-online clients and only revoke the latter when logging out? 
> The alternative, as you mentioned, is to not issue refresh tokens and do 
> token renewal the "same old way" via iframe with prompt=none, while still 
> using code flow.

Going from Implicit to Code deals with the problem of sending RT in the URL, 
which I agree is a plus. Is there anything else in a way of an improvement? I 
still am not comfortable enough with the idea of releasing RTs to the browser 
clients where it can't be encrypted, prone to xss, etc... 

-Tomek
On Thursday, November 15, 2018, 11:01:37 PM GMT+1, Brock Allen 
 wrote:  
 
   > It still lacks the ability to issue sender constraint access tokens.
So you mean at the resource server ensuring the token was really issued to the 
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP 
token binding, which is still some time off)? Resource servers don't know the 
flow the clients might use, especially if/when they have many clients.
> The AS can bind the lifetime of the refresh tokens to the session lifetime, 
>i.e. automatically revoke it on logout. 

Yea, I saw your other email asking about refresh token revocation relating to 
session management. Obviously for certain clients, this won't make sense, but 
for implicit/browser-based ones it's a nice feature to have.
The alternative, as you mentioned, is to not issue refresh tokens and do token 
renewal the "same old way" via iframe with prompt=none, while still using code 
flow.
> The only potential „baby step“ I would see is to move towards „token 
>id_token“. Since this requires signature/at_hash checks etc. I doubt this is 
>really easier than moving to code and exchange the code for an access token. 
>What’s your opinion?
Even since OIDC arrived, this is the only flow I use for JS/browser-based 
clients (anything less has always seemed so obviously inferior). So for me and 
my customers, all browser-based clients I am involved in are already there. 
Perhaps this is the reason for all of my questions/comments about the recent 
BCP doc. Given "id_token token", CSP, and using the browser history API to wipe 
the access token from browser history, we already have a decent set of tools to 
mitigate attacks. As I already conceded, the only remaining issue (IMO) is the 
short window of time the access token is in the URL.
Given that it seems to me that OIDC and OAuth2 are typically used together (at 
least when a user is involved with authentication), I always wonder why the 
OAuth and OIDC WGs are separate. Given that so much effort of the two sets of 
specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring 
the added features that OIDC provides. I don't mean to derail this thread, or 
step on any political toes, so apologies in advance..

-Brock
 ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
  ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[n-sakimura]

Good points.

Also, while it may be off-topic, I do see values in implicit flows. In some 
cases, such as when the AS is inside the firewall or on a localhost (e.g., 
smartphone), “code flow” is not possible as the client cannot reach the AS 
directly. Banning implicit (and thus “token id_token” as well) has this 
repercussion and I would not agree to it.

Best,

Nat Sakimura

From: OAuth  On Behalf Of Brock Allen
Sent: Friday, November 16, 2018 7:01 AM
To: Torsten Lodderstedt 
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

> It still lacks the ability to issue sender constraint access tokens.

So you mean at the resource server ensuring the token was really issued to the 
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP 
token binding, which is still some time off)? Resource servers don't know the 
flow the clients might use, especially if/when they have many clients.

> The AS can bind the lifetime of the refresh tokens to the session lifetime, 
> i.e. automatically revoke it on logout.

Yea, I saw your other email asking about refresh token revocation relating to 
session management. Obviously for certain clients, this won't make sense, but 
for implicit/browser-based ones it's a nice feature to have.

The alternative, as you mentioned, is to not issue refresh tokens and do token 
renewal the "same old way" via iframe with prompt=none, while still using code 
flow.

> The only potential „baby step“ I would see is to move towards „token 
> id_token“. Since this requires signature/at_hash checks etc. I doubt this is 
> really easier than moving to code and exchange the code for an access token. 
> What’s your opinion?

Even since OIDC arrived, this is the only flow I use for JS/browser-based 
clients (anything less has always seemed so obviously inferior). So for me and 
my customers, all browser-based clients I am involved in are already there. 
Perhaps this is the reason for all of my questions/comments about the recent 
BCP doc. Given "id_token token", CSP, and using the browser history API to wipe 
the access token from browser history, we already have a decent set of tools to 
mitigate attacks. As I already conceded, the only remaining issue (IMO) is the 
short window of time the access token is in the URL.

Given that it seems to me that OIDC and OAuth2 are typically used together (at 
least when a user is involved with authentication), I always wonder why the 
OAuth and OIDC WGs are separate. Given that so much effort of the two sets of 
specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring 
the added features that OIDC provides. I don't mean to derail this thread, or 
step on any political toes, so apologies in advance.


-Brock

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Daniel Fett]

Hi all,

Am 09.11.18 um 21:22 schrieb Brock Allen:
>
> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get
> into specifics, but many of the points seem confused (or at least
> confuse me) and/or the conclusion that code flow is the only approach
> seems misleading. For example:
>
> "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is
> required according to Section 6), so clients and authorization servers
> MUST NOT use the Implicit Flow for browser-based apps."
>
> This is specious. The threat is the token is in the URL, not that
> implicit clients can't use PKCE. So perhaps the document should
> explain the variety of mitigations, not just one? While code flow is
> one, using CSP and the browser history API to remove the token from
> the URL is another. Elsewhere in the document the use of CSP is a
> "SHOULD". That's great, but using CSP can be and is used today, and
> doesn't necessitate code flow.

Could you please expand on what you are achieving with replacing the URL
using the history API? Removing the token from the browser's history, or
any protection beyond that?


>
> "Supporting the implicit flow requires additional code, more upkeep
> and understanding of the related security considerations, while
> limiting the authorization server to just the authorization code flow
> simplifies the implementation."
>
> As offered by someone else already, this is opinion and not objective.
> IMO, this diminishes the potential of this document.

Another aspect is that removing implicit as an option greatly simplifies
security analysis and formal proofs of security (of which I hope we will
see more instances in the future). If you look at it this way, it is
much more than an opinion and it is definitely objective.

- Daniel
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

> It still lacks the ability to issue sender constraint access tokens.

So you mean at the resource server ensuring the token was really issued to the 
client? Isn't that an inherent limitation of all bearer tokens (modulo HTTP 
token binding, which is still some time off)? Resource servers don't know the 
flow the clients might use, especially if/when they have many clients.

> The AS can bind the lifetime of the refresh tokens to the session lifetime, 
>i.e. automatically revoke it on logout.


Yea, I saw your other email asking about refresh token revocation relating to 
session management. Obviously for certain clients, this won't make sense, but 
for implicit/browser-based ones it's a nice feature to have.

The alternative, as you mentioned, is to not issue refresh tokens and do token 
renewal the "same old way" via iframe with prompt=none, while still using code 
flow.

> The only potential „baby step“ I would see is to move towards „token 
>id_token“. Since this requires signature/at_hash checks etc. I doubt this is 
>really easier than moving to code and exchange the code for an access token. 
>What’s your opinion?

Even since OIDC arrived, this is the only flow I use for JS/browser-based 
clients (anything less has always seemed so obviously inferior). So for me and 
my customers, all browser-based clients I am involved in are already there. 
Perhaps this is the reason for all of my questions/comments about the recent 
BCP doc. Given "id_token token", CSP, and using the browser history API to wipe 
the access token from browser history, we already have a decent set of tools to 
mitigate attacks. As I already conceded, the only remaining issue (IMO) is the 
short window of time the access token is in the URL.

Given that it seems to me that OIDC and OAuth2 are typically used together (at 
least when a user is involved with authentication), I always wonder why the 
OAuth and OIDC WGs are separate. Given that so much effort of the two sets of 
specs overlap, it seems odd to keep adding onto the OAuth specs and ignoring 
the added features that OIDC provides. I don't mean to derail this thread, or 
step on any political toes, so apologies in advance.


-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock, 

> Am 15.11.2018 um 15:01 schrieb Brock Allen :
> 
> > Helps to prevent leakage, not injection in the authorization response.
> 
> So then wording and its motivation could get updated to correctly reflect 
> that.
> 
> >> "OAuth 2.0 provides no mechanism for a client to verify that an access 
> >> token was issued to it, which could lead to misuse and possible 
> >> impersonation attacks if a malicious party hands off an access token it 
> >> retrieved through some other means to the client."
> >> 
> >> Sure, but OIDC does provide a mitigation for this (even with implicit).
> >
> >This is about token replay detection at the RS. What mitigation does OIDC 
> >provide here? 
> 
> The wording doesn't go with that, then. My point about OIDC is that with the 
> at_hash in the id_token provides a mitigation so the client can verify that 
> the access token was issued to it.

Understand, you are referring to the token injection prevention provided by 
„token id_token“ or „code token id_token“.. It still lacks the ability to issue 
sender constraint access tokens. So if you wanna take the risk associated with 
bearer tokens you can use it. The Security BCP recommends to use sender 
constraint access tokens, so we cannot recommend response types not supporting 
this pattern. 

> 
> > The implicit grant was not equipped with the ability to issue refresh 
> > tokens simply because the working group didn’t want them to end up in the 
> > browser history, leak through open redirectors etc. This is different with 
> > code since tokens travel directly through a TLS protected connection.
> 
> Well, if limiting the access token renewal to the user's session lifetime 
> wasn't a conscious design goal, it's a very interesting side effect which 
> does limit the potential of an attacker.

That’s true. Note that the effectiveness of limitation depends on the lifetime 
of the issued access tokens. 

The AS can bind the lifetime of the refresh tokens to the session lifetime, 
i.e. automatically revoke it on logout. 

In my opinion, whether this is the most appropriate choice largely depends on 
what the client uses the token for. If the client effectively relies on the AS 
(OP) to login the user and obtain user data that makes sense. If the client has 
an independent login and uses the tokens to access resources (e.g. contacts), 
the session with the AS does not have  a real meaning with respect to this 
client. Potentially the client even stores the refresh token in a backend with 
the user account. 

> 
> > First of all the AS decides whether it issues refresh tokens or not. Having 
> > the ability does not mean the AS must do it. If you feel it’s safer to not 
> > do it. Fine. 
> 
> Sure, and this should be mentioned then somewhere (either in the threats doc 
> or in this proposed best practice doc). Not all end developers using these 
> protocols fully understand the ramifications. 

@Aaron: I suggest this goes to the SPA BCP since this is client specific.

> 
> > It’s still possible to refresh your access tokens the way you mentioned 
> > above by sending another authorization request to the AS. 
> 
> This also could be added as a proposal for an alternative to renewing tokens. 
> It provides more awareness to folks, and aids in a potential best practice 
> depending on the requirements of the consuming app.

I agree. 

> 
> > But let’s assume for a moment the AS, based on its risk assessment, decides 
> > to issue refresh tokens. Can you please explain how an attacker will get 
> > access to this tokens? Especially what the expected strength of the 
> > attacker would need to be?
> 
> I don't have a profile of an attack. But I'm assuming it's no different than 
> anything in the past we've been trying to defend against when we considered 
> the potential for an access token to be exfiltrated. So my point is that an 
> access token will expire so an attacker would then have to go back and 
> re-attack the app to get a new access token to continue to have access to the 
> user's resource. But now with refresh tokens in the picture, the attacker 
> would have both and then not need to go back to the app to continue to have 
> access to the user's resource. 

Largely depends on the refresh token protection. I case of public clients I 
would always recommend to rotation refresh tokens with every refresh. This 
renders the old refresh tokens useless. If the attacker happens to be at the 
lucky end and conducts the first refresh, the AS should be able to detect the 
replay when the legit user tries to refresh. It then shall revoke the active 
(in possession of the attacker) refresh token as well. 

I will add this to the Security BCP.

> 
> > I would also like to understand how a refresh token is any different from a 
> > long living cookie in the browser and what you think is the big difference 
> > to mobile apps when it comes to refresh token handling. 
> 
> To use the cookie, the app must be active, and the 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

> Helps to prevent leakage, not injection in the authorization response.

So then wording and its motivation could get updated to correctly reflect that.

>> "OAuth 2.0 provides no mechanism for a client to verify that an access token 
>> was issued to it, which could lead to misuse and possible impersonation 
>> attacks if a malicious party hands off an access token it retrieved through 
>> some other means to the client."
>> 
>> Sure, but OIDC does provide a mitigation for this (even with implicit).
>
>This is about token replay detection at the RS. What mitigation does OIDC 
>provide here? 

The wording doesn't go with that, then. My point about OIDC is that with the 
at_hash in the id_token provides a mitigation so the client can verify that the 
access token was issued to it.

> The implicit grant was not equipped with the ability to issue refresh tokens 
>simply because the working group didn’t want them to end up in the browser 
>history, leak through open redirectors etc. This is different with code since 
>tokens travel directly through a TLS protected connection.

Well, if limiting the access token renewal to the user's session lifetime 
wasn't a conscious design goal, it's a very interesting side effect which does 
limit the potential of an attacker.

> First of all the AS decides whether it issues refresh tokens or not. Having 
>the ability does not mean the AS must do it. If you feel it’s safer to not do 
>it. Fine. 

Sure, and this should be mentioned then somewhere (either in the threats doc or 
in this proposed best practice doc). Not all end developers using these 
protocols fully understand the ramifications. 

> It’s still possible to refresh your access tokens the way you mentioned above 
> by sending another authorization request to the AS. 


This also could be added as a proposal for an alternative to renewing tokens. 
It provides more awareness to folks, and aids in a potential best practice 
depending on the requirements of the consuming app.

> But let’s assume for a moment the AS, based on its risk assessment, decides 
>to issue refresh tokens. Can you please explain how an attacker will get 
>access to this tokens? Especially what the expected strength of the attacker 
>would need to be?

I don't have a profile of an attack. But I'm assuming it's no different than 
anything in the past we've been trying to defend against when we considered the 
potential for an access token to be exfiltrated. So my point is that an access 
token will expire so an attacker would then have to go back and re-attack the 
app to get a new access token to continue to have access to the user's 
resource. But now with refresh tokens in the picture, the attacker would have 
both and then not need to go back to the app to continue to have access to the 
user's resource. 

> I would also like to understand how a refresh token is any different from a 
>long living cookie in the browser and what you think is the big difference to 
>mobile apps when it comes to refresh token handling. 

To use the cookie, the app must be active, and the attacker must be attacking 
the app itself.

Maybe a different way to say it is that an attacker must only compromise the 
app once to have long lived access, whereas without refresh tokens the attacker 
can attack the app once, but the once the comprised access token is expired 
they would have to re-attack the app to get another access token. Refresh 
tokens means they only have to get in once to the app, then they no longer have 
to go back to the source. Maybe there's a better way to convey what I'm trying 
to say...

Also, I guess my question/comment about providing guidance for existing 
implicit flow clients is not up for discussion? Again, my reasoning is that 
it's a hard sell to always say there's exactly one right way to do something. 
And since so many clients have been built based on implicit flow that might not 
be able to change quickly to a new flow, perhaps there are "baby steps" that 
can be suggested to help them improve their security.

-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

Hi Brock,

> Am 09.11.2018 um 21:22 schrieb Brock Allen :
> 
> Hello all --
> 
> I also have some thoughts/feedback on this document.
> 
> Personally I agree with some of the conclusions, but as it stands I think the 
> document's main conclusion that code flow is the real solution is not 
> sufficiently convincing.
> 
> I would like to see a brief summary of the current concerns (much like 
> RFC8252 does) so we have context before the document just jumps to what a 
> best practice is. The reason I bring this up is that generally the concept of 
> "best practice" is meaningless without context. I think stating that code 
> flow is best practice without motivation seems somewhat "cart before the 
> horse".
> 
> I think just a short blurb about the desire to eliminate the access token 
> from being delivered in the URL, and the current attacks against doing so 
> would be helpful (showing attacks is super important in making this "real"). 
> I guess this would make the most sense in section "4. Overview" prior to the 
> list of "best practice" conclusions.
> 

I agree, justifications are needed. As draft-ietf-oauth-security-topics-09 
provides those justifications, I suggest to add suitable references here. 

> Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into 
> specifics, but many of the points seem confused (or at least confuse me) 
> and/or the conclusion that code flow is the only approach seems misleading. 
> For example:
> 
> "The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required 
> according to Section 6), so clients and authorization servers MUST NOT use 
> the Implicit Flow for browser-based apps.“

Don’t understand the wording either. The text should state that the implicit 
cannot detect token injection.

> 
> This is specious. The threat is the token is in the URL, not that implicit 
> clients can't use PKCE. So perhaps the document should explain the variety of 
> mitigations, not just one? While code flow is one, using CSP and the browser 
> history API to remove the token from the URL is another.

Helps to prevent leakage, not injection in the authorization response. 

> Elsewhere in the document the use of CSP is a "SHOULD". That's great, but 
> using CSP can be and is used today, and doesn't necessitate code flow.
> 
> "OAuth 2.0 provides no mechanism for a client to verify that an access token 
> was issued to it, which could lead to misuse and possible impersonation 
> attacks if a malicious party hands off an access token it retrieved through 
> some other means to the client."
> 
> Sure, but OIDC does provide a mitigation for this (even with implicit).

This is about token replay detection at the RS. What mitigation does OIDC 
provide here? 

> So perhaps it should be offered as a suggestion as well? I did see the point 
> that with code flow id_token validation could instead rely upon the token 
> endpoint, but the client still has other work to do (namely around PKCE). 
> That's just trading one bit of work for another, not a clear cut reason to 
> use one flow over another.
> 
> "Supporting the implicit flow requires additional code, more upkeep and 
> understanding of the related security considerations, while limiting the 
> authorization server to just the authorization code flow simplifies the 
> implementation."
> 
> As offered by someone else already, this is opinion and not objective. IMO, 
> this diminishes the potential of this document.
> 
> "If the JavaScript application gets wrapped into a native app, then [RFC8252] 
> also requires the use of the authorization code flow."
> 
> Given how many browser dependencies SPA apps tend to have, is this really 
> common? In all my years building both, I've never seen it.
> 
> "Historically, the Implicit flow provided an advantage to single-page apps 
> since JavaScript could always arbitrarily read and manipulate the fragment 
> portion of the URL without triggering a page reload. Now with the Session 
> History API (described in "Session history and navigation" of [HTML]), 
> browsers have a mechanism to modify the path component of the URL without 
> triggering a page reload, so this overloaded use of the fragment portion is 
> no longer needed."
> 
> While this section is intended to indicate the existence of the history API 
> is a reason to move away from implicit, it's also what can be used to protect 
> token exposure in the URL, which I think weakens its point. As a section, to 
> me, it seems unnecessary.
> 
> The push to a single flow (for consistency) is a marginal motivation, and I 
> agree with that theme in the document.
> 
> Much of the other guidance in this document is already covered elsewhere 
> (e.g. RFC6819). I don't know if the goal of the document is to reproduce 
> those existing recommendations (as a contrast RFC8252 does not and mainly 
> focuses on what's unique to the native scenario).
> 
> I can't quite tell the real motivation for this "best practice" 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

> Finally, my last real concern (which is why I'm pushing back so much on code 
>flow), is that this implies refresh tokens in the browser. My sense is that 
>given the danger of this, the original OAuth2 RFC (via the implicit flow) was 
>designed to limit the client's ability to obtain new access tokens based on 
>the user's authentication session at the AS (via a cookie). Allowing refresh 
>tokens now means that a successful attacker has unfettered ability to do this 
>(beyond just an access token's lifetime). And yes, CSP is mentioned as a 
>mitigation to protect the refresh token, but it was already necessary to 
>protect the access token, so CSP is not the only mitigation. What's missing is 
>strong guidance for token servers to provide mechanisms to limit the lifetime 
>of refresh tokens for these high risk client scenarios. I have a suspicion 
>that many existing token servers do not have such features, and this would 
>imply more features mandated for the token servers (beyond PKCE for example).


And to expand upon this serious concern -- CSP only protects the current page 
from things like XSS. It does not protect every other page under your domain. 
IOW, your app using/storing refresh tokens (and access tokens) is trusting 
every other page on the domain to also be protected from XSS. At least an 
access token compromised this way has an expiration, whereas unbounded refresh 
tokens won't necessarily. This is why I am pushing for strong guidance around 
refresh token expirations, and this requires the token servers to implement and 
enforce this. 

So this sort of threat should possibly be used in the document to reinforce and 
motivate such guidance.

-Brock
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Brock Allen]

Hello all --

I also have some thoughts/feedback on this document.

Personally I agree with some of the conclusions, but as it stands I think the 
document's main conclusion that code flow is the real solution is not 
sufficiently convincing.

I would like to see a brief summary of the current concerns (much like RFC8252 
does) so we have context before the document just jumps to what a best practice 
is. The reason I bring this up is that generally the concept of "best practice" 
is meaningless without context. I think stating that code flow is best practice 
without motivation seems somewhat "cart before the horse".

I think just a short blurb about the desire to eliminate the access token from 
being delivered in the URL, and the current attacks against doing so would be 
helpful (showing attacks is super important in making this "real"). I guess 
this would make the most sense in section "4. Overview" prior to the list of 
"best practice" conclusions.

Section "7.8. OAuth Implicit Grant Authorization Flow" does try to get into 
specifics, but many of the points seem confused (or at least confuse me) and/or 
the conclusion that code flow is the only approach seems misleading. For 
example:

"The Implicit Flow cannot be protected by PKCE [RFC7636] (which is required 
according to Section 6), so clients and authorization servers MUST NOT use the 
Implicit Flow for browser-based apps."

This is specious. The threat is the token is in the URL, not that implicit 
clients can't use PKCE. So perhaps the document should explain the variety of 
mitigations, not just one? While code flow is one, using CSP and the browser 
history API to remove the token from the URL is another. Elsewhere in the 
document the use of CSP is a "SHOULD". That's great, but using CSP can be and 
is used today, and doesn't necessitate code flow.

"OAuth 2.0 provides no mechanism for a client to verify that an access token 
was issued to it, which could lead to misuse and possible impersonation attacks 
if a malicious party hands off an access token it retrieved through some other 
means to the client."

Sure, but OIDC does provide a mitigation for this (even with implicit). So 
perhaps it should be offered as a suggestion as well? I did see the point that 
with code flow id_token validation could instead rely upon the token endpoint, 
but the client still has other work to do (namely around PKCE). That's just 
trading one bit of work for another, not a clear cut reason to use one flow 
over another.

"Supporting the implicit flow requires additional code, more upkeep and 
understanding of the related security considerations, while limiting the 
authorization server to just the authorization code flow simplifies the 
implementation."

As offered by someone else already, this is opinion and not objective. IMO, 
this diminishes the potential of this document.

"If the JavaScript application gets wrapped into a native app, then [RFC8252] 
also requires the use of the authorization code flow."

Given how many browser dependencies SPA apps tend to have, is this really 
common? In all my years building both, I've never seen it.

"Historically, the Implicit flow provided an advantage to single-page apps 
since JavaScript could always arbitrarily read and manipulate the fragment 
portion of the URL without triggering a page reload. Now with the Session 
History API (described in "Session history and navigation" of [HTML]), browsers 
have a mechanism to modify the path component of the URL without triggering a 
page reload, so this overloaded use of the fragment portion is no longer 
needed."

While this section is intended to indicate the existence of the history API is 
a reason to move away from implicit, it's also what can be used to protect 
token exposure in the URL, which I think weakens its point. As a section, to 
me, it seems unnecessary.

The push to a single flow (for consistency) is a marginal motivation, and I 
agree with that theme in the document.

Much of the other guidance in this document is already covered elsewhere (e..g. 
RFC6819). I don't know if the goal of the document is to reproduce those 
existing recommendations (as a contrast RFC8252 does not and mainly focuses on 
what's unique to the native scenario).

I can't quite tell the real motivation for this "best practice" document. If 
it's trying to give guidance for browser-based JS apps, then perhaps it should 
be enhanced to give guidance for the existing implicit flow, as well as 
suggesting code flow? But if the real motivation is just to kill off implicit 
flow then more needs to be done, IMO.

Finally, my last real concern (which is why I'm pushing back so much on code 
flow), is that this implies refresh tokens in the browser. My sense is that 
given the danger of this, the original OAuth2 RFC (via the implicit flow) was 
designed to limit the client's ability to obtain new access tokens based on the 
user's authentication session at the AS (via a cookie). 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

Hi Hans, I hope it is acceptable to reply to your message on-list.

Others could correct me if I am wrong, but I believe the purpose of this 
document is to recommend uses of other OAuth/OIDC specifications, not to 
include its own technologies.

In terms of being another spec to be referenced, I think it would be useful but 
I wonder hypothetically how to best write that specification. This method seems 
to be relying on standards-defined tokens and converting them to an application 
server session, which isn’t defined by behavior other than HTTP cookies. The 
session info hook then lets you use those proprietary session tokens to 
retrieve the access/id token.

As such, it is closer to an architecture for implementing a client - as a 
confidential client backend with an associated SPA frontend that needs to make 
OAuth-protected calls. It is not describing the communication between existing 
OAuth roles, such as between the client and AS.

There’s obvious value here, and it's one of several architectures for 
browser-based apps using a confidential client rather than a public one 
(another example being a reverse proxy which maps remote OAuth endpoints into 
local, session-token-protected ones). I personally am just not sure how you 
would define the communication between back-end and front-end portions of the 
client in these architectures as a standard within OAuth.

-DW

> On Nov 6, 2018, at 3:03 AM, Hans Zandbelt  wrote:
> 
> Hi Aaron, DW,
> 
> About draft-parecki-oauth-browser-based-apps:
> would you consider including a recommendation about and the standardization 
> of a "session info" endpoint (I'm open for better naming ;-)) as described in:
> https://hanszandbelt.wordpress.com/2017/02/24/openid-connect-for-single-page-applications/
>  
> 
> 
> this approach is not just something that I cooked up; it is based on real 
> world requests & deployments at Netflix and OAth.
> 
> Let me know what you think,
> 
> Hans.
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig  > wrote:
> Hi all,
> 
> Today we were not able to talk about 
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for 
> Browser-Based Apps".
> 
> Aaron put a few slides together, which can be found here:
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>  
> 
> 
> Your review of this new draft is highly appreciated.
> 
> Ciao
> Hannes
> 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
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> 
> 
> -- 
> hans.zandb...@zmartzone.eu 
> ZmartZone IAM - www.zmartzone.eu 

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Torsten Lodderstedt]

> Am 08.11.2018 um 22:59 schrieb David Waite :
> 
> PCKE does not resolve any known code injection attacks for SPA public clients.

It can be utilized to detect code injection at the redirect between AS and 
client. The PKCE verifier is bound to user agent that initiated the 
corresponding request. The AS binds the code to the respective PCKE challenge. 
If a code is stolen and injected at a different user agent, the PKCE verifier 
check will fail at the AS (because the client will use the wrong PKCE 
verifier).

https://tools.ietf.org/html/draft-ietf-oauth-security-topics-09#section-3.5






smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

> On Nov 8, 2018, at 4:19 AM, Tomek Stojecki 
>  wrote:
> 
> Thanks for putting this together Aaron. 
> 
> Having read through the document, I am not as convinced that there is enough 
> of a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.
> 
> In section 7.8. the document outlines the Implicit flow disadvantages as 
> following:
> 
> "- OAuth 2.0 provides no mechanism for a client to verify that an access 
> token was issued to it, which could lead to misuse and possible impersonation 
> attacks if a malicious party hands off an access token it retrieved through 
> some other means to the client."
> 
> If you use Code + PKCE with no client secret (public client) as it is being 
> advocated, you can't verify the client either. PKCE is not for authenticating 
> the client, it is there to provide a mechanism to verify inter-app 
> communication, which occurs between a browser and a native app. There is no 
> inter-app communication in implicit (everything stays in the browser), so no 
> need for PKCE.

Use of a fixed set of uniquely resolvable redirect URIs (e.g. not localhost, 
not arbitrarily registrable custom URI schemes) does provide an addressable 
channel to the public client for codes and implicit tokens. I should not be 
able to make a client that can reuses the public identifier as a third party, 
because I cannot catch the response URL from the authorization endpoint.

The difference is with implicit, the first party client cannot verify the 
tokens were meant for the client (or really even that they came from the AS). 
With code, you are contacting the AS and doing an exchange based on the code 
and your public client identifier.

In the sense of pure OAuth, where no authentication or additional authorization 
decisions are made based on the access token, the issuer and audience client 
could be checked via an introspection endpoint - but if you are using pure 
OAuth and not relying on things like CORS restrictions for your security model, 
it shouldn’t matter.

For OpenID Connect and cases where you are going beyond a pure authorization 
model (perhaps by having API access restricted by CORS), this sort of check is 
important. You could trust clients to explicitly check by looking in an 
id_token (when available) or calling an introspection endpoint, or you could 
have this check happen as part of normal flow by using code flow.

PCKE does not resolve any known code injection attacks for SPA public clients. 
Recommending administrators require PKCE does allow them to start to make a 
single coherent policy for public clients.

A consistent policy also helps in SPA/native app crossover cases. For examples, 
a javascript app could be published as a native app via wrapping in a 
Cordova-style toolset, or by sharing a significant amount of code using a 
React-native style toolset. Both the SPA and native app could then share 
handling links depending on native app installation due to universal/app link 
features of the operating systems. For this reason, there was a definite effort 
to propose best practices that overlapped with the native app BCP.

It is also worth noting that since the SPA and native app could share the same 
client identifier and redirect handling (via universal links), you *could* have 
code injection, but it would be between multiple first-party apps.

> "- Supporting the implicit flow requires additional code, more upkeep and 
> understanding of the related security considerations, while limiting the 
> authorization server to just the authorization code flow simplifies the 
> implementation."
> 
> This is subjective and can be easily argued the other way. I think one of the 
> main selling points behind implicit was its simplicity. It is hard to argue 
> (putting libraries aside) that making one redirect (implicit) requires more 
> code, work, etc.. than making a redirect and at least two additional calls in 
> order to get AT (plus CORS on AS side).

The implicit flow is only simpler for clients until they have to get a new 
access token. Typically then you need a different set of OAuth code to request 
a new token in the background via a hidden iframe, failing back to temporarily 
leaving the app via top-level redirect. There are also cases where the safari 
browser detects this cross-domain iframe bouncing as a tracker and segments any 
AS cookies/storage per client site.

It is more work for the AS to support both. You may also wind up having 
different security models for the two different public client flows. In 
particular, you may find yourself as an AS policy setter wanting to have longer 
lived sessions for implicit clients which do not have refresh tokens to extend 
access token validity in the background. For this reason, you may also decide 
implicit clients cannot get access to the same scopes that a code client can. 

There are also gotchas people are not used to in implicit, such as fragment 
identifiers being preserved on redirects.

For 

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Tomek Stojecki]

Thanks for putting this together Aaron. 

Having read through the document, I am not as convinced that there is enough of 
a benefit of Authorization Code + PKCE vs Implict Flow for SPAs.

In section 7.8. the document outlines the Implicit flow disadvantages as 
following:

"- OAuth 2.0 provides no mechanism for a client to verify that an access token 
was issued to it, which could lead to misuse and possible impersonation attacks 
if a malicious party hands off an access token it retrieved through some other 
means to the client."

If you use Code + PKCE with no client secret (public client) as it is being 
advocated, you can't verify the client either. PKCE is not for authenticating 
the client, it is there to provide a mechanism to verify inter-app 
communication, which occurs between a browser and a native app. There is no 
inter-app communication in implicit (everything stays in the browser), so no 
need for PKCE.

"- Supporting the implicit flow requires additional code, more upkeep and 
understanding of the related security considerations, while limiting the 
authorization server to just the authorization code flow simplifies the 
implementation."

This is subjective and can be easily argued the other way. I think one of the 
main selling points behind implicit was its simplicity. It is hard to argue 
(putting libraries aside) that making one redirect (implicit) requires more 
code, work, etc.. than making a redirect and at least two additional calls in 
order to get AT (plus CORS on AS side).

Further, in the beginning paragraph of 7.8, you mention that implicit gets the 
AT through the front-channel. Exchanging code for AT will also happen in the 
browser , where instead of a url you will have an xhr (and again, now we have 
cors)

Finally, how is the AT going to be refreshed? Are we allowing for long lived RT 
in the browser? I see that the document mentions CSP in 7.7, but doesn't the 
same apply to securing AT with Implicit?

Regrads,
Tomek Stojecki

On Tuesday, November 6, 2018, 10:55:40 AM GMT+1, Hannes Tschofenig 
 wrote: 





Hi all,

Today we were not able to talk about draft-parecki-oauth-browser-based-apps-00, 
which describes  "OAuth 2.0 for Browser-Based Apps".

Aaron put a few slides together, which can be found here:
https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf

Your review of this new draft is highly appreciated.

Ciao
Hannes
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[David Waite]

> On Nov 7, 2018, at 9:08 AM, Simon Moffatt  wrote:
> 
> It's an interesting topic.  I think there is a definitely a set of options 
> and considerations for this.  Namely operational.  For example, hugely 
> popular mobile apps (multi-million downloads across different OS's) using 
> dynamic reg with per-instance private creds requires the AS to be able to 
> store and index those client profiles easily.  Smaller scale custom built 
> authorization servers are not necessarily going to be able to handle that - 
> hence the popularity of assuming everything is generic and public coupled 
> with PKCE.
> 
Having unique client identifiers does provide some niceties. As examples: it 
gives a user a chance to administer/revoke those clients, and it gives the AS 
an opportunity to do behavioral analysis with a per-client rather than per-user 
granularity.

It also allows you to track user-granted consent per client. There are very 
limited options (really, just id_token_hint from OIDC) to indicate when hitting 
the authorization endpoint that you have prior consent.

In any case, the ability to work with public clients or the need to do dynamic 
client registration is AS policy, not something clients typically have the 
power to decide.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Simon Moffatt]

It's an interesting topic.  I think there is a definitely a set of
options and considerations for this.  Namely operational.  For example,
hugely popular mobile apps (multi-million downloads across different
OS's) using dynamic reg with per-instance private creds requires the AS
to be able to store and index those client profiles easily.  Smaller
scale custom built authorization servers are not necessarily going to be
able to handle that - hence the popularity of assuming everything is
generic and public coupled with PKCE.

On the other hand, if a less popular first-party app used internally for
employees for example, might well go for secure element integration on
the appropriate mobile OS.

So, I guess options are needed and best practice for a few subtly
different scenarios.

Regards

Simon



On 07/11/18 15:20, Joseph Heenan wrote:
> Hi Aaron,
>
> Thanks for putting this document together, I think this kind of
> guidance is invaluable.
>
> It may be worth slightly rewording 7.2 as it may encourage a growing
> misconception that all native apps must be public clients. With many
> devices now having embedded HSMs, we’ve seen increasing interest in
> mobile apps being dynamically (per-install) registered oauth2 private
> clients, and that model has a lot of advantages. (I’m not sure if we
> might see a similar model evolving for web apps.) 
>
> The BCP for native apps does allow
> this:https://tools.ietf.org/html/rfc8252#section-8.4
>
> Cheers,
>
> Joseph
>
>
>
>
>
>> On 6 Nov 2018, at 10:13, Aaron Parecki > > wrote:
>>
>> Thanks Hannes,
>>
>> Since I wasn't able to give an intro during the meeting today, I'd
>> like to share a little more context about this here as well.
>>
>> At the Internet Identity Workshop in Mountain View last week, I led a
>> session to collect feedback on recommendations for OAuth for browser
>> based apps. During the session, we came up with a list of several
>> points based on the collective experience of the attendees. I then
>> tried to address all those points in this draft.
>>
>> The goal of this is not to specify any new behavior, but rather to
>> limit the possibilities that the existing OAuth specs provide, to
>> ensure a secure implementation in browser based apps.
>>
>> Thanks in advance for your review and feedback!
>>
>> Aaron Parecki
>> aaronpk.com 
>>
>>
>>
>> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig
>> mailto:hannes.tschofe...@arm.com>> wrote:
>>
>> Hi all,
>>
>> Today we were not able to talk about
>> draft-parecki-oauth-browser-based-apps-00, which describes 
>> "OAuth 2.0 for Browser-Based Apps".
>>
>> Aaron put a few slides together, which can be found here:
>> 
>> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>>
>> Your review of this new draft is highly appreciated.
>>
>> Ciao
>> Hannes
>> 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
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> -- 
>> 
>> Aaron Parecki
>> aaronparecki.com 
>> @aaronpk 
>>
>> ___
>> OAuth mailing list
>> OAuth@ietf.org 
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

-- 
ForgeRock   *Simon Moffatt*
Technical Director Product Management  |  ForgeRock
*t* (44) 7903 347 240  |  *e* simon.moff...@forgerock.com

*twitter* @simonmoffatt  |  *web* www.forgerock.com




NOTICE: This message, including any attachments, may contain
confidential information. If you are not the intended recipient, please
advise the sender immediately and destroy all copies of this message and
any attachments. ForgeRock Ltd may monitor email traffic data and also
the content of email transmitted over its network for security purposes.
No employee or agent is authorized to conclude any binding agreement on
behalf of ForgeRock Ltd by means of e-mail communication. ForgeRock Ltd
is a limited company registered in England and Wales; its registered
address is 60 Queen Square, Bristol, BS1 4JZ; and its registration
number is 7227664.

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Joseph Heenan]

Hi Aaron,

Thanks for putting this document together, I think this kind of guidance is 
invaluable.

It may be worth slightly rewording 7.2 as it may encourage a growing 
misconception that all native apps must be public clients. With many devices 
now having embedded HSMs, we’ve seen increasing interest in mobile apps being 
dynamically (per-install) registered oauth2 private clients, and that model has 
a lot of advantages. (I’m not sure if we might see a similar model evolving for 
web apps.) 

The BCP for native apps does allow 
this:https://tools.ietf.org/html/rfc8252#section-8.4

Cheers,

Joseph





> On 6 Nov 2018, at 10:13, Aaron Parecki  wrote:
> 
> Thanks Hannes,
> 
> Since I wasn't able to give an intro during the meeting today, I'd like to 
> share a little more context about this here as well.
> 
> At the Internet Identity Workshop in Mountain View last week, I led a session 
> to collect feedback on recommendations for OAuth for browser based apps. 
> During the session, we came up with a list of several points based on the 
> collective experience of the attendees. I then tried to address all those 
> points in this draft.
> 
> The goal of this is not to specify any new behavior, but rather to limit the 
> possibilities that the existing OAuth specs provide, to ensure a secure 
> implementation in browser based apps.
> 
> Thanks in advance for your review and feedback!
> 
> Aaron Parecki
> aaronpk.com 
> 
> 
> 
> On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig  > wrote:
> Hi all,
> 
> Today we were not able to talk about 
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for 
> Browser-Based Apps".
> 
> Aaron put a few slides together, which can be found here:
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>  
> 
> 
> Your review of this new draft is highly appreciated.
> 
> Ciao
> Hannes
> 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
> OAuth@ietf.org 
> https://www.ietf.org/mailman/listinfo/oauth 
> 
> -- 
> 
> Aaron Parecki
> aaronparecki.com 
> @aaronpk 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

[Aaron Parecki]

Thanks Hannes,

Since I wasn't able to give an intro during the meeting today, I'd like to
share a little more context about this here as well.

At the Internet Identity Workshop in Mountain View last week, I led a
session to collect feedback on recommendations for OAuth for browser based
apps. During the session, we came up with a list of several points based on
the collective experience of the attendees. I then tried to address all
those points in this draft.

The goal of this is not to specify any new behavior, but rather to limit
the possibilities that the existing OAuth specs provide, to ensure a secure
implementation in browser based apps.

Thanks in advance for your review and feedback!

Aaron Parecki
aaronpk.com



On Tue, Nov 6, 2018 at 10:55 AM Hannes Tschofenig 
wrote:

> Hi all,
>
> Today we were not able to talk about
> draft-parecki-oauth-browser-based-apps-00, which describes  "OAuth 2.0 for
> Browser-Based Apps".
>
> Aaron put a few slides together, which can be found here:
>
> https://datatracker.ietf.org/meeting/103/materials/slides-103-oauth-sessa-oauth-2-for-browser-based-apps-00.pdf
>
> Your review of this new draft is highly appreciated.
>
> Ciao
> Hannes
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Aaron Parecki
aaronparecki.com
@aaronpk 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth