Как можно заставить службу проверки подлинности Active Directory Azure переиздать id_token с обновленными утверждениями?

Question

Мы используем Azure B2C для аутентификации наших пользователей, которые работают нормально. После регистрации мы добавляем некоторые пользовательские претензии к нашим пользователям, которые были определены в портале B2C как «Пользовательские атрибуты», используя график api. Когда я вхожу в портал, я вижу, что эти значения были установлены нашими вызовами, как и некоторые стандартные значения требований (например, мы также устанавливаем отображаемое имя, объединяя значения givenName и lastName).

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

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

Может ли кто-нибудь объяснить, как/если можно заставить кешированный id_token на сервере истечь, чтобы при запросе id_token с использованием токена доступа id_token содержит самые последние значения требований?

Answer 1

ИТАК после почти месяца ожидания ответа, официальная линия:

«Группа продуктов определить, что это на дорожной карте, даже, что мы до сих пор не имеем окончательную дату оно должно произойти в несколько месяцев."

Так что в основном они не подтвердили, что это ошибка, и они не могут сказать, когда этот сценарий будет поддерживаться. Честно говоря, низкий уровень поддержки, если честно.

Answer 2

Вопрос, который мы имеем в том, что после того, как эти значения установлены, они не появляются в маркере извлеченной, посылая маркер доступа к AUTHENTICATE конечных точек до тех пор, пока пользователь не выходит из системы и обратно снова (что, очевидно, довольно ужасный пользовательский интерфейс после регистрации).

Не могли бы вы представить подробную информацию о том, как вы приобретаете id_token?

Основываясь на моем тесте, я могу приобрести id_token с обновленной претензии успешным, как шаги ниже:

1. вход в веб-приложение

2. обновить DisplayName с помощью Azure Graph AD, как показано ниже:

POST: https://graph.windows.net/xxxx.onmicrosoft.com/users/{userId}?api-version=1.6 
{ 
    "displayName":"newValue" 
} 

3. повторно запрос id_token от OAuth 2.0 Authorization конечной точки с использованием запроса HTTP без знака отказа/входа в систему (Вы также можете захватить точное запрос с использованием Fiddler при входе в приложение)

GET:https://login.microsoftonline.com/xxxx.onmicrosoft.com/oauth2/authorize?client_id={clientId}&redirect_uri={redirectURL}&response_type=id_token&scope=email+openid&response_mode=query&nonce=HWUavSky1PksCJC5Q0xHsw%3d%3d&nux=1&nca=1&domain_hint={XXXX.onmicrosoft.com} 

4. значение заявки на обновление отображается в новом id_token, как ожидалось

Чтобы сузить эту проблему, вы можете увидеть, есть ли кеш для id_token в вашем приложении.