Stream: implementers
Topic: OAuth2 / JWT auth?
Matthew Koch (Apr 12 2018 at 13:04):
We're looking into setting up an OAuth2 server that allows for clients to authenticate themselves and then request FHIR resources from our data store. The recommended approach for this seems to be the following (SMART on FHIR):
http://docs.smarthealthit.org/authorization/backend-services/
We will not be authenticating against an existing EHR Auth Server - we're setting this up ourselves.
Our primary use case will be for third parties to request (via GET calls) bundles of resources that they are granted access to via specific authorization rules we establish. One way we were thinking of doing this was to set up a database of "users" (e.g. clients) that would then be able to make authenticated API calls to our server to get what they need. They'd do this by sending along the appropriate Authorization header with their requests.
So...on to my question. Should we pursue a JSON Web Token (JWT) model where:
- Clients generate a public/private key pair, and store the private key securely
- We store the client public key
- Clients create single use JWT's, and make requests to a
/tokenendpoint we set up, which returns them an access token - Clients can use this "bearer" token until it expires
This does seem more cumbersome to set up, but secure in the long run. Open to thoughts...
Lloyd McKenzie (Apr 12 2018 at 17:32):
@Josh Mandel @John Moehrke ?
Josh Mandel (Apr 12 2018 at 17:50):
I think you have a wide design space available to you. On the lowest end of the spectrum: just give developers API keys that they can use directly for API calls (forever or until revoked). To avoid long-lived shared secrets, the asymmetric cryptography infrastructure helps. We proposed this (with a JWT-based OAuth flow) in SMART as a good fit for many use cases -- but it's entirely possible that it's "too cumbersome". We're trying to learn more on this front through community feedback.
Josh Mandel (Apr 12 2018 at 17:52):
One overarching goal is to find an approach in a sweet spot of "good security properties" and "not too cumbersome" ... to the point that it can be come commonly adopted and understood across many vendors and use cases. We've had modest success here with user-facing app OAuth protocols, but here hasn't been enough attention to "backend services" yet.
John Moehrke (Apr 12 2018 at 18:14):
I agree with Josh on the current state of the art. This specific use-case is one we (the FHIR community) is trying to gather experience and formulate a position on. You might want to join the "Security and Privacy" stream. Over there is a specific thread to this topic https://chat.fhir.org/#narrow/stream/Security.20and.20Privacy/topic/backend.20service.20secure.20communication
Akeem Leighton Foster Spencer (Apr 12 2018 at 19:42):
I think you have a wide design space available to you. On the lowest end of the spectrum: just give developers API keys that they can use directly for API calls (forever or until revoked). To avoid long-lived shared secrets, the asymmetric cryptography infrastructure helps. We proposed this (with a JWT-based OAuth flow) in SMART as a good fit for many use cases -- but it's entirely possible that it's "too cumbersome". We're trying to learn more on this front through community feedback.
Hey @Josh Mandel, I'm sorry if the resources for this are covered in FHIR but I'll ask anyway, but what about biometrics? Can the clients use biometrics in order to sign-on? (i.e. fingerprints, facial detection). Does FHIR have resources built for this type of security protocol?
Josh Mandel (Apr 12 2018 at 21:24):
FHIR doesn't have resources for authentication (biometric or otherwise). For user-facing apps, an identity provider certainly can provide support for multiple factors including passwords, OTP, device flows, biometrics, etc. This gets into details of authentication, which should be orthogonal to how FHIR and an authorization spec are created.
Josh Mandel (Apr 12 2018 at 21:24):
Specifically for backend services (the question in this thread), there's no user in the loop, so it wouldn't make sense to talk about biometrics.
Grahame Grieve (Apr 13 2018 at 21:00):
in general you should look to SCIM for this - see http://www.simplecloud.info/
Matthew Koch (Apr 27 2018 at 16:29):
in general you should look to SCIM for this - see http://www.simplecloud.info/
Hi Grahame, is this what you would recommend for this use case? Poking around, I think the SCIM protocol does show promise, especially if part of the goal is to limit what folks should be granted access to based on their identity. https://tools.ietf.org/html/rfc7644
I also wonder how this would work in practice. I suppose we could provision users in a database but include enough information to encode them as SCIM objects. Then, when users (clients) make requests using OAuth, that mechanism doesn't change but we can restrict what FHIR resources those users can access once the request makes its way through.
Grahame Grieve (Apr 27 2018 at 23:36):
SCIM would mnage the user accounts and permissions (in the authorization server). And I'd use OAuth, yes. And the Authorization server users the user details in the SCIM fronted database to decide what user is allowed to do. THis requires that the resource server be firmly welded to the Authorization server for permission/access control as well as authorization
Last updated: Apr 12 2022 at 19:14 UTC
