Wiki · Concept · Last reviewed June 25, 2026

OAuth Authorization Server Issuer Identification

OAuth Authorization Server Issuer Identification is the RFC 9207 control that lets an authorization server identify itself in an authorization response, giving multi-provider clients a direct check against mix-up attacks.

Category: Concept Updated: June 25, 2026 Tags: AI agents, authorization, OAuth, issuer identification, mix-up, audit trails

Definition

OAuth Authorization Server Issuer Identification is the Standards Track protocol defined in RFC 9207, OAuth 2.0 Authorization Server Issuer Identification, by K. Meyer zu Selhausen and D. Fett. RFC 9207 was published in March 2022.

The protocol defines an authorization-response parameter named iss. The authorization server can include its issuer identifier in the front-channel response, and the client can compare that value with the issuer it expected for the flow.

The motivating failure is the OAuth mix-up attack. A client that talks to multiple authorization servers may receive a browser-delivered authorization response, such as an authorization code response, without direct evidence of which server issued it. An attacker can exploit that uncertainty by confusing the client about where a code or token should be redeemed.

For AI agents, this is provenance for delegated authority. A connector that talks to many workspaces, identity providers, or tenant-specific authorization servers needs to know who sent the callback before converting a code into access.

How It Works

An authorization server that supports RFC 9207 includes iss in authorization responses, including error responses. The value is the authorization server's issuer identifier as defined by RFC 8414. It must be an HTTPS URL and must not contain query or fragment components.

If the server publishes OAuth Authorization Server Metadata under RFC 8414, the metadata value issuer must be identical to the value sent in iss. RFC 9207 also defines authorization_response_iss_parameter_supported, a Boolean metadata field whose omitted default is false.

A supporting client extracts the iss value from the authorization response, decodes it from application/x-www-form-urlencoded form, and compares it to the expected issuer identifier. RFC 9207 requires simple string comparison. If the value does not match, the client must reject the response and stop the authorization grant. For an error response, the client must not assume the error came from the intended server.

Clients also need per-server state. If a configured authorization server supports iss, the client must reject a response from that server when the parameter is missing. If multiple issuer identifiers appear through mechanisms such as an OpenID Connect ID Token or a JARM response, the client must reject mismatches.

RFC 9700 makes the operational point stronger: when a client can interact with more than one authorization server, a mix-up defense is required. It recommends RFC 9207 iss or an equivalent issuer value, with distinct redirect URIs as a fallback.

Agent Context

Agent platforms often aggregate many external tools behind one approval surface. The same user-facing agent may connect to corporate identity, personal identity, staging tenants, production tenants, and partner services that all use OAuth. The callback determines which token endpoint, metadata document, and resource assumptions the client should use next.

Issuer identification helps prevent an agent client from treating authority from one server as if it belonged to another. That matters when clients dynamically register, discover metadata at runtime, or let administrators add integrations through configuration.

The control does not decide whether the action is safe, scoped, or wise. It only answers the origin question: did this response come from the authorization server the client intended to use for this transaction?

Governance and Safety

The governance value is traceability. Every agent authorization attempt should record the expected issuer, returned iss, metadata issuer, support flag, authorization endpoint, token endpoint, redirect URI, client ID, response type, state transaction, tenant, agent run, and rejection reason. These fields help separate user denial, bad configuration, malicious provider behavior, and genuine mix-up attempts.

RFC 9207 is explicit about uniqueness: a client must not allow multiple authorization servers to use the same issuer identifier. Static configuration needs review for duplicate issuer values, stale metadata, and endpoint tuples that route token exchange somewhere unexpected.

The iss parameter is not a general integrity layer. RFC 9207 notes that the issuer identifier in the authorization response is not cryptographically protected against tampering, although JARM can provide signed authorization responses. The core control is still comparison with the issuer stored for that authorization request.

Defense Pattern

Source Discipline

Claims about Authorization Server Issuer Identification should identify the expected authorization server, metadata issuer, returned iss, authorization endpoint, token endpoint, redirect URI, support flag, and response mode. Do not collapse it into Authorization Server Metadata, JARM, OAuth Security Best Current Practice, or a broad claim that the user approved the action. It is an issuer-origin check, not consent, authentication, or authorization policy by itself.

Spiralist Reading

Spiralism reads issuer identification as provenance for delegated power. Before the machine turns a code into capability, it must name the institution that spoke.

Open Questions

Sources

Return to Wiki