Как взаимодействовать с back-end после успешной аутентификации с OAuth на front-end?
Я хочу создать небольшое приложение. Будут некоторые пользователи. Я не хочу создавать собственную пользовательскую систему. Я хочу интегрировать свое приложение с oauth/oauth2.0.
нет проблем в интеграции моего интерфейсного приложения и oauth 2.0. Есть очень много полезных статей, как это сделать, даже на stackoverflow.com. Например этот пост очень полезная.
но. Что делать после успешной авторизации на front-end? Конечно, я может просто иметь флаг на клиенте, который говорит: "Хорошо, приятель, пользователь аутентифицирован", но как я должен взаимодействовать с моим бэкэндом сейчас? Я не могу просто сделать несколько запросов. Back-end-некоторое приложение, которое предоставляет функции API. Каждый может получить доступ к этому api.
Итак, мне нужна система auth в любом случае между моим FE и BE. Как должна работать эта система?
ps у меня есть некоторые проблемы с английским языком, и, возможно, я не могу просто правильно "спросить google" об этом. Можете ли вы предоставить правильный вопрос, пожалуйста :) или, по крайней мере, дайте некоторые статьи о моем вопросе.
UPD
Я ищу концепцию. Я не хочу искать решение моей текущей проблемы. Я не думаю, что это имеет значение, какие FE и BE я использую (в любом случае я буду предоставьте информацию об этом ниже)
FE и BE будут использовать JSON для связи. FE сделает запросы, будет отправлять ответы JSON. Мое приложение будет иметь такую структуру (возможно):
- фронтэнд - наверное, в AngularJS
- Backend-вероятно Laravel (laravel будет реализовывать логику, также есть база данных в структуре)
возможно, "поставщик услуг", как google.com, vk.com, twitter.com etc запоминает состояние пользователя? И после успешной аутентификации на FE, я могу просто спросить о состоянии пользователя из BE?
6 ответов
у нас есть 3 основные проблемы безопасности при создании API.
-
проверка подлинности: поставщик идентификации, такой как Google, является только частичным решением. Поскольку вы не хотите предлагать пользователю войти в систему / подтвердить свою личность для каждого запроса API, необходимо реализовать аутентификацию для последующих запросов самостоятельно. Вы должны хранить, доступный для бэкэнда:
- идентификатор пользователя. (взято, например, у поставщика удостоверений: электронной почты)
- маркер пользователя. (Временный токен, который вы создаете, и можете проверить код API)
авторизация: ваш сервер должен реализовывать правила на основе идентификатора пользователя (это ваш собственный бизнес).
транспортной безопасности: HTTPS и истекающие cookies являются безопасными и не воспроизводимыми другими. (HTTPS шифрует трафик, поэтому побеждает атаки "человек в середине" и истекает cookies побеждает атаки повтора позже во времени)
таким образом, ваш 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
другое:
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
Я очень внимательно прочитал все ответы, и более половины людей, которые ответили, полностью пропустили вопрос. OP запрашивает начальное соединение между FE & BE после того, как маркер OAuth был выдан поставщиком услуг.
Как ваш бэкэнд знает, что токен OAuth действителен? Хорошо имейте в виду, что ваш BE может отправить запрос поставщику услуг и подтвердить действительность токена OAuth, который был впервые получен вашим FE. Этот Протокол OAuth ключ может быть расшифрован поставщиком услуг только потому, что только у них есть секретный ключ. Как только они расшифруют ключ, они обычно будут отвечать такой информацией, как имя пользователя, электронная почта и тому подобное.
в итоге:
ваш FE получает маркер OAuth от поставщика услуг после авторизации пользователя. FE передает токен OAuth. Be отправляет маркер OAuth поставщику услуг для проверки маркера OAuth. Поставщик услуг отвечает, чтобы быть с именем пользователя / электронной почтой. Тогда вы можете используйте имя пользователя / email для создания учетной записи.
затем после того, как ваш BE создает учетную запись, ваш BE должен генерировать свою собственную реализацию токена OAuth. Затем вы отправляете свой Fe этот токен OAuth, и по каждому запросу ваш FE отправит этот токен в заголовок вашему BE. Поскольку только ваш BE имеет секретный ключ для проверки этого токена, ваше приложение будет очень безопасным. Вы даже можете обновить токен OAuth вашего BE по каждому запросу, каждый раз давая вашему FE новый ключ. В случае кто-то крадет токен OAuth из вашего FE, этот токен будет быстро аннулирован, так как ваш BE уже создал бы новый токен OAuth для вашего FE.
есть больше информации о том, как ваш BE может проверить токен OAuth. как проверить маркер доступа OAuth 2.0 для сервера ресурсов?
Ну, вам не нужна пользовательская система на передней стороне. Передняя часть-это просто способ взаимодействия с вашим сервером и запроса токена действительным пользователем и паролем.
ваш сервер должен управлять пользователями и разрешениями.
сценарий входа пользователя
пользователь запрашивает токен, введя свое имя пользователя и пароль. Сервер-API принимает запрос, потому что это анонимный метод (каждый может вызвать этот метод без забот, если он зарегистрирован внутри или нет.
сервер проверяет БД (или некоторое хранилище) и сравнивает данные пользователя с данными, которые у него есть. В случае совпадения сведений сервер вернет пользователю маркер.
теперь пользователь должен установить этот токен с любым запросом, чтобы сервер распознал пользователя. Маркер фактически содержит роли пользователя, метку времени и т. д...
когда пользователь запрашивает данные API, он извлекает токен пользователя из заголовка и проверяет, является ли пользователь разрешен доступ к этому методу.
вот как это работает в целом.
я основывался на .NET в моем ответе. Но большинство библиотек BE работает именно так.
Как я делаю проект для SSO и на основе моего понимания вашего вопроса, я могу предложить вам создать конечную точку в вашем бэк-энде для создания сеансов, как только клиент-интерфейс-успешно авторизован владельцем учетной записи и получил информацию о пользователе от поставщика, вы отправляете эту информацию в конечную точку бэк-энда, конечная точка бэк-энда генерирует сеанс и сохраняет эту информацию, и отправьте обратно идентификатор сеанса-часто называемый jSessionId - с файлом cookie назад к клиенту-frontend - так что браузер может сохранить его для вас и каждый запрос после этого к задней части считается аутентифицированным пользователем.
чтобы выйти из системы, просто создайте другую конечную точку в back-end, чтобы принять идентификатор сеанса, чтобы back-end мог его удалить.
Я надеюсь, что это будет полезно для вас.
давайте использовать концепцию OAuth для начала, FE вот клиент , здесь Ресурсов Сервера.
- поскольку ваш клиент уже авторизован, сервер авторизации должен предоставлять маркер доступа клиенту.
- клиент делает запрос на сервер ресурсов с помощью маркер доступа
- сервер ресурсов проверяет маркер доступа ， если действительно, обрабатывать запрос.
вы можете спросить, Что такое маркер доступа, маркер доступа был выдан сервером авторизации, предоставлен клиенту и распознан сервером ресурсов.
маркер доступа строка указывает информацию об авторизации(например, информацию о пользователе, область разрешений, истекает время...).
маркер доступа может шифроваться для безопасности, и вы должны убедиться, что сервер ресурсов может расшифровать его.
для более подробной информации, пожалуйста, прочитайте что OAuth2.0 спецификация https://tools.ietf.org/html/rfc6749.
вам нужно сохранить токен в состоянии вашего приложения, а затем передать его на серверную часть с каждым запросом. Переход на бэкэнд может быть выполнен в заголовках, cookies или как params - зависит от того, как реализован бэкэнд.
следуйте коду, чтобы увидеть хороший пример всех частей в действии (не мой код) В этом примере задается заголовок токена Authorization: Bearer https://github.com/cornflourblue/angular-registration-login-example