Securing Your Microservices: A Comprehensive Guide
System Design Refresher
There are new considerations for managing authentication and authorization in microservice environments. With a monolithic application, it is common to have fine grained roles, or at least role associated groups in a central user repository. With the emphasis on independent lifecycles for microservices, however, this dependency is an anti-pattern. Development of an independent microservice is then constrained by and coupled with updates to the centralized resource.
It is common to have authentication (establishing the user’s identity) performed by a dedicated, centralized service or even an API gateway. This central service can then further delegate user authentication to a third party.
When working with authorization (establishing a user’s authority or permission to access a secured resource), in a microservices environment keep group or role definitions coarse grained in common, cross cutting services. Allow individual services to maintain their own fine grained controls. The guiding principle again is independence. A balance must be found between what can be defined in common authorization service to meet requirements for the application as a whole, and what authorization requirements are implementation details for a particular service.
OAuth 2.0
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.
The service interaction goes through these steps:
The front end (web client or mobile application) makes a request to the Auth service on behalf of the user.
The Auth service returns a forwarding response that is automatically handled by the browser to forward the user to the selected OAuth provider with the application identifier.
After the user has authenticated and granted permission, the OAuth provider returns an authorization code in another redirect response. The browser automatically handles the redirect to invoke a callback on the Auth service with the authorization code.
The Auth service then contacts the OAuth provider to exchange the authorization code for an access token.
The Auth service then converts data from that token into a Signed JSON Web Tokens (JWTs), which allows you to verify the identity of the user over subsequent inter-service calls without going back to the OAuth provider.
Spring Boot and OAuth2 Implementation
JWT
JWTs are designed for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed.
Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.
Structure : A JWT is composed of three parts separated by dots (`.`):
Header
The header typically consists of two parts: the type of the token, which is JWT, and the signing algorithm being used, such as HMAC SHA256 or RSA.
For example:
{ "alg": "HS256", "typ": "JWT" }
Payload
The second part of the token is the payload, which contains the claims. Claims are statements about an entity (typically, the user) and additional data. There are three types of claims: registered, public, and private claims.
Registered claims: These are a set of predefined claims which are not mandatory but recommended, to provide a set of useful, interoperable claims. Some of them are: iss (issuer), exp (expiration time), sub (subject), aud (audience).
Public claims: These can be defined at will by those using JWTs. But to avoid collisions they should be defined in the IANA JSON Web Token Registry or be defined as a URI that contains a collision resistant namespace.
Private claims: These are the custom claims created to share information between parties that agree on using them and are neither registered or public claims.
Example Paylod :
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}Signature:
To create the signature part you have to take the encoded header, the encoded payload, a secret, the algorithm specified in the header, and sign that.
For example if you want to use the HMAC SHA256 algorithm, the signature will be created in the following way:
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)Limited Offer , Grab before its expire :
Complete JWT Example
A complete JWT looks like this:
