I had posted an article on two tier authentication earlier. Please read the post below for details
https://vamsitokala.blogspot.com/2023/09/two-tier-authentication-in.html
I am adding some more insights on the Authentication process in microservices architecture
1.
Angular Client (User) to Microservice
Communication
For client-to-microservice interactions where the client is
a angular web application with FAMS as IDP
·
Client Authenticates Directly with FAMS:
o
Angular UI initiates the authentication process
with FAMS, This involves redirecting the
user to login page of IDP(intranet)
o
Upon Authentication, IDP issues an ID token,
Access Token, Refresh token
·
Sending Requests to Microservices:
o
Client Sends Request with Access Token: When
making requests to the microservices, the client includes this token in the
Authorization header.
o
These requests are directed towards the API
gateway ( Ocelot), which acts as the entry point to the microservices
architecture.
·
API Gateway Validates Token:
o
The API gateway (Ocelot) intercepts the incoming
request, validates the token (ensures it's valid, checks expiration, and
verifies it against IDP JWKS endpoint), and if valid, forwards the request to
the appropriate microservice.
o
Microservices themselves might not need to
validate the token again and they trust the API gateway's authentication
process.
·
Cache
o
Caching Public Keys: Cache FAMS’s JWKS end point
at the api gateway to minimize network calls for key retrieval during token
validation.
2.
Microservice to Microservice
(Service-to-Service) Communication
For microservice-to-microservice communication that requires
server-to-server authentication without user context:
·
Microservices Act as Clients to Cognito:
o
In this scenario, microservices acts as a
"client" and uses the Client Credentials OAuth flow to authenticate
with AWS Cognito and obtain an access token.
·
Obtaining a Token Before Reaching the API
Gateway
o
A
microservice that needs to make a request to another microservice through the
API gateway first obtains a token from Cognito using its own credentials
(client ID and secret).
·
Include the Token in API Calls:
o
This service then makes the API call through the
API gateway, including the access token in the Authorization header.
·
API Gateway Validates the Token:
o
As with user-initiated requests, the API gateway
validates the token before routing the request to the target microservice.
3.
Implementation Considerations
By centralizing authentication
logic at the API gateway level, you can streamline security management and
ensure consistent authentication across all services.
·
Secure Storage of Credentials
o
Services using the Client Credentials flow must
securely store their AWS Cognito credentials (client ID and secret) in AWS
secret manager.
·
Configuration in AWS Cognito
o
Create a User Pool - All Microservices are part
of single eLIMS system sharing the same user base, A single user pool might be
sufficient.
o
Configure each Microservice as an App Client in Cognito
user pool
§
Enable OAUTH flow for each client for M2M
·
Token Validation
o
IDP (intranet) Token Validation
§
Validate token signature against JWKS endpoint
for FAMS
·
Check
·
Token Expiration
·
Issuer (ISS)
·
Audience (aud)
o
Audience should match app client id
o
Cognito Token Validation
§
By setting AWSCognito:Authority, it
automatically retrieves JWKS from AWS cognito and validates it implicitly
§
we want to disable audience validation. For
example, if we have a microservices architecture where multiple APIs are using
the same JWT for authentication, wemight set ValidateAudience to false to
allow any of the APIs to accept the token.
§
In general, it’s recommended to keep
ValidateAudience set to true to ensure the token is intended for the correct
recipient. But the final decision depends on specific use case and security
requirements.
