[Openid-specs-ab] response_type and nonce

Brian Campbell bcampbell at pingidentity.com
Tue Sep 4 18:42:20 UTC 2012


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.

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