Защита общих API с помощью Azure AD

Question

Я работаю с клиентом, чтобы определить стратегию безопасности, и застрял, пытаясь заставить что-то работать.Я новичок в Azure AD, поэтому на самом деле это может быть невозможно.

Рассмотрим следующий ландшафт приложения.У меня есть 4 приложения «API»:

• API-A, требуются интерактивные разрешения для пользователей и ролей
• API-B, доступ через службу демона, клиентское_креденционное предоставление
• API-C, не должен проходить проверку подлинности непосредственно
• API-D, доступ через службу демона, клиентское разрешение_credential

Пользователь / демон прошел проверку подлинности на основе API-A или API-Bдолжен иметь возможность доступа к API-C.Однако демон, прошедший аутентификацию по API-D, должен не иметь возможность доступа к API-C.

Я ожидал, что смогу использовать «Выставлять API» и «Разрешения API» изрегистрации приложений, чтобы иметь возможность контролировать «роли», возвращаемые в JWT, я не могу заставить его работать или найти какое-либо достойное руководство о том, как этого можно достичь.

РЕДАКТИРОВАТЬ: для ясности приложений APIне размещаются в Azure, я просто использую Azure AD для проверки подлинности

Answer 1

Может быть полезно различать клиентские приложения и приложения API (или серверы ресурсов на языке OAuth2). Каждый из них должен быть зарегистрирован отдельно. Ваш список выше, кажется, объединяет их, что может быть источником путаницы для вас.

Первые (клиентские приложения) получают токены, вторые получают их от клиентов с запросом на обслуживание. Аутентификация применяется только тогда, когда клиентские приложения получают токены. API не аутентифицируются - они используют токены для авторизации доступа к своим сервисам. Клиенты приобретают токены либо от имени пользователя - и пользователь аутентифицируется и соглашается в рамках процесса или от своего имени (кредиты клиентов). В AAD приложение API может предоставлять / определять области / разрешения, которые могут быть включены в один или оба из этих типов токенов. API может решить не требовать никаких токенов (звучит как ваш API-C). Вы Предоставляете (доступно) Разрешения для приложений API, вы указываете (обязательно) API Разрешения для клиентских приложений. Во время выполнения (если используется конечная точка AAD V2) клиент может запросить меньше областей, чем он настроен как обязательный. Это применимо, только если клиент использует делегированные токены (основанные на пользователях). (Обратите внимание, что приложение API также может быть клиентским приложением для другого приложения API (обычно в многоуровневых системах).

Кстати, где развернуты клиенты или API, это абсолютно несущественно для вышеперечисленного. В большинстве случаев развертывание влияет на значение URL-адреса ответа, которое необходимо указать для некоторых клиентских приложений (не API).