[Openid-specs-ab] response_type and nonce

Nat Sakimura sakimura at gmail.com
Tue Sep 4 15:28:00 UTC 2012


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



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list