Зачем мне нужны два приложения AAD, чтобы добавить роли в токен доступа?

Question

Как показали многие примеры, у меня есть две регистрации приложений AAD, одна для моего интерфейса на основе javascript, а другая для моих веб-API только для JSON.

Если я полностью доверяю своему клиентскому приложению AAD, почемутребует ли AAD от меня создания второго приложения AAD для моих веб-API?

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

Если я не полностью доверяю эмитенту в мошенничестве с заявками, я понимаю, зачем мне это нужнодва приложения AAD и секрет клиента. Но так как я доверяю своему AAD-приложению и подписи JWT, зачем такая сложность? Или, может быть, есть способ сделать это, которого я не нашел?

Спасибо!

---

Отвечая здесь Марку, потому что просто недостаточно символов в поле комментариев - Пример , на который вы ссылались, является отличным примером, в частности, JavaScript, вызывающим Web API . Это то, что я делаю сейчас на самом деле. Однако проблема заключается в том, что веб-API в образце открыт для всех, кто прошел аутентификацию на клиенте. Мне нужно защитить Web API для определенных лиц в арендаторе, и просто проверить идентификатор клиента / приложения недостаточно, поскольку любой, кто может создать приложение AAD, может подделать его .

Поэтому мне нужно добавить роли к токену доступа, чтобы я знал, что мое приложение аутентифицировало пользователя, и этому пользователю были предоставлены необходимые роли. Например, вот пример Microsoft . И даже здесь видео Microsoft, проходящее через процесс.

Если у меня нет двух приложений AAD с секретом клиента, утверждения о ролях никогда не предоставляются в маркере доступа. Он всегда указывается в токене id, но не в токене доступа.

Я чувствую, что здесь упускаю что-то очевидное. Если бы AAD просто поместил запрошенные мной роли в JWT, когда я аутентифицировался на нем, и я проверил его подпись, аудиторию, издателя и роли, мне бы не понадобилась какая-либо дополнительная сложность?

Answer 1

Ах, я думаю, я понимаю, куда вы идете: вы хотели бы контролировать, какие пользователи могут получить доступ к API, независимо от того, какое клиентское приложение они используют для доступа к API. Это функция API - вы не можете контролировать это через AAD. В AAD вы можете контролировать, какие пользователи могут получать доступ к каким приложениям (UI), используя ограничения доступа пользователей (вкладка предприятия) или доступ на основе ролей. Однако доступ к API контролируется в AAD на уровне вызывающего приложения через области. Доступ к API никогда не осуществляется напрямую пользователями, а только другими приложениями, поэтому управление разрешениями доступа на уровне пользователя может привести к хаосу администратора. Таким образом, вы можете контролировать, какие полномочия у пользователя в приложении, которое они используют, и вы можете контролировать, какие разрешения это приложение (клиент) имеет в других приложениях (API, серверах ресурсов), которые оно использует.

Другими словами: role касается доступа пользователей к пользовательскому интерфейсу, область действия - доступа одного приложения к другому.

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

Answer 2

Можете ли вы предоставить ссылку, показывающую, что необходимы два приложения? Это должно иметь место только в том случае, если API, который вы хотите вызвать, не предоставляется веб-приложением, которое предоставило JS браузеру. Ни один из 'официальных' примеров не требует регистрации двух приложений (Graph API, используемый в некоторых из этих примеров, является отдельным API, и он уже зарегистрирован). Проблема с токенами, передаваемыми из браузера, заключается в том, что они были приобретены общедоступным клиентом, не использующим никаких секретов, кроме прав пользователей. Поэтому их легче украсть и повторно использовать. Ваше собственное фоновое приложение может захотеть использовать секрет, чтобы получить свой собственный токен (грант расширения) для вызова еще одного API, использующего токен, который не находится в общедоступном клиенте.