Authorization Server Issuer Identification (RFC 9207)#

Janssen Server supports OAuth 2.0 Authorization Server Issuer Identification as defined in RFC 9207. By default, the authorization server includes its own issuer identifier (iss) in authorization responses — both successful responses and redirect-based error responses — so that clients can detect and reject mix-up attacks.

The Mix-Up Attack#

Without issuer identification, a client interacting with multiple authorization servers can be deceived into accepting an authorization response that originated from a different server than the one it intended to use. An attacker can exploit this by redirecting the victim's browser from a legitimate server to a malicious one that shares the same redirect URI, causing the client to submit a code or token issued by the attacker's server.

RFC 9207 counters this by having the authorization server stamp its own identity (iss) directly into every redirect response. The client compares this value against the issuer it expected, and rejects the response if they do not match.

How It Works#

When authorizationResponseIssParameterSupported is true in Janssen Server configuration, the iss parameter is appended to every non-JARM authorization redirect sent back to the client's redirect_uri, except for JARM responses, where the issuer is included in the JWT authorization response. This is the default.

Successful Authorization Response#

A standard authorization code response with issuer identification looks like:

HTTP/1.1 302 Found
Location: https://client.example.com/cb?
  code=SplxlOBeZQQYbYS6WxSbIA
  &state=af0ifjsldkj
  &iss=https%3A%2F%2Fserver.example.com

Error Response#

Error responses redirected to the redirect_uri also carry iss:

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

Flow Diagram#

sequenceDiagram
    autonumber
    participant UA as User-Agent
    participant Client
    participant AS as Authorization Server

    Client->>UA: Redirect to /authorize
    UA->>AS: GET /authorize?response_type=code&client_id=...&state=xyz&code_challenge=...&code_challenge_method=S256
    AS->>UA: 302 redirect_uri?code=...&state=xyz&iss=https://server.example.com
    UA->>Client: code + state + iss
    Client->>Client: Verify iss == expected issuer
    Client->>AS: POST /token (code + code_verifier)
    AS->>Client: access_token

Discovery Metadata#

When issuer identification is enabled, the Janssen Server advertises this capability in the OpenID Connect discovery document at /.well-known/openid-configuration:

{
  "issuer": "https://server.example.com",
  "authorization_response_iss_parameter_supported": true,
  ...
}

For non-JARM authorization responses, the client must validate the iss authorization response parameter against the expected issuer. For JARM responses, the client must validate the iss claim in the JWT authorization response instead.

Relationship to JARM#

When JWT Secured Authorization Response Mode (JARM) is used, the authorization response is wrapped in a signed JWT that already contains an iss claim. RFC 9207 explicitly recognises this: the iss JWT claim serves the same protective purpose as the plain iss query parameter.

Janssen Server therefore does not add a redundant plain-text iss parameter when the negotiated response mode is one of query.jwt, fragment.jwt, form_post.jwt, or jwt. The issuer is already secured inside the JWT.

Configuring Janssen Server#

Issuer identification is enabled by default. To disable it for compatibility with clients that cannot process the parameter, set the following property:

Using the TUI#

Navigate to Auth Server → Configuration → Properties and set authorizationResponseIssParameterSupported to false only when compatibility requires disabling issuer identification.

Using the Config API#

curl -X PATCH https://<jans-host>/jans-config-api/api/v1/jans-auth-server/config \
  -H "Authorization: Bearer <access_token>" \
  -H "Content-Type: application/json-patch+json" \
  -d '[{"op":"replace","path":"/authorizationResponseIssParameterSupported","value":false}]'

See the configuration reference for the full property description.

Client-Side Validation#

When a client receives an authorization response from a server that has advertised authorization_response_iss_parameter_supported: true, it MUST:

1. For non-JARM authorization responses, extract the iss parameter from the redirect response. For JARM responses, extract the iss claim from the validated JWT authorization response.
2. Compare its value to the expected issuer identifier using simple string comparison (as defined in RFC 3986 §6.2.1).
3. Reject the response if iss is absent or does not match the expected value.

For OpenID Connect flows where an ID Token is returned, the client should also verify that the iss parameter matches the iss claim inside the ID Token.

Have questions in the meantime?#

While this documentation is in progress, you can ask questions through GitHub Discussions or the community chat on Zulip. Any questions you have will help determine what information our documentation should cover.

Want to contribute?#

If you have content you'd like to contribute to this page, you can get started with our Contribution guide.