Stream: smart
Topic: SMARTv2 Epic Endpoint
Josh Mandel (Jan 14 2021 at 20:40):
When I authorize my client requesting patient/Observation.rs, I get:
"scope": "Epic.Security.OAuth2.Introspect patient/Observation.c?category=vital-signs patient/Patient.r fhirUser openid",
... which has some surprising things:
- I didn't ask for "create" permissions, but I got them
- I asked for "search" permissions, but I didn't get them
- Even though I don't have "search" permissions, I can still successfully search for vital signs
I think (1) and (2) are because Epic's server only looks at scopes the client is registered for rather than what is requested. (3) is more mysterious.
Josh Mandel (Jan 14 2021 at 20:42):
When I try to call https://connectathon.epic.com/Interconnect-Fhir-OAuth/oauth2/introspect I get "Service is disabled or unsupported by security policy" -- I'm guessing this is related to this note
We require Bearer token auth for the token introspection on this server.
Does this mean I'm supposed to put the same token in a header and in the body before I can this call?
Josh Mandel (Jan 14 2021 at 20:42):
(This feels like jumping through a hoop without clear benefit -- but I think I get it because in general the client calling the introspection endpoint may not be the client to whom the access token is issued, and you are managing authorization for that endpoint distinctly.)
Jake Fisher (Jan 14 2021 at 20:53):
Yeah - it is actually configurable by each Epic site how they want to handle authentication for each service/endpoint. We have it set up to require Bearer auth in this environment for the reasons you guessed I believe.
Jake Fisher (Jan 14 2021 at 20:56):
You're correct that the scopes returned are those that are statically registered, though now (as you may have seen) patients can choose which ones they want to allow the app to access.
That said, you should be getting create, search and read permissions for Observations?category=vital-signs for that app (or none of them if the patient doesn't want you to access vital-signs).
I'll take a look at what's going on there. We retooled how we inform the app of their scopes as part of the "patient selectable scopes" project and you're testing against dev that is not 100% through the dev+testing process so there could still be some quirks.
Josh Mandel (Jan 14 2021 at 20:56):
Thanks for this info, and for looking into it
Keith Carlson (Jan 15 2021 at 14:53):
The test patient portal login here seems to be broken, I'm getting a You have reached the maximum failed login attempts error. Can you reset the account @Jake Fisher ?
adam strickland (Jan 15 2021 at 16:02):
@Keith Carlson what happens if you try clearing cookies? I can look into it more need be, but if it's failed logins that might be a quick fix
Jake Fisher (Jan 15 2021 at 16:04):
@Keith Carlson The account needed to be reset. It works again now.
Keith Carlson (Jan 15 2021 at 19:50):
Does this server support PKCE with a patient facing app? It is currently not working for me
Josh Mandel (Jan 15 2021 at 20:11):
(deleted)
Josh Mandel (Jan 15 2021 at 20:12):
My bad; I think I used the wrong client ID; deleted my comment above :)
Jake Fisher (Jan 15 2021 at 20:13):
@Keith Carlson - yes it works for me:
image.png
Gowtham (Jul 26 2021 at 13:32):
Hi ,
Iam want to access patient.read api in fhir
using Access token Iam going to access only patient.search .I not able to access patient.read and other API
please help me, In the body field will we set scope for what are all api Iam going to access
if yes please say the format for scope for accessing patient.read and observation.read Api
David Pyke: This channel is for social discussions. Technical discussions should be in #implementers
Lloyd McKenzie (Jul 26 2021 at 14:29):
What sort of error are you getting?
Cooper Thompson (Jul 26 2021 at 17:03):
What is your client ID? Do you have both patient.read and patient.search APIs registered for your client?
Last updated: Apr 12 2022 at 19:14 UTC
