[Openid-specs-ab] Updated Core

[Chuck Mortimore]

On 5/1/11 6:49 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:

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.

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.

-cmort


 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.

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.

=nat

On Mon, May 2, 2011 at 10:27 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
Nat,

Not quite sure what you are getting at.

The two flows have quite different security.

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.

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.

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.

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)

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.

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.

John B.


On 2011-05-01, at 6:11 PM, Chuck Mortimore wrote:


On May 1, 2011, at 5:24 PM, "Nat Sakimura" <sakimura at gmail.com> wrote:

Thanks Chuck for quick response.

Implicit Grant can be drawn as:  <http://bit.ly/l5M90v> http://bit.ly/l5M90v

Making the use of Code would be:  <http://bit.ly/j8NmXs> http://bit.ly/j8NmXs


This wouldn't be allowed in oauth2 as it stands currently.  Exchange of a authorization code grant happens backchannel over POST

-cmort

The security characteristics is not so much different, I think, and we have a unified flow.

=nat

On Mon, May 2, 2011 at 8:23 AM, Chuck Mortimore < <mailto:cmortimore at salesforce.com> cmortimore at salesforce.com> wrote:


On Sun, May 1, 2011 at 2:32 PM, Nat Sakimura < <mailto:sakimura at gmail.com> sakimura at gmail.com> wrote:
Hi.

I have just updated the core.

HTML:  <http://openid4.us/specs/ab/openid-connect-core-1_0.html> http://openid4.us/specs/ab/openid-connect-core-1_0.html

Main diff is that I have moved the "openid" structure from the access token response to UserInfo response.
The id_token response is still treated as extension. It should probably be incorporated in the core in the next rev.

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?

One question: maybe better to send this to OAuth list but... why does not the user-agent flow use "code"?
If it does, the entire spec will be even more simple.
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.

It's for clients that can't secure secrets, and/or have difficulty making cross domain calls, such as javascript based clients.

-cmort


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110502/52156316/attachment.html>