[Openid-specs-ab] YATVE (Yet Another Token Validation endpoint)

George Fletcher gffletch at aol.com
Fri Mar 16 00:26:08 UTC 2012

Attached is a pdf of the basic flow. A few additional details...

Processing rules for the Resource Server between steps 3 and 4...

On receipt of the OAuth2 access token, the resource server MUST verify 
the validity of the token. In order to validate the token the resource 
owner MUST:
1.Decode the header and claims section of the compact JWT and ensure the 
token is of type ("typ") JWT.
2.Determine the issuer ("iss") of the token from the claims segment and 
find the shared key for that issuer. The "kid" field of the JWT header 
segment provides a hint of which key is used to sign this JWT. This also 
allows for rotating the signing keys.
3.Validate the signature of the token. Signature validation follows the 
rules identified in the draft-jones-json-web-signature specification 
(linked to in theappendix). In general this amounts to applying the 
signature algorithm with the shared key against the header and claims 
compact segments.
4.If the signature is valid, compare the expires at ("exp") value 
against the current time (seconds since epoch of Jan 1, 1970) to make 
sure the token has not expired.

Once the resource server has validated the token, the resource server 
first checks to see if the specified user ("uid") is already federated 
with AOL. If so, the resource server invokes the token validation 
endpoint at the issuing Authorization Server (e.g. /validate). The token 
validation endpoint is a standard OAuth2 protected resource. The token 
validation endpoint returns the "uid" of the user if the token is still 
valid. This is all that's needed since the user was previous federated 
with AOL.

We also defined a "user info" endpoint so this is very similar to OpenID 
Connect with it's two different endpoints. However, the validate just 
returning the uid of the user was really a performance optimization to 
not always have to return userinfo data.

The user info endpoint returns data in the PoCo schema.

Please let me know if you have any questions.


P.S. I can probably reformat all this into IETF form, it will just take 
a bit for me to find the time.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120315/26483cd8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FederatedAuthorizationwithOAuth2.pdf
Type: application/pdf
Size: 205725 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120315/26483cd8/attachment-0001.pdf>

More information about the Openid-specs-ab mailing list