REST service Mutual SSL aauthentication

Migrating applications to micro-services means having a couple of applications that need to talk to each other. We need an architecture to allow to add security at method level and to keep our data safe from inside attacks. Much of what will be said here can be applied to non spring based micro-services.

Oauth2, our best friend

This is an authorization problem that can be solved with oauth2. Oauth2 is widely used as a mechanism to give web applications developers access to users data at Google/Facebook/GitHub directly from the foreign services in a secure way.

What is Aouth2 
Oauth2 provides also a very elegant solution. The core components of oauth2 cooperates but they are loosely coupled to each other. In fact, they have no knowledge of each other. Once the system is in place, resource server modules that needs security can have almost  security for free.

• Resource Owner - our users
• Resource Server - This is any of module based spring boot that contains data of our users
• Authorization Server - This is essentially the token endpoint. It could also any existing compliant oauth2 server or simply a spring based oauth2. It allows user to manage tokens that give access to resource servers. This is the central point for authorization where users give access to their resources and resource server validate theses tokens to build their security context
• Client - This is any of module based spring boot that manage  data on the behalf of our users. Mobile apps, web apps, any program etc

How it works ? 

The user authenticates on a authorization service, which maps the user session to a token. The authentication is outside the scope of oauth2. Any further API call to the resource services must provide this token. The services are able to recognize the provided token and ask the authorization service, which authorities this token grants, and who is the owner of this resource.  

It is important to highlight that Oauth2 is not an authentication server and acts only as an authorization server by enforcing who can access to what. For that, it reuses the user identity obtained via authentication process as well as the application (client_id) who are consuming the resources on behalf the of user. 

With OAuth2 you can define, which application (web, mobile, desktop, additional website) can access which resources on the top of the user identity which tell us which user can access which data. 

JWT

Oauth2 doesn't solve all of our problems. OAuth2 as a protocol does not tell us how the token is looking like and where it is stored. Also, for each request against a resource micro service containing a token in the header, the service will perform another request to authorization server to check the token. That's not good enough.

To solve these two problems, we can use JWT or  JSON Web Token.  This token contains info about the OAuth client, optionally the user with its authorities and the granted scope that is serialized into JSON first, encoded with base64 and finally signed using cryptographic key. The result is called JSON Webtoken, which we use as an access token directly. This json token may be sign with public key, symmetric key or a shared key.

When this token is passed via HTTP header, the resource servers just have to take this JWT, verify it was really properly signed (meaning this token is coming from the authorization server), and instead of asking user info, deserializing the JSON content into a OAuth2Authentication, establishing a SecurityContext based on this.

Using JWT provides a simple way of transmitting tokens, containing the permissions and user data in the access token string. Since all the data is already inside, there neither is a need to maintain a token store, nor the resource servers must ask authorization for token checks. The security of the token is based on the underlying cryptographic primitive used to secured the tokens. So, using JWT makes OAuth2 available to micro services, without affecting the architectures scalability.

Work on progress.....