SPA + API + OIDC: Как аутентифицировать вызывающего абонента API, когда он предоставляет только токен ACCESS?

Question

Допустим, вы разрабатываете клиентское приложение JavaScript SPA (Angular), внутренний API для этого приложения (в моем случае ASP.NET Core), и вы используете провайдер идентификации, который реализует протокол Open ID Connect (я используюIdentityServer4).

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

Теперь согласно этой документации приложение JavaScript должно передавать токен доступа в заголовки всякий раз, когда оно вызывает API.И я не уверен, какой цели служит id токен в этом случае (помимо настройки интерфейса в вашем приложении JavaScript)?

Но это запутанная часть: в документации также говоритсяВы никогда не должны использовать токен доступа для аутентификации.Но это маркер, который мой API получает в заголовках запросов, как он может аутентифицировать пользователя?Если мой API получает Post(newRecord), и API требует внутреннего исправления некоторой аудиторской информации на newRecord (т.е. newRecord.CreatedBy = CurrentUsername), как он может это сделать без аутентификации вызывающего абонента ??

Я думаю, что мне не хватает части головоломки.Пожалуйста, любая помощь высоко ценится.

Answer 1

Краткий ответ / предложение

Используйте токен доступа для доступа к конечным точкам API.От конечных точек API вы должны использовать конечную точку token introspection для проверки правильности токена (активного состояния), а также для получения субъекта, прошедшего аутентификацию на сервере авторизации.IdentityServer обеспечивает поддержку для этого.Документация доступна по адресу здесь .

Пояснение

Идентификационный токен предназначен для использования принимающим клиентом.Это позволит вашему клиенту аутентифицировать конечного пользователя и предоставить пользовательские настройки.В этом вся цель OpenID Connect (OIDC).С другой стороны, OAuth 2.0 предоставляет структуру авторизации.Он заменяет учетные данные пользователя токенами доступа, что повышает безопасность доступа к API (по сравнению с обычной аутентификацией и хранением учетных данных пользователя везде).Следовательно, OIDC построен на основе OAuth 2.0, вы получаете как токен ID, так и токен доступа с потоком OIDC.

Но, как вы уже поняли (и упоминали ранее), ID-токен предназначен для клиента.Могут быть исключительные случаи, когда токен ID передается между клиентом и сервером.Это в основном, когда оба контролируются одной и той же стороной.Но токен доступа является ключом для доступа к конечным точкам API, правильно.

Токены доступа могут быть непрозрачной строкой или JWT.Когда это JWT, API может читать и понимать токен (самодостаточный).Когда он непрозрачен, единственный способ проверить токен в конечной точке API - это использовать конечную точку самоанализа токена.Если API может проверять правильность токена, он может предоставить запрос доступа (авторизации).Кроме того, если доступны данные пользователя (субъект) (посредством JWT или в качестве ответа на самоанализ), то могут быть выполнены специфичные для пользователя проверки.Это дополнительно распространяется на значения области действия токена.Но в конце концов вы авторизуете запрос API, а не аутентифицируете пользователя в конечной точке API.Это основной момент.Надеюсь, теперь все ясно.