[Openid-specs-ab] Additional issues/questions with Basic

Richer, Justin P. jricher at mitre.org
Fri May 18 17:35:06 UTC 2012


How is this insecure and how does it break the spec? I'm not proposing any changes, I'm cataloguing my read of the current specification as it stands today, for both OAuth2 and Connect.

All I was really trying to say below is that Connect should directly inherit the OAuth2 requirements in this case.

 -- Justin

On May 18, 2012, at 1:24 PM, John Bradley wrote:

According to OAuth and Connect If there are redirect URI registered, they must match up to but not including the query parameters.

In OAuth all public clients  MUST register redirect URI.

What you are proposing is insecure and violates the spec.

The OAuth spec requires that if a redirect URI was sent in the authorization request, the same URI needs to be sent to the token endpoint, and the Token endpoint must check that they are exactly the same.

I think that the OAuth spec was probably trying to say that if the authorization request redirect URI did not match a registered redirect URI then the client must send the redirect URI and the server must exactly match it with the one in the original request.

That may have been too complicated so they made it mandatory for the token endpoint to always check.

We are not trying to do anything different from OAuth though it looks like people are reading that requirement from the core spec differently.  That my be an OAuth problem.

John B.
Sent from my iPad

On 2012-05-18, at 12:07 PM, Justin Richer <jricher at mitre.org<mailto:jricher at mitre.org>> wrote:

There are several cases where you can't know the full redirect URI ahead of time, not the least of which is when you've got some application-specific query parameters that need to get added to the callback in order to route to the right page on the return. Not everybody can set up clean-looking path-only URLs in their environments. While ideally you'd use the state parameter to sync up any dynamic information with a stored environment, it's not always convenient, and it doesn't always save you from using query components anyway.

The current language of "MUST for implicit" and "SHOULD for code" makes the most sense to me, with the two stage checks. The logic goes like this:

[IdP/Authz Endpoint]:
does RP have any registered redirect uris?
  - if yes:
     did the RP send a redirect uri with the request?
        - if yes:
            check sent value against registered values, assure prefix match
        - if no:
            use "default" redirect if available; otherwise, error
   - if no:
      did the RP send a redirect uri with the request?
        - if yes:
            use this redirect uri; warn the user that the redirect uri isn't verified at all
        - if no:
            error

[IdP/Token Endpoint]:
did the RP send a redirect uri in the Authz request?
  - if yes:
     did the RP send a redirect uri with the token request?
        - if yes:
            do exact string matching against these two values, query and all
        - if no:
            error
  - if no:
     did the RP send a redirect uri with the token request?
        - if yes:
            error (?)
        - if no:
            OK

It's true that this might need to be unwound a little bit from the language in the spec, but these are the state machines as I see them in OAuth2, and I see no reason for Connect to further restrict these use cases.

 -- Justin

On 05/17/2012 06:00 PM, John Bradley wrote:
They added the redirect_uri checking to the token endpoint to make it safe for code (I suspect that many sites won't do it because they don't understand why it is required),  but i don't know what if any use cases there are for having a dynamic path on the redirect_uri and how the client would keep track of it to be able to send exactly that URI as the parameter to the token endpoint.

Perhaps Chuck or Justin will remember.

John
On 2012-05-17, at 5:46 PM, Nat Sakimura wrote:

So, the real question is, what kind of use cases do we really throw away if we require the urls to be registered. If my assumption that OAuth WG decided that there are such use cases was bogus, then I am OK with MUST.



On Fri, May 18, 2012 at 6:39 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
You don't need to register the query parameters.

I am OK with SHOULD for the code flow, however for 'code token' it allows a 3rd party to get an access token for someone else.

The attacker would then replay it with the code at the real RP.   With the removal of checking nonce in the id_token you now have a great attack.

To safely use 'code id_token' you need to check nonce or you are screwed as they say if the redirect_uri is unregistered.

The way that the code flow on it's own gets around it is by the check of the redirect_uri in the authorization request with the one sent in the token request the server is responsible for the check in that case.

I suppose we could have the client retrieve token and reject the id_token if code is invalid.  that however is a touch complicated.

John

On 2012-05-17, at 5:13 PM, Nat Sakimura wrote:

My understanding was that OAuth 2.0 allowed it to be SHOULD to accommodate some use cases such as dynamic return_to urls, etc.

On Fri, May 18, 2012 at 5:46 AM, John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>> wrote:
We are requiring registration,  under what circumstances would a client not know it's return_to?

It might be a custom scheme, but that should be known in advance.

John

On 2012-05-17, at 4:03 PM, Nat Sakimura wrote:

I think we should keep SHOULD here.
There are use cases that a MUST cannot be fulfilled.

=nat via iPhone

On 2012/05/18, at 4:57, Chuck Mortimore <cmortimore at salesforce.com<mailto:cmortimore at salesforce.com>> wrote:

Agreed.

It was basically pointing out that we were over ridding the OAuth language and turning SHOULD to MUST.    As a platform, we're ok with it, as we're on the MUST side of things.

-cmort


On May 17, 2012, at 12:51 PM, John Bradley wrote:

We may have been a bit overzealous with the MUST.   It should be a MUST for implicit and a SHOULD for code.

>From 10.6 of OAuth


 The authorization server
   MUST require public clients and SHOULD require confidential clients
   to register their redirection URIs.  If a redirection URI is provided
   in the request, the authorization server MUST validate it against the
   registered value.


I don't the think we are actually precluded from making the SHOULD a must for Connect.

John

On 2012-05-17, at 2:49 PM, Mike Jones wrote:

Hi Chuck,

I was going through some of my mail working on closing the remaining issues to finish the OAuth Bearer RFC and I ran across this message, which I realized that I never responded to.

Could you expand on “This violates OAuth”?  Is there a change you’d recommend in the Connect specs as a result?

(The second point is now moot, as we decided to remove the Check ID Endpoint at the last in-person working group meeting.)

                                                                Thanks,
                                                                -- Mike

From: Chuck Mortimore [mailto:cmortimore at salesforce.com<mailto:cmortimore at salesforce.com>]
Sent: Friday, March 02, 2012 11:13 AM
To: Mike Jones
Subject: Additional issues/questions with Basic

2.2.1  redirect_uri:  A redirection URI where the response will be sent. This MUST be pre-registered with the provider.

This Violates OAuth


2.3.1 CheckID: access_token:  REQUIRED. The ID Token obtained from an OpenID Connect Authorization Request.

Why is this the ID Token, but called access_token?

Why would we use POST if it's in an AuthZ header?
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab




--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab


_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120518/9c2a6eed/attachment-0001.html>


More information about the Openid-specs-ab mailing list