Client auth in OAuth2.0

"Client authentication" in OAuth2 is a process of confirming identity of the Client Application (so OAuth2-Proxy instance in our case) to the Resource Server (our identity provider) during token request. Default method of client authentication is providing a client_secret - as introduced in OAuth 2.0 Authorization Framework (RFC 6749 section 2.3.1).

OAuth2 specification extensions allow introduce additional client secret authentication methods, that are:

• Assertions - introduced in RFC7521, describes the general approach of passing assertion and client_assertion_type parameters intead of client secret and informations that the assertions must contain. Most common types of assertions are covered in the following specifications extenstions:
  • JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC7523)
  • SAML 2.0 Profile for OAuth 2.0 Client Authentication and Authorization Grants (RFC7522)
• mTLS - introduced in RFC8705, includes the client TLS certificate when performing token HTTP request.

Client auth in OIDC

OIDC, on the other hand has own Client Authentication methods listed in the Core Spec. These include:

• client_secret_basic - default method, include client secret in client_secret parameter of the request. This uses default client secret authentication of OAuth2.0.
• client_secret_post - include client credentials in the client_secret parameter of the request. This uses default client secret authentication of OAuth2.0.
• client_secret_jwt - client generate the JWT out of the client_secret and puts this as an assertion parameter. This uses the JWT assertion authentication of OAuth2.0.
• private_key_jwt - client registers public key on the IDP, and uses the private key to sign JWT which is then put into the assertion parameter. This uses the JWT assertion authentication of OAuth2.0.

Authentication methods above are wrappers to some of the OAuth2.0 authentication methods. They assume how trust relationship between IDP and Relying Parties are established (generate client secret or register public key) - which is clearly out of Oauth2-Proxy scope. The details of how to call the token endpoint is still up to OAuth2 specifications. Also, mTLS authentication isn't explicitly listed. Likely because it was introduced later, but also it's pretty clear in mTLS case how the trust relationship is established - it's offloaded on HTTP.

Considerations MS Entra Workload Identity

When using MS Entra workload identity, we're not explicitly doing none of the authentication methods listed in the OIDC spec. We don't generate any JWT, instead, it's already present in the environment or can be retrieved with API call, and its signing is completely abstracted from us. So in this case, the JWT assertion spec of OAuth2.0 (RFC7523) describes this usecase more generally.

Implementation proposal

• Implement assertion authentication, do not tied to a specific provider. Ideally, changing the way how oauth2.Config.Exchange() is called, after it's implemented in the library, see: Implementing "client_assertion"  golang/oauth2#744 .
• Allow different client_assertion_types. Expect assertions are present in the environment (env var, file), projected by an external tool (initContainer, workload identity plugin,...) - this could cover Entra Workload Identity too.
• Implement mTLS authentication - to be checked for oauth2 library support.
• Do not implement OIDC-specific authentication methods like private_key_jwt. Do not sign JWTs from keys or secrets - expect them to be present in the environment.

Related tickets

#2378