Рабочий процесс для обслуживания с AWS Cognito и AWS Lambda

Question

Я довольно новичок в AWS Cognito и AWS Lambda.До сих пор я играл с Serverless и развернул свой REST API через AWS Lambda.Однако я хотел бы сделать свой API доступным для нескольких внешних сторон.Так как это сервис для сервиса, нет конечного пользователя, напрямую вызывающего мой API.Я делаю API доступным для других предприятий, которые используют его в своих приложениях.Все функции, предоставляемые через API, довольно просты, то есть они не вызывают никаких других сервисов AWS, таких как Dynamo DB и т. Д.

У меня есть несколько вопросов, некоторые из них довольно высокого уровня, другие довольно специфичны для настройкиAWS Cognito.Я решил поместить все в один пост, так как это делает его более самостоятельным и понятным.

1.Вопрос, ключ Cognito против API: В чем преимущество использования AWS Cognito против AWS Lambda в сочетании с ограничением доступа через ключ API и белый список IP-адресов?Один из них намного безопаснее другого?

Предположим, я хочу использовать AWS Cognito.Поскольку это случай обслуживания для обслуживания, я прочитал, что стандартом является использование конечных точек токена, где grant_type равно client_credential.Я нашел следующее на medium .Первые несколько шагов состоят из

1. Создание пула пользователей в AWS Cognito.
2. Создание клиента приложения
3. Добавление серверов ресурсов
4. Включениеclient credentials Флажок для Allower OAuth flows

2.Вопрос, клиент приложения: В добавленном клиенте приложения я нахожу соответствующие App client id и App client secret.Если я предоставляю свой API нескольким сторонам, нужно ли добавлять для каждой стороны еще один клиент приложения?В противном случае они используют все те же учетные данные.Это правильный способ сделать это?

3.Вопрос, Ресурс Сервер: Здесь я полностью застрял.Что именно означает для этого?В конце концов, все, что я хочу, - это чтобы мои клиенты могли отправлять запросы к моему API, и доступ предоставляется через Cognito.Некоторые пояснения, для чего это нужно и как это применимо в моем случае, будут оценены.Более чем рады поделиться с вами другими идеями, если это необходимо.

Следующая часть - настройка Cognito Authorizer для шлюза API.Это должно быть хорошо.

4.Вопрос, рабочий процесс клиента Относительно рабочего процесса моего клиента.Правильно ли я считаю, что это состоит из следующих шагов:

1. Сначала я предоставляю клиенту его client_id и client_secret.

затем клиент реализует на своей стороне следующий рабочий процесс:

1. Всякий раз, когда он хочет использовать мой API, предоставляемый через API-шлюз, он сначала использует предоставленный им client_id иclient_secret для получения своего токена-носителя.
2. Он использует этот токен-носитель для выполнения запроса к API-шлюзу с токеном-носителем в заголовке Authorization.
3. Если доступ предоставлен, клиент извлекает выходные данные моего API.

Это правильно или я что-то упустил?

Answer 1

1-вопрос, ключ Cognito против API

Ну, как вы можете видеть здесь .

Amazon Cognitoпользовательские пулы позволяют создавать настраиваемые решения для проверки подлинности и авторизации для ваших REST API.

планы использования позволяют предоставлять ключи API своим клиентам, а затем отслеживать и ограничивать использование вашего APIэтапы и методы для каждого ключа API

Таким образом, цель различна, ключ API используется в основном для подсчета использования клиента, в то время как AWS Cognito существует для аутентификации / авторизации вызовов вашего API.

Допустим, у вас есть требование, чтобы пользователь трассы не мог вызывать ваш API более 100 раз.

Затем, используя AWS Cognito, вы разрешите пользователю зарегистрироваться, также вы предоставите тому же пользователю ключ API, вы будете определять источник вызовов с помощью Cognito, и с каждым вызовом API-шлюз будет уменьшатьсяпредел, назначенный API-ключу пользователя на 1.

. У вас будут следующие случаи:

1. Когда токен (полученный при входе в систему с использованием имени пользователя и пароля) и API-ключ действительны, тогда вызов будет успешным.
2. Если токен неверен / отсутствует, ваш вызывающий абонент получит код состояния 401.
3. Если ключ API неверен / отсутствует, ваш вызывающий абонент получит код состояния 403.
4. Если ключ API введен правильно, но лимит превышен, вызывающий абонент получит код состояния 429.

2.Вопрос, клиент приложения:

Ну, идентификатор клиента и секреты клиента предназначены для идентификации доверенного клиента (приложения), а не пользователя, и каждое приложение должно иметь свой собственный идентификатор клиента, поэтому, если вызывающийприложение не пользователь, так что да, создайте идентификатор клиента для каждого отдельного приложения.Помните, что секреты клиента должны храниться в тайне, поэтому, если приложение вызывающего абонента не может этого достичь, например одностраничные приложения Javascript или собственные приложения, секрет не должен выдаваться.

3.Вопрос, Сервер ресурсов:

Это ваш сервер API.

Проверьте эту страницу .

Сервер ресурсов являетсяТермин OAuth 2.0 для вашего сервера API.Сервер ресурсов обрабатывает аутентифицированные запросы после того, как приложение получило токен доступа.

Крупномасштабные развертывания могут иметь более одного сервера ресурсов.Сервисы Google, например, имеют десятки серверов ресурсов, таких как платформа Google Cloud, Google Maps, Google Drive, Youtube, Google+ и многие другие.Каждый из этих серверов ресурсов имеет свои особенности, но все они используют один и тот же сервер авторизации.

4.Вопрос, рабочий процесс клиента

Проверка предоставления учетных данных клиента в здесь

Шаги для процесса следующие:

An app makes a POST request to https://AUTH_DOMAIN/oauth2/token, and specifies the following parameters:
    grant_type – Set to “client_credentials” for this grant type.
    client_id – The ID for the desired user pool app client.
    scope – A space-separated list of scopes to request for the generated access token.

In order to indicate that the app is authorized to make the request, the Authorization header for this request is set as “Basic

BASE64 (CLIENT_ID: CLIENT_SECRET) «, где BASE64 (CLIENT_ID: CLIENT_SECRET) является представлением base64 идентификатора клиента приложения и секрета клиента приложения, соединенных двоеточием.Сервер авторизации Amazon Cognito возвращает объект JSON со следующими ключами: access_token - действительный токен доступа пула пользователей.expires_in - промежуток времени (в секундах), в течение которого указан токен доступа.token_type - устанавливается на «Носитель».

Note that, for this grant type, an ID token and a refresh token aren’t returned.
The app uses the access token to make requests to an associated resource server.
The resource server validates the received token and, if everything checks out, executes the request from the app.