Как настроить поток учетных данных клиента для внешних приложений с помощью Azure Active Directory
Получили следующую ситуацию:
Внешняя сеть
- 1 какое-то приложение, которое мы не контролируем
Внутренняя сеть:
- 1 внутренний API (функция Azure)
- Активный каталог B2C
Я хочу защитить свой внутренний API в соответствии с официальной документацией Microsoft (первый пункт списка). Но для этого нам нужно будет аутентифицировать клиента с помощью Active Directory.
Поскольку клиент, вызывающий наш API, является другим приложением (не пользователем), нам нужно использовать поток учетных данных клиента в соответствии с OAuth2. Затем поставщик удостоверений должен предоставить мне токен, содержащий настраиваемую область действия (которую другая сторона может проверить).
К сожалению, после прочтения кучи документации о том, как использовать Azure AD, я не могу получить токен JWT, содержащий настраиваемую область.
Я уже пытался зарегистрировать приложение в блейде Active Directory:
На его странице настроек я попытался зарегистрировать разрешения (которые, кажется, являются областями в мире AD), но он показывает только официальный API Microsoft.
Как я могу добавить разрешения для внешнего API?
Маркер, созданный с помощью ключа приложения, также не содержит утверждения «scp» или «scope». Как я могу получить заявку на объем в токен?
Обновление 1
Я зарегистрировал приложение в AD B2C Blade для своего API (наш API):
Для клиентов я прописал приложения в AD Blade (Тестовый клиент 1 и Тестовый клиент 2):
Тестовый клиент 1 требует разрешения для моего приложения "наш API":
Тестовый клиент 2 не требует никаких разрешений:
Когда я пытаюсь войти в AD с помощью Тестовый клиент 1, я получаю access_token, как и ожидалось. Но если я попытаюсь войти в систему как Тестовый клиент 2, я также получу access_token. Не должен ли этот процесс потерпеть неудачу? Как я могу убедиться, что только Тестовый клиент 1 имеет разрешение?
Кроме того, поток предоставления учетных данных клиента не получает области. Они специфичны для потоков с участием пользователей. Вам нужно использовать разрешения приложения в вашем случае. Таким образом, API должен определить разрешения приложения в своем манифесте, а клиентское приложение должно потребовать их (и получить на них согласие).
Хорошо, кажется, что поиск API работает. Большое спасибо за совет. Я все еще застрял во всем процессе разрешений/согласия. Как внешний клиент может запрашивать разрешения приложения?
Да, проблема в том, что ваш API находится в вашем арендаторе, поэтому они не могут запрашивать разрешения на него. Возможно, вам придется сделать ваш API многопользовательским, дать им согласие на это, а затем назначить разрешения в их клиентском приложении для вызова вашего API.
Клиент не размещен на Azure. Я так понимаю, тогда это проблема? :)
Другой вариант — зарегистрировать клиентское приложение в своем клиенте. Затем передайте свои учетные данные другим разработчикам.
Я уже сделал это и соответственно обновил свой вопрос (см. Обновление 1)
Давайте продолжить обсуждение в чате.
Насколько я понимаю, ваш API будет нести ответственность за отклонение входящего вызова как несанкционированного на основе утверждений, доступных в токене доступа. Два способа 1) просто основаны на утверждениях appid и iss.. т.е. ваш собственный пользовательский ACL 2) всегда ищет определенные разрешения/роли приложения, присутствующие в токене.. Я ответил на очень похожий вопрос здесь.. stackoverflow.com/questions/55407966/…
Когда я аутентифицирую своего пользователя со следующей конечной точкой: login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token, я получаю идентификатор арендатора в качестве утверждения iss. На самом деле это не мешает другим приложениям в моем клиенте получать доступ к этому API.
Вы также должны получить утверждение appid, которое сообщает используемому приложению ... чтобы вы могли гарантировать, что только определенные приложения могут работать (это то, что я имею в виду под вашим собственным пользовательским списком контроля доступа) ... но идея по-прежнему заключается в том, что ваш API должен быть реализован эта логика для проверки требований токена доступа
Вы должны проверить, что токен содержит действительное утверждение scp или ролей (делегированное разрешение/разрешение приложения). Если вы используете учетные данные клиента, вам необходимо определить разрешение приложения и потребовать его. Делегированные разрешения не применяются без пользователя
Тот факт, что вы можете получить токен для любого API без назначенных разрешений, является менее известной «фичей». Вам необходимо проверить наличие действительных разрешений в токене. Обратите внимание, что это относится только к API.
Спасибо всем за помощь. Я не знал, что манифест приложения — единственное место для настройки разрешений приложения. Я получаю заявки на роли прямо сейчас! :)
Ответы 1
How can i verify that only TestClient 1 has the permission?
Вы можете проанализировать свои токены в jwt.io, вы можете проверить разрешения токена.
When I try to login to AD with the TestClient 1 I get an access_token as expected. But if I try to login as TestClient 2 I get an access_token as well.
Во-первых, вы можете использовать любое приложение, чтобы получить access_token для любого API, который вы можете найти в разрешении Required вашего приложения, даже если вы не добавили его в разрешение Required вашего приложения, но вы просто не можете использовать этот access_token для доступа к ресурсу вашего приложения. API, потому что у токена нет разрешений. Как вы упомянули, вы создали свой собственный API, поэтому у API нет разрешений для приложений. И в потоке учетных данных клиента это не от имени пользователей, поэтому в этом потоке работают только разрешения приложения, и у обоих токенов ваших двух тестовых приложений не будет разрешения.
И как я могу добавить разрешение приложения в свой API? Мои разрешения API отображаются только как делегированные разрешения.
Это нужно разработчику, чтобы сделать это.
О, извините, кажется, я задал неправильный вопрос. Я не мог получить какие-либо разрешения (роли) для своего токена. Но после нескольких часов проб и ошибок я понял это. Мой API не является зарегистрированным приложением в AD, а не в AD B2C, потому что мне нужно отредактировать манифест приложения, что можно сделать только в стандартном AD. Там я добавил разрешение приложения вручную и потребовал его от другого зарегистрированного приложения в AD.
Пробовали ли вы выполнять поиск в представлении «Выберите API»? По умолчанию он показывает только приложения MS.