Best practice for id_token vs. access_token use in AWS Lambda

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 two 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?

Good question:

• Access tokens are designed to be short lived API credentials, containing scopes / claims etc, to set boundaries on where a token can be used and what resources it can access.
• ID tokens have a different role, to provide proof of the authentication event to a client, and how / when it occurred.

However, with some authorization servers you may run into vendor limitations where you cannot issue the claims you want to access tokens.

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 my authorization blog post.