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

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=
40auth0....@dmarc.ietf.org> 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=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: 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> 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> on behalf of Neil Madden <
> neil.mad...@forgerock.com>
> *Date: *Sunday, February 14, 2021 at 00:17
> *To: *Vittorio Bertocci <vittorio.bertocci=40auth0....@dmarc.ietf.org>
> *Cc: *"oauth@ietf.org" <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> 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, "internet-dra...@ietf.org" <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.
>
>    The IETF Secretariat
>
>
>
> _______________________________________________
> OAuth mailing list
> 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
> https://www.ietf.org/mailman/listinfo/oauth
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to