On Wed, May 19, 2010 at 10:52 AM, David Recordon <[email protected]>wrote:
> On Wed, May 19, 2010 at 9:40 AM, Dirk Balfanz <[email protected]> wrote: > >> On Tue, May 18, 2010 at 11:23 PM, David Recordon <[email protected]>wrote: >> >>> On Tue, May 18, 2010 at 1:08 PM, Torsten Lodderstedt < >>> [email protected]> wrote: >>> >>>> Why not split it? What about using another parameter, say "openid_mode", >>>> to activate the extended behavior of the OAuth authorization server? Then, >>>> the scope parameter could exclusively be used to determine the permissions >>>> of the client on the user data service. For example, the set of attributes >>>> accessible to the client could be requested that way. >>> >>> >>> OAuth 2.0 already has a `type` parameter which is used to differentiate >>> between the different flows. Given that we're piggybacking on those flows, >>> we don't want to overload that parameter. Having both `type` and `mode` >>> feels redundant when `scope` is designed for the client to tell the server >>> it wants more data access. >>> >>> Given that the client is asking for user information in addition to the >>> identifier, it seemed reasonable that would be an additional scope. Scope is >>> also already the mechanism servers use to determine the consent UI shown to >>> the user. >>> >> >> I'll repeat what I said earlier: I think it would be a Good Thing if the >> access token returned in a normal OAuth 2 flow was no different from the >> information returned in this "OpenID Connect" flow. In fact, I think we can >> make the "OpenID Connect" part so simple that there is nothing left in the >> end worth naming - it'll just be part of OAuth 2. >> > > What do you mean by "no different"? The proposal I made uses > the existing OAuth 2.0 flows and continues to treat the access token as > something that is opaque to the client. > Let's say I'm coolcalendar.com, and I want to "connect" one of my user's accounts to his Yahoo! account. I don't want to roll my own auth system, so I'm happy to see that Yahoo! supports OpenID Connect. To connect, I'll send the user over to Yahoo! with scope=openid%20yahoo-calendar. What I get back, in your proposal, is two different kinds of "tokens": the access token that my servers use to access Yahoo! and something I'll call "openid connect token" (which in your proposal comprises a few different parameters - user id, timestamp, signature, etc.) that browsers use (in form of a cookie) to access my own servers at coolcalendar.com. Why do those two tokens look different? They serve the same purpose - authenticating access from a client to a server, so they should look the same. Why should Yahoo! run different code to authenticate requests coming from my server than the code I'm running on my servers to authenticate requests coming from browsers - we have to solve the same task, so we should run the same code. It's simpler. If you're proposing that OpenID is nothing more than OAuth, that seems like > a discussion you need to start on the OAuth mailing list. > It's not my fault that you started this discussion on openid-specs :-). More seriously, it's probably something that both communities would be interested in. What you call "identity" is just a special case of authentication - the >> case of authenticating a browser request to a server. Let's not make that >> case any different from other authenticated requests in OAuth 2. The only >> thing "different" here is the scope of the access token: the access token >> that is used to authenticate a browser request to a server must include the >> target server as one of its scopes. That's all there is to it. >> > > While authenticating users in browsers is a large use case, OAuth was > originally created because users wanted to authenticate from desktop > applications as well. OAuth 2.0 defines flows which are designed for web > browsers, desktop applications, etc. It does not make sense to only design > for the browser use. > In OAuth 2, there's a gazillion ways to get to an access token, and then there is one way to use the access token. I want to keep it that way. You're the one proposing a new kind of token that's only good for "browser use". > > >> So, a simpler version of this would look like this: >> >> - When requesting an access token, in the scope parameter, the Client >> include the scopes it wants access to. If it also wants "identity" (i.e., >> use the access token to authenticate browser requests to its own servers), >> it includes its own client_id as one of the requested scopes. >> > > It's far easier for the server to check if the scope array contains a term > such as "openid" or "identity" versus a dynamic string that changes with > each client. > I think it's ok - if a bit odd - to use "scope=openid" in the message to the AS as a shorthand for "put the client id as a scope into the token". I'm not sure it's simpler: The server wouldn't have to "check" anything in the scope=coolcalendar.com case. The AS just puts whatever scopes the Client asks for into the tokens (subject to user approval, of course). One technical detail your proposal is still missing is the "audience" field in the auth response, which needs to be part of the signature. It says who the identity assertion/cookie is for. I'm saying that that audience can simply be one of the scopes of the token, at which point the cookie-checking server has to perform exactly the same checks that an access-token-consuming Protected Resource is performing (i.e., checking that the scopes in the token subsume the resource being accessed). > > > >> - the AS issues the access token. >> - the Client sets the access token as a cookie. >> > > Over HTTP? Remember that both OAuth and OpenID don't require that all > clients have SSL certificates. Given that the access token must remain > secret, I don't understand the security model of setting the access token > into an insecure cookie. Versus setting the signature into the token. > Your userid/timestamp/signature triple is, once you set it as a cookie, a _de facto_ access token, since it gives me access to the user account on the Client (and through that, presumably access to data from whatever Server account the Client account is linked to). If the Client decides to not protect those access tokens with SSL, that's their call. All I'm saying is that if it looks like duck, quacks like a duck, let's make it a duck. One thing you might be worried about is that an access token might have multiple scopes in it, only one of which is the "can-be-used-as-a-cookie-for-Client"-scope. The client might be happy to send tokens with (only) that scope in the clear, but would not want to leak more powerful tokens that contain additional scopes. If that's the case, you can always downscope the tokens, or maybe we should think about a way to say "give me one token with this scope in it, and another one with those scopes in it". > - whenever the Client needs to authenticate an incoming HTTP request from a >> browser, it validates the token (cookie) the same way it would do if it was >> a Protected Resource: it either calls back to the AS (using the GetUserInfo >> call you describe), or inspects the token without the help of the AS (we >> would have to agree on some sort of transparent structure of the token). >> > > Having to make a HTTP request on page load to validate the token is a > non-starter. > It's a non-starter for _some_ people. Which is why those people should be able to validate off-line. Requiring shared HMAC secrets is a non-starter for other people. Requiring public-key crypto is a non-starter for yet other people. Which is why there is also the option to call back to the AS. > Why inspect the token when you can just validate the signature? More so, > what do you mean by "inspect the token" in a way that doesn't involve > crypto? > By "inspect" I mean checking the signature, making sure the token scope matches the accessed resource, checking the expiration time, and extracting the userid (and perhaps more things I now forget). It _would_ involve crypto, just like in your proposal. Dirk. - "identity" is just an attribute of the token: it falls out of the >> validation step above (either by calling GetUserInfo, or by inspecting the >> well-understood transparent structure of the token). >> >> Done. No scope=openid, no special response parameters for "identity" vs. >> "authorization" - it's all just the same flow. >> >> Dirk. >> >
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
