Building identity on top of OAuth 2.0?

Dirk Balfanz balfanz at google.com
Wed May 19 16:40:40 UTC 2010


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:
>
>> In my opionion, your proposal offers an interesting (and simplified)
>> approach to user authentication and attribute providing.
>>
>> I have some questions/comments regarding its usage of OAuth 2.0:
>>
>> 1) In your proposal there are two services providing user data, the OAuth
>> authorization server and the user data service. Why this redundancy?
>> Wouldn't the user data service suffice?
>>
>
> The model brought forth in WRAP and now preserved in OAuth 2.0 has a
> separation between the authorization server and one or more protected
> resources. I thus view the user info API as one of these protected
> resources.
>
> From conversations at IIW, I'm thinking about removing the separate user
> info API endpoint and instead making each user identifier a protected
> resource. Thus you fetch https://server.example.com/wo1k1nklas with no
> access token and get public data. Fetch it with an access token from the
> OpenID response and you get protected information.
>
> This removes an endpoint and makes the identifier itself quite useful.
>
>
>
>> 2) The usage of the standard parameter "scope" to indicate the "openid
>> mode" of the OAuth AS surprises me. In my understanding, a client uses this
>> parameter to request permissions to be bound to tokens. So it controls what
>> a client is entitled to do when accessing a protected resource using such a
>> token. In the context of OpenId connect, the "scope" parameter additionally
>> controls whether the AS responds with additional response parameters
>> (user_id, signature, issued_at) to the client. It appears to me you packed
>> two features into one parameter.
>>
>
> Sure, that's a fair assessment.
>
>
>
>> 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 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.

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.
- the AS issues the access token.
- the Client sets the access token as a cookie.
- 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).
- "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.




>
>
>> 3) Why is a signature needed to protect the access token response from the
>> server? The proposal says:
>>
>> "The client SHOULD then verify the signature. Doing so confirms the
>> binding between the given access token and user identifier in addition to
>> the response coming from the expected server."
>>
>> Since HTTPS is a MUST on the token endpoint, the authorization server is
>> authenticated during HTTPS handshake. So what is the extra security gain
>> here? Or is it just needed in user agent flow? The respective FAQ also did
>> not explain the reason to me.
>>
>
> This bit of the spec has been a bit in limbo. My first draft forced
> validation of the signature but Google really wanted no crypto on the client
> and instead make a HTTPS request to the user info API to verify the
> identifier assertion. As this point the signature allows the client to more
> quickly determine that the assertion is valid without making the user info
> request. It can also be dropped directly into a cookie if the client doesn't
> want to do it's own session management.
>
> --David
>
>
> regards,
>> Torsten.
>>
>> David Recordon schrieb:
>>
>>> The past few months I've had a bunch of one on one conversations with a
>>> lot of different people – including many of folks on this list – about ways
>>> to build a future version of OpenID on top of OAuth 2.0. Back in March when
>>> I wrote a draft of OAuth 2.0 I mentioned it as one of my future goals as
>>> well (http://daveman692.livejournal.com/349384.html).
>>>
>>> Basically moving us to where there's a true technology stack of TCP/IP ->
>>> HTTP -> SSL -> OAuth 2.0 -> OpenID -> (all sorts of awesome APIs). Not just
>>> modernizing the technology, but also focusing on solving a few of the key
>>> "product" issues we hear time and time again.
>>>
>>> I took the past few days to write down a lot of these ideas and glue them
>>> together. Talked with Chris Messina who thought it was an interesting idea
>>> and decided to dub it "OpenID Connect" (see
>>> http://factoryjoe.com/blog/2010/01/04/openid-connect/). And thanks to
>>> Eran Hammer-Lahav and Joseph Smarr for some help writing bits of it!
>>>
>>> So, a modest proposal that I hope gets the conversation going again.
>>> http://openidconnect.com/
>>>
>>> --David
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>>
>>>
>>
>>
>
> _______________________________________________
> specs mailing list
> specs at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100519/586920c6/attachment.htm>


More information about the specs mailing list