1.3 TLS Mutual Authentication
For extra security, the customer application may wish to retrieve user information only over a TLS-connection with Mutual Authentication. While Identification Service connections always use HTTP/S, the Mutual Authentication assures that the server only allows clients to connect when they present a valid client certificate to the server. This client certificate needs to be provided up-front to Connective so that it can be trusted by the Identification Service.
Which kind of certificates are allowed depends on the environment the Identification Service is hosted in: our cloud solution may allow self-signed certificates, but an on-premise installation may do further verification through the CA which provided the client certificate, in which case the CA needs to be trusted by the server. Either way the Identification Service uses certificate pinning so that only the current set of trusted certificates is allowed.
The steps in the sequence diagrams shown in the previous sections remain mostly the same when using Mutual Authentication. However, for this setup there might be two servers hosting the Identification Service: one hosting the application for end users and an MTLS-secured server hosting the REST APIs with which the client application should integrate.
The client application backend should talk to the MTLS-secured server in all cases instead of to the Identification Service backend to which the end user might connect during the readout of their eID. This way the client application will retrieve the proper URLs from the OpenId Connect Discovery endpoint to which the end user needs to be redirected. The MTLS-secured server will check the client certificate whereas the other backend server will always reject any calls from the client application to the Token and Userinfo endpoints.
Below you'll find another sequence diagram with the following changes:
- The client application connects to the OpenId Connect Discovery endpoint to learn the location of the Authorize endpoint, amongst other things.
- Once the client application knows the Authorize URL it can redirect the end user to it. The eID readout happens as usual.
- When the end user has given his consent to read identification details the client application receives a code which it should then send to the MTLS-secured server to receive a token.
- This token can then be exchanged for user information through the UserInfo endpoint, again by connecting to the MTLS-secured server.
Note that the negative flows for the end user have been left out for clarity reasons.
TLS MA Sequence Diagram
