The current OAuth2 configuration in the config package supports client_id and client_secret (either as strings or files).
Since PR #862, it also supports the Authorization Grant flow, where a private key can be used to sign a JWT.
It would be great if we could extend the OAuth2 struct to include client_assertion and client_assertion_file fields. This would enable users to manually provide a signed JWT when needed.
While the library can generate the signed JWT itself, there are cases where the client_assertion is created externally—such as by a sidecar, a specialized KMS, or a separate job—and then injected into the application as a file or environment variable. Currently, there's no built-in way to pass this parameter directly.
The current OAuth2 configuration in the config package supports client_id and client_secret (either as strings or files).
Since PR #862, it also supports the Authorization Grant flow, where a private key can be used to sign a JWT.
It would be great if we could extend the OAuth2 struct to include client_assertion and client_assertion_file fields. This would enable users to manually provide a signed JWT when needed.
While the library can generate the signed JWT itself, there are cases where the client_assertion is created externally—such as by a sidecar, a specialized KMS, or a separate job—and then injected into the application as a file or environment variable. Currently, there's no built-in way to pass this parameter directly.