Инфраструктура идентификации ADB2C: использование токена доступа сразу после аутентификации

мы используем множество встроенных политик ADB2C и теперь хотим включить настраиваемые политики благодаря Identity Experience Framework.

Один из наших вариантов использования: сделать несколько вызовов (из политики) на конечных точках (которые защищены токеном доступа) сразу после аутентификации (регистрации или входа). Например: сразу после регистрации мы хотели бы вызвать api для управления политикой конфиденциальности. Чтобы он работал, нам нужен токен доступа.

Есть ли способ, благодаря настраиваемым политикам, вызвать конечную точку http с токеном доступа, выданным сразу после аутентификации?


person user1523812    schedule 06.05.2019    source источник
comment
Привет. Вы хотите вызвать конечную точку HTTP во время потока аутентификации или после того, как поток аутентификации завершился и был выдан токен доступа?   -  person Chris Padgett    schedule 06.05.2019
comment
Привет, если я не ошибаюсь, должно быть после. Шаг 1: пользователь создает свою учетную запись с помощью настраиваемых политик. Клиентское приложение получило код авторизации. Шаг 2: клиентское приложение вызывает конечную точку / token настраиваемой политики с помощью grant_type authorization_code, чтобы получить токен доступа / id. Пользовательская политика предоставит приложению различные токены, а также вызовет некоторые конечные точки, для которых нам также понадобится токен доступа.   -  person user1523812    schedule 06.05.2019


Ответы (1)


Когда маркер доступа или идентификатор идентификатора генерируется Identity Experience Framework (IEF), это означает, что все требования пользовательского пути были соблюдены. То есть, если путешествие пользователя потребовало некоторого управления политикой конфиденциальности и пользователь должен был дать согласие на это, только тогда будет сгенерирован токен доступа или токен идентификатора.

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

Поскольку IEF напрямую вызывает Rest API, неясно, как IEF генерирует токен и отправляет его в Rest API более выгодно, чем IEF, выполняющий запрос через SSL и предоставляющий данные пользователя.

person Omer Iqbal    schedule 12.05.2019