Как обрабатывать авторизацию и аутентификацию на SPA с OAuth2?

Question

Я занимаюсь разработкой SPA и хотел бы иметь SSO. Как я понял до сих пор, OAuth2 с OIDC - лучшее решение для SPA SSO. Лучше, чем, например, SAML.

Пока я не понял, как использовать токен авторизации в JS-коде SPA для обработки авторизации на различных ресурсах SPA. Например, я хотел бы, чтобы пользователи с ролью «покупатель» имели доступ к вкладке истории покупок, к которой другие пользователи не будут иметь доступа.

Должен ли я анализировать токен доступа, полученный с сервера авторизации, в коде JS и проверять, имеет ли пользователь подходящую роль для просмотра вкладки, или это решение должно приниматься на стороне сервера (API), и в этом случае код SPA будет просто читать ответ от API и на основе чего настраивать пользовательский интерфейс?
В случае первого подхода, есть ли какой-либо стандартный способ проверки (в виде некоторой библиотеки JS)?

Что касается аутентификации, какой подход лучше (более безопасный и т. Д.):

• чтобы SPA (в этот момент уже загруженный в браузер) выполнял процесс аутентификации, а на основе результата пользователь мог использовать свои защищенные функции. Фактически это псевдо-аутентификация, поскольку код находится в браузере пользователя и означает, что пользователь аутентифицирует себя для кода, который находится в его руках, то есть для себя. Имеет ли смысл эта аутентификация?
• требует, чтобы пользователь аутентифицировал себя, чтобы иметь возможность даже загружать SPA в своем браузере. Вероятно, это не архитектура SPA, поскольку бэкэнд, обслуживающий SPA, должен иметь возможность создавать обратный канал с сервером аутентификации.

Answer 1

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

ИМО это не обязательно нарушает архитектуру SPA. То, что вы делаете - это изменяете то, что вы используете на сервере, на основании представленных вам токенов. Кроме того, поддержание сеанса потребуется при таком подходе А вызовы SPA для бэкенда должны будут содержать этот сеанс для получения содержимого.

Answer 2

Как только пользователь войдет в систему, вы запросите аутентификацию и на основе его UserId, и роль, которой он принадлежит, должна получить все разрешения, на которые пользователь имеет право.

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

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