Stream: smart
Topic: aud parameter not passed in auth
Sagar Shah (Jan 28 2021 at 22:01):
As I understand, aud parameters is mandatory as per SMART in /auth endpoint. When its not passed by the App (or passed an invalid fhir base url as aud parameter) to the auth server, what's expected behavior? Should that return an error in json with http code 400? Or should it display an error page Or should it call the callback url of client, with error and error details?
Josh Mandel (Jan 28 2021 at 22:05):
We don't specify this, but redirecting to the client's error endpoint seems like the preferred behavior.
Josh Mandel (Jan 28 2021 at 22:06):
From OAuth spec:
If the resource owner denies the access request or if the request
fails for reasons other than a missing or invalid redirection URI,
the authorization server informs the client
Josh Lamb (Jan 31 2021 at 18:11):
I was unclear on this too, we do not reject requests without aud specified, but if the aud is specified and the value does not match we reject the request. Is aud widely supplied? I am also unclear on the value of rejecting requests without aud.
Josh Mandel (Jan 31 2021 at 21:49):
From SMART's guidance page:
2.5.1 To prevent leakage of a genuine bearer token to a counterfeit resource server, the SMART on FHIR Authorization Guide requires that authorization requests include an aud parameter whose value is the URL of the FHIR resource server from which the app wishes to retrieve FHIR data. Authorization servers must validate that the aud parameter is the URL of a known and trusted resource server prior to returning an authorization code to the requester.
2.5.2 RFC6750 describes this threat more broadly as “token redirect” – when “an attacker uses a token generated for consumption by one resource server to gain access to a different resource server that mistakenly believes the token to be for it.” To deal with token redirect, it is important for the authorization server to identify the intended recipient (or recipients) of the access token, typically a single RS (or a list of RSs), in the token. This may be done through use of the aud parameter or by some other means devised by the authorization server, in coordination with its RSs. Then, upon receipt of an access token, the RS needs to check to assure that the access token it has received is intended to be used by that RS.
I also noticed that Cerner's docs have a nice explanation of this:
This parameter is utilized by Cerner’s authorization server to protect your application against a form of exploit where an untrusted resource server advertises a legitimate authorization server in its conformance document. Without this feature, a valid, authorized access token could be inadvertently be sent by your application to the untrusted party.
Josh Mandel (Jan 31 2021 at 21:49):
Hope this clarifies @Josh Lamb (this is an important field for servers to validate).
Josh Lamb (Jan 31 2021 at 21:59):
Got it! Thanks. The aud check would be duplicatitive in my implementation but I am glad its called out.
Josh Mandel (Jan 31 2021 at 23:24):
Can you explain more about what makes it duplicative? If you are allowing this parameter to be omitted, then you might allow an app to be tricked into sharing its access token with the wrong resource server.
Josh Lamb (Feb 01 2021 at 00:51):
I do not think most servers accept random access tokens. Checks exist but it's not always called aud. I see you point and I like the idea though. It was not consistent before.
Josh Mandel (Feb 01 2021 at 01:53):
The threat isn't about servers accepting a random access token. The threat is a malicious FHIR server advertising lies in its .well-know/smart-configuration doc, tricking an app into getting a legitimate access token from a legitimate authorization sever and then using the token at the malicious resource server -- at this point, the malicious actor has a valid access token that can be used at the FHIR server associated with the legitimate authorization server.
Josh Lamb (Feb 01 2021 at 16:30):
This is interesting. I am glad I asked this question. As I am working through this thought experiment I also see a similar issue with bad actor applications (who may expose a whole bunch of fake FHIR servers). The way we must accept registrations from apps can make this tricky to detect too. It seems that the only thing in jeopardy is a single consumer's data, so we probably have to address this as consumer education (as policy requires anyway). But we should certainly reject requests without AUD. (Ill hold questions on how OPEN ID works until I do more research lol)
Last updated: Apr 12 2022 at 19:14 UTC
