Re: [OAUTH-WG] OAuth security topics

Hi Torsten, Apologies for the late reply. Suggested text: 4.x Client Impersonation of Resource Owner Resource servers may make access control decisions based on the identity of the resource owner as communicated in the "sub" claim returned by the authorization server in a token introspect

Re: [OAUTH-WG] OAuth security topics

You are right. May I ask you to propose text (threat description, advice, ...) to be included in the BCP? > On 7. May 2019, at 13:23, Neil Madden wrote: > > The same issue applies to token introspection responses though. > >> On 7 May 2019, at 12:21, Torsten Lodderstedt wrote: >> >> Hi Neil

Re: [OAUTH-WG] OAuth security topics

The same issue applies to token introspection responses though. > On 7 May 2019, at 12:21, Torsten Lodderstedt wrote: > > Hi Neil, > > you raised a very important issue but the Security BCP does not talk about > JWT content like the Access Token JWT BCP. > > I therefore think the security adv

Re: [OAUTH-WG] OAuth security topics

Hi Neil, you raised a very important issue but the Security BCP does not talk about JWT content like the Access Token JWT BCP. I therefore think the security advise should go into the security considerations section of the Access Token JWT BCP. best regards, Torsten. > Am 07.05.2019 um 11:18

Re: [OAUTH-WG] OAuth security topics

No, it is definitely not too late for your comment From: OAuth On Behalf Of Neil Madden Sent: Dienstag, 7. Mai 2019 11:18 To: IETF oauth WG Subject: [OAUTH-WG] OAuth security topics Is it too late to add the observation below to the OAuth security topics BCP draft? Begin forwarded message

[OAUTH-WG] OAuth security topics

Is it too late to add the observation below to the OAuth security topics BCP draft? > Begin forwarded message: > > From: Neil Madden > Subject: Re: [OAUTH-WG] draft-bertocci-oauth-access-token-jwt-00 > Date: 7 May 2019 at 09:37:29 BST > To: Vittorio Bertocci > Cc: Hans Zandbelt , Karl McGuinn

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Yes. This was my worry. Unless the oauth server is also an OIDC OP, it has no notion the user login state. That state is held in cookies belonging to a federated provider. The notion that javascript acting as a client and depends to the user login state is what sets these cases apart. We hav

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I think we are running in circles. I am not talking about what provides should do in an ideal world, I am describing something that some providers do today that can impact developers in unintended ways if not take into account. We can agree that in the ideal world providers would take steps to fix

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> On Dec 8, 2018, at 8:27 PM, Vittorio Bertocci > wrote: > > > Can you give a concrete example? To me it feels like you are explaining > > scenarios where OAuth is used for login. > > That's one of the scenarios of interest here. We can debate on whether that's > proper or not, but the pr

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Thanks Torsten. As another meta comment, in general I am not disagreeing with the guidance- I just think that the language we use should make it easier for practitioners to understand what they are supposed to do to put this guidance in concrete terms. That includes better clarifying risks, opening

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> How would the token endpoint detect login status of the user? Oddball idea: why not use the cookie? If the assumption is that the RT is being used from a client-side browser-based app, and CORS allows for credentials, then perhaps this is a way to bind the RT to the user's browser session. The

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> Am 08.12.2018 um 16:55 schrieb Nov Matake : > > But even using code flow, issuing TB-bound access token has same difficulty, > doesn't it? > I don’t think this issue is relate to implicit flow. Determining the referred token binding id and proving ownership of the key isn’t easy. Brian is t

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

>  Is this a matter of saying they should have an API for these clients which exposes less of the risky activities? That cookies provide a defense against XSS exfiltration? And/or other? HTTPOnly cookies prevent exfiltration of session or token data stored in cookies. Those cookies can be REPLAYED

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Torsten, > On Dec 8, 2018, at 22:20, Torsten Lodderstedt wrote: > > Hi Nov, > >> Am 08.12.2018 um 00:20 schrieb Nov Matake : >> >> For me, it seems very hard to issue TB-bound token for JS app and >> MTLS-bound token for its backend server at same time. > > Issuing TB tokens in case of i

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Nov, > Am 08.12.2018 um 00:20 schrieb Nov Matake : > > For me, it seems very hard to issue TB-bound token for JS app and MTLS-bound > token for its backend server at same time. Issuing TB tokens in case of implicit is anyway hard. You need to issue a HTTP redirect to the RS and the RS must

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Vittorio, > Am 06.12.2018 um 19:09 schrieb Vittorio Bertocci : > > Thank you Torsten. > I think that a lot of the considerations below need to be tempered with > concrete considerations about the features developers can actually rely on > today. > I agree with identifying the theoretical fra

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Vittorio, > did all the vendors on the list work on proof of concepts to ensure that the practices recommended here can work with your product, end to end? I’m not currently working on SPA apps nor apps using implicit flow. However, my previous client is using hybrid flow to fetch access t

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> On Dec 7, 2018, at 5:50 AM, Jim Manico wrote: > I still encourage developers who are not XSS guru’s to stick to cookie based > sessions or stateless artifacts to talk to the back end and keep OAuth tokens > only flying intra-server. It’s an unpopular opinion, but even moderately good > XSS

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I wanted to address Vittorio’s comment on XSS and LocalStorage. One XSS attack can extract all of LocalStorage in one line of code. It’s trivial. And after studying XSS for years, I believe that most developers are not capable of building good XSS defense into complex UI’s and the trends to use

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

For systems with stateful sessions, you could reference that via the refresh token. If the access tokens are opaque to protected resources and meant to be used via introspection, you could also reference the state there as well. For systems with stateteless sessions (e.g. JWT cookies), you have

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

How would the token endpoint detect login status of the user? Phil Oracle Corporation, Cloud Security and Identity Architect @independentid www.independentid.com phil.h...@oracle.com > On Dec 6, 2018, at 12:24 PM, David Waite wrote:

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> There are indeed several ASs which, possibly because of an interpretation of OIDC, assume refresh tokens mean offline access and are mutually exclusive with public clients. AFAIK both Microsoft and Google do support RTs with public clients, but their lifecycle is independent from the session with

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

One benefit of moving to code flow is that the refresh token can be used to check the validity of the user session (or rather, it allows the AS another avenue to force authentication events if the AS considers the user session to be expired (or has a drop in confidence). There are indeed severa

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

While I generally agree with justin that moving everything to the back channel is good, I worry that checking user login state may be more important. What if upon refresh of a javascript client the AS would like to check the validity of the current user session? Many implementers solve the use

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Thank you Torsten. I think that a lot of the considerations below need to be tempered with concrete considerations about the features developers can actually rely on today. I agree with identifying the theoretical framework and north star we want to aspire to, but if we are framing the recommendati

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I support the move away from the implicit flow toward using the authorization code flow (with PKCE and CORS) for JavaScript applications. The limitations and assumptions that surrounded the design of the implicit flow back when we started no longer apply today. It was an optimization for a diff

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Vittorio, > Am 06.12.2018 um 08:40 schrieb Vittorio Bertocci : > > Thank you! > On the RT, more questions: > > - where would you save the RT? Iam thinking of the no-backend case in > particular. There’s a lot of heartburn in the community on where to save > access tokens already, given the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Thank you! On the RT, more questions: - where would you save the RT? Iam thinking of the no-backend case in particular. There’s a lot of heartburn in the community on where to save access tokens already, given the larger scope of refresh tokens I would expect objections there would be exacerbated.

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> Am 06.12.2018 um 02:31 schrieb Vittorio Bertocci > : > > Hey Torsten/Tomek, > Can I ask a clarification on the below? > Torsten, you mentioned that an AS doesn't need to issue a RT- the browser > code can just repeat an authorization request. Did I get it right? > But in order to preserve th

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hey Torsten/Tomek, Can I ask a clarification on the below? Torsten, you mentioned that an AS doesn't need to issue a RT- the browser code can just repeat an authorization request. Did I get it right? But in order to preserve the user experience, that cannot really happen as a full page redirect; ri

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

David, I think you are hitting on something really important here. For non-identity experts, the SPA umbrella covers every app updating the UX via JS instead of postbacks- regardless of the underlying topology. Does the app have its own backend and that backend has no other clients? Does it call it

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> On Dec 5, 2018, at 5:16 AM, Torsten Lodderstedt > wrote: > > Hi Tomek, > >> Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : >> >> Thanks Torsten! >> So if I am putting myself in the shoes of somebody who sets out to do that - >> switch an existing SPA client (no backend) > > I would lik

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Tomek, > Am 05.12.2018 um 15:27 schrieb Tomek Stojecki : > > Hi Torsten, > > On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt > wrote: > > > >> So if I am putting myself in the shoes of somebody who sets out to do that > >> - switch an existing SPA client (no backen

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Torsten, On Wednesday, December 5, 2018, 1:17:08 PM GMT+1, Torsten Lodderstedt wrote: >> So if I am putting myself in the shoes of somebody who sets out to do that >> - switch an existing SPA client (no backend) > I would like to ask you a question: how many SPAs w/o a backend ha

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Tomek, > Am 04.12.2018 um 19:03 schrieb Tomek Stojecki : > > Thanks Torsten! > So if I am putting myself in the shoes of somebody who sets out to do that - > switch an existing SPA client (no backend) I would like to ask you a question: how many SPAs w/o a backend have you seen in your pro

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Thanks Torsten!So if I am putting myself in the shoes of somebody who sets out to do that - switch an existing SPA client (no backend) from Implicit to Code, the options to think through can be summed up more or less as following: 1. Do not use RTs2. If you're using RTs, rotate on every refresh

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Tomek, > Am 04.12.2018 um 09:50 schrieb Tomek Stojecki > : > > I agree with Vittorio, Dominick et al. > >> I disagree. > >> Existing deployments that have not mitigated against the concerns with >> implicit should be ripped up and updated. > > Yes, just like future deployments that will

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I agree with Vittorio, Dominick et al.  > I disagree.  > Existing deployments that have not mitigated against the concerns with > implicit should be ripped up and updated. Yes, just like future deployments that will not mitigate against the concerns of code in the browser should be a concern.

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

e the response >>> type „token". The response types >>> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the >>> issued access tokens are not >>> > sender-constrained. >>> > >>> > > >>> > > In fact,

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

; security. (At least that’s the current understanding.) > > > > I am happy to get corrected. > > > > Ciao > > Hannes > > > > > > > > *From:* n-sakimura > *Sent:* Saturday, December 1, 2018 10:44 AM > *To:* Hannes Tschofenig ; Aaron Parecki

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1 for the proposed change Providing context around the change and to clarify that this is not a reaction to some emergency would be useful IMO. On Mon, Dec 3, 2018 at 1:50 PM Dick Hardt wrote: > I disagree. > > Existing deployments that have not mitigated against the concerns with > implicit s

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I disagree. Existing deployments that have not mitigated against the concerns with implicit should be ripped up and updated. For example, at one time, I think it was Instagram that had deployed implicit because it was easier to do. Once the understood the security implications, they changed the i

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

FWIW I'm somewhat sympathetic to what Vittorio, Dominick, etc. are saying here. And that was kind of behind the comment I made, or tired to make, about this in Bangkok, which was (more or less) that I don't think the WG should be killing implicit outright but rather that it should begin to recommen

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

On Sat, Dec 1, 2018 at 5:01 AM Torsten Lodderstedt wrote: > > my proposal is to add the following definition (based on 3.8.1.2) to a new > „Terminology" section or to section 2.1.2: > > A sender constrained access token scopes the applicability of an access > token to a certain sender. This send

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> completely ignores the fact implicit also shall be abandoned because of its > vulnerability for access token injection. > >> > > > >> > > I therefore propose a modified text: > >> > > > >> > >In order to avoid these issues, C

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

t all. The main reason >> being it is unprotected against token injection and additionally also cannot >> sender constrain tokens. >> >> The second part of the statement relates to other response types and >> conditionally opens the MUST NOT in case they are

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

y opens the MUST NOT in case they are protected against >> injection (which is true for the listed response types) and can issue >> sender constrained tokens (which does not work today but might work in the >> future). >> >> kind regards, >> Torsten. >> >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

uture). > > kind regards, > Torsten. > > > > > Am I misunderstanding it? > > > > > Ciao > > Hannes > > > > PS: The IoT case is likely different. > > > > From: OAuth On Behalf Of Aaron Parecki > > Sent: Saturday, December 1, 2

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

kind regards, > Torsten. > > > > > Am I misunderstanding it? > > > > > Ciao > > Hannes > > > > PS: The IoT case is likely different. > > > > From: OAuth On Behalf Of Aaron Parecki > > Sent: Saturday, December 1, 2018 3:18 AM > >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I am happy to get corrected. Ciao Hannes From: n-sakimura Sent: Saturday, December 1, 2018 10:44 AM To: Hannes Tschofenig ; Aaron Parecki ; Torsten Lodderstedt Cc: Daniel Fett ; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> > Hannes > >   > > *From:*Vittorio Bertocci > *Sent:* Monday, December 3, 2018 5:14 AM > *To:* Torsten Lodderstedt > *Cc:* Daniel Fett ; Hannes Tschofenig > ; IETF oauth WG > *Subject:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend > authorization code

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

document we should have been working on for along time already. Ciao Hannes From: Vittorio Bertocci Sent: Monday, December 3, 2018 5:14 AM To: Torsten Lodderstedt Cc: Daniel Fett ; Hannes Tschofenig ; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

3:18 AM > To: Torsten Lodderstedt > Cc: Daniel Fett ; IETF oauth WG > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code > instead of implicit > > +1 > > I would also like to ensure there is a clear definition of "sender > constra

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

tps://aka.ms/o0ukef> を入手 差出人: OAuth (Hannes Tschofenig の代理) 送信日時: 土曜日, 12月 1, 2018 6:07 午後 宛先: Aaron Parecki; Torsten Lodderstedt Cc: Daniel Fett; IETF oauth WG 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit I agre

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

t; このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > PLEASE READ :This e-mail is confidential and intended for the named > > recipient only. > > If you are not an intended recipient, please noti

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

gt; > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276 > > > > > > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > > > PLEASE READ :This e-mail is confidential and inten

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

erver to >>>> >issue an access token in the authorization response, if the >>>> particular response type detects access token >>>> >injection and the issued access tokens are sender-constrained. >>>> > >>>> > Or we j

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

gt; >>> > In order to avoid these issues, Clients SHOULD NOT use the response >>> type „token". The response types >>> > „token id_token“ and „code token id_token“ SOULD NOT be used, if the >>> issued access tokens are not >>> > sender-co

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

;> > >> > Mike suggested to go with a SHOULD NOT to get the message out but give >> implementors time to move/change. >> > >> > > Best, >> > > >> > > Nat >> > > >> > > Nat Sakimura / n-sakim...@nri.co.jp

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

gt; > Mike suggested to go with a SHOULD NOT to get the message out but give >> > implementors time to move/change. >> > >> > > Best, >> > > >> > > Nat >> > > >> > > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

; > > Best, > > > > > > Nat > > > > > > Nat Sakimura / n-sakim...@nri.co.jp / +81-90-6013-6276 > > > > > > > このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、誠に申し訳ございませんが、送信者までお知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

NOT use the implicit >>> grant or any other response type causing the authorization server to >>> issue an access token in the authorization response. >>> >>> What would you like to modify? >>> >>>> >>>> 2) Banning the returning

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

her response type causing the authorization server to > > >issue an access token in the authorization response. > > > > > > What would you like to modify? > > > > > >> > > >> 2) Banning the returning of the access token that are not sende

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

, please notify the sender and delete this e-mail. From: OAuth on behalf of John Bradley Sent: Thursday, November 29, 2018 7:33:57 PM To: Torsten Lodderstedt Cc: Daniel Fett; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ing the authorization server to > > >issue an access token in the authorization response. > > > > > > What would you like to modify? > > > > > >> > > >> 2) Banning the returning of the access token that are not sender > constrained f

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

LEASE READ :This e-mail is confidential and intended for the named > > recipient only. > > If you are not an intended recipient, please notify the sender and delete > > this e-mail. > > > > 差出人: Torsten Lodderstedt > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > &g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

nt only. > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > 差出人: Torsten Lodderstedt > > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > > 宛先: n-sakimura > > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > > 件名: Re: [

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Of Torsten Lodderstedt Sent: sunnuntai 25. marraskuuta 2018 19.33 To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Hi all, I would like to state again what the proposal of the authors of the Security BCP is: Here is the

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

知らせ頂き、また受信されたメールは削除してくださいますようお願い申し上げます。 > > > > PLEASE READ :This e-mail is confidential and intended for the named > recipient only. > > If you are not an intended recipient, please notify the sender and > delete this e-mail. > > > > 差出人: Torsten Lodderstedt >

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ecipient, please notify the sender and delete > this e-mail. > > -- > *差出人:* Torsten Lodderstedt > *送信日時:* 水曜日, 11月 28, 2018 11:38 午後 > *宛先:* n-sakimura > *Cc:* Dick Hardt; Hannes Tschofenig; oauth@ietf.org > *件名:* Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization &

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ded for the named recipient > only. > If you are not an intended recipient, please notify the sender and delete > this e-mail. > > 差出人: Torsten Lodderstedt > 送信日時: 水曜日, 11月 28, 2018 11:38 午後 > 宛先: n-sakimura > Cc: Dick Hardt; Hannes Tschofenig; oauth@ietf.org > 件名: Re

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

; Hannes Tschofenig; oauth@ietf.org 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Hi Nat, Am 28.11.2018 um 21:10 schrieb n-sakimura mailto:n-sakim...@nri.co.jp>>: I would support 1) clearly defining Implicit as the flow that returns access

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

kens is not sender-constraint. What about this? kind regards, Torsten. > > Best, > > Nat > > > Outlook for iOS を入手 > > 差出人: OAuth (Dick Hardt の代理) > 送信日時: 水曜日, 11月 28, 2018 8:58 午後 > 宛先: Hannes Tschofenig > Cc: oauth@ietf.org > 件名: Re: [OAUTH-WG

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

authorization endpoint Best, Nat Outlook for iOS<https://aka.ms/o0ukef> を入手 差出人: OAuth (Dick Hardt の代理) 送信日時: 水曜日, 11月 28, 2018 8:58 午後 宛先: Hannes Tschofenig Cc: oauth@ietf.org 件名: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code inst

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1 While there are various mechanisms to alleviate some of the issues of implicit, I don't think we can recommend specifics, and there may be future ones in the future. I think we all agree that implicit without any mitigation is problematic. How about we recommend against using implicit alone?

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Hi Nat, I understand you are saying your draft could provide clients with an application level mechanism to sender constrain access tokens. That’s great! But I don’t see a binding to response type „token id_token“. Why do you want to expose the tokens via the URL to attackers? You could eas

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I am not talking about SPA. The client is a regular confidential client that is running on a server. Best, Nat Sakimura 2018年11月27日(火) 16:55 Jim Manico : > Nat, > > How is proof of possession established in a modern web browser in the > implicit flow? > > My understanding is that token binding

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Nat, How is proof of possession established in a modern web browser in the implicit flow? My understanding is that token binding was removed from Chrome recently effectively killing browser-based PoP tokens. https://identiverse.com/2018/10/31/chrome-puts-token-binding-in-a-bind/ Am I missing so

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

I am actually -1. +1 for public client and the tokens that are not sender/key constrained. Just not being used right now does not mean that it is not useful. In fact, I see it coming. Implicit (well, Hybrid “token id_token” really) is very useful in certain cases. Specifically, when the client is

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

+1 to recommend the deprecation of implicit. I don't see a compelling reason to keep implicit when there is an established alternative that is more secure. Our duty as WG is to give developers the best and most sensible practice. CORS adoption is currently at 94% according to https://caniuse.com

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Manicode Security is strongly in favor of deprecating the implicit flow in favor of the authorization code flow as suggested by this recommendation. We're also eager to see secure implementations for SPA delegation be clarified by the working group as well. Thank you for this important work! A

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

On 19 Nov 2018, at 10:34, Hannes Tschofenig wrote: > > Hi all, > The authors of the OAuth Security Topics draft came to the conclusion that it > is not possible to adequately secure the implicit flow against token > injection since potential solutions like token binding or JARM are in an > ear

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

confidential client. So, IMHO, Rifaat’s point is correct. Nat From: OAuth On Behalf Of John Bradley Sent: Monday, November 26, 2018 5:56 AM To: Rifaat Shekh-Yusef Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit There is no

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

describing profiles using ID Tokens and the Form Post Response Mode are in scope. -- Mike From: OAuth On Behalf Of John Bradley Sent: Tuesday, November 20, 2018 7:47 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Sec

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

day, November 26, 2018 at 10:34 AM To: Antonio Sanso Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Hi Antonio, good point. I would assume most SPAs will be public clients. Even if a single instance registers dy

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

6:32:53 PM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code > instead of implicit > > Hi all, > > I would like to state again what the proposal of the authors of the Security > BCP is: > > Here is the respective t

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

, November 25, 2018 6:32:53 PM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Hi all, I would like to state again what the proposal of the authors of the Security BCP is: Here is the respective text from the draft: —— 2.1.2

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

requires a backend to receive the request so it’s >>> not a viable solution for SPAs. >>> > >>> >>> > >>> >>> > >>>> Am 20.11.2018 um 23:29 schrieb John Bradley >>> > >>>> : >>> > >>

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

gt;>>> >> > >>>> Postmessage also has security issues passing a access token and >> leaking. >> > >>>> >> > >>>> Perhaps someone more familiar with SPA can comment on POST. >> > >>>> >> > >>>> Jo

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

>>> >> > >>>> Basically that would be something more like postmessage between two >> > >>>> JS apps. >> > >>>> >> > >>>> Postmessage also has security issues passing a access token

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

v 20, 2018, 6:40 PM George Fletcher < > > >>>> gffle...@aol.com > > >>>> wrote: > > >>>> Hi Mike, > > >>>> > > >>>> The Form Post Response Mode keeps the access_token out of the URL, > but it doesn't

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ccess_token out of the URL, but > >>>> it doesn't prevent the token from traversing through the browser. So a > >>>> man-in-the-browser attack may be able to intercept the values. It should > >>>> help with leakage in logs. > >>>> &g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

t;>>> The Form Post Response Mode keeps the access_token out of the URL, > but it doesn't prevent the token from traversing through the browser. So a > man-in-the-browser attack may be able to intercept the values. It should > help with leakage in logs. > >>>> > >>>> Thanks, > >>>> George > &

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Response Mode >>>>> https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html >>>>> mitigate the threats you’re describing below John? If so, I believe the >>>>> Security Topics draft should say this. >>>>> >>>>&g

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

gt; Mode are in scope. > > > > -- Mike > > > > From: OAuth On Behalf Of > John Bradley > Sent: Tuesday, November 20, 2018 7:47 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] OAuth Security Topics -

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

ats you’re describing below John? If so, I believe the >>>> Security Topics draft should say this. >>>> >>>> >>>> >>>> I believe we owe it to readers to present the complete picture, which is >>>> why I believe that d

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

scope. -- Mike From: OAuth On Behalf Of John Bradley Sent: Tuesday, November 20, 2018 7:47 AM To: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit Yes the at_hash protects the client

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Am 21.11.18 um 11:01 schrieb Neil Madden: >> On 21 Nov 2018, at 09:25, Daniel Fett wrote: >> >> Am 21.11.18 um 10:09 schrieb Neil Madden: If a page from origin A includes a third-party script from origin B, that external script runs in origin A and has access to all cookies and the >>>

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

> On 21 Nov 2018, at 09:25, Daniel Fett wrote: > > Am 21.11.18 um 10:09 schrieb Neil Madden: >>> If a page from origin A includes a third-party script from origin B, that >>> external script runs in origin A and has access to all cookies and the >>> JavaScript context of the page. >>> >>> The

Re: [OAUTH-WG] OAuth Security Topics -- Recommend authorization code instead of implicit

Am 21.11.18 um 10:09 schrieb Neil Madden: >> If a page from origin A includes a third-party script from origin B, that >> external script runs in origin A and has access to all cookies and the >> JavaScript context of the page. >> >> The SPA from origin A would be compromised. That is why we need

  1   2   >