Controlling access to APIs
Best practices to control access to your APIs
Published Nov 22, 2024
One of the most important aspects of application security around API Gateway is Controlling access to APIs.
Before going deeper, We must understand that the very first step to preventing undesirable access is implementing Amazon Cognito or another third-party provider for authentication in front of your APIs. More, you must secure your APIs to keep away unauthorized users from interacting with them.
Also, AWS IAM plays a vital role in controlling access and authorization among your services. IAM provides you with robust control of who can be authenticated (logged in) and authorized (have permissions) to use Amazon API Gateway resources. API Gateway integrates with IAM for a number of purposes.
Now let's discuss about the types of authorizers API Gateway offers.
There are three types of API Gateway authorizers : JSON Web Token or JWT authorizers, Lambda authorizers and IAM based authorization to users.
With JWT, developers pass the ID and access tokens to third party Identity Providers to secure JWT, which is in turn used to authorize access to application resources. Those tokens live for a relatively short period of time. The client must save the refresh token (which can live for up to 1 year) to silently refresh the ID and access tokens behind the scenes. These tokens simplify identity for developers and allow them to pass user context to downstream services in a lightweight manner. This makes it easy for developers to get this user context.
When you use an Amazon Cognito user pool directory as your IdP, AWS hosts the entire experience. If you set up Amazon Cognito user pools to federate with a third-party IdP, Amazon Cognito user pools is trusting those identities and redirecting them as if the users were in its directory.
Let's decrypt the following diagram to understand how the mechanism works.
This depicts an authorization flow for an HTTP API that uses JWT authorizer user pools:
1. The client first authenticates with the IdP.
2. The clients gets the JWTs in return.
3. The client then passes the ID and access token in the header as part of the call to API Gateway.
4. API Gateway validates the token.
5. API Gateway invokes the resource with which it integrates on the backend (in this example, a Lambda function).
6. Lambda accesses other resources within AWS.
2. The clients gets the JWTs in return.
3. The client then passes the ID and access token in the header as part of the call to API Gateway.
4. API Gateway validates the token.
5. API Gateway invokes the resource with which it integrates on the backend (in this example, a Lambda function).
6. Lambda accesses other resources within AWS.
When you use a Lambda authorizer, your client authenticates with a third-party IdP and gets custom tokens back. Lambda authorizers are available for both REST and HTTP APIs.
HTTP APIs can use a simplified authorizer payload format as compared to the version that is required for REST APIs.
The following diagram highlights perfectly the mechanism :
1. As with the previous example, the token information is passed in the header to API Gateway.
2. Your client authenticates with a third-party IdP.
3. The client gets custom tokens back.
4. API Gateway checks its policy cache to see if this requestor has already been recently authorized. If it has, API Gateway can skip the steps of validating the token and returning the IAM policy.
5. If the requestor’s policy is not cached, API Gateway invokes the Lambda authorizer function.
6. The function includes the code to emit the IAM policy and return it to API Gateway.
7. API Gateway uses the IAM policy (whether cached or newly generated) to validate the permissions for the requestor.
8. API Gateway invokes the resource with which it integrates on the backend (in this example, a Lambda function).
9. Lambda accesses other resources within AWS.
2. Your client authenticates with a third-party IdP.
3. The client gets custom tokens back.
4. API Gateway checks its policy cache to see if this requestor has already been recently authorized. If it has, API Gateway can skip the steps of validating the token and returning the IAM policy.
5. If the requestor’s policy is not cached, API Gateway invokes the Lambda authorizer function.
6. The function includes the code to emit the IAM policy and return it to API Gateway.
7. API Gateway uses the IAM policy (whether cached or newly generated) to validate the permissions for the requestor.
8. API Gateway invokes the resource with which it integrates on the backend (in this example, a Lambda function).
9. Lambda accesses other resources within AWS.
With IAM based authorization, you can enable your service to authorize requests in the same manner that all AWS APIs do, which is to validate a unique canonical request signature that the API client generates and sends with each request. The signature is uniquely generated and incorporates the time of request, resource requested, and action so that even if the signature were compromised and re-used later on, the request signature would no longer be valid at a later time.
This is the most secure authorizer option but requires that the API clients have intelligence on how to sign their requests. For API access between systems running in AWS, use IAM. IAM is great for system-to-system authorization for services running in AWS because it is the most secure.
Here is an example of IAM based authorization :
With IAM based authorization:
1. The requestor must have IAM credentials.
2. Key information is added to the authorization header.
3. API Gateway determines whether or not the IAM user or role has permissions to invoke the API.
2. Key information is added to the authorization header.
3. API Gateway determines whether or not the IAM user or role has permissions to invoke the API.
Additionally, You can use IAM based authorization at the API level for REST APIs using a resource policy on the API. You can also use IAM based authorization at the method or route level on your REST and HTTP APIs.