1

I am currently adding single sign-on functionality between my application and an electronic health record (EHR) system. The SSO is done using the OpenID Connect authorization code flow, but unlike a typical OIDC sign-in (i.e. signing in with Google/Facebook/etc), the EHR system initiates the SSO process (IdP-initiated). Basically, the user will press a button in the EHR, and the expectation is that they are then automatically logged in to my application (which is displayed in a browser frame within the EHR client).

Presently, I am using a JS library (https://github.com/smart-on-fhir/client-js), running in the browser, which manages the OIDC authorization code flow. I have everything working great through the browser and am able to ultimately retrieve an OIDC ID token.

Once I have the ID token, I need to be able to use it as a means of matching to a specific user in my system. To do this, I'll need to pass the token to my application's back-end API, so that the token can be validated and then used to extract the info necessary to find/create a user and log them in.

Are there any security concerns or considerations in regards to passing the OIDC ID token from the browser to my application's API?

FYI, I do have functionality in place to validate ID tokens per OIDC specs, using the rotating, asymmetric, keys that are provided by the EHR's authorization server.

Improve this question

2 Answers 2

Reset to default
1

The purpose of id_token is for your application acting as OIDC Client to do stuff with. Locating a user in your app based on token claims falls under the definition of "stuff". From OIDC spec:

OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it

"Safe" and "security concerns/considerations" imply a value judgement. Weighing the repercussions of a particular action requires a threat model. Good news: a lot of threat modeling work has already been done on OpenID Connect. Bad news: it's complicated.

Improve this answer
1

As long as:

  • Your token ids are shortlived and cannot be easily stolen (js injection etc.)
  • Your js application use PKCE and don't have a code flow secret somewhere,
  • You use state+nonce,
  • Your IP provides RS256 or better with rotating jwks for token validation,
  • Your api get the public keys using the jwks endpoint and validate the id tokens according to the OIDC specs, you should be fine.
Improve this answer
1
  • While this is a good checklist, we disagree with "you should be fine". This is just a tip of the iceberg
    – identigral
    Oct 13, 2020 at 22:01

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .