If you haven’t read our first article about severless computing with Amazon API Gateway, you can read it here.

AWS API Gateway is a fully managed service that allows developers to create, publish, maintain, monitor, and secure APIs (Application Programming Interface) for their applications at any scale.

While initial setup of an API is quick and easy with Amazon API Gateway, it is important to protect and secure access to the services and data provided, so that no unauthorized access is possible.

One of the key features of API Gateways is the ability to protect your API with authorization and usage plans to ensure only authorized users can access your API and it is not overloaded with excessive traffic. This article explains the different authorization and usage plan options in Amazon API Gateway and how to configure them.

Authorization is an optional feature of API Gateways. You can choose to skip authorization entirely in your API or handle it in your integration backend.

If you decide to use authorization, there are good reasons (good reasons) to integrate it with API Gateway:

If authorization is desired in your API, integrating it with API Gateway can be a good choice for several reasons:

  • It consolidates your authentication logic into a single place
  • It protects your downstream integration from unauthorized requests, saving you costs and/or freeing up your resources
  • It can be cached, reducing the number of times your authentication service is accessed

Within this authorization step there are two options – authorization check and check against API key.

Authorization with custom authorizers, Cognito or IAM

The most common form of authorization is an actual authorization check. The request information can be examined to identify the caller of an API – either based on an HTTP header or a query string – and either allow or deny the request, depending on whether the caller has permission to call the API. There are three main ways to configure an authorization check in API Gateway:

Using IAM permissions over signed HTTP requests:

This method allows you to use AWS IAM policies to authorize API requests. This requires you to sign the HTTP requests with your AWS access key and secret key. This can be done using the AWS Signature Version 4 signing process.

Using tokens from a Cognito user pool:

If you use Cognito user pools for your authentication needs, you can use tokens from the user pool to authorize API requests. This method requires you to configure the required scopes needed for a specific API endpoint.

Creating your own custom logic in a custom Lambda authorizer:

If you need fine-grained authorization, you can write your own custom logic in a Lambda function and use that as custom authorization for your API gateway. Custom approvers give you complete control over the authorization process and can run any logic you need to authenticate and authorize the user. You can also include additional context in the request based on the user’s identity.

For a user-side API, the last two options are the most commonly used.

If you’re already using Cognito User Pools for your authentication needs, integrating with API Gateway can be an easy and convenient option. You can configure the required scopes for a specific API endpoint without writing your own logic.

On the other hand, if you are not using Cognito user pools or require more granular authorization controls, you can use custom Lambda authorizers. With custom authorizers, you have full flexibility to implement any authentication and authorization logic you want. You can also add additional context to the request based on the identity of the caller.

Source: Sample architecture diagram for adding authentication (AWS Cognito) and authorization (AWS Lambda Custom Authorizer) services to AWS API Gateway. For a detailed example of setting up an API Gateway authorizer, see this article from AWS: Building fine-grained authorization using Amazon Cognito, API Gateway, and IAM.

API Keys and Usage Plans

API key verification is part of the authorization process in API Gateways. You can configure the service to require API keys to be passed with each request. These keys are stored in x-api-key-Header passed, and requests without them will be rejected. Although API keys are often involved in the authorization process, they should not be considered the primary authorization method. They are not a precise method of identifying and authorizing users.

API keys are most commonly used for rate limiting and throttling users. AWS offers usage plans that allow you to associate API keys with specific limits. These plans can be configured with throttling limits (the number of requests allowed per second) and quota limits (the maximum number of requests over a given period of time).

Throttling limits can prevent a caller from overloading your downstream resources, while quota limits can be used to enforce limits on paid APIs or specific clients. Quota limits allow you to set a maximum number of requests over a certain period of time, e.g. B. set a day, a week or a month. This allows you to enforce restrictions for a specific customer. This is especially handy if you offer a paid API where a user gets a certain number of calls per month.

By default, usage plans are capped at 300 per account per region, but you can request an increase if needed.

Summary

Overall, API gateways offer a range of options to protect your API with authorization and usage plans. While it’s not necessary to tie authorization into your API, implementing authorization in API Gateway can provide protection and save money and resources for your downstream integrations. There are three options for authorizing requests: Cognito User Pools, AWS IAM, or a custom Lambda authorizer. API keys can also be used to throttle requests from specific users. The authorization check is performed before the API key check. You have the option to use one, both, or neither of these checks in your API.

Source: https://www.protos-technologie.de/2023/01/17/sichern-sie-ihre-api-mit-autorisierung-und-nutzungsplaenen-in-aws-api-gateway-2/

Leave a Reply

Your email address will not be published. Required fields are marked *