Способ 1

Использовать класс WebSecurity
WebSecurity сохраняет информаию о пользователе в свои таблицы в базе данных.

Минусы:
• WebSecurity может работать только с Microsoft SQL Server базами данных.
Он не может работать с MySQL, NoSQL, поскольку использует специфичные для MS SQL Server выражения SQL.
• WebSecurity создает 5 таблиц в базе данных (мне кажется это излишне)

Способ 2

ASP.NET Forms Auth

Работает так:

• Вызов FormsAuthentication.SetAuthCookie или FormsAuthentication.RedirectFromLoginPage выставляет cookie, в котором лежит зашифрованный username.

• Глобальный HTTP Module просматривает все запросы и если види куку - аутентифицирует запрос.

Минусы:
• Подвержен атаке CSRF - любой левый сайт может отрендерить форму, которая сделает POST в ваше приложение, и этот POST пройдет. Для не-апи от этого спасает стандартный механизи Anti Forgery. Для API - не спасает ничего.

• Не дает сохранить в куку ничего, кроме username. Поэтому вы вынуждены или на каждом запросе вычитывать дополнительные данные для юзера из базы, или вписывать вместо username что-то свое.

• Не позволяет отзывать cookies. Нет механизма вылогинивания пользователя раз и навсегда.

Пример:
Аутентификация (login/register/logout) в ASP.NET MVC используя аутентификацию форм FormsAuthentication.SetAuthCookie(model.Name, true);

Способ 3

Cookie Authentication из ASP.NET Core Identity

По сути, исправленная версия Forms Auth. Несмотря на то, что является частью ASP.NET Identity, может быть использован и без него.

Работает по тому же принципу, что FormsAuth, но исправляет основную проблему:

Позволяет сохранять в cookie не просто username, а набор claims (утверждений, вида имя: а, роль: б, id пользователя: 5), что позволяет приложению не лезть в базу на каждом запросе и не использовать хитрые схемы сериализации JWT в username.

При этом cookie все равно вечные, неотзывные (валидация "отозвано/не отозвано" лежит на разработчике, через событие ValidatePrincipal).

Способ 4

OAuth Bearer Tokens

Механизим, позволяющий надежно аутентифицировать пользователя на основе заголовка Authentication: Bearer. Предназначен для API и для SPA приложений.

Решает проблемы CSRF и проблему отзыва.

CSRF: Вместо cookie используется http header, который клиентская часть должна сама добавлять в каждый запрос. Нет подставляемой автоматически cookie - нет CSRF.

Отзыв: токены разделяются на два вида:
• access_token - короткоживущий, stateless, используется для аутентификации.
• refresh_token - должгоживущий, обычно statefull, используется для выдачи новых access_token.
Минус - не применим в не-SPA приложении, т.к. браузер сам не шлет соответствующий заголовок.

Процесс подключения:

В качестве основы можно взять стандартный не-core шаблон ASP.NET Web App): Cоответствующий middleware уже будет подключен в самом шаблоне, вызовом app.UseOAuthBearerTokens(OAuthOptions).

Если у вас отдельная, не SPA страница логина, то со стороны бэкенда - все готово (наиболее вероятный случай)
• Редиректите всех подряд (до логина) на /Account/Authorize?client_id=web&response_type=token&state=
• Пользователю показывает страницу логина
• После логина - его редиректит на /#access_token=nRUQN1j-wVFoMQ....
• Берете токен и шлете его в заголовке вида Authentication: Bearer nRUQN1j-wVFoMQ....

И выставляете лайфтайм токена таким, чтобы он не заканчивался в течении одной пользовательской сессии (в смысле одного посещения приложения).

По сути вы получаете Cookies Auth для приложения + OAuth для API.

Если у вас интегрированная в SPA страница логина - вам придется получать токены ajax-запросом к '/token', предъявляя grant (в вашем случае - password):
• На сервере: переопределяете ApplicationOAuthProvider.GrantResourceOwnerCredentials так, чтобы он проверял имя и пароль, и пропускал тех, кого нужно.

• На клиенте: отправляете имя и пароль в виде
Content-Type: application/x-www-form-urlencoded
grant_type=password&username=johndoe&password=A3ddj3w

• Получаете токен, шлете его в каждом запросе.

Вывод: Сторонний SSO -по сути сводится к тому, что ваше приложение проверяет аутентификацию/авторизацию пользователя где-то на стороне, и по ее прохождению залогинивает пользователя в самого себя, используя механизи Cookie Auth. Т.е. случай "подключен SSO" с точки зрения работы с Web API сводится к случаю "Cookies Auth для приложения + OAuth для API" выше.