Можно ли передавать клиенту токены доступа OAuth?

Question

Я все еще довольно новичок в веб-разработке. Я сам прошел через Веб-разработку с Node и Express от Этан Браун , и в настоящее время я пытаюсь получить хороший понимание примеров, приведенных Реакт-проектами с полным стеком Шама Хоке .

В настоящее время я пытаюсь реорганизовать многие вещи, которые раньше были серверными. сторонняя визуализация для обработки в клиенте React SPA. Одна из этих вещей включает простой виджет GitHub, мой предыдущий поток работал следующим образом:

1. Пользователь клиента аутентифицируется на моем сервере с помощью приложения GitHub OAuth.
2. Сервер сохраняет доступ Токен, возвращенный для обратного вызова в базе данных на сервере .
3. сервер выполняет вызовы API GitHub с использованием токена доступа пользователя, хранящегося в базе данных.
4. Сервер обрабатывает результаты, отображает их в HTML и отправляет их клиенту.

Однако я понял, что есть возможность реализовать его как this.

1. Пользователь клиента аутентифицируется на моем сервере с помощью приложения GitHub OAuth.
2. Сервер передает токен доступа, возвращенный для обратного вызова, клиенту

3. клиент выполняет вызовы API GitHub с использованием токена доступа пользователя, полученного с сервера.

4. клиент обрабатывает результаты и делает это уместно.

Насколько я понимаю, в этом нет никакой угрозы безопасности (недобросовестный пользователь может перехватить токен доступа, когда провайдер oAuth перенаправляет на обратный вызов в любом случае), и оба потока имеют свои вверх и вниз (например, 2-й поток создает меньшую нагрузку на сервер, но также жертвует контролем). Поскольку я новичок в этом и сам придумал второй поток, я хочу еще раз проверить, хорошо ли это делать, или я что-то пропустил, если так, что я пропустил? Есть ли какие-либо другие серьезные или отрицательные стороны, которые я не рассматриваю?

Answer 1

Реализован поток авторизации OAuth . В этом потоке клиент (он же браузер) никогда не получает токен доступа. Только ваш веб-сервер получает его. И, таким образом, клиент не может совершать звонки на сервер ресурсов (github). Ваш веб-сервер выполняет вызовы от имени клиента.

Вы говорите:

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

Однако, если вы правильно реализуете поток, это не так. Это связано с тем, что после аутентификации на сервере ресурсов он только дает браузеру аутентификацию код . Этот код является всего лишь временным билетом, который можно обменять на токен доступа. Однако, чтобы обменять код на токен доступа, вы должны знать секрет клиента. Только ваш веб-сервер знает секрет. Таким образом, ваш браузер отправляет код на ваш сервер, а ваш сервер вызывает сервер ресурсов (github) с кодом + secret для получения токена.

Второй поток, который вы описываете, это OAuth Implicit Flow .

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

Оба потока очень распространены. Поток Implicit немного менее защищен, потому что у плохих парней больше возможностей получить доступ к токену в памяти браузера (или в локальном хранилище, или в хранилище ie). Процесс авторизации немного более безопасен, поскольку токен остается на вашем сервере, и вам не нужно зависеть от пользователей, чтобы обеспечить его безопасность.