Decrypting the ID token received from the token endpoint

[Ian Lindsley]

Forgive me for the following noob question, but here it comes...

How do you go about decrypting the ID token received after a successful call to the token endpoint? 

Some background to my question:
I'm working on a proof of concept to demonstrate our client application being launched from an EHR well, with patient and user context passed to our app, and an access token allowing access to FHIR clinical data resources.  I'm using the OpenID Connect Server for the P.O.C, and have been more or less following the documentation/tutorials found at the following site: http://docs.smarthealthit.org/authorization/.  I'm essentially implementing the SMART "Launch Sequence" described on the page http://docs.smarthealthit.org/authorization/, and have made a fair amount of progress.  At this point I can't launch our app from the SMART Fhir Starter, authenticate, and retrieve access and id tokens from the server.  So everything as been going pretty smooth up to this point; however, I'm  having trouble decrypting the id token, which is necessary to authenticate the currently logged-in EHR user in our system.

After registering my client with the OpenID Connect Server (https://authorize-dstu2.smarthealthit.org/manage/dev/dynreg), I saw (on the "Crypto" tab) options for choosing various encryption methods and algorithms.  And I left all of these options to the server defaults ("Use server default").  In those settings in place, which ID Token Signing Algorithm, ID Token Encryption Algorithm, and ID Token Encryption method are used by the server?  Also, what keys (if any) are used during the encryption process? 

Based on the documentation that I've read thus far on the subject, I thought I would need to provide the key(s) to use for encryption during client registration. Specifically, on the site http://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation, under section 3.1.3.7. "ID Token Validation" #1, it states:

"If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it.".

Maybe I'm interpreting the portion in red wrong; or maybe there's a place for me to provide the keys on the "Edit Client" page that I simply can't find.  My boss also mentioned that the authentication or token server may be using the public key from our apps cert, based on the redirect uris I provided during client registration.  I just need to know if that's the case. We're grasping at straws a bit; we're simply not sure.

Any help would be greatly appreciated.

Thanks,
Ian

[Justin Richer]

By default, the token is *signed* and not encrypted. If you didn’t register a client key, then it’s not encrypted at all because the server can’t encrypt to a key it doesn’t know (and you don’t have). 

However, it’s not human readable on the wire, so that might be confusing to you to look at. It’s encoded in a format known as “JWT”, or JSON Web Token. It’s actually a pretty simple format once you know what’s there: three sections, separated by periods, each section being a base64 encoded object. The first two are JSON objects, the last one is the binary signature. If you want to unpack the structure by hand, you just do:

 1) split on periods

 2) base64url decode all three sections

 3) run the first two sections through a JSON parser, keep the last as a byte array

And that’s it. For debugging purposes, I use the viewer at http://jwt.io/ to parse and display things. For actual code, there are a number of different libraries for JOSE and JWT that will handle the heavy lifting. 

 — Justin

--
You received this message because you are subscribed to the Google Groups "SMART on FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to smart-on-fhi...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ian Lindsley]

Thanks Justin!  That's exactly the information I was looking for.