JwtBearerAuthentication оленья кожа вернется 403 Forbidden, всегда возвращает 401 Несанкционированное

Question

Если ClaimsIdentity установлен через JwtBearerAuthentication промежуточного оленья кожа иметь достаточное количество ролей требуется через

[Authorize(Roles="whateverrole")] 

возвращает 401 вместо 403.

Я борюсь с этим в осины .net core web api всю ночь. Я также видел этот вопрос в stackoverflow, но я не видел решения, которое я мог бы сделать. Порядок регистрации промежуточного программного обеспечения или параметра AutomaticChallange выполнял эту работу.

Я не знаю, не хватает ли я чего-то, но кажется шокирующим, что это не было решено должным образом в течение многих лет. Это так раздражает.

Есть ли нормальный, обычный, безотходный, не-взломанный способ решения этого?

UPDATE (в ответ на комментарий от @juunas)

Я попытался, что и роли правильно отображаются в формуле изобретения. Итак, если я удалю требование Роли из атрибута, для всех ролей, которым назначен пользователь (в токене JWT) User.IsInRole (x) возвращает true. Так что картирование работает отлично.

О переходе от авторизации на основе ролей к политикам ... можете ли вы предоставить некоторую ссылку на некоторые рекомендации, рекомендации или что-то, на чем вы основываете это утверждение? Я не говорю, что это не то, что нужно сделать, а просто хотел бы это понять.

Answer 1

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

401 предназначен для аутентификации. Если вы получаете эту ошибку, вы должны спросить себя, является ли пользователь зарегистрирован или у пользователя есть текущий токен, предоставленный действительным поставщиком токенов? Если токен истек или поставщик недействителен, вы можете получить 401. Если это то, что вы получаете, вам нужно проверить User.Identity.IsAuthenticated, это возвращает true? Скорее всего, он возвращает false.

403 предназначено для авторизации. Это означает, что у пользователя есть действительный токен, но токен, который у них есть, не дает им доступа к ресурсу, который они запрашивают. Здесь вы хотите проверить User.IsInRole(), и он вернет false.

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

Редактировать: Извинения за допущение, что пользователь не был аутентифицирован, я не видел, где вы заявили, что они, где в вашем первом посте. Трудно помочь, не видя кода, но мое следующее предположение заключается в том, что проверка требований не была добавлена ​​в конвейер служб.

public void ConfigureServices(IServiceCollection services) 
{ 
    services.AddMvc(); 

    services.AddAuthorization(options => 
    { 
    options.AddPolicy("whateverrole", policy => policy.RequireClaim("whateverrole")); 
    }); 
} 

Это в вашем Startup.cs. MS doc находится здесь https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims

Последнее обновление: Проще говоря, используя атрибут атрибута Authorize по умолчанию, вы не можете его изменить. MS проектирует I таким образом из-за количества слоев в конвейере, которые могут повлиять на аутентификацию. Я не знал об этом, потому что я использую специальный атрибут Authorize и забыл, что я написал способ обработки кодов состояния.

Однако я нашел хорошее решение, которое могло бы в отели https://github.com/aspnet/Security/issues/872#issuecomment-232624106

Он добавляет страницу ошибки в трубопровод до app.UseMvc(), который перенаправляет ошибку аутентификации на страницу с ошибкой, которая возвращает правильный код статуса ,