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]> 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";, > "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] <Axel.Nennker= > [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] > -- _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]
