As I hope is well known in this group, In various OAuth 2 contexts, the subject
of a token (either a JWT or something introspectable) can be
• A User ID, or
• A Client ID
The audience can be
• A Client ID (OIDC ID Token)
• A Resource Indicator (Access token)
• Another AS' Issuer Identifier (Identity Chaining)
Typically resource indicators (or their paths) are pre-registered with an AS.
Typically (though not necessarily) association establishment between two ASes
is also restricted. Regardless `/.well-known/oauth-authorization-server` and
`/.well-known/oauth-protected-resource` can be reasonably said to be within the
same security domain and it could also reasonably be siad that both represent
the same entity.
Client and User IDs are typically not URIs and therefore there is no risk of
conflict. If they are URIs, typically those URIs would be alocated by the AS.
The Security BCP calls out the need to avoid conflicts between User IDs and
Client IDs, though says nothing about confusion between those resource or
issuer identifiers.
As I mentioned in issue 76
(https://github.com/oauth-wg/draft-ietf-oauth-client-id-metadata-document/issues/76)
on the CIMD draft, I believe there is a security risk here whereby it enables
confusion between issuer identifiers and client identifiers (there is perhaps a
similar risk of confusion between resource identifiers and client identifiers,
though I am not sure it is feasible):
• The org example.com run an IDP at https://auth.example.com/, with issuer
identifier https://example.com/
• example.com redirects https://example.com/.well-known/* to
https://auth.example.com/.well-known/, to satisfy the OAuth2 / OpenID Connect
Metadata requirements
• example.com has established an identity chaining relationship with the IDP
at example.net. example.net also supports CIMD.
• An attacker manages to find a vulnerability in the web application at
example.com, and uses it to place a CIMD document at https://example.com/. The
attacker cannot manipulate the .well-known directory, because the redirection
is handled by a (more secure/trusted) reverse proxy or similar. Such an attack
can be largely silent, by distinguishing between web browser & CIMD fetch
requests
• The attacker triggers an authentication at example.net with the client ID
https://example.com/, triggering CIMD usage. This results in issuing of an OIDC
ID token with `{"iss": "https://example.net/";, "aud": "https://example.com/";,
"sub": "<user>"}`
• The attacker uses this in an identity chaining request at example.com's IDP.
I believe there is a risk of other security vulnerabilities resulting from
confusion between the Client and AS, especially if the identifier gets
serialized to a string and back
I don't really see a fix unless either (a) the CIMD is put under .well-known,
or (b) a prefix is added to the client-ID-URL (in the same way as OpenID4VP is
doing)
(I quite like the .well-known option, actually; there are many reasons for an
IDP to be all three of an AS, client and RS and it brings nice symmetry to the
definitions there; but I also realise it may not be the ideal option for a lot
of uses of CIMD does not constrain the URL in this way)
Additionally, I raise this here on the mailing list because I wonder if there
should perhaps be some kind of informative document to warn people around the
hazards of identifier mixups when extending the protocol. In many ways this is
less a direct CIMD bug and more a result of the haphazard evolution of the
OAuth 2.0 ecosystem, which needs to be considered in future extensions.
In retrospect I believe we should not have had
"/.well-known/oauth-authorization-server", but instead "/.well-known/oauth"
with an "as" subkey, but that is water under the bridge at this point. OpenID
Federation probably has the right idea with the "federation entity"
terminology...
- Erin_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
