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

[Aaron Parecki <[e-mail]>]

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

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 <[e-mail]> 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
>
>
>
> 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
>
> 9.3.  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
>
>