[Openid-specs-ab] response_type and nonce

Justin Richer jricher at mitre.org
Tue Sep 4 19:04:37 UTC 2012


On 09/04/2012 02:42 PM, Brian Campbell wrote:
> FWIW I think implicit was actually intended to mean the grant is
> implied because there is no grant being exchanged at the token
> endpoint (see the text I quoted earlier).  Not something about the
> client identity being implicit.
For the record, that's the intended interpretation in OAuth2. It took me 
months of head scratching and several conversations with Eran to get 
what that was about.

  -- Justin

>
> That John and I have different interpretations, however, only
> underscores the need to not use code/implicit flow and rather be
> explicit about response types.
>
> As I read some things again, I don't think my previous comment about
> implicit flow -> fragment and code flow -> query works out.
>
> Anyway, I do believe this needs to be addressed so I created a rough
> ticket to track this: https://bitbucket.org/openid/connect/issue/648/
>
>
> On Tue, Sep 4, 2012 at 9:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> Flow in OAuth was more of an artificial thing for structuring the spec examples than a useful distinction.
>>
>> The Oauth spec uses it to describe the fragment encoded flow.
>>
>> Though by definition I think it was intended to separate confidential clients from public ones where the client identity is implicit in the registered response URI.
>> That also covers the code flow for public clients though no one uses the term that way.
>>
>> I think we are better talking about response_type and token endpoint authentication explicitly.
>>
>> John B.
>>
>>
>> On 2012-09-04, at 12:34 PM, Justin Richer <jricher at mitre.org> wrote:
>>
>>> I agree with this. As stated in the OAuth core, the "flows" are narrowly defined by a combination of the response_type and authorization_grant parameters on the Authorization Endpoint and Token Endpoint, respectively. OpenID Connect has added a whole bunch of extra permutations to the response_type parameter, putting it explicitly outside of the defined "flows". (for better or worse)
>>>
>>> -- Justin
>>>
>>> On 09/04/2012 11:28 AM, Nat Sakimura wrote:
>>>> We probably should stop using "flows" to describe and refer
>>>> http://openid.bitbucket.org/oauth-v2-multiple-response-types-1_0.html
>>>> for the response types.
>>>>
>>>> Nat
>>>>
>>>> On Tue, Sep 4, 2012 at 8:19 PM, Brian Campbell
>>>> <bcampbell at pingidentity.com> wrote:
>>>>> Agreed that there's room for improvement here.
>>>>>
>>>>> The terms "implicit flow" and "code flow" are used a lot in the
>>>>> connect suite of specs but are never explicitly defined. The terms do
>>>>> appear in OAuth but the text there is somewhat at odds with how the
>>>>> terms are used in Connect.
>>>>>
>>>>> I.e. on the implicit flow (from 1.3.2):
>>>>>
>>>>>    "In the implicit flow, instead of issuing the client
>>>>>     an authorization code, the client is issued an access token directly
>>>>>     (as the result of the resource owner authorization).  The grant type
>>>>>     is implicit as no intermediate credentials (such as an authorization
>>>>>     code) are issued (and later used to obtain an access token)."
>>>>>
>>>>> So, following from that text, is a response type of code+token really
>>>>> an implicit flow?
>>>>>
>>>>> It seems to me (please correct me, if I'm wrong) that when Connect
>>>>> says "implicit flow" what is meant is any fragment encoded response
>>>>> and "code flow" means any query string encoded response (though the
>>>>> "none" response type is kind of an odd man out there). Explicitly
>>>>> stating that would be helpful in the connect specs and I think it's
>>>>> worth considering not using the terms "implicit flow" and "code flow"
>>>>> as the meaning is somewhat overloaded and under defined.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Sep 3, 2012 at 5:19 PM, Nat Sakimura <sakimura at gmail.com> wrote:
>>>>>> Hmm.
>>>>>>
>>>>>> Seems like another ticket item.
>>>>>>
>>>>>> nat
>>>>>>
>>>>>> On Tue, Sep 4, 2012 at 4:27 AM, Roland Hedberg
>>>>>> <roland.hedberg at adm.umu.se> wrote:
>>>>>>> John Bradley skrev 2012-09-03 18:13:
>>>>>>>> id_token on it's own is returned fragment encoded in the front
>>>>>>>> channel.
>>>>>>>>
>>>>>>>> The identity of the requester is implicit through the registered
>>>>>>>> redirect.
>>>>>>>>
>>>>>>>> Nonce is required in that flow.
>>>>>>>>
>>>>>>>> The nonce is only not required in the code flow where you are getting
>>>>>>>> the id_token directly from the token endpoint.
>>>>>>>>
>>>>>>>> It may be better to say nonce is REQUIRED for all response_type
>>>>>>>> except the "code" response_type.
>>>>>>> Absolutely, as it is right now it's open for interpretation which it
>>>>>>> shouldn't be.
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>> _______________________________________________
>>>>>> 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
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>



More information about the Openid-specs-ab mailing list