FI-3161: ID Token

[tstrass]

Summary

• Add support for openid and fhirUser scopes.
• Return an ID Token in addition to access token. I followed this spec.

  • I chose to always return the ID token, regardless of whether the SUT requested the openid and fhirUser scopes. This is because it would add complexity to check which scopes they requested, and I didn't see any harm in always returning an ID Token.

    Update: I added consideration of OpenID scopes to avoid potentially misleading the tester: 221eaf1

  • This just hard codes in the Practitioner from the DTR bundle on the reference server

  • This doesn't mock any kind of identity provider

• Expose a new JWKS endpoint, in case the client needs to verify the ID token signature to function.

Testing Guidance

• Exercise the SMART App suite's authorization steps, including fetching the smart configuration, fetching the JWKS, make an authorize request, make a token request
• Run against the SMART App Launch test kit

[tstrass]

Pushed two commits to fix and improve various things with OpenID and verified with the SMART Launch test kit.

Ready for review again @karlnaden

[karlnaden]

I need better instructions for how to run this using the postman collection. Specifically, the authorize and token requests I wasn't able to get to work.

[karlnaden]

see comments

[tstrass]

I need better instructions for how to run this using the postman collection. Specifically, the authorize and token requests I wasn't able to get to work.

@karlnaden In what way were they not working? You should only need to set the base_url variable and then send the requests when the suite is in a wait. If you saw a 404 on the Authorize request(s), that's just because the response to Authorize is a redirect, and Postman attempts to follow the redirect. You can see the 302 if you look in the console.