We have a use case whereby we need to add custom fields in the response to a call to /oauth/token.
e.g.
{
"access_token": "<jwt-access-token>",
"id_token": "<jwt-id-token>",
"refresh_token": "<opaque-refresh-token>",
"customField": "<custom-value>"
}
Is there any way to do so using rules or hooks? If not, is this something auth0 are looking to add?
Hi s.skillman
What’s the use case?
I don’t think there is a way to do exactly what you are asking, but I am pretty sure there’s a better way to do this rather than customizing the result of the /oauth/token endpoint.
Post the details here and we can try to figure it out.
John
Hi John,
The use case is this flow: http://www.hl7.org/fhir/smart-app-launch/index.html#smart-authorization-sequence.
A work around is to include the “patient” context inside either the ID token and access token as a custom claim, however if the client doesn’t request openid scope they won’t receive the ID token and even though they could get it from the access token, this should be treated as opaque by the client (as I understand). In any case, this wouldn’t conform to the specification documented.
Severin
Hi @s.skillman
This looks like you want to add a patient ID number, right?
I think this belongs in the access token or the ID token, depending on the security context.
This doesn’t sound like a workaround to me, it sounds like the right way to do it.
You have to evaluate the security here: is patient PII? If so, can it be released to the client? It may belong in the access token if it is PII.
John
That’s right and yes I think the patient ID number should go in the access token so the consuming API knows and trusts the patient ID in context. However, to conform to that specification one would need to include the patient ID outside the token as well from what I can tell. Exposing the patient ID itself to the application is not an issue, in fact it’s desired. Anyway, the access token is a JWT so can be decoded by the application if it wishes.
@s.skillman As I understand it, the patient context is created by requesting specific scopes in the Auth request, which are returned in the the access token response.
@john.gateley The issue is that the access token used to request data from the resource server specifies the scopes but does not specify the patient. Can this information be embedded into the access token and extracted by the resource server? If not, is there an Auth0 API to lookup the access token and return the user that granted it? Or is this the responsibility of the resource server to store this information in a database and check it when a resource is requested?
I have been investigating how to use Auth0 with FHIR SMART Authorization flow, and found that is currently not possible to do so in accordance with the framework.
Requirements to get SMART working:
To utilize the compartments in FHIR, custom claims needs to be added to the access token. To be able to use scope “Patient/*.*”, the access token need to have a claim named “patient” (excactly), and similar for the other compartments defined in SMART App Launch. The value of the patient claim must be an ID that allows the FHIR-server to identify the patient. It doesn’t have to be the FHIR-server’s internal Patient resource ID. In Norway, for example, we have a national person identifier that can be used for this purpose.
Why Auth0 doesn’t support this:
In Auth0 all custom claims must be prefixed with a custom namespace. It will not allow adding a claim named “patient” to the access token. It will only allow claims named with a custom namespace like “http://smarthealthit.org/fhir/scopes/patient”, but this is not according to the FHIR Smart App launch framework.
I had a support ticket for this, and was got feedback that this is currently not supported. I was asked to raise it as a feature request, which I have done, but I don’t know any timeline for this to be implemented.
[1] https://hl7.org/fhir/smart-app-launch/
[2] http://www.hl7.org/fhir/smart-app-launch/scopes-and-launch-context/
Non custom claims are coming soon. I don’t have a release date, but they are coming.
John