Stream: inferno
Topic: No patient id provided in token exchange
Lee Surprenant (Jun 26 2020 at 17:00):
Another question / potential issue with SLS-08: Token exchange response body contains required information encoded in JSON
Lee Surprenant (Jun 26 2020 at 17:00):
image.png
what does it look for to check if a patient id has been provided?
Lee Surprenant (Jun 26 2020 at 17:02):
I was under the impression that the patient id would be denoted by a "patient" claim in the access token and I verified the token I'm getting back includes a patient claim:
{
"exp": 1593119295,
"iat": 1593118995,
"auth_time": 1593118152,
"jti": "...",
"iss": "...,
"sub": "...",
"typ": "Bearer",
"azp": "inferno",
"session_state": "...",
"acr": "0",
"scope": "openid offline_access patient/*.* user/*.* launch profile launch/patient",
"patient": "1234",
"name": "testy mctestface",
}
Lee Surprenant (Jun 26 2020 at 17:03):
am I doing it wrong?
Robert Scanlon (Jun 26 2020 at 20:26):
We are expecting a patient context in the token exchange. Is this the access token? If so, we do not check the content of the access token because it is opaque to the client (unlike the id_token). You can check the request/response in the previous step to see if the patient context is provided in the token exchange.
Robert Scanlon (Jun 26 2020 at 20:27):
For example:
Screen-Shot-2020-06-26-at-4.24.49-PM.png
Lee Surprenant (Jun 26 2020 at 20:31):
oh, interesting, i thought the patient was a claim to include in the token, not an attribute to include in the body of the token response...re-reading http://www.hl7.org/fhir/smart-app-launch/#step-3-app-exchanges-authorization-code-for-access-token I guess I had that wrong...but then how does the resource server which is servicing the request to know which patient is making the request?
Robert Scanlon (Jun 26 2020 at 20:38):
The purpose of the patient context is to communicate to the client which patient id to use in queries, because it cannot inspect the content of the bearer token (and you wouldn't want a user to have to tell the app they are using what patient ID to use, better to have the authorization service communicate that to the app). You certainly would want to somehow associate authorization information with the bearer token also so the resource server can determine if it should grant access to the resource requested. But how to do it is up to you. You could encode it within the bearer token somehow (as it appears you have done here), or have the resource server query some kind of introspection service / data store.
Lee Surprenant (Jun 26 2020 at 20:43):
interesting
Lee Surprenant (Jun 26 2020 at 20:43):
FWIW JWTs aren't encrypted, they are just base64-encoded and cryptographically signed to prevent tampering
Lee Surprenant (Jun 26 2020 at 20:43):
anyone can inspect a JWT
Robert Scanlon (Jun 26 2020 at 20:44):
Right, I meant that it cannot assume a standard encoding. Not all servers will use JWTs for bearer tokens, and that's ok.
Lee Surprenant (Jun 26 2020 at 20:45):
thanks for clearing up this fundamental misunderstanding i had with SMART...I had assumed user info would be in the id_token (or available from the userinfo endpoint on the auth server) and that the patient id was really needed in the bearer token itself
Robert Scanlon (Jun 26 2020 at 20:59):
Yes, id_token is for "user" information (who you are). The bearer token signals what the app has been granted access to. And the context parameters (patient, encounter) gives the app a enough information to make queries that are useful to the user of the app.
Last updated: Apr 12 2022 at 19:14 UTC
