OK. I thought I read somebody saying in the OAuth list that apps are using "code" flow, but I might have mixed it up with something else. <div><br></div><div>Why did you chose implicit grant for the native app, by the way? </div>
<div><br></div><div>=nat<br><br><div class="gmail_quote">On Mon, May 2, 2011 at 11:54 PM, Chuck Mortimore <span dir="ltr"><<a href="mailto:cmortimore@salesforce.com">cmortimore@salesforce.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div class="im">
<font face="Lucida Grande"><span style="font-size:11pt"><br>
<br>
<br>
On 5/1/11 6:49 PM, "Nat Sakimura" <<a href="http://sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
<br>
</span></font><blockquote><font face="Lucida Grande"><span style="font-size:11pt">Right, introducing 'code' makes the flow not "implicit". I am kind of bothered by the implicit flow because it makes the spec dirty. It causes several 'If, When', in the core.As I understand, the standard "code" flow can also be used by Javascript client. Most "thick" active clients seem to use the standard flow. <br>
<br>
</span></font></blockquote></div><font face="Lucida Grande"><span style="font-size:11pt">Almost all of our native clients use the implicit flow. We’ve shipped 6 different ones ourselves, plus a number of ISVs are using it.<br>
<br>
-cmort<br>
<br>
</span></font><blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt"><br>
So, I am trying to understand the real reason that this is a valuable flow. It is probably best to bring this "merit" out in the user-agent binding. <br>
<br>
When I said that not much difference in security characteristics, I meant that introducing 'code' portion into the flow does not lower the security characteristics of implicit flow. <br>
<br>
=nat<br>
<br>
On Mon, May 2, 2011 at 10:27 AM, John Bradley <<a href="http://ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>> wrote:<br>
</span></font></div><blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt">Nat,<br>
<br>
Not quite sure what you are getting at. <br>
<br>
The two flows have quite different security. <br>
<br>
In the code flow the RP knows that the access token is coming from the IdP, In the implicit flow it is taking the chance that the user is not cutting and pasting a different token.<br>
<br>
In my opinion the implicit flow is good for when the Requester is the Java client itself, so the user has no reason to fake it.<br>
<br>
If the Requester is the Web service then it should use the code flow to be certain there is no cutting and pasting going on.<br>
<br>
The other issue is that in the implicit flow you are counting on JS security in the browser to keep the access token safe. (good luck with that)<br>
<br>
The problem comes when Facebook and others want to simplify the client. They can more easily give a RP a JS to past in than get them to install a library. That is why implicit gets used where it probably shouldn't.<br>
<br>
On the other hand leaving aside JS security it is probably no worse than the current openID 2.0 flow at LoA 1, at-least with an audience restricted ID_token and nonce to prevent replay.<br>
<br>
John B.<br>
<br>
<br>
On 2011-05-01, at 6:11 PM, Chuck Mortimore wrote:<br>
<br>
</span></font></div><blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt"><br>
On May 1, 2011, at 5:24 PM, "Nat Sakimura" <<a href="http://sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
<br>
</span></font></div><blockquote><font face="Lucida Grande"><span style="font-size:11pt"><div class="im">Thanks Chuck for quick response. <br>
<br></div>
Implicit Grant can be drawn as: <<a href="http://bit.ly/l5M90v" target="_blank">http://bit.ly/l5M90v</a>> <a href="http://bit.ly/l5M90v" target="_blank">http://bit.ly/l5M90v</a><br>
<br>
Making the use of Code would be: <<a href="http://bit.ly/j8NmXs" target="_blank">http://bit.ly/j8NmXs</a>> <a href="http://bit.ly/j8NmXs" target="_blank">http://bit.ly/j8NmXs</a><br>
<br>
</span></font></blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt"><br>
This wouldn't be allowed in oauth2 as it stands currently. Exchange of a authorization code grant happens backchannel over POST<br>
<br>
-cmort<br>
<br>
</span></font></div><blockquote><font face="Lucida Grande"><span style="font-size:11pt"><div class="im">The security characteristics is not so much different, I think, and we have a unified flow. <br>
<br>
=nat<br>
<br></div>
On Mon, May 2, 2011 at 8:23 AM, Chuck Mortimore < <<a href="mailto:cmortimore@salesforce.com" target="_blank">mailto:cmortimore@salesforce.com</a>> <a href="http://cmortimore@salesforce.com" target="_blank">cmortimore@salesforce.com</a>> wrote:<br>
</span></font><blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt"><br>
<br>
On Sun, May 1, 2011 at 2:32 PM, Nat Sakimura < <<a href="mailto:sakimura@gmail.com" target="_blank">mailto:sakimura@gmail.com</a>> <a href="http://sakimura@gmail.com" target="_blank">sakimura@gmail.com</a>> wrote:<br>
</span></font></div><blockquote><font face="Lucida Grande"><span style="font-size:11pt"><div class="im">Hi. <br>
<br>
I have just updated the core. <br>
<br></div>
HTML: <<a href="http://openid4.us/specs/ab/openid-connect-core-1_0.html" target="_blank">http://openid4.us/specs/ab/openid-connect-core-1_0.html</a>> <a href="http://openid4.us/specs/ab/openid-connect-core-1_0.html" target="_blank">http://openid4.us/specs/ab/openid-connect-core-1_0.html</a><div class="im">
<br>
<br>
Main diff is that I have moved the "openid" structure from the access token response to UserInfo response. <br>
The id_token response is still treated as extension. It should probably be incorporated in the core in the next rev. <br>
<br>
One discussion point. When we are using JWS, "signed" actually contains everything in the original response. Is it not redundant to return both? Just returning "signed" as "access_token" should suffice?<br>
<br>
One question: maybe better to send this to OAuth list but... why does not the user-agent flow use "code"? <br>
If it does, the entire spec will be even more simple. <br>
User-agent getting "access_token" directly instead of "code" and using that "access_token" repeatedly on the resource seem to be a small amount of optimization (one round-trip) with a lot of spec complication. <br>
</div></span></font></blockquote><div class="im"><font face="Lucida Grande"><span style="font-size:11pt"><br>
It's for clients that can't secure secrets, and/or have difficulty making cross domain calls, such as javascript based clients.<br>
<br>
-cmort<br>
<br>
<br>
</span></font></div></blockquote></blockquote></blockquote></blockquote></blockquote>
</div>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<br><a href="http://www.sakimura.org/en/">http://www.sakimura.org/en/</a><br><a href="http://twitter.com/_nat_en">http://twitter.com/_nat_en</a><br>
</div>