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

Nat Sakimura sakimura at gmail.com
Tue Jan 18 01:52:57 UTC 2011


Thanks Breno for your comment.

On Tue, Jan 18, 2011 at 4:09 AM, Breno de Medeiros <breno at google.com> wrote:

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


As it is written now, the UAB and AB shares exactly the same Core model and
abstract protocol.


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

Actually, WebServer flow requires much less security measures than
User-Agent flow. If we start from User-Agent flow, it amounts to removing
various requirements. For example, in Web Server/Artifact Flow, you do not
need to sign the access_token etc. if you just want LoA1 (which is the
highest User-Agent flow can go.)

=nat


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



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110118/db06799e/attachment-0001.html>


More information about the Openid-specs-ab mailing list