Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-16.txt
Hi all, Thanks to Filip Skokan for his thorough review of the OAuth for Browser-Based Apps BCP. I've incorporated his changes as well as a few other editorial fixes from Louis Jannett and published Draft 16. You can view the latest version here: https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-16.html Aaron On Fri, Feb 16, 2024 at 4:24 PM wrote: > Internet-Draft draft-ietf-oauth-browser-based-apps-16.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-16.txt >Pages: 59 >Dates: 2024-02-16 > > 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 (oauth@ietf.org), 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-16.html > > A diff from the previous version is available at: > > https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-16 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > 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
[OAUTH-WG] I-D Action: draft-ietf-oauth-browser-based-apps-16.txt
Internet-Draft draft-ietf-oauth-browser-based-apps-16.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-16.txt Pages: 59 Dates: 2024-02-16 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 (oauth@ietf.org), 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-16.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-browser-based-apps-16 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
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 wrote: > > > > > *From: *Kai Lehmann > *Date: *Monday, 6. November 2023 at 07:48 > *To: *"oauth@ietf.org" > *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
Re: [OAUTH-WG] FW: Call for consensus on SPICE charter
Hey Tony, On Thu, Feb 15, 2024 at 1:36 PM wrote: > 1) Do you support the charter text? Or do you have objections or blocking > concerns (please describe what they might be and how you would propose > addressing the concern)? > > Not sure I support at this point, I understand the need for an > architecture document with patterns and definitions, etc. > > There is a lot of work going on outside the IETF in this area such as the > mDL work in ISO that already has patterns and definitions along with > credential formats (mdoc) and transports (ble/http/nfc). I don’t believe > the IETF should ignore these efforts since most of the driving licence and > passport communities/companies are adopting this as one of the standards > that issuers and verifiers will use. The same is true for W3C WebAuthn. > WebAuthN cannot produce standard digital signatures, and so it cannot be used to produce standard digital credentials (for example it cannot be used to produce JWT or SD-JWT). It could produce authentications for public keys that could be bound to credentials, but because of the origin binding in WebAuthN, this would not fit well with the "audience" typically used for digital credentials (usually there is no audience) You might find this thread on possible relation between mDoc and CWT interesting: https://mailarchive.ietf.org/arch/msg/spice/xiRpmd-Bexv94qentlGg1Snjw1A/ > The architecture, patterns and definitions should be free from technology, > I don't know why W3C is mentioned in the introduction as the only > technology, this should not be in the introduction but along with other > technologies such as mDL/mdoc, webauthn, etc when describing profiles. As > the goal would be for interested parties to produce profiles of other > technologies to fit the architecture document with patterns and definitions. > W3C is mentioned because some W3C members asked for a term other than "Verifiable Credentials" to be used... and they asserted the "Verifiable Credentials" implies the JSON-LD data model developed in W3C. ISO was not emphasized because formal coordination would require contribution from ISO experts, and we have had relatively low engagement from them. > > I believe that the WG if formed should also think about holder > verification and patterns and attestations that can be used. Interesting. I think this is covered under the metadata discovery deliverable, but if you feel it could be made more clear, please send text. > Also there needs to be a notion of a "reader/wallet/etc" that can > potentially store credentials (not necessarily the user or verifier) and > release/store credentials upon "user" consent. This sounds like an application to me. How do you see this related to "credential formats" or "issuer/holder/verifier metadata"? > > > There are other models than the 3 party that VCs use, so these also need > to be considered in the architecture, patterns and definitions documents > to enable profiles for other technologies. Agreed, OAuth JWTs/SD-JWTs, and ISO mDocs are examples we have discussed. Are there others you would like to see considered? > > I believe in the 1st 3 items in Goals but I don't believe it would be in > the best interest to define a metatdata protocol, as this sounds like this > would be a protocol for obtaining DID documents, there are already many > protocols out there for metadata retrieval, not sure there is a need for > another one, if one is needed for DIDs then that may be better done in W3C > as this does not seem to fit well with the charter > Discovering attestations for wallets seems to fit here, why should URLs or URNs (DIDs) be specifically marked as out of scope? For consideration, JWK / COSE Key Thumbprints are good alternatives to DIDs which have been standardized / are being standardized in the IETF: - https://datatracker.ietf.org/doc/draft-ietf-cose-key-thumbprint/ > > This charter seems to be very scoped to W3C technology, I understand that > interested parties will have to contribute if they want to have other > technologies included but the charter in general does not seem to allow > this, so removing specific technology will allow this to happen. We chose to use "Digital Credential" and "Digital Presentation" specifically to keep the door open to CWT and COSE Sign1 structures which are used in IETF and ISO. > > > I would be happy to give provide specific text changes to the charter. > I think it would be great if you could offer text that refines your comment about format support, and holder/wallet metadata / attestations. > > > 2) If you do support the charter text: > > > 3) Are you willing to author or participate in the developed of the WG > drafts? > > yes > > • Are you willing to review the WG drafts? > > yes > > • Are you interested in implementing the WG drafts? > > I'm willing to see how we can use these outputs with the other industry > technologies. > > Thank you for your comments. > > >
