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

Nat Sakimura sakimura at gmail.com
Thu May 17 21:46:18 UTC 2012


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> 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> 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>
>> 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]
>> *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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 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/20120518/7f27d787/attachment.html>


More information about the Openid-specs-ab mailing list