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

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

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 <[email-masked]> On Behalf Of Brian Campbell
Sent: Friday, November 30, 2018 11:43 PM
To: Torsten Lodderstedt <[email-masked]>
Cc: oauth <[email-masked]>
Subject: Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00

On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
> Am 15.11.2018 um 23:01 schrieb Brock Allen <[email-masked]<mailto:[email-masked]>>:
>
> 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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 1 Dec 2018 15:34:10 +0100

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 <[email-masked]>:
> 
> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <[email-masked]> wrote:
> > Am 15.11.2018 um 23:01 schrieb Brock Allen <[email-masked]>:
> > 
> 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.
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 1 Dec 2018 16:25:09 +0100

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 <[email-masked]>:
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Sat, 1 Dec 2018 20:44:37 -0300

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 
> <[email-masked] <mailto:[email-masked]>>:
>
>> 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 
>> <[email-masked] <mailto:[email-masked]>>:
>>
>>> 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 <[email-masked] 
>>> <mailto:[email-masked]>> *On Behalf Of *Brian Campbell
>>> *Sent:* Friday, November 30, 2018 11:43 PM
>>> *To:* Torsten Lodderstedt <[email-masked] 
>>> <mailto:[email-masked]>>
>>> *Cc:* oauth <[email-masked] <mailto:[email-masked]>>
>>> *Subject:* Re: [OAUTH-WG] draft-parecki-oauth-browser-based-apps-00
>>>
>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt 
>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>>     > Am 15.11.2018 um 23:01 schrieb Brock Allen
>>>     <[email-masked] <mailto:[email-masked]>>:
>>>     >
>>>     > 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.
>> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 2 Dec 2018 08:31:09 +0100

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 <[email-masked]>:
> 
> How is that different from a regular server client with a web interface if the backed is doing the API calls to the RS?
> 
> 
>

---

From: Rob Otto <[email-masked]>
Date: Sun, 2 Dec 2018 11:54:52 +0000

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 <[email-masked]>
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.
>
> How is that different from a regular server client with a web interface if
> the backed is doing the API calls to the RS?
>
>
> 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.
>
> 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.
>
> 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 <[email-masked]> *On Behalf Of *Brian Campbell
> *To:* Torsten Lodderstedt <[email-masked]>
> *Cc:* oauth <[email-masked]>
> > 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.*
> 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 [email-masked]://www.ietf.org/mailman/listinfo/oauth
>

-- 
<https://www.pingidentity.com>
<https://www.pingidentity.com>
Rob Otto
EMEA Field CTO/Solutions Architect
[email-masked]

c: +44 (0) 777 135 6092
Connect with us: 
<https://www.glassdoor.com/Overview/Working-at-Ping-Identity-EI_IE380907.11,24.htm>
[image:
LinkedIn logo] <https://www.linkedin.com/company/21870> [image: twitter
logo] <https://twitter.com/pingidentity> 
<https://www.facebook.com/pingidentitypage> 
<https://www.youtube.com/user/PingIdentityTV> 
<https://plus.google.com/u/0/114266977739397708540> 
<https://www.pingidentity.com/en/blog.html>
<https://www.google.com/url?q=https://www.pingidentity.com/content/dam/ping-6-2-assets/Assets/faqs/en/consumer-attitudes-post-breach-era-3375.pdf?id%3Db6322a80-f285-11e3-ac10-0800200c9a66&source=gmail&ust=1541693608526000&usg=AFQjCNGBl5cPHCUAVKGZ_NnpuFj5PHGSUQ>

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 2 Dec 2018 14:10:47 +0100

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 <[email-masked]>:
> 
> 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)? 
> 
>> On Sun, 2 Dec 2018 at 07:31, Torsten Lodderstedt <[email-masked]> wrote:
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Aaron Parecki <[email-masked]>
Date: Sun, 2 Dec 2018 15:43:51 -0800

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

---

From: Phil Hunt <[email-masked]>
Date: Sun, 2 Dec 2018 17:16:39 -0800

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

---

From: David Waite <[email-masked]>
Date: Sun, 2 Dec 2018 20:18:09 -0700

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 <[email-masked]> wrote:
> 
> aaronparecki.com <http://aaronparecki.com/>
> 
> 
> 
> On Sat, Dec 1, 2018 at 11:31 PM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
> Am 02.12.2018 um 00:44 schrieb John Bradley <[email-masked] <mailto:[email-masked]>>:
> 
>>> Am 01.12.2018 um 15:34 schrieb Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>:
>>> 
>>>> Am 01.12.2018 um 10:15 schrieb Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>:
>>>> 
>>>>> From: OAuth <[email-masked] <mailto:[email-masked]>> On Behalf Of Brian Campbell
>>>>> To: Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>
>>>>> Cc: oauth <[email-masked] <mailto:[email-masked]>>
>>>>> On Sat, Nov 17, 2018 at 4:07 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <[email-masked] <mailto:[email-masked]>>:
>>>>> > 
>>>>> 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 <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 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-12>) are the options available. 
>>>>> 
>>>>>  
>>>>> 
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>> 
>>> 
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Hans Zandbelt <[email-masked]>
Date: Mon, 3 Dec 2018 08:30:32 +0100

On Mon, Dec 3, 2018 at 4:18 AM David Waite <[email-masked]>
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.

> 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?
>
>> Sender constrained access tokens in SPAs need adoption of token binding
>> or alternative mechanism. mtls could potentially work in deployments with
>> I share the concern Brian has, which is also the conclusion I came up
>> with in my other email sent a few minutes ago.
>>
>>
>>
>> <https://tools..ietf.org/html/draft-ietf-oauth-token-binding-08>) as
>> well as Mutual TLS for OAuth (

-- 
[email-masked]
ZmartZone IAM - www.zmartzone.eu

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 3 Dec 2018 09:25:10 +0100

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 <[email-masked]>:
> 
> 
>> On Mon, Dec 3, 2018 at 4:18 AM David Waite <[email-masked]> wrote:
> 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
>>

---

From: David Waite <[email-masked]>
Date: Mon, 3 Dec 2018 02:11:45 -0700

> On Dec 3, 2018, at 1:25 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 

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

> 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

---

From: John Bradley <[email-masked]>
Date: Mon, 3 Dec 2018 11:19:06 +0100

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.

---

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

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

---

From: Aaron Parecki <[email-masked]>
Date: Mon, 3 Dec 2018 06:57:12 -0800

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 <[email-masked]>
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.
>
> 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.
> —
>
> 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.
> >>>
> 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.
> >>>>
> >>>>> > 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)?
> >>>>>
> methods for sender constraining access tokens (
> 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.
> >>>>>
> >>>>>
> >>>>>
> 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
> your computer. Thank you.
> >>>>>
----
Aaron Parecki
aaronparecki.com
@aaronpk <http://twitter.com/aaronpk>

---

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

I would also like to see something to that effect. I feel that sometimes
because SPAs use APIs, there's an unchallenged assumption that OAuth also
has to be used with the in-browser code accessing those APIs. Even if the
details are out of scope for this document, some text like the below at
least gives a nod to the possibility of different approaches, which may
ultimately be more secure and easier to mange.
https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps-00#section-5.1
kinda does this too but I'm a +1 for a little something along the lines of
what is being discussed recently in this thread.

On Mon, Dec 3, 2018 at 7:57 AM Aaron Parecki <[email-masked]> wrote:

> On Mon, Dec 3, 2018 at 3:15 AM Torsten Lodderstedt <
> [email-masked] <torsten@lodderstedt..net>> wrote:
>
>> > 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.
>> >
>> > 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
>> >> How is that different from a regular server client with a web
>> interface if the backed is doing the API calls to the RS?
>> >>
>> >>
>> >>
>> >>>>> > Am 15.11.2018 um 23:01 schrieb Brock Allen <[email-masked]
>> >:
>> >>>>> >
>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as well
>> privileged material for the sole use of the intended recipient(s).. Any
>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments
>> are confidential and may also be privileged. If you are not the intended
>> >>> OAuth@ietf..org <[email-masked]>

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 4 Dec 2018 10:56:40 -0800

Thanks for all the discussion here. I've added the paragraph described to
the document in a new "Architectural Considerations" section. Currently in
the GitHub source code but not yet published as a new IETF draft, which
will be coming shortly. https://github.com/aaronpk/oauth-browser-based-apps

----
Aaron Parecki
aaronparecki.com

On Mon, Dec 3, 2018 at 9:53 AM Brian Campbell <[email-masked]>
wrote:

>> 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:
>>
>> ---
> review, use, distribution or disclosure by others is strictly prohibited.

---

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

As mentioned during IIW when this pattern was borught up: I think readers
should receive a stronger warning about the known challenges of that
approach. Namely, assuming that the developer wants to perform API calls
from the browser:
- Making the app backend the true client for the AS is tantamount to making
the app backend act as an AS for the JS running in the browser. The traffic
between the JS layer and its backend for getting the initial token,
renewing tokens, doing stepup auth and the like is not codified in any
normative document- hence it's not threat modeled. Leaving it as exercise
to the reader without proper warnings seems reckless
- Various important providers indicate in the access token whether it was
issued to a confidential client or to a public one- and resources can rely
on that to make authorization decisions (for example allowing access only
to specific confidential clients). By having an app backend to act as a
proxy and pass those access tokens along to the JS layer, a resource might
be fooled into thinking that the caller is a confidential client, while in
fact the client is just a public client. Implementers choosing to use the
proxy pattern should either ensure resources refrain from using the nature
of the client (as certified by the access token) as input to authorization
decisions, or should have a way to signal to the AS that the tokens
requested are meant to be actually used by a weaker client hence should not
mark the ATs as issued to a confidential client.

I am not suggesting that the document should necessarily contain this level
of detail, but I do think we should hint at those two challenges so that
readers have a better idea of the risks inherent to the approach with
today's tools.

Related to this: if we think this pattern is common, we should consider
producing formal guidance on how to handle the necessary exchanges- or
we'll end up with a babel of proprietary ways of connecting the JS frontent
to the backend, with huge waste of cycles across the industry.

On Tue, Dec 4, 2018 at 10:57 AM Aaron Parecki <[email-masked]> wrote:

> will be coming shortly.
> https://github.com/aaronpk/oauth-browser-based-apps
>
> ----
> Aaron Parecki
> aaronparecki.com
>>>> 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.
>>>>
>>>> client...   The fact that it has a angular or other JS UI protected by a
>>>> frontend... just a different cut through the web app’s layering
>>>> >
>>>> >>>>> I share the concern Brian has, which is also the conclusion I
>>>> came up with in my other email sent a few minutes ago.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>
>>>> 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)?
>>>> >>>>>
>>>> privileged material for the sole use of the intended recipient(s)... Any
>>>> >>> OAuth@ietf...org <[email-masked]>

---

From: Aaron Parecki <[email-masked]>
Date: Wed, 5 Dec 2018 19:17:08 -0600

That's a very good point, I will see what I can adapt from your description
below for the spec. I do think it's worth emphasizing like you say.

Aaron

On Wed, Dec 5, 2018 at 7:15 PM Vittorio Bertocci <[email-masked]> wrote:

> - Making the app backend the true client for the AS is tantamount to
> making the app backend act as an AS for the JS running in the browser. The
> traffic between the JS layer and its backend for getting the initial token,
> I am not suggesting that the document should necessarily contain this
> level of detail, but I do think we should hint at those two challenges so
> that readers have a better idea of the risks inherent to the approach with
> today's tools.
>
>>>>> Security of the connection between code running in the browser and
>>>>> this backend component is assumed to utilize browser-level protection
>>>>> > 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
>>>>> https://tools.ietf.org/html/draft-ietf-oauth-token-binding-08) as
----
Aaron Parecki
aaronparecki.com