<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><!--[if !supportLists]--><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><!--[if !supportLists]--><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><!--[if !supportLists]--><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><!--[if !supportLists]--><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>
<p class="MsoPlainText"><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><br>
</p>
<o:p></o:p>
</body>
</html>