Assume the token is signed with RSA and all we want to do as an OAUTH client (SP) is decode the attributes within (using a project such as this):
Let’s assume that this token is still subject to interoperability testing, within the community of OAUTH vendors. So, what we see in this email is “for future interest” – to get a feel for where products will be, shortly.
Within the Microsoft world, and the office 365 world in particular with its recent Exchange Online support for OAUTH in the API, we see the project:
we can add a test page that calls the decoder class, using the access token minted by the OAUTH STS above. We have to modify the project above, which is too “microsofty” (and makes assumptions about mandatory JWT properties.
we some some very basic compatibility by making the following alterations to the original code:
We first just gut the project to get to a basic blob decoder – while waiting for the dotNet4.0 release of the formal JWT security token handler (which will do “local” validation of token signatures).
A trivial project to decode the string supplied by Ping Federate then holds together as
The supporting (variant) base64 decoder is given already in the project
with an array (with one element) of scopes: edit
Remember back here for the JWT Security Token handler project work. The above is just enough complexity to get one going, particularly if there is an SSL “bearer” channel.