[Openid-specs-ab] response_type and nonce

Brian Campbell bcampbell at pingidentity.com
Tue Sep 4 11:19:42 UTC 2012


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