[Openid-specs-ab] 3.3.1. Hybrid Flow Steps
Mike Jones
Michael.Jones at microsoft.com
Fri Jan 31 01:56:05 UTC 2014
I plan to apply the agreed-upon language tomorrow unless I hear objections. Specifically, the language that will be used is:
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.
-- Mike
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of n-sakimura
Sent: Monday, January 06, 2014 1:41 PM
To: openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] 3.3.1. Hybrid Flow Steps
+1
This is a non normative overview text so that level of abstruction may work better.
Nat
(2014/01/06 22:09), John Bradley wrote:
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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:ritou.06 at gmail.com>
====================
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
--
====================
Ryo Ito
Email : ritou.06 at gmail.com<mailto:ritou.06 at gmail.com>
====================
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab
--
Nat Sakimura (n-sakimura at nri.co.jp<mailto:n-sakimura at nri.co.jp>)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ござӓ
6;|
14;せんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
PLEASE READ:
The information contained in this e-mail is confidential and intended for the named recipient(s) only.
If you are not an intended recipient of this e-mail, you are hereby notified that any review, dissemination, distribution or duplication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete your copy from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140131/596b1fb9/attachment.html>
More information about the Openid-specs-ab
mailing list