Какие утверждения JWT из маркеров Azure AD можно безопасно использовать для сопоставления пользователей?

Мы используем OAuth 2.0 для получения токенов JWT из Azure AD. В нашем приложении мы использовали значение утверждения " upn " для идентификации связанного внутреннего имени пользователя.

Ссылка на токен Azure ADдокументирует утверждение upnкак "имя участника-пользователя", которое, насколько я понимаю, является именем пользователя, следующим формату addr-spec (т. е. user@domain). Это хорошо работает для пользователей, созданных в клиенте Azure AD. К моему удивлению, однако, утверждение upn , похоже, исчезнет, если аутентифицированный пользователь синхронизируется с другим объявлением. Такое поведение, по-видимому, нигде не задокументировано.

  1. где я могу найти документацию о том, когдаupn гарантированно находится в токене?
  2. какие надежные альтернативные утверждения я могу использовать вместо этого? Предпочтительно, чтобы претензии гарантированно имели форму "пользователь / домен", поскольку это лучше всего соответствует нашей модели. Я рассмотрел следующее:
    • unique_name : я только заметил, что это равен upn , но я не уверен, откуда он берется. Смущает, что ссылка на токен говорит: это значение не является уникальным в пределах арендатора и предназначено для использования только в целях отображения. (Курсив мой)
    • email: это тоже похоже на upn , но опять же, откуда он взят? На портале Управления я попытался ввести другое значение в каждое связанное с электронной почтой поле, связанное с пользователем, но ни один из них, по-видимому, не распространяется на это утверждение. Поэтому кажется, что это поле на самом деле не является электронной почтой.

Я хочу быть абсолютно уверен, что наше приложение сможет обрабатывать все маркеры, выпущенные Azure AD, поэтому я не решаюсь использовать любое из вышеупомянутых утверждений, если у меня нет документации, объясняющей их фактическую семантику.

2 2
jwt oauth-2.0 openid-connect

2 ответа:

  1. где я могу найти документацию о том, когда upn гарантированно будет в токене?

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

Какие надежные альтернативные утверждения я могу использовать вместо этого? Предпочтительно, чтобы претензии гарантированно имели форму "пользователь / домен", поскольку это лучше всего соответствует нашей модели. Я обдумал следующее: следующее:

Мы можем использовать утверждение oid для отображения пользователей. Это утверждение содержит уникальный идентификатор объекта в Azure AD. Это значение является неизменяемым и не может быть переназначено или использовано повторно. Используйте идентификатор объекта для идентификации объекта в запросах к Azure AD.

И если у вас есть какие-либо отзывы о документе Azure, вы можете попытаться отправить отзыв от эта страница полезна? на правой нижней странице, чтобы помочь улучшить документ. Введите описание изображения здесь

1

Хотя довольно часто UPN и основной адрес электронной почты пользователя являются одним и тем же, это не гарантируется (как и существование UPN, как вы заметили). Поэтому вы должны действовать в предположении, что UPN != адрес электронной почты. Если вам нужно знать адрес электронной почты, вы должны сделать вызов графика и поиск с помощью oid.

0