> 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 <michael.jo...@microsoft.com> 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 > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
