Re: [OAUTH-WG] OAuth browser based apps with first-party same-domain apps

[Kai Lehmann <[e-mail]>]

Hi Aaron,

(To be honest, I haven’t expected to receive feedback for my inquiry after that long timespan. I thought my question was lost due to IETF going on at the time.)

Thanks for taking the time to answer. The draft you mentioned looks interesting, although I don’t think it fits our purposes. I have a few concerns regarding the draft and I hope Jared is subscribed to the mailing list as well. My main concern with the approach in the draft is that the access token would not be issued to a specific client, but to the user agent itself. If the the user navigates to another client after the access token was returned with Set-Cookie, this other client could just initiate requests to the Resource Server and the browser would send the cookie with the AT along. This AT in the cookie may have a scope which the other client was not supposed to receive in the first place. All clients are essentially sharing the AT in the cookie instead of each client having their own AT issued.

Furthermore, the cookie with the AT would need to be set on a domain which is shared by the AS and all RS which would accept this AT via cookie. That usually means that this cookie would need to be set on the eTLD+1. It also means that web servers running on any subdomain of that TLD+1 will receive that cookie/AT with each and every request done by the user agent, even if this request is not related to accessing protected resources.


The approach I mentioned has similarities with FedCM: The user agent already has a login session which is bound with a session cookie to the (sub-)domain of the AS only and the AS can issue access tokens to SPA clients running in the user agent using Fetch API calls. The ATs are issued to specific clients and can have individual scopes. The RS accept the AT as usual as Bearer Token in the Authorization header. The difference is, that we do not need FedCM as the login session cookie is set and used in first-party context.

One of our main concerns was the redirects which we wanted to avoid. You mentioned that the authorize endpoint may already have some logic which would be required to be implemented on the token endpoint for this approach (e.g. what clients are allowed and so on) which is a valid point. An in-between approach might be to allow POST requests with the necessary parameters on the authorize endpoint (similar to the approach in https://www.ietf.org/archive/id/draft-meyerzuselha-oauth-web-message-response-mode-00.html) and return the authcode within a JSON body. Then the SPA client could take the authcode to the token endpoint to fetch the AT. That would be two requests instead of one, but they can both be performed from within the SPA without the need to redirect and giving up control.

If you like, we can talk about it at the upcoming OSW and see if there is some interest for this scenario within the Oauth community.

Best regards,
Kai



From: OAuth <[e-mail]> on behalf of Aaron Parecki <aaron=[e-mail]>
Date: Saturday, 17. February 2024 at 01:13
To: OAuth WG <[e-mail]>, Kai Lehmann <kai.lehmann=[e-mail]>
Subject: Re: [OAUTH-WG] OAuth browser based apps with first-party same-domain apps

Hi Kai,

This sounds similar to an approach described in this draft, although never actually implemented as far as I know: https://www.ietf.org/archive/id/draft-hanson-oauth-cookie-response-mode-00.html

The main difference is the hanson draft does a redirect to the authorization endpoint, but the access token is still returned by setting a cookie. There are a few advantages of this approach over submitting a POST to the token endpoint directly:

• Leverages existing infrastructure at the authorization endpoint, including rate limits, CSRF protection, bot protection, etc
• Leverages existing logic at the authorization endpoint for applying policies of the request, things like which clients can request which scopes, etc, rather than having to redefine all the authorization parameters at the token endpoint

Since you have to do a redirect the first time the user logs in anyway, the hanson draft is faster for the first login. I could imagine trying to find an optimization for the case where the browser wants to refresh the token while the session at the AS is still active, so maybe we could extend that to support that use case instead of having to do a full redirect as often.

In any case, both of these approaches are far too experimental to consider adding to the Browser Apps BCP right now. But I do think there is something here worth exploring in the future.

Aaron



On Mon, Nov 6, 2023 at 5:22 AM Kai Lehmann <kai.lehmann=[e-mail]<mailto:[e-mail]>> wrote:


From: Kai Lehmann <[e-mail]<mailto:[e-mail]>>
Date: Monday, 6. November 2023 at 07:48
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: OAuth browser based apps with first-party same-domain apps

Hi,

I’ve been reading through the recent update of the draft for using OAuth in browser based apps and highly appreciate the excellent work.

The draft mentions first-party single-domain browser based apps. Maybe I misunderstood this, but it seems to discourage using OAuth in this scenario. It is not clear whether the discouraged pattern is to use OAuth ATs or session cookies and what would be the recommended approach. At the end of the chapter it referes to the other recommended patterns above, but one of the patterns is to have ATs in the browser based client with all the respective risks. Even in a first-party context, using OAuth and ATs can be beneficial as the same public APIs and resource servers can be used which are also provided to 3rd parties as well as other first-party clients running on mobile devices or desktop. I would like to get a bit more clarification on this.

(I apologize for the next part. I was unable to describe it otherwise.)

As there have been a draft released for first-party clients, I would like to get your thoughts about our approach to integrating first-party browser based apps (SameSite with AS) to obtain Access tokens. I have not found this approach in any other RFC / draft … maybe for good reasons as it might have some flaws. As the browser based app receives Access Tokens, it is essentially vulnerable to the same attack scenarios mentioned in the draft. We are aware of those risks and mitigate some of them while accepting others. If this or similar approaches are already covered by the draft, please let me know which one it is related to (apart from the one I mentioned already). If this is a different approach, it might be worth mentioning in the draft as there have been some discussions around this approach and I understood that other implementers had something similar.

Our approach is that the browser based app requests access tokens by doing a token request against the token endpoint of the well-known Authorization Server. The trust anchor is the Origin header. The client sends the required scope with the POST request and uses a specific grant_type (e.g. “first-party-spa”). As this is a first-party request, SameSite ookies (without the __Host prefix) are sent with the request. This includes session cookies from previously created login sessions. The token endpoint of the AS uses the Origin request header to identify/verify the client and uses the session cookie to create an Access Token with the requested and allowed scope; the scope allowed for the client is configured at the AS and the scope of the AS only includes what the client is allowed to have. If the client did not sent a scope with the request, the AT will contain the scope allowed for that client.

No refresh tokens are returned. The issued ATs have a limited TTL (e.g. 20 minutes) and will not be longer than the TTL of the session associated with the session cookie. If the login session is terminated, the ATs issued based on this login session are being revoked as well (ATs contain authentication context identifier and Token introspection checks for revocation).

Should there be no valid login session (cookie) or should the token request demand a step-up authentication, the AS will respond with a respective error to let the client know that user interaction is required, in which case the client will initiate a standard Authcode grant to allow user-interaction (re-auth, fulfill obligations). Optionally, the AS can use a secondary device to interact with the End-User (e.g. get consent or raise level of assurance of the login session) whilst holding back the token response or telling the client to resend the token request after a specific time so that user interaction can complete on the second device.

The shortcut by directly calling the Token endpoint has a few advantages:


  *   No iframe with redirect which might end up in a failure not captured. Also no redirect_uri necessary.
  *   No need for PKCE and state
  *   Just one request to obtain the Token(s)

I hope to get your feedback about this.

Thanks,
Kai

From: OAuth <[e-mail]<mailto:[e-mail]>> on behalf of Aaron Parecki <aaron=[e-mail]<mailto:[e-mail]>>
Date: Monday, 23. October 2023 at 18:22
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-15.txt

After a lot of discussion on the mailing list over the last few months, and after some excellent discussions at the OAuth Security Workshop, we've been working on revising the draft to provide clearer guidance and clearer discussion of the threats and consequences of the various architectural patterns in the draft.

I would like to give a huge thanks to Philippe De Ryck for stepping up to work on this draft as a co-author!

This version is a huge restructuring of the draft and now starts with a concrete description of possible threats of malicious JavaScript as well as the consequences of each. The architectural patterns have been updated to reference which of each threat is mitigated by the pattern. This restructuring should help readers make a better informed decision by being able to evaluate the risks and benefits of each solution.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps

https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html

Please give this a read, I am confident that this is a major improvement to the draft!

Aaron

On Mon, Oct 23, 2023 at 8:35 AM <[e-mail]<mailto:[e-mail]>> wrote:
Internet-Draft draft-ietf-oauth-browser-based-apps-15.txt is now available. It
is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF.

   Title:   OAuth 2.0 for Browser-Based Apps
   Authors: Aaron Parecki
            David Waite
            Philippe De Ryck
   Name:    draft-ietf-oauth-browser-based-apps-15.txt
   Pages:   58
   Dates:   2023-10-23

Abstract:

   This specification details the threats, attack consequences, security
   considerations and best practices that must be taken into account
   when developing browser-based applications that use OAuth 2.0.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list ([e-mail]<mailto:[e-mail]>), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/oauth-browser-based-apps.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-15

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth