OAuth 2.0 mutual client authentication (mTLS)
🔥More exclusive content: productioncoder.com/you-decid...
Twitter: / _jgoebel
Website: jangoebel.com
Blog: productioncoder.com
OAuth mTLS RFC: tools.ietf.org/html/rfc8705
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.
Пікірлер: 15
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
@ernestbrant
Жыл бұрын
Thinking about this a little further to resource server will also have to check the client has the private key (and not just a copy the certification) by performing POP (mTLS or other) with the client
@jgoebel
Жыл бұрын
yes, the mechanism you described is called certificate-bound access tokens which makes the access token a sender-constrained access token. Contrary to Bearer tokens, you must do proof of possession to use the token. The most straight forward way to do this is certificate-thumbprining with the cnf claim as you described. In case the parties use self-signed certificates then the resource server might not be able to verify the certificate chain. However, still even without verification, the client needs to prove it is in the possession of the private key.
good job!
@jgoebel
Жыл бұрын
thx
sounds like certificate pinning but a bit better
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 !
@jgoebel
Жыл бұрын
No, because the cert is expired
Solves the missing verification thing from par endpoint... Can you share diagrams for oauth series, good work!
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. 😞
The hash is from the client TLS certificate and not the authorization server TLS certificate right?
@jgoebel
Жыл бұрын
Hi Josue, no the hash is from the client certificate because the the access token is only valid on the resource server if the caller proves that he is 1. in the possession of the access token and 2. that he owns the private key corresponding to the certificate to which the access token was bound to via hashing
@JosueMartins
Жыл бұрын
@@jgoebel Great, because that is also what I understood from the RFC.
i have few questions on this MTLS. can we connect on Ms Teams?