Аутентификация в ASP.NET 5 (vNext)

У меня есть традиционное приложение ASP.NET, которое я хочу переместить в ASP.NET 5 (vNext). Я делаю это как учебное упражнение.

В моем текущем приложении используется проверка подлинности на основе форм. Однако я хотел бы использовать OAuth. Я смотрел на модуль безопасности и было любопытно, что следует использовать для OAuth. Я вижу вариант для Microsoft.AspNet.Authentication.OAuth и Microsoft.AspNet.Authentication.OAuthBearer.

Какой из них используется для входа пользователя в систему?

Кто-нибудь знает пример/пример, показывающий их в действии?

Ответы

Ответ 1

Microsoft.AspNet.Authentication.OAuth

  • Разрешает сторонним идентификаторам (например, Google, Facebook) аутентифицировать пользователей для вас, сохраняя пользователей досадностью регистрации.
  • Позволяет другим приложениям использовать ваше приложение для аутентификации

После того, как ваши пользователи прошли аутентификацию третьей стороной, средний уровень OWIN считывает файл cookie OAuth и создает файл cookie, основанный на конкретном домене. Пока файл cookie доступен (присутствует, не истек и не поврежден), ваши пользователи остаются аутентифицированными.

Введение в ASP.NET 5 Generic OAuth Provider

Microsoft.AspNet.Authentication.OAuthBearer

Создает жетоны-носители. Когда пользователь подписывается в конечную точку (Web-API) или аутентифицируется третьей стороной, средний уровень OWIN возвращает маркер-носитель. Маркер-носитель отправляется со всеми запросами на обслуживание для идентификации ваших пользователей вместо Cookies.

В режиме запуска

app.UseOAuthBearerAuthentication(options =>
{
    options.Authority = "http://localhost:5000/oauth/";
    options.Audience = "http://localhost:5000/oauth/resources";

    options.TokenValidationParameters = new TokenValidationParameters
    {
        IssuerSigningKeys = new[] { new X509SecurityKey(cert) },
        ValidateLifetime = false,
    };
    options.AutomaticAuthentication = true;

    options.SecurityTokenValidators = new[]
    {
        new JwtSecurityTokenHandler()
    };
});

Знаки маркеров используются при создании SPA (одностраничное приложение) или для обеспечения AJAX запросов.

Проверка подлинности файлов cookie считается адекватной для запросов сервера. Но конечные точки службы (независимо от того, разрешают ли они C ross O rigin R esource S) более уязвимы до CSRF и XSS.

Многие приложения используют оба:

Общей практикой является использование проверки файлов cookie для запросов страниц и токенов-носителей для запросов AJAX.

Вам нужно будет различать ресурсы, которые используют файлы cookie и ресурсы, которые используют токены.

В этом fooobar.com/info/52122/... Мэтт Дэкри неплохо описал свою реализацию, используя

[Authorize("Bearer")]

Для контроллеров или методов, которые должны использовать токены-носители, а не стандартный атрибут [Authorize] на основе cookie.

Многие приложения полагаются только на файлы cookie:

Насколько уязвимо ваше приложение к атакам CSRF при использовании файлов cookie? Это спорно. Многие сайты полагаются только на файлы cookie и никогда не сталкиваются с проблемами. Ответ может зависеть от вашего уровня трафика и потребностей в безопасности.

Если вы разрабатываете сайт для десятков тысяч пользователей, вы, вероятно, надежно полагаетесь на файлы cookie.

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

Примечание.. Вы упоминаете использование проверки подлинности форм, я настоятельно рекомендую использовать Идентификация. Структура интегрируется с OWIN из коробки, чтобы предоставить вам оба типа функциональности.