V51, Verify usage of the "iss" parameter in by the authorization server

[randomstuff]

Currently there is this verification:

51.3.1 Verify that when an OAuth Client can interact with more than one Authorization Server, Clients should verify that the issuer "iss" parameter value is what it expected from the authorization response to prevent against mix-up attacks. In the absence of "iss" parameter, Clients may instead use distinct redirect URIs to identify authorization endpoints and token endpoints.

i.e. if the "iss" parameter is included in the authorization response the client must check it. By the client can proceed if the "iss" parameter is missing.

However, there is no verification for making sure that the authorization server actually included this parameter in the authorization response.

Why is this important: Verification of the issuer mitigates mix-up attacks as described in draft-ietf-oauth-security-topics-27.

Proposition:

Verify that the Authorization Server includes the "iss" parameter in authorization responses for the code grant in order to mitigate mixup-attacks.

This is not strictly necessary if the authorization server knows that the client will never talk to another authorization server but is it helpful to include this exception?

[elarlang]

Verify that the Authorization Server includes the "iss" parameter in authorization responses for the code grant in order to mitigate mixup-attacks.

For this proposed requirement I think we should not go to the functionality testing field. We also don't have a requirement a'la verify that the "state" value is presented in the access token or something like that, although this is a pre-condition to implement some other requirement.

We also have issues like:

• Proposal/discussion: OIDC requirement to ensure issuer URL == issuer claim #2003
• V51: Additional OAuth/OIDC proposals #1969 (proposal 5)

I think those issues should be solved together with the focus to "Verify that there is defense against mixup-attacks."

[randomstuff]

Note, this is about Authorization Server Issuer Identification.

[randomstuff]

I think those issues should be solved together with the focus to "Verify that there is defense against mixup-attacks."

Yes. It would probably be good to explicitly mention that the authorization server should include the "iss" in some way or another (possibly as part of a more general verification).

[elarlang]

So, as I said, I prefer to not go to the AS functionality testing field with a separate requirement, so I try to "inject" this need into to the current/replacement for 51.3.1

Verify that if the OAuth Client can interact with more than one authorization server it has a defense against mix-up attacks, for example, by requiring that the authorization server returns the 'iss' parameter value and validating it.

(validating it can be technically more descriptive)

[jmanico]

I would add:

Verify that if the OAuth Client can interact with more than one authorization server it has a defense against mix-up attacks, for example, by requiring that the authorization server returns the 'iss' parameter value and validating it in both in the authorization response and in the token response.

[jmanico]

And if you want an even more beefy version of this, consider the text before. Clients that can interact with more than one auth server should also verify the client id.

Verify that if the OAuth Client interacts with more than one authorization server, it implements defense mechanisms against mix-up attacks. For example, the client should require that the authorization server includes the 'iss' (issuer) parameter in both the authorization response and token response. The client must then validate that the 'iss' value matches the expected authorization server to prevent confusions between different servers. Additionally, consider verifying the client_id and other key parameters to further strengthen security, as recommended in RFC 9207.

[TobiasAhnoff]

I think all 3 suggestions would work, but perhaps this (from @jmanico) aligns best with detail-level in other OAuth requirements?

Verify that if the OAuth Client can interact with more than one authorization server it has a defense against mix-up attacks, for example, by requiring that the authorization server returns the 'iss' parameter value and validating it in both in the authorization response and in the token response.