New OAuth spec for TLS client authentication with X.509 certificate

2017-04-06

Brian Campbell and other members of the OAuth WG published a new spec for letting clients authenticate with TLS and a X.509 certificate to the token endpoint of an OAuth / OpenID Connect server. The issued access token includes a hash (thumbprint) that binds it to the client's certificate, preventing misuse of the token if it's stolen.

Open banking applications in Europe, where X.509 certificate based authentication is required by law, will find this spec indispensable.

How does this new method for OAuth client authentication work?

1. The client registers for TLS authentication with the OAuth 2.0 server, and also provides the subject and issuer DNs of the X.509 certificate(s) that it is going to use.

   POST /register HTTP/1.1
   Content-Type: application/json
   Accept: application/json
   Host: demo.c2id.com
   
   {
    "redirect_uris"              : [ "https://client.example.org/callback" ],
    "client_name"                : "My Banking App",
    "token_endpoint_auth_method" : "tls_client_auth",
    "tls_client_auth_subject_dn" : "cn=mybankingapp.com",  
    "tls_client_auth_issuer_dn"  : "cn=trustedca.com"  
   }
   

2. At the token endpoint the client sends the usual request, but instead of using basic or JWT authentication, it authenticates via TLS using its X.509 certificate.

3. The OAuth / OpenID Connect server issues an access token with a special cnf.x5t#s256 field specifying the hash (thumbprint) of the client's certificate.

   {
    "iss" : "https://demo.c2id.com",
    "aud" : "https://open.bank.com",
    "sub" : "[email protected]",
    "scp" : [ "openid", "email", "check-balance" ],
    "exp" : "1493726400",
    "nbf" : "1493722800",
    "cnf" : { "x5t#s256" : "bwcK0esc3ACC3DB2Y5_lESsXE8o9ltc05O89jdN-dg2" }
   }
   

4. At the protected resource server (web API) the client submits its access token while also authenticating via TLS using its certificate.

5. The resource server validates the certificate, the token and finally, whether their binding is correct. If these checks pass, the request can proceed.

We hope this spec will be adopted as an official working item by the OAuth, so that it can eventually become an RFC.

For more information:

• Check out draft-campbell-oauth-mtls

• The slides from IETF 98 in Chicago (March 2017)

You can post questions or comments on this spec below, or write to the OAuth WG.