Я работаю над приложением ASP.NET Core 2.0 с использованием токенов Bearer.Все, что касается токенов и аутентификации, работает / работает нормально.
Я только что реализовал другой процесс авторизации.Теперь вместо использования атрибута Authorize
для применения политик я использую подход IAuthorizationService
и DefaultAuthorizationPolicyProvider
.
Однако я вижу то, чего не ожидал увидеть и не могунайти решение или найти любую полезную документацию по проблеме.
Я настраиваю токены-носители в Startup.cs
следующим образом:
.AddJwtBearer(options =>
{
options.TokenValidationParameters = tokenValidationParameters;
});
Параметры проверки создаются следующим образом:
return new TokenValidationParameters
{
// The signing key must match!
ValidateIssuerSigningKey = true,
IssuerSigningKey = GetSymmetricSecurityKey(configuration),
ValidateIssuer = true,
ValidIssuer = configuration.GetSection("TokenAuthentication:Issuer").Value,
ValidateAudience = true,
ValidAudience = configuration.GetSection("TokenAuthentication:Audience").Value,
ValidateLifetime = true,
ClockSkew = TimeSpan.Zero // leave at zero, we validate expiry!
};
Мой установочный код авторизации выглядит следующим образом:
public static void AddAuthorisationPolicies(this IServiceCollection services)
{
services.AddAuthorization();
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
services.AddTransient<IAuthorizationPolicyProvider, AuthorisationPolicyProvider>();
services.AddTransient<IAuthorizationHandler, RoleClaimHandler>();
}
Это все работает, как и ожидалось.Теперь в моих контроллерах я могу внедрить экземпляр службы авторизации, например так:
public SyncController(IAuthorizationService auth)
Все мои требования и обработчики работают так, как ожидалось, и так далее.Теперь в контроллерах метода действия я могу сделать это:
var auth = await authz.AuthorizeAsync(User, "Administrator");
if (!auth.Succeeded)
{
return Challenge();
}
...
Когда токен действителен, ClaimsPrinciple
установлен правильно, то есть вызов AuthorizeAsync
выполняется с действительным пользователем.
Я вижу, что не ожидал увидеть, что с маркером Bearer
с истекшим сроком действия запрос все еще достигает методов действия, но с нулевым ClaimsPrinciple
.
Я должен отсутствоватькакая-то настройка ключа где-то.Я не ожидал, что это произойдет, и нет никакого смысла вызывать AuthorizeAsync
с нулевым пользователем.Строго говоря, это не открыло никакой дыры в безопасности, поскольку при нулевом пользователе вызов на AuthorizeAsync
всегда будет неудачным, но это не особенно чисто, разумно или логично.
Как я могу предотвратить запросс токеном с истекшим сроком действия, чтобы пройти этот путь через конвейер запросов?
Это на самом деле ожидаемое поведение, или мне нужно откатить свой собственный процесс (больше Middleware?) для этой проверки срока действия теперь, когда яв обход встроенной логики AuthorizeAttribute
?
Я ожидал, что ValidateLifetime = true
продолжит отклонять запрос, поскольку я изменил способ авторизации, а не аутентификацию.