[OAUTH-WG] (no subject)

___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth Digest, Vol 148, Issue 45

on in the user?s browser. > > There is a clear distinction, but whether that matters is a different > discussion. It depends on how the application used, and how token lifetimes > are configured. FWIW, the DPoP threat model makes the same distinction > ("Stolen token (XSS)? vs ?XSS

[OAUTH-WG] Your opinion about draft-ideskog-assisted-token

Hi OAuth, The authors of draft-ideskog-assisted-token [1] have approached me requesting that the draft be published as an Informational RFC in the Independent Submission Stream [2]. The draft extends the OAuth 2.0 framework to include an additional authorization flow for single page applications

[OAUTH-WG] (no subject)

Hi OAuth, The authors of draft-ideskog-assisted-token [1] have approached me requesting that the draft be published as an Informational RFC in the Independent Submission Stream [2]. The draft extends the OAuth 2.0 framework to include an additional authorization flow for single page applications

Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-rar-04.txt

> Am 13.02.2021 um 00:38 schrieb Brian Campbell > : > > > > On Tue, Feb 9, 2021 at 5:53 AM Francis Pouatcha > wrote: > Find bellow my review of the draft: > > • Redactional changes: > 2.2. Authorization Data Types > > Interpretation of the value of the "type" parameter, and the obj

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

Thank you again for the explanation. I think your assumption about the overall flow should be described in the draft. As I understand it now the core contribution of your proposal is to move refresh token management from frontend to backend. Is that correct? > Am 14.02.2021 um 21:35 schrie

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

Thank you for the comprehensive answer, Neil. Initially I said that "I need the client app. to be authenticated at the AS", and I meant authenticated as by the spec (explicit authentication). It seems that the reason which I gave as an example to explain why would I need that (to determine if it i

Re: [OAUTH-WG] JWT Response for OAuth Token Introspection and types of tokens

RFC 7662 is not explicit on the refresh token "aud". Omitting the "aud" value or setting it to the AS, the ultimate consumer, appears valid here. Vladimir On 11/02/2021 23:47, Andrii Deinega wrote: > Hi Vladimir, > > What would be a value in the aud claim for refresh tokens? > > Regards, > Andrii

Re: [OAUTH-WG] Authorization Header Encoding

Hi Justin, Thanks for alerting us on this development. +1 for keeping the updated HTTP semantics unencumbered by the Authorization header formatting in RFC 6750. IMO revising the RFC 6750 to reflect that is too late now, as few people will notice. So updating the Bearer header definition in OAut

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

Yes, I’ve argued against this distinction for DPoP too. Since the first days of HttpOnly attackers learnt to proxy requests through the browser (as you know of course). This is not only to bypass the restrictions but it’s also just much better for the attacker because it hides their traffic and

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 >> > wrote: >>> On 15 Feb 2021, at 08:32, Philippe De Ryck >>>

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

Totally agree. Warren Parad Founder, CTO Secure your user data with IAM authorization as a service. Implement Authress . On Mon, Feb 15, 2021 at 11:51 AM Neil Madden wrote: > > > On 15 Feb 2021, at 10:26, Philippe De Ryck < > phili...@pragmaticwebsecurity.com> wrote: > >

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

> On 15 Feb 2021, at 10:26, Philippe De Ryck > wrote: > >  > >>> 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 singl

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 attacker is no longer able to run a silent >> flow to obt

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

> 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 attacker is no longer able to run a silent flow > to obtain a fresh set of tokens (since the client is now a confi

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

> On 15 Feb 2021, at 08:50, Vittorio Bertocci > wrote: > > Thank you Philippe for your comments! Some considerations: > It also aims to avoid the need for a reverse proxy-based BFF, but comes up > short compared to such a BFF. > That isn’t a goal. If the developer can use a reverse proxy, they