Enable Transport Layer Security (TLS)

OAuth 2.0 tokens used in Figure 12-1 are bearer tokens. Bearer tokens are like cash. If someone steals ten bucks from you, no one can prevent him or her from using the stolen money at Starbucks to buy a cup of coffee. The cashier will never challenge the person to prove the ownership of money. In the same way, anyone who steals a bearer token can use it to impersonate the owner of it and can access the resource (or the microservice). Whenever we use bearer tokens, we must use them over a secured communication channel, hence we need to enable TLS for all the communication channels shown in Figure 12-1.

The certificate created in this example is known as a self-signed certificate. In other words, there is no certificate authority (CA). Typically in a production deployment, either you will use a public certificate authority or an enterprise-level certificate authority to sign the public certificate, so any client who trusts the certificate authority can verify it. If you are using certificates to secure service-to-service communication in a microservices deployment, you need not worry about having a public certificate authority. You can have your own certificate authority.

Setting Up an OAuth 2.0 Authorization Server

The responsibility of the authorization server is to issue tokens to its clients and respond to the validation requests from downstream microservices. This also plays the role of a security token service (STS) , as shown in Figure 12-1. There are many open source OAuth 2.0 authorization servers out there: WSO2 Identity Server, Keycloak, Gluu, and many more. In a production deployment, you may use one of them, but for this example, we are setting up a simple OAuth 2.0 authorization server with Spring Boot. It is another microservice and quite useful in developer testing. The code corresponding to the authorization server is in the ch12/sample01 directory.

The sample01/src/main/java/com/apress/ch12/sample01/TokenServiceApp.java class carries the @EnableAuthorizationServer annotation, which turns the project into an OAuth 2.0 authorization server. We’ve added the @EnableResourceServer annotation to the same class, as it also has to act as a resource server to validate access tokens and return the user information. It’s understandable that the terminology here is little confusing, but that’s the easiest way to implement the token validation endpoint (in fact, the user info endpoint, which also indirectly does the token validation) in Spring Boot. When you use self-contained access tokens (JWTs), this token validation endpoint is not required.

Protecting a Microservice with OAuth 2.0

Since the Order Processing microservice calls the user info endpoint over HTTPS, and we use self-signed certificates to secure the authorization server, this call will result in a trust validation error. To overcome that, we need to export the public certificate of the authorization server from ch12/sample01/keystore.jks to a new key store and set it as the trust store of the Order Processing microservice.

In addition to setting up the trust store system properties, the last few lines of code in this code snippet do something else too. Apart from the trust validation, we could also face a potential other problem while making an HTTPS connection to the authorization server. When we do an HTTPS call to a server, the client usually checks whether the common name (CN) of the server certificate matches the hostname in our server URL. For example, when we use localhost as the hostname in user-info-url (which points to the authorization server), the authorization server’s public certificate must have localhost as the common name. If not, it results in an error. This code disregards the hostname verification by overriding the verify function and returns true. Ideally in a production deployment you should use proper certificates and avoid such workarounds.

If we see this response, then we’ve got our OAuth 2.0 authorization server and the OAuth 2.0 protected microservice running properly.

Setting Up an Authorization Server to Issue JWT

The value of spring.security.oauth.jwt is set to false by default, and it has to be changed to true to issue JWTs. The other three properties are self-explanatory and you need to set them appropriately based on the values you used when creating the key store.

Only the decoded header and the payload are shown here; we are skipping the signature (which is the third part of the JWT). Since we used the client_credentials grant type, the JWT does not include a subject or username. It also includes the scope values associated with the token.

Protecting a Microservice with JWT

Scope-Based Access Control

Role-Based Access Control

Just like in the previous section, here we have to use self-contained access tokens (or JWTs) and first you need to have a valid JWT obtained from the OAuth 2.0 authorization server.

Service-to-Service Communication Secured with JWT

In this section, we see how to invoke a microservice secured with OAuth 2.0 from another microservice by passing a JWT.

Figure 12-2 extends Figure 12-1 by introducing the Inventory microservices. Upon receiving an order, the Order Processing microservice talks to the Inventory microservice to update the inventory. Here, the Order Processing microservice passes the access token it gets to the Inventory microservice.

The token validation step in Figure 12-2 will change if we use self-contained (JWT) access tokens. In that case, there is no validation call from the microservice to the authorization server (or the security token issuer). Each microservice will fetch the corresponding public key from the authorization server and will validate the signature of the JWT locally.

If all works fine, we should see the 201 HTTP status code at the cURL client and the order numbers printed on the terminal that runs the Inventory microservice.

Service-to-Service Communication Secured with TLS Mutual Authentication

In this section, we see how to enable TLS mutual authentication between the Order Processing microservice and the Inventory microservice. In most cases, TLS mutual authentication is used to enable server-to-server authentication, while JWT is used to pass the user context between microservices.

One primary requirement to enable mutual authentication is that each service should have its own key store (keystore.jks) and a trust store (trust-store.jks). Even though both are key stores, we use the term key store specifically to highlight the key store that stores the server’s private/public key pair, while the trust store carries the public certificates of the trusted servers and clients. For example, when the Order Processing microservice talks to the Inventory microservice, which is secured with TLS mutual authentication, the public certificate of the certificate authority that signs the Order Processing microservice’s public key must be in the trust store (sample03/trust-store.jks) of the Inventory microservice.

Since we use self-signed certificates here, we have no certificate authority, hence we include the public certificate itself. The Order Processing microservice, which acts as the TLS mutual authentication client, uses its keys from the key store (sample02/keystore.jks) during the TLS handshake for authentication. It also has to store the public certificate of the certificate authority that signs the Inventory microservice’s public key, in its trust store (sample02/trust-store.jks). Once again, since we do not have a certificate authority, we store the public certificate itself. Figure 12-3 illustrates what we discussed here.

Once we have the javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword system properties set, the client automatically picks the corresponding key pair to respond to the server’s challenge to request the client certificate, during the TLS handshake.