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