Skip to main content
Identity Authority
Category: OAuth & OIDC

Client Assertion

Also known as: JWT client assertion, signed client assertion
Simply put

A client assertion is a cryptographically signed statement that an application (the OAuth client) presents to prove its identity when requesting tokens, instead of sending a simple shared password like a client secret. It lets a workload demonstrate that it is the legitimate caller during client authentication. In practice, this assertion is often a signed JWT whose contents identify the client and the intended recipient.

Formal definition

In the OAuth 2.0 assertion framework, a client assertion is a security token used to authenticate the client to the authorization server's token endpoint, as an alternative to methods such as client ID and secret. Under the JWT profile (RFC 7523), which builds on the OAuth Assertion Framework (RFC 7521), the assertion is typically a signed JWT: the sub and iss claims reference the client ID of the calling application, and the audience (aud) claim identifies the intended recipient, generally the token endpoint or authorization server. Being signed provides integrity and origin authentication of the client's authentication claims, but note that signing is not the same as encryption; a signed-only JWT is not confidential. Some deployments (for example, MSAL.NET confidential client assertions) require additional authentication claims mandated by the specific provider, and the exact required claims and validation behavior vary by profile and vendor. This term concerns client authentication at the token endpoint and is distinct from end-user authentication and from authorization decisions themselves.

Why it matters

Client authentication is the foundation that keeps confidential OAuth clients from being impersonated, and the choice of method directly affects the blast radius of a credential compromise. Traditional client ID and secret authentication relies on a shared symmetric password that must be transmitted to the authorization server and stored on both sides; if that secret leaks, an attacker can authenticate as the client. A client assertion changes the trust model: the client proves possession of a signing key without transmitting the key itself, so the material presented on the wire is a signed token rather than a reusable long-lived password.

Because the assertion is scoped by claims such as the audience (aud), it is bound to a specific intended recipient, typically the token endpoint or authorization server, which limits where a captured assertion can be replayed. Under the JWT profile (RFC 7523), the signature provides integrity and origin authentication of the client's authentication claims. It is important to keep the security properties precise: signing establishes that the assertion came from the holder of the key and was not altered, but signing is not encryption, so a signed-only JWT is not confidential and its contents can be read by anyone who intercepts it.

The practical significance for architects and engineers is that client assertion support, and the exact claims required, vary by profile and by vendor. For example, some deployments such as MSAL.NET confidential client assertions require additional authentication claims mandated by the provider. Treating client assertions as a uniform drop-in without validating against the specific authorization server's profile can lead to interoperability failures or weaker-than-expected authentication guarantees.

Who it's relevant to

IAM and Security Architects
Architects choosing between client authentication methods should weigh client assertions against client ID and secret. Assertions avoid transmitting a shared symmetric secret and can bind authentication to a specific audience, but the exact claims and validation behavior vary by profile (for example, RFC 7523) and by vendor, so the design must be validated against the target authorization server's requirements.
IAM and Integration Engineers
Engineers implementing confidential clients need to construct the assertion correctly, typically a signed JWT with sub and iss set to the client ID and aud set to the token endpoint or authorization server, and account for any additional provider-mandated claims, such as those required by MSAL.NET confidential client assertions. They must also manage signing keys, since the security of the method depends on protecting the private key rather than a shared secret.
System Administrators and Operators
Operators responsible for workload and application credentials should understand that a client assertion is used at the token endpoint for client authentication, not for end-user authentication. Because a signed-only JWT is not confidential, operators should not assume signing provides secrecy, and should manage key rotation and storage for the signing material used to produce assertions.

Inside Client Assertion

Assertion Format
In most OAuth 2.0 deployments, a client assertion is a JWT (per the JWT bearer client authentication profile) whose structure includes a header, a claims payload, and a signature. The token is signed rather than necessarily encrypted, so its contents are integrity-protected but may remain readable unless additional encryption is applied.
Issuer (iss) Claim
Typically set to the client identifier, indicating which client issued the assertion. This binds the assertion to a specific OAuth client registered with the authorization server.
Subject (sub) Claim
In client assertion flows, the subject is generally the client identifier as well, since the assertion authenticates the client itself rather than an end user. This distinguishes it from ID tokens, where the subject represents an authenticated user.
Audience (aud) Claim
Identifies the intended recipient, typically the authorization server's token endpoint. This scoping helps prevent an assertion intended for one endpoint from being replayed against another.
Expiration and Timing Claims
Claims such as exp, iat, and nbf constrain the assertion's validity window. Short lifetimes reduce the window for replay, depending on configuration.
JWT ID (jti) Claim
A unique identifier that supports replay detection when the authorization server tracks previously seen assertion identifiers.
Signing Mechanism
The assertion is typically signed using either a private key (private_key_jwt) with an asymmetric algorithm, or a shared client secret (client_secret_jwt) with a symmetric algorithm, depending on the client authentication method configured with the authorization server.

Common questions

Answers to the questions practitioners most commonly ask about Client Assertion.

Does using a client assertion authenticate the end user?
No. A client assertion authenticates the client application to the authorization server, not the end user. It is a form of client authentication that replaces or supplements a client secret at the token endpoint. User authentication is a separate concern typically handled through OpenID Connect (the authentication layer on top of OAuth 2.0), where an ID token conveys claims about the user. Client assertions operate on the client-to-authorization-server relationship and should not be conflated with verifying who a person is.
Is a client assertion the same thing as an access token or ID token?
No. A client assertion is credential material the client presents to the token endpoint to prove its own identity when requesting tokens. It is an input to the token request, not a token issued as output. Access tokens (used to call protected resources), ID tokens (which convey user authentication claims in OpenID Connect), and refresh tokens are results the authorization server may return after it validates the request. Although a client assertion is commonly a JWT, its role and audience differ from those issued tokens; the assertion's audience is typically the authorization server itself.
What signing approaches are typically used for a JWT client assertion?
In most deployments a JWT client assertion is either signed with a private key the client holds (asymmetric signing, where the authorization server validates using the corresponding public key or a registered JWKS) or signed using a shared secret (symmetric signing, HMAC-based). The exact algorithms permitted depend on the authorization server's configuration and the profile in use. Note that signing provides integrity and authentication of origin, not confidentiality; a signed but unencrypted assertion is still readable, so avoid placing sensitive data in it.
How does the authorization server know which client an assertion belongs to?
Typically the assertion's issuer and subject claims identify the client, commonly set to the registered client identifier, and the authorization server matches these against its client registration. Validation then depends on the registered key material or shared secret associated with that client. Depending on the standard profile and vendor implementation, the server may also require the audience claim to reference the token endpoint or issuer, along with expiration and a unique identifier to limit reuse. Exact required claims vary by profile and configuration.
When would you choose a client assertion over a plain client secret?
In many deployments teams choose client assertions, particularly asymmetrically signed JWTs, when they want to avoid transmitting a long-lived shared secret to the token endpoint, when private key material can be held securely by the client, or when a security profile or regulatory requirement calls for stronger client authentication. A plain client secret may remain acceptable for lower-risk clients or where key management overhead is not justified. The right choice depends on threat model, key management capability, and what the authorization server supports.
What operational considerations apply to client assertions in production?
Common considerations include managing the lifecycle of the signing key material, such as rotation and secure storage; keeping assertion lifetimes short and, where the profile supports it, using a unique identifier to reduce replay risk; ensuring clock synchronization so expiration and issued-at claims validate correctly; and registering the correct public keys or JWKS endpoint with the authorization server. Specific requirements for claim contents, permitted algorithms, and replay protection depend on the standard profile and the authorization server's configuration, so consult the relevant specification and vendor documentation.

Common misconceptions

A client assertion authenticates the end user.
A client assertion is used for client authentication to the authorization server, confirming the identity of the OAuth client itself. It is distinct from user authentication, which in the OIDC context is conveyed by an ID token. OAuth 2.0 client authentication addresses which client is making the request, not who the user is.
Because a client assertion is a signed JWT, its contents are confidential.
Signing provides integrity and origin verification, not confidentiality. Unless the assertion is additionally encrypted, its claims can typically be read by any party that obtains it. Signed and encrypted are separate properties.
A client assertion is just another way of sending the client secret.
While client_secret_jwt does derive from a shared secret, the private_key_jwt method uses asymmetric key pairs where the private key never leaves the client, which differs materially from transmitting a plaintext secret. The assertion approach also carries scoped, time-limited claims rather than a static credential.

Best practices

Set a narrow audience claim targeting the specific authorization server token endpoint, and validate it strictly on the server side to limit replay across endpoints.
Use short expiration windows and, where supported, track the jti claim to detect and reject replayed assertions.
Prefer private_key_jwt with asymmetric keys over shared-secret methods where the deployment and authorization server support it, so the signing key is never transmitted.
Rotate signing keys on a defined schedule and publish public keys via a JWKS endpoint so the authorization server can verify signatures without out-of-band key distribution.
Do not place sensitive data in assertion claims assuming confidentiality; apply encryption in addition to signing if any claim must be kept private.
Verify the client authentication method registered for each client matches what the authorization server enforces, and confirm signature algorithm expectations to avoid algorithm-confusion or downgrade issues.
Promotional banner graphic asking if you are ready for PCI DSS 4.0 with a call-to-action to get the guide