[Openid-specs-ab] response_type and nonce

Justin Richer jricher at mitre.org
Tue Sep 4 15:34:15 UTC 2012


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
>
>



More information about the Openid-specs-ab mailing list