* For UI related functionality, i.e. document selection, user profile display/changes, contact updates, etc... You should be able to execute the client side silent authentication using the provided session token from the Azure AD AS, without needing to make any RO api calls nor user redirects. Can you expand on what silent authentication and session token stands for here? If you are referring to the iframe scenario, the new browser measures make it problematic. In code+PKCE you can use a refresh token, but see the other reply for how this proposal is an alternative to that in some situations. This answer was specifically on why having backend-issued tokens didn’t apply to this scenario.
From: Warren Parad <wparad=40rhosys...@dmarc.ietf.org> Date: Sunday, February 14, 2021 at 03:48 To: Vittorio Bertocci <vittorio.berto...@auth0.com> Cc: Neil Madden <neil.mad...@forgerock.com>, "oauth@ietf.org" <oauth@ietf.org> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) For the trusted part, see above. For the short lived JWTs, that’s not really an option. The most generic scenario addressed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine we’re talking about a SPA application that signs in users using Azure AD, and needs to call Office and Azure APIs. The SPA backend cannot issue tokens for those APIs, it can only request them to the Azure AD AS. For UI related functionality, i.e. document selection, user profile display/changes, contact updates, etc... You should be able to execute the client side silent authentication using the provided session token from the Azure AD AS, without needing to make any RO api calls nor user redirects. For RO responsibilities, you can present the user with a button "Grant RO access to Azure resources" button and the user will go through a permission scope elevation flow, again no reason to need a BFF here. We did consider adding something to that effect, an error message that can direct the frontend to perform the interactive portion necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client offers an endpoint that is guaranteed to initiate a sign in flow (hence inject all the necessary nonces etc). We didn’t add it upfront and left it as exercise for the reader mostly because it’s not easy to model properly and before opening that work front we wanted to see how the idea was received. It may make sense for the app to have an error message, or even better might be a 302 Location header depending on what you are doing. There is nothing here that is OAuth specific however (nor common), and then we should challenge the need to directly provide an RFC recommendation for handling this. [Image removed by sender.] Warren Parad Founder, CTO Secure your user data and complete your authorization architecture. Implement Authress<https://authress.io>. On Sun, Feb 14, 2021 at 12:29 PM Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> wrote: Hi Neil, Thanks for the prompt comments! * Re: GET vs POST, personally I’d be fine with restricting to POST. * Re: RO-AS, interaction- perhaps it is not very clear from the text at the moment (first draft), but that is assumed that the RO went thru whatever interactive steps are necessary to establish a session (eg sign in, assuming the AS is say an OIDC provider) and obtain beforehand the access token and refresh tokens that will be needed during the app activities taking place after that. In concrete terms, imagine that the backend performs an authorization code grant requesting an IDtoken, access token and refresh token BEFORE the activities described in TMI-BFF take place. The current language trying to express that is in 1.2: As a prerequisite for the flow described below, the backend MUST have established a secure session with the user agent, so that all requests from that user agent toward the backend occur over HTTPS and carry a valid session artifact (such as a cookie) that the backend can validate. This document does not mandate any specific mechanism to establish and maintain that session. And cached, it requests to the authorization server a new access token with the required characteristics, using any artifacts previousy obtained (eg refresh token) and grants that will allow the authorization server to issue the requested token without requiring user interaction. * If the backend is already implicitly trusted then couldn’t you skip OAuth and just get the backend to issue short-lived JWTs to the frontend that it can use for API access? For the trusted part, see above. For the short lived JWTs, that’s not really an option. The most generic scenario addressed here is for APIs that accept tokens issued by the AS; the backend can request them as a client, but it cannot mint them. Imagine we’re talking about a SPA application that signs in users using Azure AD, and needs to call Office and Azure APIs. The SPA backend cannot issue tokens for those APIs, it can only request them to the Azure AD AS. * If you want to allow auth code flow etc then perhaps the bff-token endpoint can return a standard error code with an authorization endpoint URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that references that so that authorization details aren’t passed through the frontend). We did consider adding something to that effect, an error message that can direct the frontend to perform the interactive portion necessary for this topology to work. It would be something similar to the IDP initiated login in OIDC, where the client offers an endpoint that is guaranteed to initiate a sign in flow (hence inject all the necessary nonces etc). We didn’t add it upfront and left it as exercise for the reader mostly because it’s not easy to model properly and before opening that work front we wanted to see how the idea was received. From: OAuth <oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>> on behalf of Neil Madden <neil.mad...@forgerock.com<mailto:neil.mad...@forgerock.com>> Date: Sunday, February 14, 2021 at 00:17 To: Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> Cc: "oauth@ietf.org<mailto:oauth@ietf.org>" <oauth@ietf.org<mailto:oauth@ietf.org>> Subject: Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF) I have a lot of security concerns about this draft. The draft alludes to security issues associated with handling access tokens in the frontend but never really spells them out. From the Security Considerations it seems that the primary concern is with theft of access tokens from local storage. To do this you’d need an XSS attack. But in that case, wouldn’t the attacker simply use the XSS to make a call to the bff-token endpoint instead? The combination of the bff-token endpoint recommending the use of GET requests together with the hint to use cookie-based authentication is likely going to punch a hole in most CSRF defenses, which assume that GETs are safe. The only thing preventing this being exploitable is Cross-Origin Read Blocking (https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md) due to the JSON content-type. That makes me really nervous. We should at least mandate X-Content-Type-Options: nosniff on that response. I’d feel more comfortable if this was a POST request only. As Stoycho Sleptsov mentioned in the other email, the lack of front-channel communication between the AS and the RO seems odd. If the backend is already implicitly trusted then couldn’t you skip OAuth and just get the backend to issue short-lived JWTs to the frontend that it can use for API access? If you want to allow auth code flow etc then perhaps the bff-token endpoint can return a standard error code with an authorization endpoint URI that the SPA then navigates the user to. (Eg the backend can do a PAR request first and return a URI that references that so that authorization details aren’t passed through the frontend). — Neil On 12 Feb 2021, at 20:46, Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org<mailto:40auth0....@dmarc.ietf.org>> wrote: Dear all, Brian and yours truly are proposing a new specification that shows how the user agent frontend of a web app can delegate token acquisition and persistence to its backend, and request such tokens when needed for direct access of protected resources from the frontend code. The pattern is already in use, in proprietary form, by various modern development stacks, such as Next.JS. Variants of the pattern, often discussed under the catch-all term BFF (backend for frontend), have been often mentioned in this workgroup’s activity, but always left all implementation details to the reader. We believe the pattern has merit, as corroborated by its growing adoption. By delegating access token acquisition to the backend, we avoid many of the often brittle moving parts (and implied attack surface) required to acquire access tokens from a user agent. The topology also relieves the frontend from the need of persisting tokens in local storage, a well known sore point of using OAuth directly in JavaScript, by relying on its backend storage and session to preserve tokens. Although the specification is very simple, providing explicit guidance on the scenario offers many advantages. - It makes it possible to create interoperable SDKs, where frontend dev stacks (any JS flavor) can be mixed and matched with compliant backend stacks (middlewares in node, java, ASP.NET<http://ASP.NET>, PHP etc) - It allows us to provide guidance on how to properly tackle the scenario and warn implementers against security risks (scope escalations, using IDtokens instead of access tokens, etc) - It allows us to discuss (and when appropriate, promote) this pattern as part of the browser apps security guidance, and position the scenario where frontend only calls API on its own backed (hence doesn’t need access tokens) simply as a special case of this more general pattern - This approach makes mocking and testing apps very easy, possibly preventing developers from weakening the security of their system (eg turning on ROPG options) or turning to risky practices like scraping Needless to say, this specification doesn’t entirely eliminate the risks inherent to direct use of access tokens from a browser. But reality is that the pattern is in widespread use, and the circumstances leading to that (eg developers on a particular project only work with frontend stacks; components like reverse proxies might not always be viable; etc) aren’t going away any time soon. By providing simple guidance on this pattern, we can simplify the life of many developers while enshrining basic security hygiene in scenarios that would have otherwise be left to their own device. Looking forward for your feedback! B&V On 2/12/21, 12:41, "internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>" <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> wrote: A new version of I-D, draft-bertocci-oauth2-tmi-bff-00.txt has been successfully submitted by Vittorio Bertocci and posted to the IETF repository. Name: draft-bertocci-oauth2-tmi-bff Revision: 00 Title: Token Mediating and session Information Backend For Frontend Document date: 2021-02-12 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.txt Status: https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/ Html: https://www.ietf.org/archive/id/draft-bertocci-oauth2-tmi-bff-00.html Htmlized: https://tools.ietf.org/html/draft-bertocci-oauth2-tmi-bff-00 Abstract: This document describes how a JavaScript frontend can delegate access token acquisition to a backend component. In so doing, the frontend can access resource servers directly without taking on the burden of communicating with the authorization server, persisting tokens, and performing operations that are fraught with security challenges when executed in a user agent, but are safe and well proven when executed by a confidential client running on a backend. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>. The IETF Secretariat _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth ForgeRock values your Privacy<https://www.forgerock.com/your-privacy> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
