Client Certificates and REST APIs

In high-security environments the use of public/private key infrastructures (PKI) is wide-spread for good reasons. A mechanism that is often found in more traditional client/server environments is to leverage X.509 client certificates to authenticate clients on a TLS level to the server. That achieves the desired high security that PKI promises us but comes with a number of drawbacks:

  1. it is cumbersome to deploy and maintain across clients
  2. the application development support on both the server side and the client side is non-existent or shaky
  3. the transport level nature of this mechanism not mix with less secure traffic on the same TCP port and makes SSL offloading (i.e. proxy deployments) harder

For the reasons above in modern REST API environments it is next to impossible to require TLS client certificate authentication. Yet it is often desirable from a security perspective or perhaps even a regulatory requirement to use PKI in those environments. Enter OAuth 2.0 and the token paradigm! OAuth 2.0 splits client/server interaction apart in a phase where the client *gets* a so-called access token from an Authorization Server and a phase where the client *uses* the access token to get access to the API.

In an OAuth 2.0 system it is fine to authenticate Clients to the Authorization Server using TLS client certificates and to then issue a (short-lived) access token *derived* from that initial authentication down to the Client, which the Client in its turn can use towards the API without having to present that client certificate ever to the API. This alleviates the pains as described earlier for regular client/server interaction and pushes it on to the interaction of the Client with the Authorization Server. One could argue that it is a specialized “jumpbox” through which short-lived access to regular systems can be obtained. Well as it happens that is OK: that is an interaction that is based on a much tighter relationship between the two actors, does not need to mix traffic, is there for authentication purposes only, has good security properties and support, and more importantly it can be *changed* or upgraded more easily because of the controlled nature.

That last “change” statement is where the true value of OAuth 2.0 comes in: TLS client certificate authentication to the Authorization Server is alleviating just a part of the pains that were mentioned earlier. To get rid off all the drawbacks we can actually use a different “grant” that allows us to present a signed “piece of data” to the Authorization Server on the HTTP/application level instead of doing TLS client certificate authentication on the TCP level. That interaction  could be architected as described in an the IETF RFC 7521 standard here: https://tools.ietf.org/html/rfc7521 and the “piece of data” could take the form of a SAML assertion or a JSON Web Token as described in RFC 7522 and RFC 7523 respectively.

In this way we can obtain PKI-strength access to APIs, leveraging X.509 certificates without ever doing TLS client certificate authentication on the wire. To achieve the appropriate level of security we can tune the  access token expiry timeouts to ensure data “freshness” and in case we want to mitigate lost/stolen token effects.

Cliff-hanger: stay tuned for a future post on so-called “proof-of-possession” access tokens that tightens up security even more (at the cost of bringing back some of the drawbacks…) and allows us to relax requirements on token expiry…

Advertisements
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s