client.callbackParams() - state="" vs state undefined

[alxndrsn]

I've had an interesting experience trying to support integration with an open source IdP called Authentik (https://github.com/goauthentik/authentik) using openid-client v5.4.3.

Implementing the authorization code flow, using PKCE, and NOT providing a state parameter, Authentik makes the authN callback with state= as a query param, which causes:

RPError: state mismatch, expected undefined, got: 
    at Client.callback (/usr/odk/node_modules/openid-client/lib/client.js:398:13)

Would it be reasonable for openid-client to consider '' (empty string) and undefined states to be identical?

Related:

• issue filed with authentik: core/oauth2: don't set state in responses if not supplied goauthentik/authentik#9735 (comment)
• original bug report & debugging: https://forum.getodk.org/t/oidc-issue-when-logging-in/46619/11

[panva]

This is an interesting edge case. I am of the opinion that when the client expects no state to be echoed by the AS there's no state in the query string, I think that's clear based on the implementation.

[panva]

As a workaround you can obviously send an actual state value.

[alxndrsn]

As a workaround you can obviously send an actual state value.

Yes 👍

The only issue there would be if there are integrations with IdPs which do not support state 🙃

[panva]

IdPs which do not support state

   state
         REQUIRED if the "state" parameter was present in the client
         authorization request.  The exact value received from the
         client.

🤷 I'm not worried about hypothetical IdPs that would not do the bare minimum to support the OAuth 2.0 specification.