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

[Warren Parad <[e-mail]>]

>
> To restate, the TMI-BFF proposal is not trying to fix any of that... it’s
> definitely not a top level driver.

Great, then we are back to: what is the top level driver. Because, while I
appreciate the circumstances around ITP2.1~ as I fully understand how
identity providers like Auth0 are using iframes and thirdparty cookies,
this problem vanishes with the use of first-party domains. So let's skip
the digression and assume we aren't solving ITP future related issues.

The real problem I have with the draft is that it essentially suggests that
every app needs to run a BFF to do user token generation because an AS is
no longer afforded the capability for some reason. If we pull in expecting
to solve ITP related issues then I think that justification is in play and
we can work together to come up with a solution, rather than starting with
the current deleterious prevalent pattern on the internet (which honestly
is the most ridiculous paradigm I have seen). If we don't assume ITP is an
issue, then I fail to see the core problem that existing AS have (as you
pointed out code+PKCE already works) without the front channel or back
channel needing really to make any additional changes.

I assume there is a flaw in my reasoning somewhere, so please help me find
it.

- Warren

Warren Parad

Founder, CTO


On Sun, Feb 14, 2021 at 9:20 PM Vittorio Bertocci <vittorio.bertocci=
[e-mail]> wrote:

> Let me rewind a bit here. This was never presented as driving use case.
>
>
>
>    - Neil suggested that the backend could simply give short lived JTWs
>    for the frontent to call API.
>    - I clarified that this would not be viable in the general case and
>    provided an example scenario where backend issued short lived tokens would
>    not have worked
>    - You commented that the frontend can obtain AS tokens from JS and
>    mentioned silent authentication. I clarified (or tried to) that this
>    offshoot of the discussion wasn’t to say that there is no viable way of
>    doing the scenario already, and by the way using an iFrame to do silent
>    authentication is now problematic. At this point we are no longer
>    discussing TMI-BFF, but current affairs in the authentication world. The
>    fact that we are proposing TMI-BFF and the fact that silent authentication
>    is less and less viable are independent facts, the former isn’t meant to be
>    a solution for the latter (it’s already addressed by using RTs in coke+PKCE)
>
>
>
> That clarified. Not only we expect ITP to affect silent authentication, it
> has been affected for the past year and that has been one of the primary
> business drivers for the rapid adoption of code+PKCE+RTs in the user agent,
> as customers with pure SPAs found themselves unable to renew tokens without
> prompting as their access to cookies in flows driven by iframes became less
> and less reliable.
>
> When ITP was introduced we put many companies together to try to get Apple
> to change it (you can find the doc in
> https://docs.google.com/document/d/1Rs--DFzZj_SfQjtz8oH9DlLII0ra3viMEHrK7sKsaiU/edit#heading=h.p3nvp6xmxvzf)
> but they didn’t bulge and ultimately the introduction of RTs in user agent
> code (albeit with extra restrictions, the one I mentioned not everyone is
> following) made the problem manageable. We have an initiative cross working
> groups (IETF, OIDC etc)for working with browser vendors to try containing
> similar regressions in the future. For a summary of similar problems see
> https://identiverse.gallery.video/detail/video/6184443037001/browser-features-vs-identity-protocols.
>
>
>
>
> To restate, the TMI-BFF proposal is not trying to fix any of that, nor per
> the above some of it need fixing. The only indirect connection might be
> that less stuff happening in the user agent means less opportunities for
> similar changes to impact the flows, but it’s definitely not a top level
> driver.
>
>
>
> *From: *Warren Parad <wparad=[e-mail]>
> *Date: *Sunday, February 14, 2021 at 11:41
> *To: *Vittorio Bertocci <[e-mail]>
> *Cc: *Neil Madden <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> That only applies to third party cookies, it shouldn't affect third-party
> iframes as far as I'm aware. So unless we expect those to break, we
> probably shouldn't include that as a driving use case. Is there another
> measure that would be relevant here?
>
>
> [image: 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 7:57 PM Vittorio Bertocci <vittorio.bertocci=
> [e-mail]> wrote:
>
> ITP, for example
>
>
>
> *From: *Warren Parad <wparad=[e-mail]>
> *Date: *Sunday, February 14, 2021 at 04:54
> *To: *Vittorio Bertocci <[e-mail]>
> *Cc: *Neil Madden <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *Subject: *Re: [OAUTH-WG] Token Mediating and session Information Backend
> For Frontend (TMI BFF)
>
>
>
> 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.
>
> Which new browser measures?
>
>
> *Error! Filename not specified.*
>
> *Warren Parad*
>
> Founder, CTO
>
> Secure your user data and complete your authorization architecture.
> Implement Authress <https://authress.io>.
>
>
>
>
>
> On Sun, Feb 14, 2021 at 1:33 PM Vittorio Bertocci <vittorio.bertocci=
> [e-mail]> wrote:
>
>
>    - 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=[e-mail]>
> *Date: *Sunday, February 14, 2021 at 03:48
> *To: *Vittorio Bertocci <[e-mail]>
> *Cc: *Neil Madden <[e-mail]>, "[e-mail]" <
> [e-mail]>
> *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.
>
>
>
> *Error! Filename not specified.*
>
> *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
>
>