2

I am working on a cloud native microservices based application deployed in AWS. This application should use a OIDC based IdP (preferably AWS Cognito). The authentication and authorization flow are as follows. Once the user logs in using authorization code flow, the IdP generates one ID token and access token. The access token is sent to the backend services for the backend calls. The backend service can fetch the user information through /userinfo endpoint if needed. Additionally, the access token has the required group claim and the scopes to determine if the right access is present. Now if the backend service needs to call downstream backend internal microservices on behalf of the logged in user, then should I create a

  1. new token with client credentials grant with a reduced scope needed for the service call? or
  2. Should I send the initial access token of the user only?

In the first case the user context is lost in the new access token and if the downstream service requires the user context, then how will the downstream service get the user information? In the second case the downstream service is not called with the exact specific scope needed for that service and is not security best practice.

However, there is also one more grant call exchange grant (https://www.rfc-editor.org/rfc/rfc8693.html) which supports creating a new access token with the user context from the initial token without relogging in the user (delegation mode in https://www.rfc-editor.org/rfc/rfc8693.html). Is it supported in AWS Cognito? If not, then how can I achieve the same functionality if I use AWS Cognito?

Arindam Ghosh
  • 98
  • 5

1 Answers1

0

It kind of depends on the level of trust between microservices. By default, if they are part of the same unit, aim for this type of setup:

  • Orders microservice, requires an orders scope
  • Shipping microservice, requires a shipping scope
  • Customer website, uses scopes orders and shipping

You can then flow the user identity securely, if Orders calls Shipping, by forwarding the access token. Meanwhile each API verifies the JWT on every request and checks for the scopes it needs.

Each API should also check for an audience claim has the expected value, representing a set of related APIs, such as api.example.com. I believe currently though, AWS Cognito does not issue an audience claim to access tokens.

If Shipping is a less trusted subdivision of your company, token exchange would be more appropriate. Eg if you have concerns about a Shipping service abusing Orders privileges.

Avoid over-reliance on scopes, or too many of then. Use claims for the main authorization. In Cognito you can look up these values after verifying the JWT but before your API creates its claims principal

Cognito only has quite limited support for more advanced token behaviour, such as issuing custom claims, reference tokens, or token sharing techniques. If you need them, the preferred option is to choose an authorization server that supports the standards.

Gary Archer
  • 22,534
  • 2
  • 12
  • 24