OpenIdConnect: как добавить дополнительные заявки в токен?

Question

Я совершенно новичок в OpenIdConnect, так что извините, если я все еще скучаю по некоторой базовой концепции. У меня есть веб-приложение в стиле SPA, которое я разрабатываю для своей компании (AspNet Core + Aurelia). Я хочу использовать AzureAD через OpenIdConnect для аутентификации и авторизации, пока все работает очень хорошо, я могу получить токен и войти в систему.

проблема в том, что мое приложение должно предоставить браузеру клиента некоторые претензии, относящиеся к конкретному приложению, такие как: может читать X, может редактировать Y ...

• если я добавлю эти утверждения в токен JWT, предоставленный AzureAD, очевидно, он станет недействительным, так как подпись не будет соответствовать содержимому.

• если я сгенерирую новый токен с новыми утверждениями, но подписанный ключом приложения, очевидно, это будет другой токен, действительный только в контексте моего приложения (что если позже мне потребуется получить доступ к некоторым другой ресурс, использующий токен AzureAD? Является ли хорошей идеей вставить токен AzureID в качестве заявки на недавно выпущенный токен?)

Есть ли что-то, чего мне не хватает в OpenConnectId? или есть способ добавить претензий к токену, выпущенному сторонним поставщиком, таким как AzureAD, при сохранении токена в силе? Может быть, можно попросить AzureAd добавить претензии в токен и повторно подписать его?

Answer 1

Вы можете попробовать использовать собственную политику сопоставления заявок. Это задокументировано здесь .

Эта функция используется администраторами арендаторов для настройки заявок, выдаваемых токенами, для конкретного приложения в их арендаторе.

Насколько я понимаю, это все еще в стадии предварительного просмотра. Так что может потребоваться некоторая проверка проб и ошибок.

Кроме того, вы можете определить некоторую политику в самом приложении. Учитывая, что вы знаете идентификаторы клиентов из своего приложения (следовательно, вам необходимо использовать их для запросов OpenID Connect), вы можете создать простую политику для проверки токенов и выполнения проверок.

Answer 2

Я думаю, что хорошим способом решения этой ситуации может быть получение access_token для API моего собственного приложения (из бэкэнда моего приложения) в обмен на id_token, предоставленный azure (после его проверки)

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

Есть некоторые стандартизированные потоки, которые очень похожи на это, но не совсем то же самое.