[Openid-specs-ab] 3.3.1. Hybrid Flow Steps

John Bradley ve7jtb at ve7jtb.com
Mon Jan 6 13:09:45 UTC 2014


Good point, the code token response returns the id_token from the token endpoint.

So while code is always returned in the fragment, token and id_token are optional in the fragment depending on the response type.

That would make "Authorization Server Sends the End-User back to the Client with an Authorization Code and, depending on the response_type one or both of ID Token , Access Token"
The most correct.   

This is a high level flow description so we could say:
"Authorization Server Sends the End-User back to the Client with an Authorization Code and, depending on the response_type one or more additional parameters"
That makes it read better.

There is always a second parameter otherwise it is a code flow.

John B.

On Jan 6, 2014, at 2:29 AM, Ryo Ito <ritou.06 at gmail.com> wrote:

> > code is actually always returned in successful response
> OK
> 
> > + 5. Authorization Server Sends the End-User back to the Client with an ID Token, an Authorization Code and, if requested, an Access Token.
> 
> At the table of OpenID Connect "response_type" Values, hybrid flow may not require ID Token in authorization response.
> 
> > | code id_token | Hybrid Flow |
> > | code token | Hybrid Flow |
> > | code id_token token | Hybrid Flow |
> 
> Ryo
> 
> 
> 2014/1/5 John Bradley <ve7jtb at ve7jtb.com>
> The response types "id_token token" and "id_token" are now covered in implicit.  I think the language was intended to cover the "id_token" response type before refactoring.
> 
> The current text is not strictly incorrect but is misleading as the Authorization code is always requested in the Hybrid flow.
> 
> Nat and Ryo's proposed change is less confusing and is editorial in my opinion.
> 
> John B.
> 
> On Jan 5, 2014, at 2:04 AM, Nat Sakimura <sakimura at gmail.com> wrote:
> 
>> Good catch. 
>> Though, in hybrid flow, code is actually always returned in successful response so it would be 
>> 
>> - 5. Authorization Server Sends the End-User back to the Client with an ID Token and, if requested, an Authorization Code and/or Access Token.
>> + 5. Authorization Server Sends the End-User back to the Client with an ID Token, an Authorization Code and, if requested, an Access Token.
>> 
>> If it does not return an authorization code, it is an implicit flow. 
>> 
>> 
>> 2014/1/5 Ryo Ito <ritou.06 at gmail.com>
>> Hybrid flow includes code in authorization response.
>> 
>> Step 5 should be corrected as follows.
>> 
>> - 5. Authorization Server Sends the End-User back to the Client with an ID Token and, if requested, an Authorization Code and/or Access Token.
>> + 5. Authorization Server Sends the End-User back to the Client with an Code and, if requested, an Authorization ID Token and/or Access Token.
>> 
>> Thanks,
>> Ryo.
>> 
>> -- 
>> ====================
>> Ryo Ito
>> Email : ritou.06 at gmail.com
>> ====================
>> 
>> _______________________________________________
>> 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
> 
> 
> 
> 
> -- 
> ====================
> Ryo Ito
> Email : ritou.06 at gmail.com
> ====================

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140106/8ae3453e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4507 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140106/8ae3453e/attachment.p7s>


More information about the Openid-specs-ab mailing list