Использовать ли Microsoft Identity для авторизации web api?

Question

[Taras25]

Начал делать проект, состоящий из asp.net webapi на бэке, и vuejs на фронте.
Опыта у меня в таких делах маловато, так что хотелось бы поинтересоваться у знающих людей.
Как известно, в asp.net есть встроенный механихм для авторизации/аутентификации - Identity.
Но мне показалось, что он слишком перегружен всякой левой фигней, и недостаточно гибок для настройки.
К тому же, я хочу иметь БД в виде Mongo. Есть решения которые позволяют не писать свое хранилище, а взять уже готовые для Mongo, но я не уверен в них на 100%, все-таки это поделки какие-то, и возможно они далеки от оптимальности по скорости, и содержат баги.
Но основной вопрос все же об Identity - есть ли у кого-то опыт с его использованием?
Например, было решено его использовать, а в процессе было решено его выпилить и написать всю логику авторизации самостоятельно.
Планируется также использовать аутентификацию через социальные сети. В том числе те, которых нет в стандартной поставке .net

Answer 1

[Василий Банников]

> аутентификацию через социальные сети
Если они поддерживают oauth, то проблем не должно возникнуть.
Сам не пробовал Identity, но много людей им пользуется и я особых жалоб на него не слышал.
В принципе запилить велосипед с собственной авторизацией - это ок, но для аутентификации/идентификации лучше использовать что-то готовое. Из таких: IdentityServer и Hydra.
>возможно они далеки от оптимальности по скорости, и содержат баги.
Это можно определить по количеству пользователей. Если очень много людей используют его в продакшене, то, вероятнее всего, оно будет работать и у вас.

Answer 2

[Владимир Коротенко]

По порядку. В net core рекомендуют identity server 4 . Он таки позволяет как авторизацию из базы так и стандартный oauth2 в примерах Гугл фэйсбук Майкрософт и по моему яндекс. Геморроя правда много, особенно если хочешь авторизацию в одном приложении вместе с апи и спа. Если не смущает лишний домен то запилите авторизацию по шаблонному проекту и разместите его на другом домене. Либо пишите отправлю шаблон

Comments

[Taras25]

Я решил что Identity Server мне не нужен, потому что его основная фишка - быть доверенным центром для многих сервисов, то есть выдавать токены. А у меня все будет на одном домене располагаться, и на одном сервере. Для меня он избыточен.
Речь идет об обычном Identity.

[Владимир Коротенко]

Taras25, в том то и дело что они рекомендуют именно его. Я для своего проекта именно так и сделал завязал все на одну бд и одно приложение

Answer 3

[Виктор П.]

Добрый день всем любителям всем любителям дот нета )
Я использовал стандартную реализацию Identity во многих версиях .net, для маленьких проектов (в том числе коммерческих, но так же, не особо сложных). Всё работает, условно, из коробки. Но из-за того, что это очень гибкий инструмент, в нём очень много различных настроек, в которых довольно легко запутаться.
Именно из-за этого, при использовании стандартного Identity меня всегда не покидало ощущение перегруженности и не полного контроля кода в этом аспекте. Да и, собственно, когда хочется разобраться как всё работает, особенно в учебных целях, желательно своими руками выполнить соответствующие куски кода.
Желания прям выпилить стандартную реализацию и заменить всё своим кастомным решением у меня не было, так как архитектура (что будет использоваться) обычно планируется заранее и если стандартный Identity подходит, чего ж его выпиливать. Но в последнем проекте, например, я делал самостоятельно логику авторизации, хотя, при этом, оставив стандартные схемы аутентификации.
Если есть время/желание, могу показать, например, в дискорде.
p.s. я не работал с монгой, но это, вроде как, не принципиально в подходе code first при работе с базой

Comments

[RandomLucker]

А подскажите, пожалуйста, как человек имеющий опыт. На сколько нужно абстрагироваться от реализации авторизации на Identity внутри проекта, например WebApi? Хочется реализовать красиво архитектурно, а в примерах с мсдн всё прбивается гвоздями в проект апи. Хотелось бы взглянуть на какой-нибудь эталонный проект, где используется данная технология. Есть конкретные вопросы:
1. Позволяет ли ваша реализация с лёгкостью поменять технологию авторизации?
2. Реализована ли у вас в проектах паттерн-мишура(касательно именно функционала авторизации), типа провайдеры и всё такое?
3. Можно ссылочку на гит для примера?)

По факту технология авторизации - это тоже деталь, которая по хорошему должна быть отделена архитектурно. Я сделал её по туториалам мсдн, но понял что что-то не так, когда начал писать тесты на userService, и мне пришлось там мокать объект userManager из неймспейса Identity(т.к. он используется в DI). В этот момент я подумал что я делаю что-то не так, т.к. при изменении технологии авторизации придётся править еще и тесты.

[Виктор П.]

Привет,
Я не претендую на истину, просто из последнего примера (сейчас в процессе перепиливания)
Есть кастомный сервис с методами работы с базой, я там разделил пользователя на две таблицы (один к одному) системного юзера и профиль. Роли веду без базы просто в енуме, у пользователя есть массив ролей. (Ну и еще игрался с тем, что пользователь может заходить по никнейму, почте или телефону, возможно это кривовато)
Обычный контроллер, с тремя методами. Посмотрите снизу как реализован метод SignInAsync, там стандартное использование клаймсов из Security.Claims, в которые я засовываю гуид пользователя и массив доступных ролей и SignInAsync из AspNetCore.Authentication.
Подключается по классике всё в стартапе (в новой версии языка уже в Program.cs)

services
    .AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme)
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme, o =>
    {
        o.Cookie.HttpOnly = true;
        o.Events = new CookieAuthenticationEvents
        {
            OnRedirectToLogin = redirectContext =>
            {
                redirectContext.HttpContext.Response.StatusCode = 401;
                return Task.CompletedTask;
            }
        };
    });

// ...

app.UseAuthentication();
app.UseAuthorization();

Вопрос про изменение аутентификации, у меня на основе кукисов. Если бы я захотел перейти на авторизацию по токенам, то нужно было бы добавить метод получения токена в контроллере, в стартапе, собственно, изменить схему примерно так:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
                    .AddJwtBearer(options =>
...

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