Stream: smart
Topic: SMARTv2 Cerner Endpoint: aud error
Josh Mandel (Jan 14 2021 at 21:07):
@Max Philips when I try to authorize against the Cerner server I'm getting
... but I'm passing along
aud=https%3A%2F%2Ffhir-myrecord.stagingcerner.com%2Fbeta%2Fec2458f2-1e24-41c8-b71b-0e701af7583d
Josh Mandel (Jan 14 2021 at 21:07):
(I've also tried with a trailing / in my aud, same result.)
Josh Mandel (Jan 14 2021 at 21:07):
Is this a known issue?
Max Philips (Jan 14 2021 at 21:10):
this is not a known issue, let me check it out
Max Philips (Jan 14 2021 at 21:21):
oopsie, looks like i didn't test this properly, that's the aud you'd expect to use. if you can customize that value an aud of https%3A%2F%2Ffhir-myrecord.cerner.com%2Fr4%2Fec2458f2-1e24-41c8-b71b-0e701af7583d should work at the moment but let me see if i can fix this up
Josh Mandel (Jan 14 2021 at 21:25):
I see, one has .stagingcerner.com and the other has cerner.com. I can't easily decouple the FHIR server from the aud -- would be great if you can let me know when they're synced up.
Max Philips (Jan 14 2021 at 21:25):
will do
Max Philips (Jan 14 2021 at 21:26):
yeah and r4 vs beta - the aud that works now is Cerner's non-connectathon URL :)
Max Philips (Jan 14 2021 at 21:40):
@Josh Mandel this should work now! no trailing slash is what i'm testing with
Josh Mandel (Jan 15 2021 at 20:17):
I've made it as far as a login screen! I don't see the login details in your GH doc though @Max Philips . How do I sign in?
Max Philips (Jan 15 2021 at 20:23):
they should be in there - nancysmart / Cerner01
Josh Mandel (Jan 15 2021 at 20:27):
Thanks! I missed these and searched for "user", "login", "password", etc and didn't find this :)
Max Philips (Jan 15 2021 at 20:28):
i'll put some more conspicuous keywords near them :)
Josh Mandel (Jan 15 2021 at 20:29):
Now I'm getting further, to image.png but can't click "Allow Access"; cancel is my only option.
Max Philips (Jan 15 2021 at 20:31):
Keith ran into this too - for Cerner's case we require that you request patient/Observation.read as well as the new scopes in order to give our non-connectathon auth server something to think about on that screen
Max Philips (Jan 15 2021 at 20:31):
This was the case in sept too and I think Gino enhanced the smart.argo.run client to allow other scopes to be requested
Josh Mandel (Jan 15 2021 at 20:31):
Thanks!
Josh Mandel (Jan 15 2021 at 20:32):
Yeah, I have extra checkboxes I can use (would be great if you can patch up this behavior at some point for consistency of testing)
Josh Mandel (Jan 15 2021 at 20:33):
Looks like I can't do token introspection from the browser:
Access to fetch at 'https://authorization.cerner.com/tokeninfo' from origin 'https://smart.argo.run' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
... is this intentional?
Max Philips (Jan 15 2021 at 20:34):
huh, let me check that out
Josh Mandel (Jan 15 2021 at 20:35):
And when I call token introspection outside the browser I get
{
"active": true,
"scope": "openid profile patient/Observation.rs patient/Observation.read",
"client_id": "aa95d23c-8a3c-4155-ac73-c5c4226f9ef2",
"tenant_id": "ec2458f2-1e24-41c8-b71b-0e701af7583d"
}
which is missing patient and fhirUser and sub and iss.
Jenni Syed (Jan 15 2021 at 20:46):
@Josh Mandel I had previously raised some concerns about fhiruser there as our auth system doesn't currently have that type of info available at that point
Josh Mandel (Jan 15 2021 at 20:59):
OK; we tailored the language to reflect SHALL for iss and sub, and SHOULD for fhirUser. Are you still comfortable with those as the formal requirements?
Max Philips (Jan 15 2021 at 21:33):
no luck on CORS for token introspection yet. can you link me to the documentation around those other claims?
Josh Mandel (Jan 15 2021 at 21:56):
Max Philips (Jan 15 2021 at 22:38):
I was having a lot of troubles getting past that first page but I see now you can go back up to the TOC
Jenni Syed (Jan 19 2021 at 16:02):
@Josh Mandel What is the use case for a browser to call a token introspection endpoint? Usually the use case is for a server/service to make an access decision
Josh Mandel (Jan 19 2021 at 17:06):
Agreed, re: the usual/most-important use case. For the connectathon the use case for a browser to call token introspection was just "we're writing a browser app to test a bunch of stuff". Outside of testing, the main example I'd think about is explicit tracking of token expiration. You can always try using a token and see if it fails, but it's nice to have an explicit API to tell you whether it's valid, rather than needing to infer reasons for failure.
Jenni Syed (Jan 19 2021 at 17:21):
I believe we tell users to use the OAuth 2 returned parameters for expiration and not to wait until failure
Jenni Syed (Jan 19 2021 at 17:21):
We wouldn't recommend introspection for that (and there's nothing in the response that tells you it fails b/c it's expired)
Jenni Syed (Jan 19 2021 at 17:22):
The url being used in the connectathon was our production endpoint - we wouldn't likely implement CORS there
Jenni Syed (Jan 19 2021 at 17:22):
since it's not an endpoint we actually want browsers to call
Josh Mandel (Jan 19 2021 at 17:25):
When you talk about using the return parameters you mean an expected duration? This is good but tokens can in general be expired sooner.
Josh Mandel (Jan 19 2021 at 17:26):
in any case I don't think there's a deep need to have CORS support for this endpoint; just want to make sure this is a considered decision if you're going to omit it
Jenni Syed (Jan 19 2021 at 17:27):
expires_in: https://tools.ietf.org/html/rfc6749#section-5.1
Jenni Syed (Jan 19 2021 at 17:27):
That is expected to be accurate
Jenni Syed (Jan 19 2021 at 17:27):
if it's returned
Jenni Syed (Jan 19 2021 at 17:28):
when you say they can "in general expire sooner" what do you mean?
Jenni Syed (Jan 19 2021 at 17:28):
(and we're speaking access token, not refresh token)
Jenni Syed (Jan 19 2021 at 17:29):
(and if it's not returned, servers are supposed to provide documentation or something else instead... but I'm curious what servers don't currently provide that today)
Josh Mandel (Jan 19 2021 at 21:21):
Jenni Syed: when you say they can "in general expire sooner" what do you mean?
I just mean... a token I have that's intended to last 3600s might actually be invalidated by a server before 3600s is up.
Jenni Syed (Jan 19 2021 at 22:18):
Ours doesn't work that way (our tokens are also much shorter lived). In systems that do longer lived tokens, usually tokens are invalidated not because they expire - ie, a refresh wouldn't fix it, it's because the auth itself was revoked either due to security or patient choice?
Jenni Syed (Jan 19 2021 at 22:18):
IE: wouldn't the app need to go back through full auth again, not just a refresh?
Jenni Syed (Jan 19 2021 at 22:20):
If we have someone asking for this use case, do we have something more concrete?
Josh Mandel (Jan 19 2021 at 22:34):
As I said above, I don't think there's a deep need to have CORS support for the token introspection; I just wanted to make sure that this is a considered decision if you're omitting it.
Jenni Syed (Jan 19 2021 at 22:35):
Yes, today I believe it's not a use case we would encourage nor expect based on current asks
Jenni Syed (Jan 19 2021 at 22:35):
our introspection endpoint has been in prod for a while now :)
Last updated: Apr 12 2022 at 19:14 UTC
