[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.
Thanks,
George
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.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.pdf>
More information about the Openid-specs-ab
mailing list