Ответ 1

У нас есть 3 основных проблемы безопасности при создании API.

• Аутентификация. Поставщик идентификации, такой как Google, является лишь частичным решением. Поскольку вы не хотите запрашивать у пользователя логин/подтверждение своей личности для каждого запроса API, вы должны реализовать аутентификацию для последующих запросов самостоятельно. Вы должны хранить, доступные для бэкэнд:

  • Идентификатор пользователя. (взято у поставщика удостоверений, например: электронная почта).
  • Пользовательский токен. (Временный токен, который вы создаете, и можете проверить из кода API)

• Авторизация. Ваш сервер должен внедрять правила, основанные на идентификаторе пользователя (в вашем собственном бизнесе).

• Транспортная безопасность. HTTPS и устаревшие файлы cookie безопасны и не воспроизводятся другими. (HTTPS шифрует трафик, поэтому он побеждает атаки "человек в середине", а истекшие файлы cookie поражают повторные атаки позже)

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

Здесь как работает поток в этой системе:

User-Agent    IdentityProvider (Google/Twitter)   Front-End    Back-End
 |-----------------"https://your.app.com"---------->|
                                                    |---cookies-->|
                                 your backend knows the user or not.
                                       if backend recognizes cookie, 
                          user is authenticated and can use your API

ELSE:

                                             if the user is unknown:
                                                    |<--"unknown"-|
                     |<----"your/login.js"----------+
                "Do you Authorize this app?"
 |<------------------+
 |--------"yes"----->|
                     +----------auth token--------->|
                     |<---------/your/moreinfo.js---|
                     |-------access_token ---------->|
                1. verify access token
                2. save new user info, or update existing user
                3. generate expiring, random string as your own API token
                                                    +----------->|
 |<-------------- set cookie: your API token --------------------|

СЕЙЧАС, пользователь может напрямую использовать ваш API:

 |--------------- some API request, with cookie ---------------->|
 |<-------------- some reply, depends on your logic, rules ------|

ИЗМЕНИТЬ

Основываясь на обсуждении - добавив, что бэкэнд может аутентифицировать пользователя, проверив токен доступа с поставщиком удостоверений:

Например, Google предоставляет эту конечную точку, чтобы проверить токен XYZ123:

https://www.googleapis.com/oauth2/v3/tokeninfo?id_token=XYZ123

Ответ 2

Ну, вам не нужна система User-System на стороне вашего фронта. Передняя часть - это всего лишь способ взаимодействия с вашим сервером и попросить токен действительным пользователем и паролем.

Ваш сервер должен управлять пользователями и разрешениями.

Сценарий входа пользователя

Пользователь запрашивает токен, введя его имя пользователя и пароль. Сервер-API принимает запрос, потому что он анонимный метод (каждый может вызвать этот метод без особого внимания, если он вошел в систему или нет.

Сервер проверяет БД (или некоторое хранилище) и сравнивает детали пользователя с деталями, которые у него есть. Если данные совпадают, сервер вернет токен пользователю.

Теперь пользователь должен установить этот токен с любым запросом, чтобы сервер распознал пользователя. Токен фактически содержит роли пользователя, временную метку и т.д.

Когда пользователь запрашивает данные по API, он извлекает токен пользователя из заголовка и проверяет, разрешен ли пользователю доступ к этому методу.

Как это работает в целом.

Я основывался на .NET в своем ответе. Но большая часть библиотек BE работает так.

Ответ 3

Я очень внимательно прочитал все ответы, и более половины людей, которые отреагировали, полностью лишены вопроса. OP запрашивает НАЧАЛЬНОЕ соединение между FE и BE, после того, как поставщик OAuth был выпущен поставщиком услуг.

Как ваш бэкэнд знает, что токен OAuth действителен? Хорошо помните, что ваш BE может отправить запрос поставщику услуг и подтвердить действительность токена OAuth, который был впервые получен вашим FE. Этот ключ OAuth может быть расшифрован поставщиком услуг только потому, что только у них есть секретный ключ. Как только они дешифруют ключ, они обычно будут отвечать информацией, такой как имя пользователя, адрес электронной почты и т.д.

Вкратце:

Ваш FE получает токен OAuth от поставщика услуг после того, как пользователь дает авторизацию. FE передает ток OAuth в BE. BE отправляет токен OAuth поставщику услуг для проверки токена OAuth. Поставщик услуг отвечает на BE с именем пользователя/электронной почты. Затем вы можете использовать имя пользователя/адрес электронной почты для создания учетной записи.

Затем, после того как ваш BE создаст учетную запись, ваш BE должен создать свою собственную реализацию токена OAuth. Затем вы отправляете свой FE этот токен OAuth, и по каждому запросу ваш FE отправит этот токен в заголовок вашего BE. Поскольку только ваш BE имеет секретный ключ для проверки этого токена, ваше приложение будет очень безопасным. Вы можете даже обновить токен BE OAuth по каждому запросу, каждый раз добавляя свой FE новый ключ. Если кто-то украл токен OAuth из вашего FE, этот токен будет быстро недействителен, так как ваш BE уже создал новый токен OAuth для вашего FE.

Там больше информации о том, как ваш BE может проверить токен OAuth. Как проверить токен доступа OAuth 2.0 для сервера ресурсов?

Ответ 4

Как я делаю проект для единого входа и исходя из моего понимания вашего вопроса, я могу предложить создать конечную точку в вашем внутреннем блоке для создания сеансов, как только клиент-приказ успешно разрешен владелец учетной записи и получил информацию о пользователе от поставщика, вы отправляете эту информацию во внутреннюю конечную точку, конечная конечная точка создает сеанс и сохраняет эту информацию и отправляет обратно идентификатор сеанса, который часто называется jSessionId, с файлом cookie обратно к клиенту -frontend, поэтому браузер может сохранить его для вас, и каждый запрос после этого в фоновом режиме считается аутентифицированным пользователем.

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

Я надеюсь, что это будет полезно для вас.

Ответ 5

давайте использовать концепцию OAuth, FE здесь Клиент, BE здесь Сервер ресурсов.

• Поскольку ваш клиент уже авторизовался, сервер авторизации должен предоставить Доступ к токену для клиента.
• Клиент запрашивает сервер ресурсов с токеном доступа
• Сервер ресурсов проверяет токен доступа, если он действителен, обрабатывает запрос.

Вы можете спросить, что такое токен доступа, токен доступа был выпущен сервером авторизации, предоставлен клиенту и распознан сервером ресурсов.

Ток доступа - это строка, указывающая информацию авторизации (например, информация пользователя, область полномочий, время истечения срока действия...).

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

для более подробной информации, пожалуйста, прочтите спецификацию OAuth2.0 https://tools.ietf.org/html/rfc6749.

Ответ 6

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

Следуйте коду, чтобы увидеть хороший пример всех частей в действии (не мой код) В этом примере задается заголовок Authorization: Bearer TOKEN https://github.com/cornflourblue/angular-registration-login-example