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

Nat Sakimura sakimura at gmail.com
Fri Jan 14 23:52:35 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110115/24908849/attachment.html>


More information about the Openid-specs-ab mailing list