I disagree that using endpoint URLs is more secure than the issuer identifier,
per my comments in the pull request. The issuer identifier is validated. The
endpoint URLs are not.
-- Mike
From: [email protected]
<[email protected]>
Sent: Sunday, January 18, 2026 7:36 AM
To: [email protected]
Subject: [OAUTH-WG] draft-ietf-oauth-rfc7523bis more specific aud is better
Hi,
I created https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24
because I think that the more specific the aud value the better if that
assertion is sent to the same url as the aud value.
There could be an egress rule at the client that protects client applications
to send assertions to endpoints with different aud values.
The important point is that aud and endpoint to which the assertion is sent are
the same. And then the URL cannot be misused at a different endpoint.
If the client sends an assertion to an endpoint, then using that endpoint URL
as the aud value, then that is more secure than using the issuer identifier
because this assertion is now only valid at this endpoint. Using the issuer
identifier as the audience value less secure.
The root cause of the attack is that token url from the metadata is not
mandatory to validate and hard to validate if the token url is not relative to
issuer.
Using issuer identifier as the aud still allows to use the assertion at
different endpoints at the same authorization server. Having the specific url
the assertion is sent to as aud prevents that.
Regarding metadata and when e.g. token_endpoint can be trusted, that is when
issuer url and token_endpoint are relative to each other.
If issuer url in the metadata is e.g. https://issuer.example.com/realms/realm
And token_endpoint is https://issuer.example.com/realms/realm/token
Then token_endpoint url can be "trusted", because issuer was validated as per
rfc8414.
If URLs are not based on metadata, but received out-ot-band then more specific
urls as aud are more secure than using issuer.
Kind regards
Axel
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
