This is the last part of my PoP and Mutual TLS post series.
Part 1 covered some history and motivation, and part 2 looked at various server setups.
Part 3 was supposed to be a walk-through guide on how to set-up ASP.NET Core and IdentityServer, as well as a client and an API.
While writing this up, I realized that this should be really in our documentation rather than on my private blog.
But to summarize those steps, you need to:
- set-up MTLS at the hosting layer (e.g. IIS, Nginx, Apache etc..)
- set-up ASP.NET Core to receive the client certificate from the hosting layer if present
- enable MTLS in IdentityServer
- associate IdentityServer clients with client certificates
Now the client can start sending the client certificate while requesting tokens and calling APIs. IdentityServer will embed the thumbprint of the client certificate in the access token, and the API will compare that value with the actual client certificate of the TLS layer.
If they match, voila! The client has successfully proven that it is really the owner of the access token – aka Proof-of-Possession.
The full walkthrough including samples etc. can be found here.
Hi Dom, I am keen to explore Mutual TLS with nginx etc, however, in the latest release (3.1.1) MutualTlsOptions doesn’t contain DomainName. Any plans on 3.1.2 having the updated code? Right now your wonderful docs don’t reflect the latest release
Our wonderful docs reflect whatever is on master
This reflects the latest 4.0 preview. We will not port that back to 3.x
Why did you make the decision to make the: ‘Validating and accepting a client certificate’ (ConfirmationValidationMiddleware) a custom middelware component. Why isn’t it a component that will be part of a (new) IdentityServer package?
Thanks in advance,
IdentityServer would not be used inside an API – and since it is only a couple line of code, I didn’t feel like maintaining yet another nuget package. Feel free to use the source code direcrly.