private_key_jwt is an OAuth 2.0 and OpenID Connect client authentication method in which the client proves its identity to the token endpoint by signing a JWT assertion with its private key, rather than sending a shared client secret. Based on RFC 7523 and RFC 7521, it removes shared secrets from the wire and is required by the FAPI security profiles used across open banking and open finance.
private_key_jwt
private_key_jwt is a client authentication method for OAuth 2.0 and OpenID Connect in which the client authenticates to the token endpoint by presenting a signed JWT assertion instead of a shared client_secret. The client signs the assertion with a private key; the authorization server verifies it against the client’s registered public key.
- No shared secrets on the wire - Because authentication is asymmetric, there is no static secret to leak, intercept, or replay from logs.
- Standards basis - Defined by RFC 7523 (JWT profile for OAuth client authentication and authorization grants) and RFC 7521, and named directly as a
token_endpoint_auth_methodin OpenID Connect Core. - A FAPI baseline - The Financial-grade API profiles require asymmetric client authentication, so
private_key_jwt(or mTLS client auth) is the floor in open banking, open finance, and CDR ecosystems.
When I audit a regulated API’s authentication profile, private_key_jwt is one of the tells that the provider is running a real, high-assurance authorization stack — typically alongside FAPI, PAR, and mTLS-bound access tokens. It is the difference between “we accept a key in a query string” and “we cryptographically verify who is calling.”
Referenced in API Evangelist papers
This standard shows up in my published research. These reports read the machine-readable evidence provider by provider — and put this standard in the context of a real sector.
The State of Australian Banking APIs
private_key_jwt client authentication is mandated across the CDR data-sharing surface.
