Subject: [OAUTH-WG] More product group review comments on the OAuth 2.0 for Browser-Based Apps spec

From: Mike Jones <[email-masked]>
Date: Sat, 22 Feb 2020 01:02:01 +0000

More comments hot off the presses from a Microsoft product architect...

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-6.2<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-browser-based-apps-04%23section-6.2&data=04%7C01%7CMichael.Jones%40microsoft.com%7C73725d8c1c014d1b6e2408d7b731dce8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637179297104326028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=7ycNTjlpOBqPB22EFNhqnCBN3T0kev1bGw%2BmtL5KgKo%3D&reserved=0>
Applications with BE

If I read this correctly, the prescribed pattern is to have browser JS call into its own BE only and have the BE call into 3P WebAPIs:

When the JavaScript application in the browser wants to make a
   request to the Resource Server, it MUST instead make the request to
   the Application Server, and the Application Server will make the
   request with the access token to the Resource Server (C), and forward
   the response (D) back to the browser.

Many of our application services give the access tokens to browser instead and have JS call the resource server directly.
If we enforce the prescribed pattern, then app server becomes proxy to all resource servers. This may not scale of our services

SPO, for example, has a pattern that is a mix b/n application with and without BE. It can behave as public or conf client depending on the redirect URI as we allow URI to be marked as 'SPA'.

https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-9.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-browser-based-apps-04%23section-9.3&data=04%7C01%7CMichael.Jones%40microsoft.com%7C73725d8c1c014d1b6e2408d7b731dce8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637179297104326028%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=TD0czW39IBoTpREeBFhmcUGcIzbYmPU02f6qZ4lFWFo%3D&reserved=0>
9.3<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-oauth-browser-based-apps-04%23section-9.3&data=04%7C01%7CMichael.Jones%40microsoft.com%7C73725d8c1c014d1b6e2408d7b731dce8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637179297104335990%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C-1&sdata=NfIE3QQYxgnRRkAFMR4ljuEcHKJYEBdVN2IyKf6m6ww%3D&reserved=0>.  Client Impersonation
It is implied that consent granted to public client should not be recorded:

Even when the user has previously approved an

   authorization request for a given client_id, the request SHOULD be

   processed as if no previous request had been approved, unless the

   identity of the client can be proven.

Do we agree with this? If implemented, it will add significant number of consent prompts.

tx

---

From: Aaron Parecki <[email-masked]>
Date: Fri, 28 Feb 2020 13:02:57 -0800

> 9.3.  Client Impersonation

This text in this BCP is summarizing section 10.2 of RFC6749, not
defining anything new. The following paragraph allows the
authorization server to treat an exact match of a registered redirect
URI as proof of identity for the client to avoid the consent screen.
This is actually allowing the exact behavior the commenter wants. I
will try to rephrase this text to make it more clear.

> Many of our application services give the access tokens to browser instead and have JS call the resource server directly.

How is this different from the pattern defined in 6.3, "JavaScript
Applications without a Backend"? Is the difference that the OAuth
exchange is handled by something other than the SPA? If that's the
case, it sounds like that might be a new pattern that could be worth
documenting as well, if that's a common pattern others have
implemented and have good suggestions for.

----
Aaron Parecki
aaronparecki.com
@aaronpk

----
Aaron Parecki
aaronparecki.com
@aaronpk

On Fri, Feb 21, 2020 at 5:02 PM Mike Jones <[email-masked]> wrote:
>
> More comments hot off the presses from a Microsoft product architect…
>
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-6.2
>
> Applications with BE
>
>
>
> SPO, for example, has a pattern that is a mix b/n application with and without BE. It can behave as public or conf client depending on the redirect URI as we allow URI to be marked as ‘SPA’.
>
>
>
> https://tools.ietf.org/html/draft-ietf-oauth-browser-based-apps-04#section-9.3
>
> 9.3.  Client Impersonation
>