Support for RFC 9207 (Authorization Response Issuer Identification)

[uvdsl]

I would like to volunteer to do my bit of editing on the Solid-OIDC specification, starting with this proposal.

I have a implemented solid-oidc-client-browser, and following up the discussion in #221, I would like to propose adding the there outlined mechanism of [RFC9207], in accordance with the Current Best Practice [RFC9700].

[RFC9207] prevents Mix-up Attacks by requiring the Identity Provider to return an iss parameter alongside the authorization code. This allows the client to verify that the response originated from the intended provider, which is particularly critical in the decentralized environment that Solid facilitates where clients often interact with multiple, dynamic OPs discovered via WebIDs.

Requirement for RFC 9207

Current Best Practice [RFC9700] declare defense against mix-up attacks REQUIRED if a client may interact with multiple Authorization Servers (i.e., Identity Providers in our case). To do so, they recommend either supporting [RFC9207] or choosing an alternative.

In Solid-OIDC

• it is assumed that there does not pre-exist a trust relationship between client and Identity Provider, and
• thus clients are expected to interact with multiple different Identity Providers, and
• the specification does not mandate an alternative defense against mix-up attacks

Therefore, supporting [RFC9207] is a requirement.

Implementation Experience

Supporting [RFC9207] in the client library was straight forward and required only a few lines of code. See also uvdsl/solid-oidc-client-browser#12 on the server-support of [RFC9207]:

Already supported by

• the Solid Community Server (CSS)
• Pivot as a fork of CSS
• Graphmetrix' TrinPod
• Inrupt's Enterprise Solid Server (ESS), e.g., deployed at PodSpaces

Close to support

• the Node Solid Server (NSS) (should be supported as of version 6, though I did not yet come around to testing it)
• the PHP implementations, i.e. the PHP Solid Server and Nextcloud Plugin, are on track to supporting it

Status unkown

• https://github.com/NoelDeMartin/lss
• https://github.com/manomayam/manas

[elf-pavlik]

#244 has fix for the build breaking on CI

latest version was generated quite some time ago, i saw in my local output that formatting for authors links doesn't work any more, there might be some other things that will break.

Locally I used latest version 7.0.7 from nix packages via devbox https://www.nixhub.io/packages/bikeshed

[acoburn]

Identity providers that conform to RFC 9207, in addition to providing the iss= parameter as part of the authorization code grant, must also include the authorization_response_iss_parameter_supported metadata parameter. In the section describing client validation, it seems that a client should also be checking this field in the corresponding metadata document.

[uvdsl]

Thank you Aaron for reviewing!

Indeed, [RFC9207] indicates that

If clients interact with both authorization servers supporting this specification and authorization servers not supporting this specification, clients MUST retain state about whether each authorization server supports the iss parameter.

which I read as a requirement to enable the distinction of the two checks:

Clients MUST reject authorization responses without the iss parameter from authorization servers that do support the parameter according to the client's configuration.

Reflected in the proposal text.

Clients SHOULD discard authorization responses with the iss parameter from authorization servers that do not indicate their support for the parameter. However, there might be legitimate authorization servers that provide the iss parameter without indicating their support in their metadata.

I understand the purity aspect of this SHOULD statement but I am left wondering about the security implications. The security considerations do not provide any guidance here (as far as I read them), especially given the second sentence that there may be reasons to not advertise support.

Consider the following mix-up example:

• client initiates login with attacker-idp (who advertises support for RFC9207)
• client redirects to attacker-idp
• attacker-idp redirects to honest-idp (who does not advertise support - but client does not necessarily know that)
• user logs into honest-idp
• honest-idp redirects to client
  • without iss parameter => client rejects
    Reason: iss parameter missing (and thus would not match the idp they initiated with (attacker-idp)).
  • with iss parameter => client rejects
    Reason: iss parameter does not match the idp they initiated with (attacker-idp)

Or the inverse:

• client initiates login with attacker-idp (who does not advertise support - but client will check for iss anyway)
• client redirects to attacker-idp
• attacker-idp redirects to honest-idp (who advertises support for RFC9207 - but client does not necessarily know that)
• user logs into honest-idp
• honest-idp redirects to client
  • without iss parameter => client rejects
    Reason: iss parameter missing (and thus would not match the idp they initiated with (attacker-idp)).
  • with iss parameter => client rejects
    Reason: iss parameter does not match the idp they initiated with (attacker-idp)

Whether or not a server indicates support does not really seem to matter if the client enforces the iss check.

My current understanding is that the above SHOULD statement targets the case when:

• server does not advertise support
• server includes iss parameter
• client does NOT check iss parameter to match expected value (which a client may do according to the rfc but not according to my proposal)
• client uses iss parameter anyway, e.g., to load provider context

In such case, a mismatching iss parameter may lead to unintended behavior of the client.

This is already mitigated by the proposal: A client MUST check that the iss parameter matches the expected value upon receiving the authorization response.
Also given that servers are not required to indicate support, I deem the lookup of the metadata field rather optional.

What are your thoughts here?