Azure AD Oauth2 неявное предоставление нескольких областей - PullRequest
Новая
       136

Azure AD Oauth2 неявное предоставление нескольких областей

0 голосов
/ 27 января 2020

У меня есть несколько приложений angularJS, которые обращаются к множеству nodeJS размещенных API. и я хотел бы заменить специальную авторизационную структуру на неявное предоставление Azure AD (длинный рассказ о том, как я туда попал).

В настоящее время выполняется PO C (на основе пример Microsoft ) и столкнулись с проблемой получения одного токена доступа для использования с числом API

. Пользовательский интерфейс и API были зарегистрированы в AZURE приложении AD. Также настроили несколько разрешений, чтобы им было разрешено вызывать API, например https://graph.windows.net/User.Read api://xxx-xxx-xxxx-xx-xxxx/sales.admin

Затем я определяю в клиенте 

var requestObj = {
    scopes: ["https://graph.windows.net/User.Read", "api://xxx-xxx-xxxx-xx-xxxx/sales.admin" ]
};

Так наивно я думал, что буду возможность получить токен доступа, который я могу использовать против нескольких API

Однако, похоже, что это не так. Клиентское приложение должно создавать отдельные маркеры доступа для каждого API, к которому приложение должно получить доступ.

Это правильно? Это значительно усложняет работу клиента, поскольку ему необходимо поддерживать и обновлять sh этих токенов.

Я что-то упускаю из-за «архитектуры», например, уровня управления API?

Спасибо

Ник

1 Ответ

0 голосов
/ 27 января 2020

Это правильно. Токен доступа работает только для одного API.

Причина заключается в том, что каждый токен указывает свою действительную «аудиторию» (хранится в утверждении aud). Это идентифицирует целевую цель (API) токена.

Кроме того, MS Graph API использует совершенно другой алгоритм подписи, чем другие API, и поэтому в любом случае не сможет даже находиться в одном и том же токене.

API могут устанавливать различные настройки в своих манифестах, которые по-разному влияют на токены. Это также делает совершенно невозможным иметь один токен, который будет работать на всех API.

Если вы используете sh, вы можете упростить его для своего клиента, создав «шлюз API», который проксирует вызовы правильные API с правильными токенами. Этот шлюз будет обрабатывать сложность токенов, а не клиента, что будет необходимо только для аутентификации на шлюзе. Изучите поток предоставления от имени, чтобы увидеть, как шлюз может вызывать API-интерфейсы как зарегистрированный пользователь.

...