Angular .NET Core Web API проверка подлинности с использованием файлов cookie в том же домене = безопасно?

#c# #angular #asp.net-core #authentication #cookies

#c# #angular #asp.net-core #аутентификация #файлы cookie

Вопрос:

Мне еще предстоит найти пример аутентификации Angular с использованием серверной части .NET Core Web API и аутентификации с использованием файлов cookie. Еще в 2019 году я обнаружил, что пока angular SPA обслуживается из того же домена, что и API, использовать аутентификацию с использованием файлов cookie «нормально».

Reference:
https://damienbod.com/2019/01/20/is-a-spa-less-secure-than-a-server-rendered-web-application/

Angular

 const credentials = {
    UserName: userName,
    Password: password
};
this.httpClient.post<AuthorizationInfo>(url, credentials, { withCredentials: true });
 

.NET Core 5.0 Web API (код удален для краткости)

 (startup.cs)
            // Configure cookie authentication.
            services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme).AddCookie(options => {
                options.Cookie.Name = AUTH_COOKIE_NAME;
                options.Cookie.SameSite = SameSiteMode.Strict;
                options.Cookie.HttpOnly = true;
                options.Cookie.SecurePolicy = CookieSecurePolicy.SameAsRequest;
                options.Cookie.IsEssential = true;
                options.SlidingExpiration = true;
            });

(AuthenticationController.cs)
[HttpPost]
public async Task<AuthorizationInfo> Login([FromBody] UserInfo credentials)
{
    if (this.authenticationStore.Authenticate(credentials.UserName, credentials.Password))
    {
        // ... (claims)

        // Create the user's identity and create an authorization cookie.
        ClaimsIdentity claimsIdentity = new ClaimsIdentity(claims, CookieAuthenticationDefaults.AuthenticationScheme);
        await this.HttpContext.SignInAsync(CookieAuthenticationDefaults.AuthenticationScheme, new ClaimsPrincipal(claimsIdentity), new AuthenticationProperties() {
            IsPersistent = true
        });

        return new AuthorizationInfo() {
            UserName = user.UserName,
            Roles = roleNames
        };
    }
    else 
    {
        // ...
    }
}
 

С помощью приведенной выше реализации после успешной аутентификации клиент отправит файл cookie на все остальные запросы, и все это работает отлично и удивительно просто.

Вопрос на миллион долларов: есть ли что-то принципиально неправильное в вышеупомянутом подходе, например, плохая практика смешивать SPA и аутентификацию cookie в одном домене? Можете ли вы предоставить какие-либо онлайн-доказательства в поддержку своих утверждений?

Я уже знаю аргумент о том, что обслуживание вашего приложения и логики идентификации из одного и того же приложения не является хорошей практикой. Кроме того, я искал повсюду какие-либо доказательства, свидетельствующие о том, что приведенная выше реализация является «плохой практикой», но я не нашел ни одного. Отсутствие доказательств не означает, что это хороший шаблон или не «плохой шаблон». Каждый пример Angular или SPA, который я вижу, использует отдельные серверы или службы идентификации, токены, oidc и т. Д.

Бонус: существуют ли какие-либо неосновные, но неотъемлемые аспекты / риски, о которых следует знать при таком подходе, которые следует смягчить, такие как CSRF и т. Д.? (Любые ссылки приветствуются, но не требуются, поскольку вопрос очень широкий).

Комментарии:

1. Я думаю, что вопрос о том, является ли проверка подлинности файлов cookie «плохой», не так хорош, как вопрос: при использовании всех технологических компонентов (angular, asp.net ядро) какие подходы к аутентификации являются популярными? Могут быть веские причины для использования не столь распространенного подхода, но я думаю, что лучше сначала найти наиболее распространенный. Почему бы не попробовать oauth? что привязывает вас к использованию файлов cookie? Если бы вы могли изложить свой аргумент в пользу использования файлов cookie на основе oauth, это может помочь читателям понять.

2. SPAS и OAuth страдают от некоторых проблем, которые имеют некоторые обходные пути. К сожалению, это непросто, но я считаю, что эта статья действительно хороша и затрагивает многие моменты, включая проверку подлинности файлов cookie: brockallen.com/2019/01/03 /…

3. @jbooker Как архитектор программного обеспечения, по иронии судьбы неопытный в веб-разработке, После проведения исследований по аутентификации, SPA и т. Д. Еще в 2019 году стало ясно, что OAuth — это правильный путь. Это было / было «отраслевым руководством». Тем не менее, мы изо всех сил пытались реализовать это технически, и очень опытный сотрудник настаивал на «проверке подлинности файлов cookie в том же домене / приложении» и смог реализовать это довольно легко. Я не за или против этого, так как из-за недостатка опыта у меня нет возможности узнать, действительно ли это неправильно. Простота приветствуется, но полный объем рисков мне неизвестен.

4. @jpgrassi Да, та статья, которую вы опубликовали, была потрясающей, когда я прочитал ее тогда. Если бы не эта статья, я бы остановил нас от продвижения вперед с проверкой подлинности с использованием файлов cookie. Согласно draft-ietf-oauth-browser-based-apps-07 , в нем говорится: «OAuth добавляет дополнительные векторы атак, которых можно избежать с помощью другого решения». и «Вместо этого более безопасный дизайн заключается в использовании HTTP-файла cookie только между приложением JavaScript и API, чтобы JavaScriptкод не может получить доступ к самому значению cookie «.

5. @jbooker Смотрите мою ссылку и комментарий выше, которые, по-видимому, дают самый сильный аргумент в пользу проверки подлинности файлов cookie в нашей простой архитектуре приложения. Независимо от того, сделали ли мы это «правильно», я не знаю на 100%, поскольку я не могу найти ни одного примера аутентификации файлов cookie в том же домене.