Building identity on top of OAuth 2.0?

[David Recordon]

On Wed, May 19, 2010 at 9:40 AM, Dirk Balfanz <balfanz at google.com> wrote:

> On Tue, May 18, 2010 at 11:23 PM, David Recordon <recordond at gmail.com>wrote:
>
>> On Tue, May 18, 2010 at 1:08 PM, Torsten Lodderstedt <
>> torsten at lodderstedt.net> 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.

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.



> 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.



> 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.



> - 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.



> - 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. 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?



> - "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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100519/aab9c49f/attachment.htm>