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

Justin Richer jricher at mitre.org
Fri May 18 16:07:50 UTC 2012


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
> 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/0ff80b7d/attachment-0001.html>


More information about the Openid-specs-ab mailing list