[Openid-specs-ab] Validation Characteristics of UserInfo Endpoint

Breno de Medeiros breno at google.com
Mon Jan 17 19:09:10 UTC 2011


My preference is that the User-Agent and WebServer flows be as similar as
possible. It will make easier to change between implementations, and
facilitate developer's understanding of the OpenIDConnect flows.

Since User-Agent has a more limited operational context in terms of
security, I suggest we design an end-to-end solution for it, and then make
minimal changes to add support for WebServer flow.

On Fri, Jan 14, 2011 at 19:06, John Bradley <ve7jtb at ve7jtb.com> wrote:

> An existing graph API Endpoint would need to be modified to return a JWT
> anyway.
>
> I think it is cleaner to keep them as separate protected resources.
>
> We are adding complexity for backwards compatibility with legacy oAuth.
>  Seems ironic.
>
> John
>
> Sent from my iPad
>
> On 2011-01-14, at 11:51 PM, Nat <sakimura at gmail.com> wrote:
>
> The complication seem to be the fact that some use vases are overloading
> the UserInfo endpoint. If we want to use an existing graph API for this
> purpose, it obviously does not work.
>
> =nat
>
> On 2011/01/15, at 10:18, John Bradley < <ve7jtb at ve7jtb.com>
> ve7jtb at ve7jtb.com> wrote:
>
> Assuming the JWT is signed then a smart client validates the sig and a dumb
> one sends it to the Sig validation endpoint otherwise known as the user info
> endpont.
>
> The endpoint then only needs to validate the sig on the JWT and hand it
> back in the simple case.
>
> John B.
> On 2011-01-14, at 10:14 PM, Nat Sakimura wrote:
>
> I agree in sending the entire JWT to the Signature Validation Endpoint.
> UserInfo Endpoint looks like a kind of such.
>
> =nat
>
> On Sat, Jan 15, 2011 at 9:55 AM, John Bradley < <ve7jtb at ve7jtb.com><ve7jtb at ve7jtb.com>
> ve7jtb at ve7jtb.com> wrote:
>
>> I was thinking that the access tokens for the various endpoints would be
>> in the JWT.  The JWT would only be the access token for the user info
>> endpoint.
>>
>> John B.
>>
>> On 2011-01-14, at 9:51 PM, Nat Sakimura wrote:
>>
>>
>>
>> On Sat, Jan 15, 2011 at 9:03 AM, John Bradley < <ve7jtb at ve7jtb.com><ve7jtb at ve7jtb.com>
>> ve7jtb at ve7jtb.com> wrote:
>>
>>> I think exchanging code for the access token in the web server flow is
>>> equivalent proof for any assertion returned along with the access token in
>>> the web server flow.
>>>
>>
>> Thanks.
>>
>>
>>>
>>> On your second question, that's why I was asking if the JWT returned in
>>> the web server flow could also be the access token.  Given that it is a new
>>> endpoint there are no backwards compatibility issues.
>>>
>>> It works for the user agent flow as well, as far as I can tell.  I was
>>> discussing a similar idea with the UMA people for there dumb mode flow.
>>>
>>
>> Unless, of course, we return the access tokens for multiple endpoints. We
>> may not want to reveal more information than necessary.
>>
>>
>>> John B.
>>> On 2011-01-14, at 8:52 PM, Nat Sakimura wrote:
>>>
>>> Hi.
>>>
>>> I have a question about the validation characteristics of the UserInfo
>>> Endpoint.
>>>
>>> According to the <http://openidconnect.com/> <http://openidconnect.com>
>>> openidconnect.com proposal, the Client is supposed to make a query to
>>> the UserInfo Endpoint if it does not wish to validate the signature on the
>>> positive assertion that includes the access_token. It sends the user_id and
>>> access_token to the UserInfo Endpoint and it gets back asserted_user among
>>> other things. If asserted_user is true, then the validation was successful.
>>>
>>> It makes some sense in the User-Agent Flow. In case of the User-Agent
>>> Flow, the assertion is returned through the browser/user-agent so it cannot
>>> be trusted. It may have been tampered etc. Thus, assuming it is operated by
>>> the Authorization Server, sending the query to the UserInfo Endpoint has
>>> value. Also, there is an additional value in doing so because the UserInfo
>>> Endpoint can validate that it is the same User-Agent that was found at the
>>> End User Authorization Endpoint, that the User-Agent has not been swapped.
>>>
>>> However, it does not make much sense in case of the Web Server like flows
>>> where 'code' is exchanged to 'access_token' over the direct https
>>> Client-Server channel. All the validation characteristics for the UserInfo
>>> Endpoint already exists in the Access Token Endpoint. Thus, UserInfo query
>>> is redundant as a validation process and becomes an OPTIONAL user attribute
>>> query.
>>>
>>> Am I missing something? If I am right, then the 'MUST check' language
>>> comes in for the validation through the UserInfo Endpoint only in the
>>> User-Agent Flow. In fact, the assertion does not even have to be signed by
>>> the Server in case of Web Server/Artifact Flow.
>>>
>>> Also, in the current <http://openidconnect.com/><http://openidconnect.com>
>>> openidconnect.com proposal, only the access_token and user_id but not
>>> the entire token is sent to the UserInfo Endpoint. It was argued earlier
>>> that this was done because UserInfo Endpoint ought to be a regular protected
>>> resource. I thought that was a good reason. However, now I consider it as a
>>> validation endpoint, I find some value in sending the entire JWT as well. If
>>> the JWT was using RSA or EC-DSA as a signature algorithm, then the
>>> validation endpoint can be operated by a separate entity than the Server,
>>> without assuming any additional characteristics on the access_token. It
>>> probably is worth considering.
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
>>> http://www.sakimura.org/en/
>>> <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
>>> http://twitter.com/_nat_en
>>>  _______________________________________________
>>> Openid-specs-ab mailing list
>>> <Openid-specs-ab at lists.openid.net> <Openid-specs-ab at lists.openid.net>
>>> Openid-specs-ab at lists.openid.net
>>> <http://lists.openid.net/mailman/listinfo/openid-specs-ab><http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
>> http://www.sakimura.org/en/
>> <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
>> http://twitter.com/_nat_en
>>
>>
>>
>
>
> --
> Nat Sakimura (=nat)
> <http://www.sakimura.org/en/> <http://www.sakimura.org/en/>
> http://www.sakimura.org/en/
> <http://twitter.com/_nat_en> <http://twitter.com/_nat_en>
> http://twitter.com/_nat_en
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110117/4cf84bea/attachment.html>


More information about the Openid-specs-ab mailing list