Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallNo. Mutual TLS (mTLS) can prove that a client controls the private key for a trusted X.509 certificate. That authenticates the client at the TLS layer; it does not grant permission to call particular API methods or access particular records. The resource server must still authorize the request, usually by validating an access token and applying its permissions and local policy.
What mTLS proves
During a mutual TLS handshake, the client presents an X.509 certificate and proves possession of the corresponding private key. The receiving system can use the certificate and its configured trust policy to establish a client identity. TLS 1.3 describes the protocol handshake and certificate authentication in RFC 8446; OAuth-specific uses of client certificates are defined in RFC 8705.
That is an authentication result: it answers which client proved control of a credential. Authorization is a separate decision: whether that client may perform this operation on this resource. A trusted certificate alone does not specify those permissions.
How OAuth separates client authentication from authorization
RFC 8705 defines two related but distinct capabilities. An authorization server may authenticate an OAuth client with mTLS, and it may issue an access token bound to the client’s certificate. Either capability can be deployed without the other, or both can be used together.
Recommended Free Tools
#1 Best Overall
- mTLS client authentication: The authorization server verifies the client certificate when the client connects to an endpoint that requires this authentication method. Whether mTLS is required depends on the server’s configuration and policy.
- Access-token authorization: The protected resource validates the access token and uses its claims, scopes, and applicable application policy to decide whether to allow the requested action.
- Certificate-bound token check: When a token is bound to a certificate, the protected resource also checks that the certificate on the current TLS connection matches the certificate associated with the token.
As RFC 8705 Section 6.2 puts it: “The resource server makes authorization decisions based on the access token presented by the client but does not directly authenticate the client per se.”
What certificate-bound access tokens add
A certificate-bound token ties token use to possession of the private key corresponding to a particular certificate. The protected resource compares the certificate presented through the TLS connection with the certificate associated with the token. If they do not match, RFC 8705 requires the resource to reject the request.
This check can make a stolen token harder to replay: possession of the token alone is insufficient if the presenter does not also control the bound certificate’s private key. The binding does not add API scopes or grant extra access. The resource server must still decide whether the token authorizes the requested operation.
| Control | What it checks | Where the decision occurs |
|---|---|---|
| mTLS peer authentication | Whether the TLS client presents a certificate trusted under the receiving system’s policy and proves possession of its private key. | During the TLS handshake. |
| OAuth mTLS client authentication | Whether the OAuth client is authenticated with its certificate, if the authorization server requires that method. | At the authorization-server endpoint. |
| Access-token authorization | Whether the token and application policy permit the requested API action. | At the protected resource when it processes the request. |
| Certificate-bound token verification | Whether the certificate on the request matches the certificate bound to the token. | At the protected resource when it validates the token-bearing request. |
Where each check belongs in a request flow
A clear design assigns each check to a component rather than treating them all as “mTLS authorization.” A typical flow looks like this:
- Establish the TLS connection. The TLS endpoint validates the peer certificate according to its trust policy and verifies proof of possession during the handshake.
- Authenticate to the authorization server if required. If the authorization-server endpoint requires OAuth mTLS client authentication, the client uses its certificate there.
- Validate the access token at the protected resource. The resource checks that the token is valid for the request under the deployment’s token-validation rules.
- Check the certificate binding when applicable. For a certificate-bound token, compare the connection’s client certificate with the certificate associated with the token and reject a mismatch.
- Authorize the requested operation. Apply the token’s permissions and the application’s policy to the requested method, resource, and other relevant context.
What changes when a proxy terminates TLS
If a reverse proxy or load balancer terminates TLS, the backend application does not directly observe the original client TLS handshake. The proxy may pass certificate information onward, but the backend must have a secure way to establish that the metadata came from the trusted proxy and was not altered or supplied by the client.
RFC 8705 allows TLS termination at an intermediary but leaves secure communication of client-certificate metadata between that intermediary and the application server to the deployment. The trust boundary therefore needs deliberate handling: the backend should accept identity metadata only through a protected, trusted path from the component that performed the certificate check.
Rank #4
mTLS is not the only asymmetric client-authentication option
mTLS is one option for OAuth client authentication, not a synonym for all strong client authentication. The IETF’s January 2025 OAuth 2.0 Security Best Current Practice (RFC 9700) recommends asymmetric cryptography for client authentication and names both mTLS and signed JWTs as examples. The appropriate mechanism depends on the system’s architecture and policy; neither method eliminates the need for the protected resource to enforce authorization.
Keep client identity and service identity distinct as well. RFC 9525 addresses verification of the identity of a server a client connects to. That server-identity check is different from authenticating a client to an API and different again from deciding what that client may do.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Quick Recap
Best Value
- Used Book in Good Condition
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
