<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<font face="Helvetica, Arial, sans-serif">Attached is a pdf of the
basic flow. A few additional details...<br>
<br>
</font><font face="Helvetica, Arial, sans-serif">Processing rules
for the Resource Server between steps 3 and 4...<br>
</font><font face="Helvetica, Arial, sans-serif"><br>
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:<o:p></o:p> <br>
</font><font face="Helvetica, Arial, sans-serif"><span
style="mso-fareast-font-family:Courier;
mso-bidi-font-family:Courier"><span style="mso-list:Ignore">1.<span
style="font:7.0pt "Times New Roman""> </span></span></span>Decode
the
header and claims section of the compact JWT and ensure the token
is of type (“typ”) JWT.<o:p></o:p> <br>
</font><font face="Helvetica, Arial, sans-serif"><span
style="mso-fareast-font-family:Courier;
mso-bidi-font-family:Courier"><span style="mso-list:Ignore">2.<span
style="font:7.0pt "Times New Roman""> </span></span></span>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.<o:p></o:p> <br>
</font><font face="Helvetica, Arial, sans-serif"><span
style="mso-fareast-font-family:Courier;
mso-bidi-font-family:Courier"><span style="mso-list:Ignore">3.<span
style="font:7.0pt "Times New Roman""> </span></span></span>Validate
the
signature of the token. Signature validation follows the rules
identified in the draft-jones-json-web-signature specification
(linked to in the<span style="mso-spacerun: yes"> </span>appendix).
In general this amounts to applying the signature algorithm with
the shared key against the header and claims compact segments.<o:p></o:p>
<br>
</font><font face="Helvetica, Arial, sans-serif"><span
style="mso-fareast-font-family:Courier;
mso-bidi-font-family:Courier"><span style="mso-list:Ignore">4.<span
style="font:7.0pt "Times New Roman""> </span></span></span>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.<br>
<o:p></o:p> <br>
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.<br>
<br>
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.<br>
<br>
The user info endpoint returns data in the PoCo schema.<br>
<br>
Please let me know if you have any questions.<br>
<br>
Thanks,<br>
George<br>
</font> <font face="Helvetica, Arial, sans-serif"><br>
P.S. I can probably reformat all this into IETF form, it will just
take a bit for me to find the time.</font>
</body>
</html>