Best practice for id_token vs. access_token use in AWS Lambda

1
votes

Consider a restapi backend consisting of AWS-ApiGateway and -Lambda.

After successful oauth2 authentication, AWS Cognito returns both an access_token and an id_token to the client in the code authorization grant flow.

During api calls, the lambda function needs to know the email address of the authenticated client, so I basically have 2 choices:

  1. Send the id_token in the Authorization header which is validated by the ApiGateway and passed to the Lambda. Let Lambda decrypt the id_token and access the email address contained in it.
  2. Send the access_token in the Authorization header which is validated by the ApiGateway with scope=openid email and passed to the Lambda. Let Lambda make a GET call to the /oauth2/userinfo endpoint with the access_token in the Authorization header to obtain email address.

Which of both is best practice? Why?

1
amazon-web-servicesapiauthenticationoauth-2.0openid

1 Answers

4
votes

Good question:

  • Access tokens are designed to be short lived API credentials, containing scopes / claims etc
  • Id tokens have a different role, to provide proof of authentication to a client, as in my blog post

However, if you are using AWS Cognito then there is a vendor limitation that access tokens cannot be customised - eg to include email address.

So it can be common for an API or a Gateway to do more work when a token is first received - eg to look up user info or claims from other sources - then cache them for subsequent requests with the same access token.

That is, option 2 is preferred, rather than using an id token in an unnatural way.

For further info on this design pattern see:

Not sure if you're looking into API Gateway custom authorizers, but if so my blog has some stuff on this here