OAuth 2.0 Authorization Server Issuer Identification

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 10 December 2021.¶

Copyright Notice

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

The OAuth authorization framework [RFC6749] allows clients to interact with multiple independent authorization servers under the control of separate entities. Some OAuth grant types utilize the resource owner's user-agent to deliver the authorization server's response to the OAuth client. One example of this pattern is the authorization response of the authorization code grant.¶

The authorization response as specified in Section 4.1.2. of [RFC6479] does not contain any information about the identity of the authorization server which issued the response. Therefore, clients receiving a response from the resource owner's user-agent cannot be sure who initially issued the response and the secrets contained therein. The lack of certainty about the origin of the response enables a class of attacks called "mix-up attacks".¶

Mix-up attacks are a potential threat to all OAuth clients that interact with multiple authorization servers. When at least one of these authorization servers is under an attacker's control, the attacker can launch a mix-up attack to acquire authorization codes or access tokens issued by any one of the other authorization servers. There are multiple ways in which an attacker can gain control over an authorization server supported by the client: For instance, an authorization server could become compromised, or the attacker could register their own authorization server, for example, using dynamic client registration ([RFC7591]).¶

OAuth clients that interact with only one authorization server are not vulnerable to mix-up attacks. However, when such clients decide to add support for a second authorization server in the future they become vulnerable and need to apply countermeasures to mix-up attacks.¶

Mix-up attacks aim to steal an authorization code or access token by tricking the client into sending the authorization code or access token to the attacker instead of the honest authorization or resource server. This marks a severe threat to the confidentiality and integrity of resources whose access is managed with OAuth. A detailed description and different variants of the mix-up attack class can be found in Section 4.4. of the OAuth Security Best Current Practice [I-D.ietf-oauth-security-topics].¶

This document defines a new parameter in the authorization response called iss. The iss parameter allows the authorization server to include its identity in the authorization response explicitly. The client can compare the value of the iss parameter to the issuer identifier of the authorization server (e.g., retrieved from its metadata) it believes it is interacting with. The iss parameter gives the client certainty about the authorization server's identity and enables it to send credentials such as authorization codes and access tokens only to the intended recipients. Therefore, the implementation of the iss parameter serves as an effective countermeasure to mix-up attacks.¶

2. Response Parameter iss

In authorization responses to the client, including error responses, an authorization server supporting this specification MUST indicate its identity by including the iss parameter in the response.¶

The iss parameter value is the issuer identifier of the authorization server which created the authorization response, as defined in [RFC8414]. Its value MUST be a URL that uses the "https" scheme without any query or fragment components. If the authorization server provides metadata as defined in [RFC8414], the value of the parameter iss MUST be identical to the authorization server metadata value issuer.¶

HTTP/1.1 302 Found
Location: https://client.example/cb?
  code=x1848ZT64p4IirMPT0R-X3141MFPTuBX-VFL_cvaplMH58
  &state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
  &iss=https%3A%2F%2Fhonest.as.example

HTTP/1.1 302 Found
Location: https://client.example/cb?
  error=access_denied
  &state=ZWVlNDBlYzA1NjdkMDNhYjg3ZjUxZjAyNGQzMTM2NzI
  &iss=https%3A%2F%2Fhonest.as.example

3. Authorization Server Metadata

The following parameter for the authorization server metadata [RFC8414] is introduced to signal the authorization server's support for this specification:¶

authorization_response_iss_parameter_supported

Boolean parameter indicating whether the authorization server provides the iss parameter in the authorization response as defined in Section 2. If omitted, the default value is false.¶

4. Security Considerations

The authorization response parameter iss defined in this specification serves as a countermeasure to mix-up attacks described in Section 4.4. of the OAuth Security Best Current Practices [I-D.ietf-oauth-security-topics] and in detail in "On the security of modern Single Sign-On Protocols: Second-Order Vulnerabilities in OpenID Connect" [arXiv.1508.04324] and "A Comprehensive Formal Security Analysis of OAuth 2.0" [arXiv.1601.01229]. The latter provides a formal proof of the effectiveness of the countermeasure.¶

Clients MUST validate the iss parameter precisely as described in Section 2.4 and MUST NOT allow multiple authorization servers to use the same issuer identifier. In particular, when authorization server details can be manually configured in the client, the client MUST ensure that the accepted iss values are unique for each authorization server.¶

The iss parameter enables a client to decide if an authorization server "expects" to be used in an OAuth flow together with a certain token endpoint and potentially other endpoints, like the userinfo endpoint ([OIDC.Core]). When OAuth metadata is used, the iss parameter identifies the issuer and therefore the respective OAuth metadata document which points to the other endpoints. When OAuth metadata is not used, the client can use, for example, a statically configured expected iss value for each configured authorization server.¶

The issuer identifier contained in the authorization response is not cryptographically protected against tampering. In general, mechanisms such as JWTs (as specified in JARM [JARM]) could be used to protect the integrity of the authorization response. However, in mix-up attacks, the client generally receives the authorization response from an uncompromised authorization server. If an attacker can tamper this authorization response before it is received by the client, the attacker would also have direct access to the authorization code. The attacker does not need to execute a mix-up attack to steal the authorization code. Therefore, integrity protection for the authorization response is not necessary to defend against mix-up attacks.¶

There are also alternative countermeasures to mix-up attacks. When an authorization response already includes an authorization server's issuer identifier by other means, and this identifier is checked as laid out in Section 2.4, the use and verification of the iss parameter is not necessary and MAY be omitted. This is the case when OpenID Connect response types that return an ID token from the authorization endpoint (e.g., response_type=code id_token) or JARM response mode are used, for example. However, if a client receives an authorization response that contains multiple issuer identifiers, the client MUST reject the response if these issuer identifiers do not match. The details of alternative countermeasures are outside of the scope of this specification.¶

Mix-up attacks are only relevant to clients that interact with multiple authorization servers. However, clients interacting with only one authorization server might add support for a second authorization server in the future. By supporting multiple authorization servers they become vulnerable to mix-up attacks and need to apply countermeasures.¶

5. IANA Considerations

6. Acknowledgements

TBD¶

Appendix A. Document History

[[ To be removed from the final specification ]]

-01 [[ Working Group Draft ]]
*  Incorporated WG feedback
*  Changed title of the draft to make it shorter
*  Clarified mix-up attacks in introduction
*  Improved note on JARM in validation section

-00 [[ Working Group Draft ]]
*  Working group draft

-02
*  Incorporated WG feedback
*  Clarifications for unique issuer identifier
*  Clarifications when multiple issuer identifier could be present
*  Added note that iss parameter MUST NOT be used with JARM
*  Added note on error responses and example for error response
*  Editorial changes

-01

*  Incorporated first WG feedback
*  Clarifications for use with OIDC
*  Added note that clients supporting just one AS are not vulnerable
*  Renamed metadata parameter
*  Various editorial changes

-00

*  initial draft

Authors' Addresses