Какова логика проверки сущности пользователя с помощью Microsft Graph / Azure AD в качестве аутентификатора моего API?

Question

Я уже выполнил процедуру аутентификации с помощью Microsoft Graph / Azure AD. Как только я получаю токен аутентифицированного пользователя, я сохраняю его в его куки. Чтобы проверить токен пользователя, я вызываю ресурс API Microsft Graph /me. Это не кажется хорошим подходом, потому что в основном каждый раз, когда клиент делает запрос к моему API, он в основном делает 2 запроса, потому что мой API запрашивает Azure AD для проверки.

Это хороший поток?

Answer 1

Вам не нужно проверять токены для API, который не принадлежит вам (выдан для вашего AppId Uri).

Например, Graph проверяет отправленные ему токены (выдается для «https://graph.microsoft.com).

»

Если вы создаете и регистрируете в Azure AD свой собственный API (скажем, AppIdUri = "https://myapi.mydomain.com"),, ваши клиенты будут запрашивать и получать токены доступа с утверждением aud, установленным на" https://myapi.mydomain.com".

Самим клиентам не нужно проверять токен доступа, выданный для вашего API, но ваш Api, когда он получает эти токены доступа, должен их проверить. Проверки, помимо прочего, подтвердят, что токен доступа был выдан "https://myapi.mydomain.com".

Попробуйте этот пример , чтобы лучше понять концепции проверки токенов.

Answer 2

Нет, это не так. Ваш клиент должен получить токен доступа для вашего API, который API может проверить с помощью своей цифровой подписи. Маркер будет содержать некоторую информацию о пользователе, а также о приложении, которое его приобрело.

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

Пока ваш сервер настроен со стандартной аутентификацией JWT Bearer, все обработано. Это можно сделать, указав полномочия в качестве своего клиента Azure AD (или общей конечной точки, если она мультитенантна), и стандартные биты для аутентификации JWT должны загружать открытые ключи из конечной точки метаданных Azure AD, которые затем можно использовать для проверки действительности любого полученного маркера доступа.