Почему токены доступа, выпущенные AAD, содержат информацию о пользователе?

Question

Я много читал об OAuth 2.0 и OpenId Connect, и теоретически теперь я понимаю обе концепции.
Но если я go на практике, некоторые вещи все еще сбивают меня с толку, и я надеюсь, что вы сможете просветить меня путь ...
Во-первых, во всех примерах кода, как защитить основной API. net в AAD-среде, я нахожу такие строки в разделе configure:

app.UseAuthentication()

и такие строки в разделе ConfigureServices:

        services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
        .AddJwtBearer(options =>
        {
            options.Authority = "https://login.microsoftonline.com/xxxxxxxx";
            options.Audience = "xxxx-xxx-xxx-xxx-xxxx";
        });

Однако для доступа к моему API я использую не токен ID, а токен доступа, то есть Authorization , а не " Аутентификация "как в примерах кода.
Это работает, но я не понимаю его на 100%.
Итак, мой первый вопрос:

1. Токен доступа тоже каким-то образом «аутентифицируется»?

Второе:
Я читал, что токены доступа не имеют стандартизованного формата. Они могут быть JWT или нет, могут иметь аудиторию или нет et c. По этой причине вы даже можете поместить информацию о пользователе в токен, как это делает Microsoft. Маркеры доступа содержат утверждения, такие как «фамилия» или «данное имя» и т. Д. c.
идентификаторы, напротив, имеют стандартизованный формат, чтобы гарантировать, что аутентификация выполняется одинаково для всех.

Если люди обращаются к моему API с токеном доступа, я могу прочитать их имя или адрес электронной почты, например, с помощью «user.identity.name». Это значение я могу использовать для хранения информации , кто что-то редактировал или кто что-то вставил.
Итак, я получаю информацию о пользователе с токенами доступа!
Итак, мой второй вопрос:

Правильно ли я поступаю здесь? Или нужно сделать это по-другому.

и:

Должны ли токены доступа содержать информацию о пользователе?

Answer 1

Токен доступа также каким-то образом «аутентифицируется»?

Да. Ваш API проверяет токен доступа при его получении. Это часть аутентификации, когда ваш API проверяет, что подпись токена действительна, получена от клиента Azure AD, которому вы доверяете, что он предназначен для вашего API и срок его действия не истек. авторизация - это когда вы проверяете, какие разрешения содержит токен. Ваш API может определять различные разрешения, которые предоставляются клиентским приложениям, обеспечивая им разные уровни доступа. Действительный токен может пройти аутентификацию, но он может не пройти авторизацию, если у него нет необходимых разрешений.

Правильно ли я поступаю здесь? Или это нужно сделать по-другому.

По сути, вы делаете правильные вещи. Маркер сообщает вам, кто пользователь, который использует клиентское приложение, и если вам нужно знать, кто именно что-то сделал, это информация, которую вы используете. Однако, если вы действительно хотите связать действие с пользователем, я предлагаю вам использовать его идентификатор объекта / идентификатор объекта / oid вместо его имени / имени пользователя, поскольку они могут измениться. Если только вам не нужно их отображаемое имя.

Должны ли токены доступа когда-либо содержать информацию о пользователе?

В контексте Azure AD токен доступа всегда будет содержат информацию о пользователе, если клиентское приложение обращается к API от имени пользователя. Это включает в себя потоки аутентификации, такие как код авторизации, код устройства, неявный и от имени. Все они используют делегированные разрешения, также называемые областями, для вызова API от имени пользователя. Таким образом, токен содержит информацию о вызывающем приложении и пользователе.

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

Если ваш API поддерживает оба этих сценария ios, иногда токены содержат информацию о пользователе, а иногда нет.

Часть о форматы токенов в основном верны с точки зрения спецификации. OAuth не определяет строгий формат для токенов доступа, в то время как OpenID Connect определяет его для токенов ID.

Использование токена доступа для вызова вашего API определенно правильно. Маркер ID предназначен только для приложения, которое инициировало аутентификацию пользователя, а не для каких-либо API-интерфейсов, которые оно вызывает. Вот для чего нужны токены доступа.

Answer 2

, если вы отметите здесь: https://docs.microsoft.com/en-us/azure/active-directory/develop/access-tokens в новых токенах доступа, по умолчанию он соответствует стандарту отсутствия какой-либо личной информации о пользователе. что и предлагают стандарты, токены доступа не должны содержать много или какую-либо информацию о пользователе. скорее просто информация для авторизации (вещи, к которым пользователь может получить доступ). Однако вы всегда можете добавить необязательные утверждения (и azure позволяет вам это сделать) для личной информации, но передовой опыт подсказывает, что этого не делать.

с точки зрения дополнительной аутентификации: аутентификация в основном доказывает, кем вы себя называете. addauthentication (), в основном вызывает microsoft azure ad для выполнения этой задачи, говоря: эй, ай, пожалуйста, спросите этого человека, кто он, azure затем проверяет и говорит, что это реальный человек, но я ничего вам не скажу ему кроме идентификатора, и у них есть доступ к вашему API / приложению. Итак, из вашего фрагмента все в порядке.

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

вот отличное чтение об этом: https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api/

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