Keeping things simple is always good but I think the recommendations and requirements the draft and the resulting changes in RFCs should allow systems that use out-of-band communication of endpoint URL to continue to use those endpoints as audience. The validity of these endpoint urls is as good as the validated issuer from RFC8414 metadata.
What the current draft requires makes these systems less secure because now an assertion can be used at any endpoint at the server. Human error is always possible, and we cannot protect against that, really. What we should do is make easy errors hard. So, yes probably clients who use out-of-band communication can also be tricked into doing something stupid. But, I think, we should concentrate on automated "mistakes". If the client received the endpoint url out-of-band and chooses to use it as the audience value in an assertion then the client MUST not send the assertion to a different endpoint. If the client uses RFC8414 and validated the endpoint url by matching it to the validated issuer and chooses to use it as the audience value in an assertion then the client MUST not send the assertion to a different endpoint. Another part of the attack is that the client uses the same key to sign its assertions regardless of the audience. And it should be RECOMMENDED to choose a client signing key that is unique to for each AS. I know that signatures are not a panacea, there is currently no convention in resource server metadata to say "this signing key is for AS1, and that is for AS2". Maybe dynamic client registration can do that? Systems that do not use URLs as issuer identifier cannot use rfc8414. I think following sentence does not apply to those systems. * A general description of the updates made is to require that the issuer identifier URL of the authorization server, as defined in [RFC8414], be used as the sole value of the audience of the JWT client authentication assertion. Removing choices is good but requiring the issuer URL to be used as the sole value of the audience of the JWT client authentication assertion makes some systems less secure because the assertion can now be used at all endpoints of the AS. Even if that sentence is changed to the following, which allows e.g. UUIDs as issuer identifiers, the resulting assertion is still usable at all endpoints. "A general description of the updates made is to require that the issuer identifier of the authorization server be used as the sole value of the audience of the JWT client authentication assertion." The PR does not change this sentence, because I did want to change too much in one PR. I am proposing that change now in https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/24/changes/1207cfb1556b110a20e90c9da1b47528e6cfa461. I still think that creates the risk that assertions are now acceptable at all endpoints. //Axel ps: I removed the github email address because that seems to result in strange effects. From: Brian Campbell <[email protected]> Date: Monday, 2. February 2026 at 19:19 To: Nennker, Axel <[email protected]> Cc: [email protected] <[email protected]>, reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com <reply+aanemb3vnwtdtwwiasng5ndj6pcapevbnhhof6d...@reply.github.com> Subject: Re: [OAUTH-WG] Unvalidated metadata is the problem Re: draft-ietf-oauth-rfc7523bis more specific aud is better It has been suggested/argued that out-of-band exchange of AS information is potentially subject to the same kinds of issues from an AS with bad intent via social engineering or even service documentation. It seems to me a little less likely in those cases but certainly still possible. So the online vs. out-of-band obtainment of metadata values didn't seem like a meaningful enough distinction to base security controls or options on. As I understand it, the root of the issue is a little different and/or subtle than what you've described and is more about sending/accepting the token endpoint as aud to/at endpoints other than the token endpoint itself. That URLs in metadata aren't and can't be validated is part of the issue but not the entirety of it. Using only the endpoint that the request is sent to as the aud value is also secure with respect to the problem as far as I understand it. But I think it's arguable that using the endpoint is really any more secure than the issuer identifier. And after much discussion the working group decided to use the issuer identifier and only that to keep optionality down and simplify things as much as possible. On Thu, Jan 29, 2026 at 8:20 AM <[email protected]<mailto:[email protected]>> wrote: 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<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<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]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Date: Sunday, 18. January 2026 at 16:40 To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
