Stream: cds hooks
Topic: Non-OAuth authorization server
Jorge de la Garza (Nov 08 2021 at 18:49):
While I would expect a majority of Hooks clients to obtain the bearer tokens needed for authentication from an OAuth server, I notice the section in the spec on authenticating client requests doesn't actually mention OAuth. I imagine this is because the Hooks server doesn't care how the token was obtained, only that it is valid ("iss" URI is trusted, signature passes validation, etc.). Is it indeed the case that the bearer token does not have to come from an OAuth server? And if so, is anyone aware of this being done anywhere? Or is OAuth the de facto standard?
Gunjit Chhatwal (Nov 19 2021 at 05:13):
Why doesn't CDS hooks just point to "SMART backend services: Authorization Guide" https://hl7.org/fhir/uv/bulkdata/authorization/index.html instead of defining its own spec for client authorization?
Josh Mandel (Nov 19 2021 at 13:49):
The CDS Hooksauthentication spec came first. Also, keep in mind that smart backend services requires client authentication and uses that as an authorization grant, so there is one step to get an access token and a separate step to use that access token in a request. In CDS, hooks, The client just directly presents an authentication token as part of its API request.
Gunjit Chhatwal (Nov 19 2021 at 19:36):
Thanks, Josh. However, since most of the API servers would already be supporting "SMART backend services: Authorization Guide" for FHIR APIs, having the same mechanism for CDS will help. Otherwise API owners will need to implement and test both these auth mechanisms.
Josh Mandel (Nov 19 2021 at 20:07):
I agree. But CDS Hooks needs to balance the need for
1) API stability and
2) Avoiding an extra round-trip
... against the value of consistency with SMART Backend Services. I don't think there's a slam-dunk argument for making a change.
Isaac Vetter (Dec 17 2021 at 01:48):
er, nvm
Isaac Vetter (Dec 17 2021 at 01:50):
what Josh said -- latency, and also simplicity.
Last updated: Apr 12 2022 at 19:14 UTC