{"id":2894,"date":"2026-11-07T16:57:31","date_gmt":"2026-11-08T00:57:31","guid":{"rendered":"https:\/\/self-issued.info\/?p=2894"},"modified":"2026-11-07T17:27:00","modified_gmt":"2026-11-08T01:27:00","slug":"rfc-10070-closing-the-door-on-an-actionable-oauth-security-vulnerability","status":"publish","type":"post","link":"https:\/\/self-issued.info\/?p=2894","title":{"rendered":"RFC 10070 – Closing the door on an actionable OAuth security vulnerability"},"content":{"rendered":"

\"OAuth<\/span>I’m pleased to announce that RFC 10070<\/a>, which closes an actionable security vulnerability<\/a> in OAuth 2.0 JWT Client Authentication, has been published. The abstract of the specification is:<\/p>\n

\nThis document updates RFCs 7521, 7522, 7523, and 9126 with respect to the treatment of audience values in OAuth 2.0 Client Assertion Authentication and Assertion-based Authorization Grants to address a security vulnerability identified in the previous requirements for those audience values in multiple OAuth 2.0 specifications.\n<\/p><\/blockquote>\n

As I described when writing<\/a> about draft-ietf-oauth-rfc7523bis<\/a>, which became this RFC, the security vulnerability was identified during formal analysis of an earlier draft of the OpenID Federation<\/a> specification. The vulnerability resulted from ambiguities in the treatment of the audience values of tokens intended for the authorization server. The ambiguities enabled a malicious authorization server to use the token endpoint of a legitimate authorization server as the audience value, resulting in a client authentication JWT that the attacker could use there.<\/p>\n

It’s interesting to note that the fix utilizes uses two features of OAuth 2.0 that did not exist when we wrote RFC 7523<\/a>:<\/p>\n