Реализация Oauth. Куда следует перенаправить использование после аутентификации третьей стороной?

Question

Я впервые использую OAuth, поэтому я просто пытаюсь обернуть голову вокруг всего потока.

Я пытаюсь реализовать OAuth для Stripe Connect . Итак, на шаге 4 вы отправляете POST-запрос со своим клиентским секретом на серверы Stripe, что, как я полагаю, означает, что ваш бэкэнд будет обрабатывать это.

Хочу убедиться, что я правильно об этом думаю. После аутентификации пользователя в Stripe они будут перенаправлены на указанную вами ссылку (с кодом авторизации в качестве параметра). Предполагаете ли вы перенаправить обратно клиенту переднего плана, а затем клиент переднего плана отправляет этот код авторизации на ваш сервер, который затем отправит его и секрет клиента в Stripe? Или вы перенаправили бы на какой-нибудь маршрут на вашем бэкэнде, который затем взял бы код авторизации и снова перенаправил бы пользователя на клиент переднего плана (на один сетевой запрос меньше)?

edit: Глядя на этот пример . Таким образом, кажется, что пользователь фактически сделает запрос GET на ваш сервер, который перенаправит их в Stripe, а затем выполнит еще один запрос GET на другой маршрут на вашем сервере после аутентификации.

edit 2: После еще нескольких копаний я собираюсь сделать следующее:

1. Пользователь нажимает «Подключиться к Stipe», и клиент переднего плана отправляет запрос GET на мой сервер.
2. Мой сервер использует uuid / v4 для генерации случайной строки, а base64 ее кодирует.
3. Некодированная строка сохраняется в моей базе данных, а закодированная строка добавляется в качестве параметра состояния.
4. Мой сервер перенаправляет пользователя на Oauth-связь Stripe с закодированным состоянием в качестве параметра.
5. Пользователь авторизуется с помощью Stripe и перенаправляется на страницу загрузки моего внешнего интерфейса.
6. Клиент переднего плана отправляет запрос POST на мой сервер с кодом авторизации от Stripe и состоянием.
7. Мой сервер декодирует состояние и сверяет его с состоянием в базе данных.
8. Если состояния совпадают, мой сервер отправляет POST-запрос Stripe с кодом авторизации и секретом клиента.
9. Stripe отправляет моему серверу идентификатор учетной записи пользователя, который затем сохраняется в модели пользователя моей базы данных.

Answer 1

Лично я перенаправил бы их на интерфейсную страницу, которая отправляет код авторизации на мой бэкэнд-сервер, чтобы я мог отобразить загрузочную анимацию, пока я заканчиваю делегированный процесс авторизации пользователя. Таким образом, пользователь знает, что происходит, и не остается висеть на медленном сервере идентификации / авторизации. В любом случае, все в порядке, и перенаправление на маршрут в «бэкэнде» (тот, у которого нет представления внешнего интерфейса - это то, что я имею в виду), которое в конечном итоге перенаправит пользователя на маршрут с представлением внешнего интерфейса (в зависимости от того, была ли выполнена авторизация). в случае успеха или неудачи) тоже будет хорошо.

Answer 2

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

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

Я тоже сначала запутался с вещами OAuth.

Ответ на вопрос редактора № 2:

На # 2 я не уверен, есть ли необходимость поразить ваш сервер перед отправкой первоначального запроса в Stripe. Эти кнопки «зарегистрироваться через ..» довольно часто имеют прямую ссылку на сервис. Таким образом, может быть кнопка <a>, которая имеет что-то вроде href="https://connect.stripe.com/express/oauth/authorize?redirect_uri={URL}&client_id={ID}&state={STATE_VALUE}". STATE_VALUE может быть сгенерировано, когда пользователь заходит на страницу.

Затем, когда пользователь нажимает кнопку, он переходит на страницу регистрации / входа в Stripe. Когда пользователь заканчивает заполнять форму, Stripe переводит пользователя на «redirect_uri». Здесь (# 5), я не совсем уверен, что вы подразумеваете под «Пользователь перенаправлен на страницу загрузки на моем конце». Я думаю, это URL вашего приложения, поэтому этот запрос должен попасть на ваш сервер. Страница, с которой только что пришел пользователь, не может получить и обработать ответ, если запрос не был сделан ajax. В случае Stripe похоже, что их поток предназначен для простых html-запросов. (Некоторые сервисы могут делать это через ajax, и в этом случае обработка кода выполняется во внешнем коде.)

Итак, именно ваш сервер получает код авторизации от Stripe. Сервер проверяет STATE_VALUE, отправляет POST-запрос на Stripe с кодом авторизации, получает секретные ключи / ключи обновления от Stripe. Затем сервер может ответить пользователю с помощью любой подходящей страницы.

Я полагаю, что ваш сервер мог бы сразу ответить перед выполнением последнего запроса POST, а внешний код мог сделать это через ajax и показать страницу загрузки во время выполнения запроса. Однако я не согласен с тем, что это хороший вариант; по моему мнению, он может раскрыть конфиденциальную информацию, и время загрузки недостаточно велико, чтобы быть плохим UX.

Итак, с точки зрения браузера,

Когда пользователь нажимает ссылку для входа в систему Stripe

-> делает запрос на страницу авторизации Stripe

-> получает страницу, содержащую форму от Stripe

Когда пользователь отправляет форму Stripe

-> делает запрос в Stripe для отправки формы

-> получает 302 от Stripe, перенаправляя на URL перенаправления вашего приложения (содержащий код авторизации)

-> делает запрос на ваш сервер

-> получает новую страницу с вашего сервера

Не стесняйтесь комментировать / исправить.