Ответ 1
Я думаю, вы в основном столкнулись с основной проблемой с помощью OAuth2.0. OAuth2.0 - это только протокол авторизации. Вам нужна модель безопасности, которая поддерживает как аутентификацию, так и авторизацию.
Представляем OpenId Connect
OpenId Connect - это уровень аутентификации, построенный на уровне авторизации OAuth2.0. Он обеспечивает простой способ проверки конечного пользователя на основе аутентификации, выполняемой на фоновом сервере/службе. Кроме того, он может передать базовый профиль о пользователе в RESTful HTTP API для авторизации с использованием JSON.
"
OpenId Connectпозволяет использовать целый ряд клиентов, включая веб- мобильных и JavaScript-клиентов, запрашивать и получать информацию об аутентифицированных сеансах и конечных пользователях. Набор спецификаций расширяемый, поддерживающий дополнительные функции, такие как шифрование идентификационные данные, обнаружение поставщиков OpenID и управление сеансами". - Wikipedia
Для .NET существует пакет Nuget для компонента Identity Server, называемый IdentityServer3. Существует довольно углубленное начало учебника о том, как получить простой MVC/Web-API, работающий с IdentityServer3.
Веб-приложения против веб-API и Cookies против токенов
-
Обычно веб-приложения являются традиционными серверными приложениями, использующими аутентификацию на основе файлов cookie.
-
С другой стороны, веб-API представляют для нас новую породу приложений, как правило, одностраничных приложений (таких как Angular, Ember, Backbone и т.д.) или собственных мобильных приложений (таких как iOS, Android, и т.д.), которые потребляют API (написанные в Node, Ruby, ASP.NET или даже их сочетание) и будут пользоваться аутентификацией на основе токенов.
Вы можете прочитать эти статьи для большего контекста: Cookies vs Tokens. Получение прав с помощью Angular.JS и 10 вещей, которые вы должны знать о токенах.
-
Проверка подлинности на основе cookie реализуется каждой веб-платформой по-разному, но в конце дня все они устанавливают некоторый файл cookie (привязанный к сеансу на сервере), который представляет собой "аутентифицированный пользователь". По каждому запросу этот cookie отправляется и сеанс десериализуется из некоторого хранилища (в памяти, если это один сервер или некоторое постоянное хранилище, если это ферма серверов).
-
Аутентификация на основе токена реализуется путем создания токена, когда пользователь аутентифицируется, а затем устанавливает этот токен в заголовке авторизации каждого последующего запроса в ваш API. Вы хотите, чтобы этот токен был чем-то стандартным, например, JSON Web Tokens, так как вы найдете библиотеки на большинстве платформ, и вы не хотите делать свой собственный крипто.
-
Для обоих подходов вы можете получить одинаковое количество информации от пользователя. Это контролируется параметром области, отправленным в запросе на вход.
-
Вы можете смешивать аутентификацию на основе токена с аутентификацией на основе файлов cookie. Учтите, что файлы cookie будут работать очень хорошо, если веб-приложение и API будут обслуживаться из одного домена, поэтому вам может не понадобиться аутентификация на основе токенов. Если вы хотите вызывать свои API из JavaScript (вместо использования существующего файла cookie), то вам нужно установить id_token на свою веб-страницу. Один из способов сделать это - установить на своей макете/главной странице что-то вроде window.token = <% = id_token% > ; и затем вы получите его из любого места в своем JavaScript-коде.
PS Это отличный видео по теме под названием "Объединение аутентификации и делегированного доступа к API для мобильных устройств, Интернета и рабочего стола с помощью OpenID Connect и OAuth2 от Доминика Байера". Это должно помочь пролить свет на ограничения OAuth2.0 и то, как OpenId Connect пытается их решить.