Hi, I think the draft should make it clear that only systems that take endpoint urls from server metadata are at risk.
A system that uses preconfigured endpoint urls e.g. for token_endpoint are not affected by the discussed attacks. Those systems are better off when they use an audience value that equals the url the assertion is sent to, because then the assertion is not usable at a different endpoint at the same issuer/AZ. Requiring the issuer to be used in those systems weakens security. Also, systems, where all endpoint urls start with the same issuer url string are not at risk. Example server: 1) https://account.booking.com/.well-known/openid-configuration "issuer": "https://account.booking.com";, "token_endpoint": "https://account.booking.com/oauth2/token/v2"; 2) https://accounts.login.idm.telekom.com/.well-known/openid-configuration "issuer": "https://accounts.login.idm.telekom.com";, "authorization_endpoint": "https://accounts.login.idm.telekom.com/oauth2/auth";, "token_endpoint": "https://accounts.login.idm.telekom.com/oauth2/tokens";, "userinfo_endpoint": "https://accounts.login.idm.telekom.com/userinfo";, "revocation_endpoint": "https://accounts.login.idm.telekom.com/oauth2/revoke";, "backchannel_auth_start": "https://accounts.login.idm.telekom.com/oauth2/bc-auth/start";, "backchannel_auth_end": "https://accounts.login.idm.telekom.com/oauth2/bc-auth/end";, "logout_endpoint": "https://accounts.login.idm.telekom.com/sessionmessage/logout";, "end_session_endpoint": "https://accounts.login.idm.telekom.com/sessionmessage/logout";, All endpoint urls that start with the issuer value can be trusted and can safely be used as audience values. The draft should mention that endpoint urls taken from metadata are the problem and that all systems that do not rely on metadata are not affected. That should also be mentioned in all section of the draft that change RFCs, I think. Kind regards Axel From: [email protected] <[email protected]> Date: Sunday, 18. January 2026 at 16:40 To: [email protected] <[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]
