У меня есть приложение для нескольких арендаторов, которое использует B2 C в качестве системы управления идентификацией, которую мы настроили Azure AD Multitenant согласно do c (https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-azure-ad-multi-tenant-custom?tabs=applications) с использованием пользовательских политик.
У нас есть несколько требований, когда пользователь использует Azure AD для входа в систему:
- Извлечение изображения профиля пользователя из Azure AD (через график API) для отображения в приложении
- Получите имя клиента Azure AD, отображаемое в приложении, согласно Azure рекомендациям AD.
- Прочитайте пользователей каталога, чтобы пользователь мог добавить других пользователей в app.
Я пытаюсь заставить работать номер 1, так как это укажет мне правильное направление для остальных.
Сначала я попытался пропустить токен эмитента как per (https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-custom), но это настолько раздувает первоначальный вход пользователя в систему, что я получаю ошибку слишком длинных заголовков 400. Потратил несколько дней, пытаясь устранить неполадки, которые, как кажется, каждый раз указывают на разрешение «Очистить куки» ... но в этом случае это на самом деле не работает. На самом деле куки не так много, и нигде не кажется, что переполнение заголовка можно исправить. Кроме того, я бы предпочел не получать токен доступа и вызывать api графа напрямую из моего внешнего интерфейса, а скорее из моего основного веб-интерфейса. net и прокси-сервера для изображения или любых других операций Graph API, которые я хочу выполнить. Чтобы добиться этого, я посмотрел на аутентификацию на основе приложений с помощью серверного API, но кажется, что это довольно долгий путь, чтобы заставить это работать с несколькими согласиями администратора, и т. Д. c позже в приложении, что я бы предпочел сделать при первоначальном входе в систему пользователя из внешнего интерфейса.
Я рассмотрел несколько решений, глядя на создание демона идентификации, искал inte rnet для вариантов .. однако кажется, что что-то должно быть простой, слишком сложный.
, который отвечает на мои вопросы:
- Можно ли не проходить через токен доступа эмитента в B2 C, но запрашивать токен доступа позже, когда нужно? Как бы я сделал это из моего внутреннего API?
- Если вышеупомянутое невозможно, смог ли кто-нибудь пройти через токен доступа эмитента и не получить ошибку заголовков слишком долго? есть ли примеры, объясняющие, как это сделать, как в пользовательских политиках B2 C, так и в обработке этого маркера доступа в коде при получении? Я пытался удалить некоторые утверждения, возвращаемые из Azure AD и самого B2 C, но, похоже, я не могу отклонить требования достаточно, чтобы не вызвать переполнение.
- Как вы безопасно управляете этим токеном в своем интерфейсе, если единственный вариант - передать его?
Большое спасибо заранее!