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

Nat Sakimura sakimura at gmail.com
Sat Jan 15 00:51:22 UTC 2011


On Sat, Jan 15, 2011 at 9:03 AM, John Bradley <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 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 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://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
>
>
>


-- 
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/20110115/fe1e4119/attachment-0001.html>


More information about the Openid-specs-ab mailing list