Атрибут Authorize не перенаправляет на страницу входа при использовании AddJwtBearer.NET Core 2

Я не могу заставить какие-либо образцы работать при использовании нового AddJwtBearer. У меня есть HomeController с атрибутом Authorize:

[Authorize]
public class HomeController : Controller
{
    public IActionResult Index()
    {
        return View();
    }
}

Я пробовал новый ASP.NET Core AddJwtBearer, и у меня есть этот код в ConfigureServices непосредственно перед services.AddMvc():

services.AddAuthentication(opts =>
{
    opts.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
    opts.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
    opts.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
})
.AddJwtBearer(opts =>
{
    opts.RequireHttpsMetadata = false;
    opts.SaveToken = true;
    opts.TokenValidationParameters = new TokenValidationParameters()
    {
        IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("mysupersecretkey")),
        ValidIssuer = "issuer,
        ValidAudience = "audience",
        ValidateIssuerSigningKey = true,
        ValidateLifetime = true,
    };
});

и в методе Configure в автозагрузке, у меня есть это перед app.UseMvc()

app.UseAuthentication();

Я ожидал, что он перенаправит на страницу входа (у которой нет атрибута Authorize), поэтому я могу ввести имя пользователя и пароль, а затем создать токен для последующего использования, но меня всегда перенаправляют на пустую страницу.

Я пробовал перемещаться по Home / Index с помощью почтальона, тело было пустым и в шапке есть:

WWW-Authenticate →Bearer error="invalid_token", error_description="The token is expired"

Если я использую аутентификацию куки, он перенаправляет на страницу входа. В предыдущей версии (UseJwtBearerAuthentication) эта переадресация позволяла мне ввести пароль и получить токен.

Я ожидаю неправильного поведения или я что-то упускаю?

2 ответа

Решение

Я думаю, вы ожидаете неправильное поведение. Токены Bearer JWT чаще всего используются при вызове API. Не очень полезно, чтобы другое приложение вызывало ваш API, например, с помощью HttpClient, чтобы получить перенаправление в качестве ответа. Вызов 401 напрямую говорит вызывающему абоненту, что ему нужно пройти аутентификацию.

Если у вас есть интерфейсный JavaScript, использующий этот API, вы должны добавить проверку для кода состояния 401 и перенаправить на страницу входа со стороны клиента.

Вы можете увидеть исходный код здесь: https://github.com/aspnet/Security/blob/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer/JwtBearerHandler.cs#L194

Он устанавливает код состояния 401 и возвращает правильную ошибку.

Хотя, глядя на код, я думаю, вы могли бы также выполнить перенаправление со стороны сервера, используя OnChallenge событие. Лично я не стал бы, кроме API, делать перенаправления на страницы входа.

Если вы пытаетесь выяснить, как перенаправить на страницу входа, как я был день или два назад, вероятно, стоит взглянуть на этот ответ на сообщение SO . Оно работает. И я был взволнован.

НО!....

Мой первоначальный азарт быстро исчез , как только я понял , что в современных потоках , которые фактически используют JWTs, мы не хотим , чтобы управлять экраном входа в любом случае . И мы не можем (со стороны сервера) вставлять JWT в заголовки запросов. Это может сделать только браузер.

Таким образом, хотя приведенная выше ссылка была интересной, я пришел к тому, что в первую очередь указал Юунас - что JWT обычно используются не так. Рискуя сказать это неправильно, я повторю, что JWT чаще используются в сценариях OpenId Connect. В любом случае, именно здесь неумолимо рисуется мое собственное приложение MVC.

Другие вопросы по тегам