Re: [OAUTH-WG] PKCE & Hybrid Flow

Thanks! we are almost done implementing PKCE in identity server. And yea - a comment that PKCE applies to whenever a code is involved would be probably helpful for other implementers. Even if that makes total sense, it is not obvious. —  cheers Dominick Baier On 27 January 2016 at 03:11:28,

Re: [OAUTH-WG] Call for Adoption

I'm not sure what's described in the blog post is actually a variant of an attack that anyone is really concerned about? A client developer would have to change a production system to use an unfamiliar value for the token endpoint based solely on a an email without even looking at service

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

Nov, Are you referring to Sec 3.1.2.1 of RFC 6749. Stating that the the redirection endpoint SHOULD require TLS, and that the AS should warn the user if the redirect URI is not over TLS (Something I have never seen done in the real world) Not using TLS is reasonable when the redirect URI is

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Hi I'm not sure if the next question is off topic or too low level, hopefully not, When the repeated authorization is skipped or only new scopes are requested to be authorized as per the incremented auth approach, is it reasonable to assume that the record that is used to track it all is

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

The grants should be tied to the refresh token, or a grant record tied to the confidential client. For native iOS I have seen people bind it to the client_id if the client is not confidential. That way if the user installs the same app on another device it gets the same grants. I am

[OAUTH-WG] (no subject)

-- J Dred from -- ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

Fwiw, at Ozwillo, we track grants per user per client_id (we don't support native apps; only web flows for now), and we don't do "incremental grants" like Google: if you request scope B and the user had only granted scope A, you'll get a token for scope B only. This is partly because our tokens

Re: [OAUTH-WG] Call for Adoption

I'm staying that it's sufficiently unlikely that it shouldn't be part of the threat model and that a discovery lookup on iss isn't necessary. On Tue, Jan 26, 2016 at 8:21 AM, George Fletcher wrote: > While it's a different way of getting the endpoints mixed up, I don't >

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Discovery

Hi, I support the adoption of this document as starting point for our work towards OAuth discovery. Restating what I already posted after the last IETF meeting: It seems the document assumes the AS can always be discoverd using the user id of the resource owner. I think the underlying

Re: [OAUTH-WG] Call for Adoption

I understand what you're saying but disagree with the premise. On Tue, Jan 26, 2016 at 12:07 PM, George Fletcher wrote: > So I'm fine with not requiring discovery in the simple case of an RS > supporting a single AS. However, once the RS moves to supporting multiple >

[OAUTH-WG] PKCE & Hybrid Flow

Hi,  PKCE only mentions OAuth 2.0 code flow - but wouldn’t that also apply to OIDC hybrid flow e.g. code id_token? —  cheers Dominick Baier ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Hi Mike, I really like the new revision since it is much simpler :-) My comments: I'm fine with describing all mitigations we talked about in Darmstadt in one/this spec. But the state check at the tokens endpoint is supposed to be a mitigation against code injection/cut and paste attack,

Re: [OAUTH-WG] PKCE & Hybrid Flow

Yes it also applies to the “code id_token” response_type. It would also apply to “code token” , “code token id_token” response types as well though I can’t think of why a native app would use those. We can look at a errata to clarify. It is a artifact of resonse_type being treated as a

Re: [OAUTH-WG] Second OAuth 2.0 Mix-Up Mitigation Draft

Agreed. The security ext draft might fit well with the general grab bag of issues around all the "dynamic" cases. It would be stronger than a new threat model ext draft which would likely be informational. Phil > On Jan 26, 2016, at 12:10, Torsten Lodderstedt >

Re: [OAUTH-WG] Can the repeated authorization of scopes be avoided ?

In MITREid Connect we track grants per client_id per user, and we have a separate database object for storing them. I wouldn’t recommend simply updating an access token that’s already in the wild with more power — that just sounds wrong. — Justin > On Jan 26, 2016, at 1:57 PM, Thomas Broyer

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

John, Nov is not talking about the redirection endpoint. I just noticed that 3.1.2.1 of RFC 6749 is just asking TLS by "SHOULD" and I think it needs to be changed to "MUST" but that is not what he is talking about. Instead, he is talking about before starting the RFC 6749 flow. In many cases, a

Re: [OAUTH-WG] PKCE & Hybrid Flow

To the end, perhaps amending RFC6749 so that the response type is treated as a space separated value would be a better way to go? 2016年1月27日(水) 5:20 John Bradley : > Yes it also applies to the “code id_token” response_type. It would also > apply to “code token” , “code token

Re: [OAUTH-WG] Call for Adoption: OAuth 2.0 Mix-Up Mitigation

While I agree it may not be "proper" OAuth the fact is that the attack is still possible and that means that some acknowledgement (security or spec considerations) is required. Being able to MITM the UA or get the user to click a link that takes them to a malicious "client" that is really a