[Openid-specs-ab] Guidance on what the different flows are for

n-sakimura n-sakimura at nri.co.jp
Thu Oct 31 05:05:38 UTC 2013


Ah, OK. Then a stand alone "Code Flow" in -d15 2.2.2.1 para 2 must be a 
bug.

There is "Hybrid Code Flow" left in 2.3.3.9 para 1 as well.

What about the main point around "OAuth 2.0 flow"?
Some tokens may be returned from other endpoints, e.g., userinfo 
endpoint in the case of the distributed claims model.


(2013/10/31 12:29), Mike Jones wrote:
>
> We use the term “Authorization Code Flow” instead of “Code Flow” to 
> match the OAuth 2.0 terminology.
>
> *From:*openid-specs-ab-bounces at lists.openid.net 
> [mailto:openid-specs-ab-bounces at lists.openid.net] *On Behalf Of 
> *n-sakimura
> *Sent:* Wednesday, October 30, 2013 8:19 PM
> *To:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] Guidance on what the different flows 
> are for
>
> OK. That's better. Note that my comment is against -14.
>
> Now we have Hybrid Flow and Implicit Flow as defined terms. Why not 
> define Code Flow and more notably OAuth 2.0 Flow as well?
>
> Code Flow
> OAuth 2.0 flow in which all tokens are returned from the Token Endpoint.
>
> Implict Flow
> OAuth 2.0 flow in which all tokens are returned from the Authorization 
> Endpoint.
>
> Hybrid Flow
> OAuth 2.0 flow in which some tokens are returned from the 
> Authorization Endpoint
> and others are returned from the Token Endpoint.
>
> OAuth 2.0 Flow
> Sequence of request and response among the Client, Server, and the 
> User-Agent to obtain Tokens as the direct result of Authorization Grant.
>
> The "direct result of Authorization Grant" bit is important since 
> otherwise all the Flows definition become inaccurate because you could 
> get further tokens from other endpoints e.g. UserInfo endpoint in 
> exchange to Access Token.
>
>
>
> (2013/10/30 21:23), Brian Campbell wrote:
>
>     FWIW "Implicit Code Flow" has been changed to ""Implicit Flow" in
>     -15 of core:
>     http://hg.openid.net/connect/commits/c5fa47253977b44983fb5e29337144d1c87f69cb
>     so it is defined in the Terminology section.
>
>     On Wed, Oct 30, 2013 at 5:47 AM, Nat Sakimura <sakimura at gmail.com
>     <mailto:sakimura at gmail.com>> wrote:
>
>
>
>
>     Oct 30, 2013 20:04、John Bradley <ve7jtb at ve7jtb.com
>     <mailto:ve7jtb at ve7jtb.com>> のメッセージ:
>
>         I like the table idea.
>
>     Let's go that way.
>
>
>
>     Where do you see "Implicit Code Flow"?
>
>     http://openid.net/specs/openid-connect-core-1_0-14.html#Terminology
>
>         RFC 6749 defines it.  Essentially as any flow not using a
>         grant type at the token endpoint, arguably more confusing
>         than referring to the response types.
>
>     Yeah, actually, the paragraph 1 of 1.3.2 of RFC6749 starts as "The
>     implicit grant is ... " then in the next sentence it says "In the
>     implicit flow ... " so it sort of implicitly defines implicit flow
>     but not as a defined term .
>
>
>
>     On Oct 30, 2013, at 4:31 AM, n-sakimura <n-sakimura at nri.co.jp
>     <mailto:n-sakimura at nri.co.jp>> wrote:
>
>
>
>     "Implicit Code Flow" is defined. Neither "Implicit Flow" nor "Code
>     Flow" is defined.
>     And that is a very secondary point in my email.
>     What I pointed out was that perhaps a table is better as a guidance.
>
>     See my other email for the proposed text.
>
>     Nat
>
>
>     (2013/10/30 15:42), Mike Jones wrote:
>
>         "Implicit Flow" is defined in the Terminology section.
>
>         ------------------------------------------------------------------------
>
>         From: n-sakimura
>         Sent: 10/29/2013 9:51 PM
>         To: openid-specs-ab at lists.openid.net
>         <mailto:openid-specs-ab at lists.openid.net>
>         Subject: Re: [Openid-specs-ab] Guidance on what the different
>         flows are for
>
>         (2013/10/30 10:22), Mike Jones wrote:
>
>             Several reviewers have requested guidance on when to use
>             the different flows.  I believe that we’d be doing a
>             service to our readers by providing it.
>
>             Several reviewers have objected to this text in
>             http://openid.net/specs/openid-connect-core-1_0.html#Authentication>             saying that sometimes the Code flow is used even when the
>             client can’t maintain the secrecy of the client_secret:
>
>             The Authorization Code Flow is suitable for Clients that
>             can securely maintain a Client Secret between themselves
>             and the Authorization Server whereas, the Implicit Flow is
>             suitable for Clients that cannot.
>
>             I believe that that the statement would still be true if
>             we changed the word “suitable” to “intended”.  And then,
>             as discussed in the F2F meeting, we could add the sentence:
>
>             “However, the Authorization Code flow is sometimes also
>             used by Native applications in order to be able to obtain
>             a Refresh Token, even when they cannot ensure the secrecy
>             of the client_secret value.”
>
>         It does not have to be native applications.
>         We do not have to constrain code grant for anything.
>
>         Only the thing which may be worth noting is that (1) enables
>         client authentication for confidential clients, (2) allows
>         clients to obtain refresh token, (3) more secure than implicit
>         grant as the token is not exposed in the front channel, (4)
>         requires extra roundtrip compaired to the implicit, (5) Token
>         endpoint has to be directly reacheable from the client.
>
>         In contrast, the implicit grant will have (1) less roundtrip
>         and thus latency, (2) the client does not need a direct
>         reacheability to the server, (3) client cannot be
>         confidential, (4) tokens are exposed in the frong channel so
>         inherently less secure, and (5) you cannot get refresh token
>         with this grant.
>
>         Perhaps having tables like the following  is better as the
>         guidance.
>
>         Conditions / Requirement
>
>         	
>
>         code grant
>
>         	
>
>         implicit grant
>
>         	
>
>         hybrid grant
>
>         Server is not directly reachable from the client
>
>         	
>
>         	
>
>         x
>
>         	
>
>         Want less round trip
>
>         	
>
>         	
>
>         x
>
>         	
>
>         x
>
>         Do not want to reveal tokens for better security
>
>         	
>
>         x
>
>         	
>
>         	
>
>         (some)
>
>         Want client authentication
>
>         	
>
>         x
>
>         	
>
>         	
>
>         x
>
>         Want refresh token
>
>         	
>
>         x
>
>         	
>
>         	
>
>         x
>
>         Slow front channel, fast back channel
>
>         	
>
>         x
>
>         	
>
>         	
>
>         x
>
>
>         The same table is uploaded here:
>         http://nat.sakimura.org/2013/10/30/guidance-on-which-grant-flow-to-use-for-openid-connect/
>
>         BTW, do we still want to use the term "flow"? OAuth stopped
>         using the term and it uses "grant" instead. Currently,
>         "implicit flow" for example is not defined.
>
>         Nat
>
>
>
>         Would that combination work for people?
>
>         Finally, I propose that we add this guidance about the Hybrid
>         Flow:
>
>         “The Hybrid flow enables Clients to obtain an ID Token and/or
>         Access Token with only one round trip to the Authorization
>         Server, possibly minimizing latency, while still enabling
>         Clients to later get tokens from the Token Endpoint –
>         especially a Refresh Token.”
>
>         Per the decision at the F2F, all this “guidance” text would
>         move to the introduction.
>
>         Are people good with the wording above, or would you like to
>         make alternative suggestions?
>
>                                                                         --
>         Mike
>
>
>
>         _______________________________________________
>
>         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  <tel:+81-3-6274-1412>  Fax:+81-3-6274-1547  <tel:%2B81-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.
>
>
>
>
>     -- 
>
>     Nat Sakimura (n-sakimura at nri.co.jp  <mailto:n-sakimura at nri.co.jp>)
>
>     Nomura Research Institute, Ltd.
>
>     Tel:+81-3-6274-1412  <tel:+81-3-6274-1412>  Fax:+81-3-6274-1547  <tel:%2B81-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.
>
>     _______________________________________________
>     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
>
>         _______________________________________________
>         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
>
>
>     _______________________________________________
>     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
>
>
>
>
>     _______________________________________________
>
>     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.


-- 
Nat Sakimura (n-sakimura at nri.co.jp)
Nomura Research Institute, Ltd.
Tel:+81-3-6274-1412 Fax:+81-3-6274-1547

本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
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/20131031/9fd5a6c8/attachment-0001.html>


More information about the Openid-specs-ab mailing list