OAuth 2.0 mutual client authentication (mTLS)

00:00 Client Authentication between client and OAuth authorization server
01:41 OAuth 2.0 mutual TLS (mTLS)
04:43 OAuth 2.0 Certificate-Bound Access tokens with mutual TLS
05:59 Binding an access token to a certificate
08:59 Security considerations for OAuth mutual TLS

OAuth requires confidential clients to have some form of client authentication. The original spec defines a simple way of authenticating between the client and the authorization server by leveraging shared secrets and by sending the secret in every request either with HTTP Basic Auth or with the request itself.

OAuth also defines that the client and the authorization server might use any means of authentication that is found suitable. The mutual TLS extension of OAuth allows the client to authenticate to the authorization by using mutual TLS. This means that during the TLS handshake both the client and the authorization server have to prove that they are in the possession of the respective private key before a connection is successfully established.

Using mutual TLS to authenticate a client is much more secure than relying on a shared secret that is sent over the wire with every requests (note that the secret is encrypted by TLS because OAuth mandates the use of TLS for the communication between the client and the authorization server.

The RFC also defines a way to bind an issued access token to a certificate so that only he who is in possession of the private key of the certificate can actually use the access token. This implements a proof of possession kind of scenario that is found in enterprise setups where more security is required.

[ernestbrant]

Thanks for posting 🙂, great channel

So in a nutshell as the Access Token is signed (because there is an existing trust relationship between the resource server and the authentication server, based on asymmetric keys), so you know it has not been altered since it was issued. You can simply place the hash value of the client certificate (stream of bytes of the actual certificate file, sent through a one-way hash like SHA256) as the cnf claim in the access token. This then proves to the resource server the client is one and the same client who initially obtained the signed access token; rather than someone else stealing the access token (bearer token).The key point being the mutual authentication between the client and the authorisation server using X509 certificate they both trust (from a mutually trusted CA for example). Plus the resource server also trusts the entity that issued the client certificate. As long as all parities protect their private keys adequately all is good. If any of this is incorrect, please let me know, thanks

[ArvindKumar-ozjg]

Solves the missing verification thing from par endpoint...

Can you share diagrams for oauth series, good work!

[zekininadresi]

sounds like certificate pinning but a bit better

[khennedybacule]

Very nice. But I have a question, I understood that is very security, but I dont understand how this can be use as an auth process, because in my interpretation you can generate a certificate and get a acess token, in this case everyone can create a application that generate a certificate and get the token. In this case is necessary a third party like CA to verify, and the Authorization Server need trust in CA. Right? A plus question, this flow is adequate for a use case where we have more 10 thousand devices?

[வீரசோழன்]

That explanation was neat ..! Just a quick question in self signed certificate, will it accept the expired certs as well to initialize the connection and exchange the data ? pls suggest .. Thanks !

[Voigt_Analytics]

Wenn ich doch nur wüsste, wie man diese blöden Konfigurationsprofile (p12) mit Zertifikat & Key für iOS/iPadOS erstellen könnte. Bei macOS klapppt der Import in die Keychain über das Terminal. Doch wie macht man das bei iOS, wenn man mTLS in Safari zum Login nutzen möchte? Jemand eine Idee? Hab schon verschiedene Ansätze ausprobiert, alle sind gescheitert. 😞

[JosueMartins]

The hash is from the client TLS certificate and not the authorization server TLS certificate right?

[manjerekarrao]

i have few questions on this MTLS. can we connect on Ms Teams?