Authentication in microservice
Created on: Oct 19, 2024
The new modern norm is to use microservice, but it comes with many challenges. One of the challenges is to authentication and authorization.
Let's understand with a example how we can solve this in a e-commerce platform. Let's say that we have product service, order service and payment service. Let's see how we authentication and authorization works here.
-
A rest api request will will come to api gateway.
-
Api gateway forwards the request to Authentication service.
-
Authentication servicer redirect user to Keyclock(IDP) authorization endpoint. (OpenID Connect (OIDC) protocol)
-
User enters their credential like username and password. Credential can be other multi-factor authentication )
-
After successful login, Keyclock redirects the user back to authentication service with an authorization code.
-
Authentication service makes a post request to Keyclock(IDP) Token endpoint and fetches three tokens a. ID Token b. Access token c. Refresh token
POST https://<keycloak-server>/auth/realms/<realm>/protocol/openid-connect/token Content-Type: application/x-www-form-urlencoded client_id=<client-id> client_secret=<client-secret> (optional if required) grant_type=authorization_code code=<authorization-code> redirect_uri=<your-service-url> -
Authentication service returns the token back to gateway and gateway attaches access token to outgoing request in the headers. This ensures providing flexibility, better separation of concern.
-
Users sends GET/Post or any other api request to gateway. Authentication can happen in two ways
a. Remote Token Validation: Gateway sends the token to Authentication service and it calls the introspect endpoint to verify the token. It token is valid, it responds with JSON payload. If invalid it responds with active as false.
POST https://<keycloak-domain>/auth/realms/<realm-name>/protocol/openid-connect/token/introspect Authorization: Basic <client_id:client_secret> Content-Type: application/x-www-form-urlencoded token=<access_token>// if validated { "active": true, "username": "john_doe", "exp": 1634962861, "client_id": "api-gateway", "scope": "openid profile email", "sub": "e72fef35-5a5c-4fae-94a3-bcc74072ac57", "realm_access": { "roles": ["user", "admin"] } } // if not validated { "active": false }b. Local Token Validation: Api Gateway extract header and payload parts of the JWT and rehashes them using same algorithm. Gateway uses public key to decrypt signature. The decrypted signature is compared with rehash value of header and payload. If it is validated, it forwards the request to corresponding service or 401 status if invalid.
Gateway can fetch the public key from IDP(keyclock) using public endpoint certs
https://keycloak-server/auth/realms/myrealm/protocol/openid-connect/certs -
Request reaches to order service service.( or any other service). Authorization can be handled at two ways.
a. At gateway b. At corresponding service.
-
Authorization at corresponding service label is often a better approach because it decouples the responsibility of handling authorization.
-
Api gateway forwards the request to corresponding service say order service. And order service fetched role and do the authorization based on business logic.
OpenID Connect Protocol
It is a identity layer built on the top of OAuth 2, providing secure authentication. It add authentication layer to oauth 2 framework, allowing application to verify thr identity of the end user.
OpenId connect provides a url where a user is authentication and upon successful authentication, the system returns a JWT(ID token), refresh token, ID token.
