What is the best practice when it comes to AWS API Gateway Authorization via tokens? I've been receiving mixed messages from AWS in terms of which token to use for API Gateways. Traditionally, the Access Token is meant for API Authorization via scopes and claims on the token.
However, AWS Cognito allows little flexibility with Access Token claims. This example on AWS: https://aws.amazon.com/blogs/security/use-amazon-cognito-to-add-claims-to-an-identity-token-for-fine-grained-authorization/ even goes so far as to use the Id Token for its Authorization. Since you can add/remove claims from the Id Token using the Pregen lambda but you can't with the Access Token.
Am I better off trying to get the Access Token to work in a more creative way for specific users than with claims? Can using the Id Token like an Access Token to my APIs cause any issues in the future?
Using access tokens in APIs is the standard. ID tokens do not contain scopes and do not have the correct lifetime and renewal behavior.
One of the good things about Cognito access tokens is that they do not reveal sensitive token data to internet (web and mobile) clients. This makes them a little similar to reference format access tokens.
You do not have to do JWT authorization in the gateway. In fact an emerging zero trust security model is for each API to verify the JWT itself, to prevent potential threats inside the network.
One option to extend access token claims is to validate the JWT in the API, then look up custom claims (eg from your business data), then add them to a Claims Principal used by your API's logic.
This pattern is followed in this code of mine, which uses Cognito access tokens. This adds a little complexity, but results in portable API code.
For simpler use cases, using the ID token in APIs may be sufficient and more convenient, as long as you understand the limitations.