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
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
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.
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 !
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?
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. 😞
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
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
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
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.
Solves the missing verification thing from par endpoint...
Can you share diagrams for oauth series, good work!
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 !
No, because the cert is expired
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?
good job!
thx
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?
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
@@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?