Enforce token_endpoint_auth_method during the token request

[j-kowal]

Hello 👋
Currently, in oidc-provider (tested with v9.1.1), the token_endpoint_auth_method configured per client (e.g., client_secret_basic or client_secret_post) is not strictly enforced during token requests.

Even if a client is registered with:

{
  "client_id": "foo",
  "client_secret": "bar",
  "token_endpoint_auth_method": "client_secret_basic"
}

it is still possible to authenticate using client_secret_post (i.e., by sending the client ID and secret in the POST body rather than the Authorization header).

Upon reviewing the source code (lib/shared/client_auth.js, it appears that both client_secret_basic and client_secret_post are always added to the allowed methods (ctx.oidc.authorization.methods) regardless of the client's configured method, making these methods effectively interchangeable.

Expected Behavior

The server should enforce the authentication method specified in the client's token_endpoint_auth_method. If a client is configured to use client_secret_basic, any attempt to authenticate via client_secret_post (or any other method) should result in an invalid_client error.

Proposal

Update the client authentication logic to only allow the method defined in client.tokenEndpointAuthMethod (or its default if not set), and reject all others with invalid_client.

I'd be happy to help contribute a patch if you're open to this change.

Thanks for your work on this excellent project! 🙌

[panva]

Hello @j-kowal

I am not interested in such behaviour. The module had it in the past (before version 6.5.0), relaxing it poses no security risk and improves general interop with off the shelf software where basic is default sometimes, post otherwise.

It's just these two methods that are interchangeable and it is very much intentional.

[j-kowal]

Thanks for the clarification, and that makes sense from an interoperability perspective.

That said, would you consider adding a note about this intentional interchangeability between those methods to the documentation? It might help avoid confusion for those expecting strict enforcement of the method.

Cheers

[panva]

It hasn't come up until now since 6 years ago when the change was made. So i'm keen to say it's not necessary