Hi, A similar concept is defined in 'OAuth 2.0 Mutual TLS Client Authentication' specification [1]. There it defines two distinct methods for certificate based client authentication.
1. PKI Mutual TLS OAuth Client Authentication Uses a subject distinguished name (DN) and validated certificate chain to identify the client. 2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Support client authentication using self-signed certificates. Client registers needs to associate a self-signed X.509 certificate at the time of registering. The client is successfully authenticated, if the subject public key info of the certificate matches the subject public key info of one of the certificates configured or registered for that client. Currently in IS we support only self-signed certificate based authentication [2]. In the first method, client needs to associate the CA certificate and need to provide the DN of the signed certificate at the time of client registration. During mutual TLS handshake, we only need to validate client's CA certificate. The client is successfully authenticated if the subject information in the certificate matches with the expected DN configured or registered for that particular client. [1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1 [2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients" Thanks, Sathya On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena <[email protected]> wrote: > I guess following scenario will be useful in a microservices deployment, > when we need to secure service to service communication. > > Please find below the steps.. > > 1. We create a service provider provider, and associate a CA's certificate > with it. > 2. Now we have multiple microservices, each with a signed certificate from > the previous trusted CA. > 3. Each of those microservice will be able to talk to the /token endpoint > of IS (or STS), authenticate with mTLS and get a token. The token request > also carries an audience value (or implied in scope). > 4. IS treats, the thumbprint of the cert (preferably SVID, in a > SPIFFE/Istio environment) as the client id, and the access token is issued > against it (which can be a JWT as well). > 5. This new access token/JWT can be used for service to service > authentication, within the same domain or cross domain. > > This helps to onboard all the microservices, carrying a key pair (as their > workload identity) to an OAuth environment. > > WDYT..? > > Thanks & Regards, > Prabath > > Twitter : @prabath > LinkedIn : http://www.linkedin.com/in/prabathsiriwardena > > Blog: http://blog.facilelogin.com > Vlog: http://vlog.facilelogin.com > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sathya Bandara Software Engineer WSO2 Inc. http://wso2.com Mobile: (+94) 715 360 421 <+94%2071%20411%205032> <+94%2071%20411%205032>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
