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

Mike Jones Michael.Jones at microsoft.com
Thu May 17 22:49:24 UTC 2012


This may be related to some of the special redirect_uri values that are actually not URLs that Breno described to us for use with native applications.  We might want to check in with him about that.

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of John Bradley
Sent: Thursday, May 17, 2012 3:01 PM
To: Nat Sakimura
Cc: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Additional issues/questions with Basic

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


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


More information about the Openid-specs-ab mailing list