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

Torsten Lodderstedt torsten at lodderstedt.net
Wed Oct 30 07:04:39 UTC 2013


I support Nat's proposal as it describes capabilities of grant types and what the implementor can achieve. 

The discussion about maintaining secrecy of client secrets is fruitless and has misguided people in the past.



n-sakimura <n-sakimura at nri.co.jp> schrieb:
>(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
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>-- 
>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.
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Openid-specs-ab mailing list
>Openid-specs-ab at lists.openid.net
>http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20131030/d53fe7ea/attachment-0001.html>


More information about the Openid-specs-ab mailing list