Ресурс - это концепция, которая может быть разделена на логические части (области), которые могут быть реализованы различными способами. В любом случае, хотя это может быть неочевидно из документации, для одного ресурса у IdentityServer есть хотя бы одна область действия.
Чтобы разрешить клиенту доступ к ресурсу, клиент должен настроить, какие области разрешены для этого клиента. В примерах имя области равно названию ресурса, но в действительности ресурс имеет несколько областей действия. Обратите внимание, что клиент, которому разрешено использовать только одну область, может получить доступ ко всему ресурсу (аудитории), если только ресурс (api) не фильтрует доступ на основе разрешенной области (области являются частью маркера доступа как утверждения области).
Одной из особенностей IdentityServer является то, что он является поставщиком токенов, например, для токенов доступа и токенов идентификации.
Для начала с последним существует два типа токенов идентификации. Существует один «минимальный» идентификационный токен (содержит только «подчиненное» утверждение), который выдается только по запросу вместе с токеном доступа. И есть «полный» токен идентификации, который может быть запрошен клиентом в конечной точке UserInfo.
Для IdentityServer пользовательские утверждения являются ресурсом (информации об идентичности). В качестве примечания, пользователя следует запросить согласие, прежде чем использовать эту информацию, поскольку пользователь владеет этой информацией.
Не все заявления пользователей должны относиться к токену идентификации, который запрашивается в конечной точке UserInfo. Чтобы определить, какие утверждения должны, IdentityServer просматривает таблицы Identity ~. На основе этих таблиц доступна коллекция RequestedClaims для контекста UserInfo, который используется для фильтрации ресурса заявок пользователя.
Другими словами, когда клиент настроен для запроса области действия openid, тогда только подпункт «утверждение» включен, добавление области «профиль» будет включать в себя основные утверждения профиля (если они доступны в таблице UserClaims), а настройка области «электронная почта» также добавит сообщение электронной почты в маркер идентификации.
Для токена доступа существует аналогичный механизм. На основе таблиц ApiClaims и ApiScopeClaims доступна коллекция RequestedClaims для контекста авторизации. Посмотрите мой ответ здесь для получения дополнительной информации.
Предположим, вы хотите добавить утверждение 'name' к токену доступа, а затем добавить его в одну из таблиц. Посмотрите мой ответ здесь или фактически весь поток, для получения дополнительной информации.
Хотя с помощью IdentityServer возможно добавить все виды утверждений к токену доступа, вы должны Интересно, является ли это правильным подходом, как объяснено в этом сообщении .
Проблема с утверждениями о токене доступа заключается в том, что эти утверждения используются для авторизации пользователя. Но заявления пользователей обычно не предназначены для авторизации пользователей. И вы не хотите в конечном итоге получить один токен супер-доступа, содержащий все утверждения.
Делая шаг назад, IdentityServer настроен для защиты ресурсов и авторизации клиентов. Клиент может подключиться к ресурсу (области действия), но это пользователь, который авторизован для доступа к информации: запросы от клиента всегда «от имени пользователя». Вот почему утверждение «sub» всегда (в интерактивном потоке) является частью токена доступа. Кроме того, IdentityServer может быть расширен для обработки аутентификации пользователя. Но, хотя это возможно в текущем проекте, авторизация пользователей не является (или, по крайней мере, уже не) заботой IdentityServer.
Создатели IdentityServer думали об авторизации пользователей в прошлом и придумали отдельный сервис для этого: PolicyServer . Получение утверждений об авторизации из IdentityServer и из маркера доступа.
Итак, чтобы ответить на ваш вопрос, различные таблицы используются для настройки ресурсов, областей, клиентов и фильтров, которые используются для построения токенов. , Заявки пользователей что-то говорят о пользователе (удостоверение личности) и отсутствуют в маркере доступа.
Для авторизации пользователя я могу порекомендовать реализацию, похожую на сервер PolicyServer, в сочетании с авторизацией на основе ресурсов.
Краткое резюме таблиц:
AspNetUserClaims - ресурс пользовательской информации
ApiResources - название ресурса
ApiScopes - области «один ко многим», которые являются частью ресурса
IdentityResources - фактически область идентификации (например, профиль openid)
IdentityClaims - фильтры AspNetUserClaims для токена идентификации
ApiClaims - фильтры AspNetUserClaims для токена доступа, независимо от запрошенной области действия
ApiScopeClaims - фильтры AspNetUserClaims для маркера доступа, зависят от запрошенной области действия
ClientClaims - заявки, включенные в спецификацию ifi c client
ClientScopes - разрешенные области для клиента
Клиент запрашивает области. Если области не указаны, то (по спецификации) все разрешенные области считаются запрошенными.
API является частью ресурса (аудитории). Более детальная авторизация клиента (на основе области действия) требуется, когда ресурс имеет несколько областей действия.
Для определения того, что разрешено делать пользователю, существует авторизация пользователя: клиент может подключаться к API, фильтруется по области действия. (например, календарь), и пользователь имеет право читать, но не записывать события.
Хотя calendar.write и calendar.read могут быть областями действия, это не имеет никакого отношения к авторизации пользователя. Пользователь может быть авторизован для чтения и записи, но, поскольку клиент может быть ограничен (например, calendar.read ), пользователю может потребоваться использование отдельных клиентов для подключения к ресурсу, например приложение календаря имеет оба, почтовое приложение calendar.read только.