Я использую OpenIdDict и Aspnet core 2.0 Identity. У меня он настроен (на данный момент) для использования потока паролей (предоставление учетных данных пароля владельца ресурса). Клиент - это созданный мной Angular SPA. У меня есть контроль над клиентом и сервером.
В настоящее время я пишу собственный AuthorizationHandler, и пока он работает хорошо.
Однако меня немного беспокоит мой ClaimsPrincipal. Мои защищенные методы WebAPI украшены атрибутами авторизации
[Authorize(AuthenticationSchemes = AuthValidationDefaults.AuthenticationScheme)]
Насколько я понимаю, если я добавлю политику в свой Авторизация, контекст, который я получаю, будет таким же, как и у моего контроллера. У него есть свойство «Пользователь», из которого я могу вызвать «HasClaims».
Я добавил несколько утверждений типа "разрешения" моему Принципалу, и они действительно появляются.
Построен ли этот ClaimPrincipals простым декодированием токена-носителя, переданного из SPA? Если это так, то кажется небезопасным доверять этому списку заявлений что-либо делать на стороне сервера ... но токен-носитель - это access_token, а не id_token, и его нельзя просто декодировать на https://jwt.io/
Я мог бы использовать UserManager / RoleManager, чтобы получить все мои заявки на стороне сервера для зарегистрированного пользователя, а затем использовать этот список для проверки. Однако меня беспокоят возможные проблемы с производительностью при этом ...
Итак, я хотел бы знать, можно ли доверять ClaimPrincipals, которые я получаю (как свойство User) моего контроллера, или я должен сам получать свои претензии.
