Hi Axel, a few thoughts/replies are inline below: On Sun, Jan 11, 2026 at 7:44 AM <[email protected]> wrote:
> Hi, > > I created a PR > https://github.com/oauth-wg/draft-ietf-oauth-rfc7523bis/pull/23 that > explains the reason why issue is better as the “aud”-value than token_url. > > The reason is that RFC8414 requires that the client validates the issuer > but it does not require anything else for the other values like e.g. > token_endpoint. > So, the evil-AS can lie about token_endpoint but it cannot lie about > issuer. > It is a bit more subtle than that but yes. I made a suggestion on the PR attempting to be a little more precise about it. > > For JWT access tokens I think that having the full URL as aud is a good > security practice. If the access token has an audience that is not the > resource server endpoint then the RS should reject it. This is also ensured > by scopes and path validation but adding the correct audience seems good. > Just for clarification, JWT access tokens are not in the scope of this work. > > I assume the WG has also considered to change RFC8414 to not only require > validation of “issuer” but also require validation of “token_url”? > Would add such a requirement to > https://datatracker.ietf.org/doc/html/rfc8414#section-3.3 be an > alternative in the draft to requiring that the aud equals issuer? > > E.g. in RFC8414 add a section Updates to RFC 8414 > “The “token_endpoint" value MUST be relative to the returned issuer. If > the token_endpoint is not relative to the issuer URL then the data > contained in the response MUST NOT be used.” > > The same could be demanded for the jwks_uri. > I believe things along those lines were discussed but there are legit existing deployments that have endpoints not conforming to that restriction so the idea didn't go very far. > > In the CAMARA project we currently demand that all aud values are the URL > the request is sent too. > Which is now considered vulnerable if metadata is used. > I created an issue there > https://github.com/camaraproject/IdentityAndConsentManagement/issues/340 that > follows the current advice from the draft-04. > Following the hopefully soon-to-be RFC'd draft is a good thing but what's actually vulnerable is more subtle and narrow than that. > 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]
