On Wed, May 19, 2010 at 9:40 AM, Dirk Balfanz <span dir="ltr"><<a href="mailto:balfanz@google.com">balfanz@google.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Tue, May 18, 2010 at 11:23 PM, David Recordon <span dir="ltr"><<a href="mailto:recordond@gmail.com" target="_blank">recordond@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Tue, May 18, 2010 at 1:08 PM, Torsten Lodderstedt <span dir="ltr"><<a href="mailto:torsten@lodderstedt.net" target="_blank">torsten@lodderstedt.net</a>></span> wrote:<br></div><div class="gmail_quote">
<div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.</blockquote>
</div><div><div><br></div></div><div>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.</div>
<div><br></div><div>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.</div>
</div></blockquote><div><br></div></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote">
<div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>So, a simpler version of this would look like this:</div><div><br></div><div>- 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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>- the AS issues the access token.</div><div>- the Client sets the access token as a cookie.</div></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div>- 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).</div>
</div></blockquote><div><br></div><div>Having to make a HTTP request on page load to validate the token is a non-starter. 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?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote">
<div>- "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). </div><div>
<br></div><div>Done. No scope=openid, no special response parameters for "identity" vs. "authorization" - it's all just the same flow.</div><div><br></div><font color="#888888"><div>Dirk.</div></font></div>
</blockquote></div>