Я пытаюсь понять использование токенов доступа для авторизации API, обслуживаемого API Gateway.
Мое текущее понимание этого процесса следующее:
- После настройки пул пользователей Cognito, я могу определить сервер ресурсов и связанные области (например,
https://wibble-api.com/read, https://wibble-api.com/full). - Затем я могу выбрать разрешенные настраиваемые области для клиента приложения пула пользователей.
- В AWS Шлюз, я могу создать Cognito Authorizer для авторизации входящих запросов.
- Для каждого AWS ресурса шлюза я могу go в запрос метода и выбрать Cognito Authorizer и определить, какие области OAuth необходимо для выполнения метода API, например, я могу ввести
https://wibble-api.com/read, https://wibble-api.com/full, чтобы указать, что либо из этих двух областей достаточно для выполнения ресурса API. - Когда при использовании размещенного пользовательского интерфейса параметр
scope будет включать все разрешенные области, настроенные для этого клиента приложения, и возвращенный токен доступа (при использовании неявного gr ant) будет содержать эти области как часть JWT.
Чего я не понимаю, так это то, что у меня должен быть очень распространенный сценарий, в котором я хочу иметь возможность предоставлять доступ только для чтения например, для пользователя, который не заплатил за услугу, и для пользователя, который заплатил. Тем не менее, похоже, что мне понадобятся два отдельных клиента приложений, если я собираюсь использовать размещенный пользовательский интерфейс, потому что, похоже, нет способа вернуть разные области в зависимости, скажем, от того, в какой группе был пользователь. назначены или некоторые другие метаданные в профиле пользователя, например отдел и т. д. c. Я не буду знать, что это за пользователь, пока не будет аутентифицирован, но мне все равно нужно ввести точный scope при аутентификации. Есть ли решение для этого, пожалуйста?