FHIR Chat · id token

Stream: smart

Topic: id token

David Hay (Dec 12 2017 at 21:47):

If the auth server supplies an id token (maybe in response to the openid & profile scopes) then the 'profile' claim in the token is the url for the user (Patient, Provider, RelatedPerson) - correct? The spec has a section (copied below) that seems redundant (unless it allows for a server to include an issuer only) ...

Steps for using an ID token

Examine the ID token for its “issuer” property
Perform a GET {issuer}/.well-known/openid-configuration
Fetch the server’s JSON Web Key by following the “jwks_uri” property
Validate the token’s signature against the public key from step #3
Extract the “profile” claim and treat it as the URL of a FHIR resource

John Moehrke (Dec 12 2017 at 22:37):

I think the first four steps are used to validate the OAuth claim. This gives you trust in the token, it is good and from someone you trust. The last step is specific to FHIR use. If you skip the first four steps then someone could present a malicious claim that you would think is a valid claim for the identified 'profile' user. (I don't see a protection that the id is the same as the profiled FHIR resource. Not sure what prevents a malicous user/app from taking a valid token (like a janitor) and doing nothing but replacing the FHIR url with one of a chief clinician with much broader user rights)

David Hay (Dec 12 2017 at 23:54):

Thanks John - apparently we do that already as part pf our base OAuth implementation (which I'm looking to migrate to SMART - hence the questions!).

John Moehrke (Dec 13 2017 at 14:57):

so I guessed right? But did I answer your question?

David Hay (Dec 13 2017 at 17:04):

well - not really I'm afraid :) What I'm unclear of is whether the profile claim (url of user resource) is in the userid directly, or whether you use the issuer (iss) to get it... (or potentially both, depending on the implementation - ie look first in the userid, and if not found then get it via the issuer)...

Ben Spencer (Dec 14 2017 at 07:33):

aiui the last step means "extract the profile claim from the ID token"
you're not using the issuer to get the value, just to validate it

Brian Postlethwaite (Dec 14 2017 at 12:15):

Issuer just verifies the system, not the user.

David Hay (Dec 14 2017 at 18:55):

Oh, I get it.

1. get the id token.
2. validate that it is correct using the first 4 steps above.
3 if valid, then use the profile claim as the reference to the current user.

silly me!

John Moehrke (Dec 14 2017 at 19:27):

isnt that what I said?

John Moehrke (Dec 14 2017 at 19:28):

should smart require that the id in the token also be an identifier in the referenced resource?

David Hay (Dec 18 2017 at 23:03):

where do I find the keys and algorithm to decrypt the id token returned when I specify openid & profile in the scope?

Dan Gottlieb (Dec 18 2017 at 23:09):

For the SMART launcher it's at https://launch.smarthealthit.org/.well-known/openid-configuration/ which points to https://launch.smarthealthit.org/keys . @Travis Cummings - do you know where the sandbox has this info?

David Hay (Dec 19 2017 at 01:17):

thanks!

David Hay (Dec 19 2017 at 01:35):

deleted

Dan Gottlieb (Dec 19 2017 at 02:00):

Hi David, I think the id jwt is just base64 encoded and signed, not encrypted, so you should be able to decode it (I'd recommend using a jwt library) and then verify the signature with the key. The keys are out of band - the SMART launcher (a streamlined UI for the sandbox) keeps them at the address I mentioned. I was asking Travis where the older sandbox UI stores them.