Re: [OAUTH-WG] Call for Adoption

I don't see how that can deal with the specific form of the attack where the Client would have sent the authorization request to the legitimate authorization endpoint of a compromised AS and believes it gets the response from that, where in fact it was redirected away to the good AS. IOW, I do

Re: [OAUTH-WG] Call for Adoption

Hi Hans, Sorry, I mixed up the IdP mix-up attack and the code phishing attack. Mandating the Authorization and Token Endpoint being in the same authority would solve the later without changing the wire protocol. For AS mix-up attack, mandating the client to change the redirection endpoint per

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

Hi, Many thanks to all who provided the feedback. As far as the existing token update is concerned I was thinking about it in the context of the incremental authorization which we haven't implemented yet so we'll need to review how to handle it later on. Right now we are only prototyping the

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

As fat as I'm concerned, grant==authorisation (English is not my native language so forgive me if I'm misusing some words). When the user clicks the authorize button on the consent screen, we save the scopes in the database. Tokens are independent from that (except for the business rules that we do

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

Your English is better than mine :-), thanks for the feedback. Well, I guess it can become quite implementation specific. We keep the the list of authorized scopes in the access token record, and if this access token can also be refreshed then I guess it can be a long term record (as far as pr

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

Following up on Nat's last paragraph... did the group in Darmstadt discuss this option? Namely, to require that the authority section of the AuthZ and Token endpoints be the same? Are there known implementations already deployed where the authority sections are different? It seems like a simple

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

Based on Hans' response to Nat I understand why this doesn't solve all the use cases. It does still seem like a good idea from a client perspective that would address the dynamic client registration cases where the Bad AS is returning mixed endpoints. On 1/27/16 7:43 AM, George Fletcher wrote:

Re: [OAUTH-WG] PKCE & Hybrid Flow

It is confusing that the value is a string that is order independent based on space breaks, rather than a space separated list of responses requested. Changing it now may be more trouble than it is worth, if it may break deployments. The editor at the time really didn’t want multiple response

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

The difference might be whether you want to store the scope consent by client "instance" vs client_id application "class". Assuming that the client is not using dynamic client registration, then storing scope consent by client_id applies to all instances of that client. In most cases this is su

Re: [OAUTH-WG] PKCE & Hybrid Flow

> 27 jan. 2016 kl. 13:51 skrev John Bradley : > > It is confusing that the value is a string that is order independent based on > space breaks, rather than a space separated list of responses requested. Absolutely, I’ve always found that completely broken. > Changing it now may be more trouble

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

Yup. For the RPs that would deal with valuable data, I also recommend it to become HTTPS only. This will effectively close the hole for the AS Mix-Up. Also, I would recommend to the clients to think twice before accepting random ASs. To prevent the code phishing, it is a good idea to require the s

Re: [OAUTH-WG] Call for Adoption

It think requiring a common authority segment for the authorization endpoint and the token endpoint might work in common cases, but there are legitimate cases where the URI of the Authorization endpoint might be a alias in the case of multi tenants, all using a common token endpoint. The la

Re: [OAUTH-WG] Call for Adoption

I agree that in many cases the RS and AS are in different domains and I think that OAuth2 explicitly was designed to support that. I don't see how "sending a token to a bad RS" is a variant of the mix-up attack. To me, it's the clients responsibility to send the token to an appropriate endpo

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

On Wed, Jan 27, 2016 at 1:54 PM George Fletcher wrote: > The difference might be whether you want to store the scope consent by > client "instance" vs client_id application "class". > Correct me if I'm wrong but this only makes sense for "native apps", not for web apps, right? (of course, now wi

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

Yes, I was thinking mostly of "native apps"... though you bring up a good point. It would be great if "installable" web apps could do dynamic client registration:) I suppose for a "public" client that is loaded onto a device, the "installation" process could obtain a new client_id for that ins

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

My recommendation, like the others, is to store consent by client_id:user and then try and leverage dynamic client registration if instance level consent is needed. On 1/27/16 11:43 AM, George Fletcher wrote: Yes, I was thinking mostly of "native apps"... though you bring up a good point. It w

Re: [OAUTH-WG] Call for Adoption

There's at least one smallish deployment that has a different authority for the Authorization Endpoint and the Token Endpoint. from https://accounts.google.com/.well-known/openid-configuration : { "issuer": "https://accounts.google.com";, "authorization_endpoint": "https://accounts.google.com/o

Re: [OAUTH-WG] Call for Adoption

hi John, if you remember I even proposed something along those lines in Darmstadt and it was deemed (with reason) as not enough good protection since the attacker can use a proxy…. regards antonio On Jan 27, 2016, at 2:30 PM, John Bradley wrote: > It think requiring a common authority segme

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

Hi George Thanks. I think I'll need to spend more time on thinking about the way it has to be implemented, but I guess one thing I realize is that using only access tokens as records for this purpose is not ideal/generic. That said, it is not clear to me that a per-instance level consent mak

Re: [OAUTH-WG] Call for Adoption

yeah. But for Google, Microsoft, etc., every RP can whitelist, cannot they? ;-) Otherwise, for a code phishing attack, you need to implement discovery of some sort. My thinking before reading your email was: if( authority(authz_ep)==authority(token_ep) ) { get_token(token_ep, code, client_cre

Re: [OAUTH-WG] Call for Adoption

Unless I’m missing something, requiring the authority section to match discounts attackers being able to deploy executable code on a path. This kind of hole was exploited in a number of Facebook hacks. Yes I’m aware that those were dealing with redirect URIs but we’re talking about the same kind

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

I propose we rename this the “Random ASs Attack”. — Justin (only half joking) > On Jan 27, 2016, at 8:07 AM, Nat Sakimura wrote: > > Yup. > > For the RPs that would deal with valuable data, I also recommend it to become > HTTPS only. This will effectively close the hole for the AS Mix-Up.

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

a perfectly valid - at first - AS may get compromised later and used to attack other ASes; that attacj does not require code changes or control over the authorization endpoint: a rogue employee that happens to have access to log files (granted those include GET & POST data) on the AS can mount

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

Interesting. No code change even at the now compromised AS? I can see that the phase two, the cut-and-paste attack portion works, but I cannot see how the first portion works. Could you elaborate? 2016年1月28日(木) 5:56 Hans Zandbelt : > a perfectly valid - at first - AS may get compromised later and

Re: [OAUTH-WG] Call for Adoption

You mean the string comparison on authority section would allow execution of some code? Or are you suggesting that not checking the path portion would allow the attacker to plant something on the other paths on the host? Yes, the later is possible especially when there are user generated content o

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

indeed, if the attacker is able to phish the user, he can put up a script that first triggers the authorization request to the compromised AS (i.e. the AS at which he has access to the logs and gathers the state value from) through the Client, and subsequently trigger the redirect to the good A

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

I see. That's like double cut-n-paste. I tried to capture this case of used-to-be-good AS turning Compromised AS (Log leaking AS) in a sequence diagram: http://j.mp/1QtDeKD Given this, just relying on not using random AS is not good enough. You would probably require AS w/ISMS with the policy of

Re: [OAUTH-WG] Call for Adoption

Definitely the latter. I don’t think the requirement actually helps secure things in practice and artificially limits things otherwise. — Justin > On Jan 27, 2016, at 7:19 PM, Nat Sakimura wrote: > > You mean the string comparison on authority section would allow execution of > some code? Or

Re: [OAUTH-WG] Call for Adoption

I agree, common origin mapping for OAuth would be a horrible road to go down. Pattern matching redirect URI has been a thorn in Facebook’s side that has never worked. At best it would be security theatre, and cripple many legitimate use cases. John B. > On Jan 27, 2016, at 11:02 PM, Justi

[OAUTH-WG] oauth-meta: turi allows user to mislead app

The OAuth-Meta draft returns the token endpoint (in a "turi" query parameter) when redirecting a user from the authorization endpoint back to an app. The app presumably then POSTs the "code" (also in the redirect) to "turi" to get an access token. However, apps typically send their client_secr

Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app

Hi James, Right. I thought of the man-in-the-browser case and was originally thinking of sending them in signed JWT(state,c_hash,a_hash,turi,ruri,duri,.) or sending HMAC(sha256, state+code+turi+ruri, client_secret) together but subsequently dropped the idea as anything is broken in the man-in-

Re: [OAUTH-WG] Call for Adoption

OK. I’m sold. There is no way out without some kind of discovery in the multi-AS case. Do I have to worry for the cases that the client is storing the client secret with the issuer authority (e.g., https://example.com/) as the key and sends the client secret to the

Re: [OAUTH-WG] oauth-meta: turi allows user to mislead app

Even if theoretically secure, I don't think it is a good idea to send turi and require the client app to confirm it matches (or send duri and match issuer+well-known...). It will be too tempting to client apps to just use the turi/duri value. draft-jones-oauth-mix-up-mitigation-01 is slightly b