Re: [OAUTH-WG] Token Mediating and session Information Backend For Frontend (TMI BFF)

[Warren Parad <[e-mail]>]

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

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=
[e-mail]> 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 <[e-mail]> on behalf of Neil Madden <
> [e-mail]>
> *Date: *Sunday, February 14, 2021 at 00:17
> *To: *Vittorio Bertocci <vittorio.bertocci=[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
> *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=
> [e-mail]> 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, 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, "[e-mail]" <[e-mail]>
> 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.
>
>    The IETF Secretariat
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>