Re: [OAUTH-WG] OAuth for Browser-Based Apps

Hi Justin, Thank you for your detailed review. > §9+ this draft should add privacy considerations, particularly for BFF > pattern's proxy architecture.e I wanted to ask for a bit more context on this comment. I understand that having a proxy as a separate entity would expose all

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

hereby mostly useless) CSP policy. Philippe > > On Mon, Nov 6, 2023 at 11:25 AM Philippe De Ryck > <mailto:phili...@pragmaticwebsecurity.com>> wrote: > I went back to the Security BCP and combed through the fine details, and > there is indeed some guidance on CSP. But

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

ions. The core > of my feedback is to add Cookie and Header best practices to Section 2, and > point to one or more living documents. > > On Mon, Nov 6, 2023 at 8:45 AM Philippe De Ryck > <mailto:phili...@pragmaticwebsecurity.com>> wrote: >> While I understand the ide

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

While I understand the idea of pointing to additional security resources, I’m not sure if it is the role of the security BCP (or other specs) to take on the responsibility to address these issues. In my point of view, the security BCP should focus on OAuth aspects, and discuss security topics

Re: [OAUTH-WG] WGLC for Browser-based Apps

b.com/Valuya/servicewauther/blob/e3e4a3db5a77b272380ad7c44547ae842fc719a1/documentation/serviceworker_sequence.png — Pragmatic Web Security Security for developers https://pragmaticwebsecurity.com/ > > Le lun. 28 août 2023 à 14:15, Jim Manico <mailto:j...@manicode.com>&

Re: [OAUTH-WG] WGLC for Browser-based Apps

Responses inline. > Still, there is some initial incorrect point that makes the rest of the > discussion complicated, and partly wrong. I believe the key to make the discussion less complicated is to acknowledge that there are two separate issues: 1. An attacker can potentially obtain tokens

Re: [OAUTH-WG] WGLC for Browser-based Apps

My responses inline. > Hi everyone, > > The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract > further explains that it "details the security considerations and best > practices that must be taken into account when developing browser-based > applications that use OAuth

Re: [OAUTH-WG] WGLC for Browser-based Apps

I’m going to respond inline and re-organize the previous message a bit. > It's worth noting that it didn't get so much traction up to this time, and > that I stopped using it in multiple applications myself. That’s exactly what I meant with my statement of an “unproven approach”. If you, the

Re: [OAUTH-WG] WGLC for Browser-based Apps

> I have a different interpretation of the objective of using a service worker, > and it aligns with descriptions in most of those links -- minimize the risk > of the access token and refresh token exfiltration from the application by > malicious JS code. Service workers, when implemented

Re: [OAUTH-WG] WGLC for Browser-based Apps

Aug 2023, at 02:56, Dick Hardt wrote: > > > Philippe: would you expand on your comment: > > On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck > <mailto:phili...@pragmaticwebsecurity.com>> wrote: > - Remove unproven and overly complicated solutions (i.e., the service

Re: [OAUTH-WG] WGLC for Browser-based Apps

In my opinion, this document is not ready to be published as an RFC. In fact, I will be at the OAuth Security Workshop in two weeks to discuss exactly this (See "The insecurity of OAuth 2.0 in frontends" here: https://oauth.secworkshop.events/osw2023/agenda-thursday). My hope is that my

Re: [OAUTH-WG] Web apps BCP feedback

That’s why cookies should be set with the __Host- prefix. In a carefully-designed API, CORS will function as a CSRF defense, even when the attacker is controlling a subdomain or sibling domain. Overall, I think the first part of 6.1 makes sense, but I don’t think the document should try to

Re: [OAUTH-WG] TMI BFF - html meta tags over/alternative to discovery

Without having the full context of the interim meeting, this feels really off to me. I see the need for making this configurable, but I have doubts about using HTML elements for this purpose. As far as I understand, this mechanism is supposed to be used for modern frontends (Angular, React,

Re: [OAUTH-WG] Re-creation of Access Token on Single Page Application

> On 13 Mar 2021, at 07:52, Tatsuya Karino wrote: > > By the way, I also wonder what is the better option to use OAuth2.0 on SPA > Client (3rd party) with good UIUX. > In my understanding, there are two options to achieve it. > 1. Using response_momde=web_message or 2.Using Refresh Token with

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

> On 18 Feb 2021, at 13:08, Neil Madden wrote: > > Thanks for following up, Brian. Responses below. > >> On 17 Feb 2021, at 22:48, Brian Campbell > > wrote: >> >> Always appreciate (and often learn from) your insights, Neil. I'd like to >> dig into the CSRF

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

> > On 15 Feb 2021, at 11:50, Neil Madden wrote: > >> On 15 Feb 2021, at 10:26, Philippe De Ryck >> wrote: >> >>> On 15 Feb 2021, at 11:14, Neil Madden >> <mailto:neil.mad...@forgerock.com>> wrote: >>> >>>

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

> On 15 Feb 2021, at 11:14, Neil Madden wrote: > >> On 15 Feb 2021, at 08:32, Philippe De Ryck >> wrote: >> >> [...] >> >> Compared to using a worker for handling RTs, I believe the TMI-BFF only adds >> a single security benefit: an att

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

fit: an attacker is no longer able to run a silent flow to obtain a fresh set of tokens (since the client is now a confidential client). Hope this helps Philippe > > From: Philippe De Ryck > Date: Sunday, February 14, 2021 at 22:45 > To: Vittorio Bertocci > Cc: Warren Parad , &quo

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

A couple of notes from my end: Developers building an application that consists of a frontend, a backend, and APIs indeed often struggle with identifying the correct client, especially with the combination of OAuth 2.0 and OIDC. Having a standardized way of handling such cases is definitely

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

uted/complex. And while an access token hash would > reign it in somewhat (ATs obtained from the stolen RT wouldn't be usable) > it's hard to say if the cost is worth the benefit. > > > > On Tue, Dec 8, 2020 at 11:47 PM Philippe De Ryck > <mailto:phili...@pragmaticwebsecu

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

ersonally on the fence about it. > > Including an RT hash in the proof seems more niche. Best I can tell, it would > guard against prolonged offline access to protected resources when access > tokens are bearer and the RT was DPoP-bound and also gets rotated. The > trade-off there seems

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

> The suggestion to use a web worker to ensure that proofs cannot be > pre-computed is a good one I think. (You could also use a sandboxed iframe > for a separate sub/sibling-domain - dpop.example.com > ). An iframe with a different origin would also work (not really

Re: [OAUTH-WG] DPoP followup I: freshness and coverage of signature

Hi all, This is a very useful discussion, and there are some merits to using DPoP in this way. However, the attacker's capabilities are stronger than often assumed, so it may not matter in the end. I've been wanting to write this out for a while now, so I've added a couple of scenarios below.

Re: [OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

Hi Torsten, > On 16 May 2020, at 19:50, Torsten Lodderstedt wrote: > > Hi Philippe, > >> On 16. May 2020, at 17:08, Philippe De Ryck >> wrote: >> >> Hi all, >> >> I am working on formulating developer guidelines on using Refresh Tok

[OAUTH-WG] OAuth 2.0 for Browser-Based Apps - On the usefulness of refresh token rotation

Hi all, I am working on formulating developer guidelines on using Refresh Token Rotation (RTR), as required by "OAuth 2.0 for Browser-Based Apps". The protection offered by RTR kicks in the moment a refresh token is used twice, so the assumption is that the attacker has the ability to steal

Re: [OAUTH-WG] OAuth 2.1 - require PKCE?

From working with a lot of developers on understanding OAuth 2.0 and OIDC, I definitely vote for simplicity. Understanding the subtle nuances of when a nonce is fine and when PKCE should be used is impossible without in-depth knowledge of the flows and their properties. Misunderstandings will

Re: [OAUTH-WG] DPoP: Threat Model

On 4 May 2020, at 21:44, Daniel Fett wrote: > > Am 04.05.20 um 21:27 schrieb Philippe De Ryck: >> >>>> (https://beefproject.com <https://beefproject.com/>) rather than >>>> exfiltrating tokens/proofs. >>> As a sidenote: BeEF is not rea

Re: [OAUTH-WG] DPoP: Threat Model

>> (https://beefproject.com ) rather than >> exfiltrating tokens/proofs. > As a sidenote: BeEF is not really XSS but requires a full browser compromise. > No, it’s not. The hook for BeEF is a single JS file, containing a wide variety of attack payloads that can be

Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

In theory, you can issue a token that only becomes valid in the future. That would have a different iat and nbf timestamp. I have not seen this in practice though. Given that RFC 7519 lists “iat” as informative, I would not change that behavior in a specific use case if there is no