- Вопрос или проблема
- Ответ или решение
- Аутентификация пользователей между серверами с использованием OAuth2
- Архитектура системы
- Этапы процесса аутентификации
- 1. Начало процесса аутентификации
- 2. Получение доступа через Гейт-сервер
- 3. Генерация токена доступа
- 4. Доступ к игровому серверу
- 5. Валидация токена и доступ
- Заключение
Вопрос или проблема
Допустим, у меня есть сервер A (веб-сервер). Пользователи первоначально используют внешний провайдер, такой как Google, для аутентификации на этом сервере. В моей базе данных создается запись о том, что этот пользователь вошел в систему раньше и подтвердил свою учетную запись. Теперь у них есть доступ к ресурсам, таким как форум, доступный с веб-сервера (по сути, мы создали для них локальную учетную запись).
Теперь пользователь хочет аутентифицироваться на сервере B (игровом сервере). Сервер B доступен через настольное приложение (игровой клиент) по протоколу TCP. Также у нас есть шлюзовой сервер C, который будет обрабатывать первоначальные запросы от настольных клиентов, прежде чем они смогут подключиться к серверу B.
Запись, созданная для этого пользователя ранее, необходима для доступа к серверам B и/или C. Следовательно, настольное приложение должно открыть браузер для аутентификации нашего пользователя на сервере A.
Каков общий порядок действий, необходимый для реализации такой системы? Меня беспокоит тот момент, что даже если сервер C знает, что пользователь аутентифицирован (обмениваясь токенами доступа с сервером A), какую информацию мы передаем настольному клиенту и серверу B, чтобы, когда клиент отключается от сервера C, они могли быть уверены, что сервер B не отклонит их попытку подключения (предполагая, что запрос легитимен)?
Сначала я бы определил все роли всех узлов, которые у вас есть. Смотря на вашу архитектуру, я бы предположил, что шлюзовой сервер (C) выполняет функции API Gateway для авторизации, который отвечает за управление токенами, необходимыми для всей аутентификации и авторизации. Веб-сервер (A) и игровой сервер (B) являются ресурсами, для доступа к которым требуется авторизованный пользователь (с использованием токена доступа OAuth2 или другого JWT).
Я бы определил поток следующим образом:
- Пользователь открывает настольный клиент, который направляет его на вход с помощью учетной записи Google.
- Google отвечает токеном идентификации (т.е. токеном JWT), и настольный клиент отправляет его на шлюзовой сервер (C) с информацией о своем client_id и ресурсе, к которому он хочет получить доступ (в виде скоупов – т.е. game_server).
- Сервер авторизации API Gateway (C) принимает токен идентификации и от его имени создает токен доступа (или другой токен авторизации в виде JWT) и отправляет его на настольный клиент, который безопасно сохраняет его.
- При каждом вызове игрового сервера (B) настольный клиент отправляет токен авторизации, и игровой сервер проверяет его, чтобы авторизовать запрос.
Важный момент здесь заключается в том, что токен авторизации необходимо безопасно хранить на стороне клиента. Это непросто, поэтому я бы рекомендовал использовать что-то вроде референсных токенов. В этом решении после получения игровым сервером (B) токена авторизации, ему необходимо отправить его на API авторизации, чтобы получить содержимое токена (претензии). Таким образом, в этом случае каждый запрос от настольного клиента к игровому серверу (B) приводит к дополнительному запросу от игрового сервера (B) к шлюзовому API авторизации (C).
Ответ или решение
Аутентификация пользователей между серверами с использованием OAuth2
Введение
В современном мире связи и интернет-технологий, использование протоколов аутентификации, таких как OAuth2, становятся всё более актуальным. В данной статье рассмотрим процесс аутентификации пользователей на сервере B, если они уже прошли аутентификацию на сервере A при помощи внешнего провайдера, например, Google.
Архитектура системы
Для наглядности, представим нашу систему, состоящую из трёх ключевых компонентов:
- Сервер A (Веб-сервер): отвечает за первоначальную аутентификацию через Google и хранит локальные учётные записи пользователей.
- Сервер B (Игровой сервер): обеспечивает доступ к игровым ресурсам.
- Сервер C (Гейт-сервер): выступает в роли промежуточного компонента, который обрабатывает запросы клиентов перед тем, как передавать их на сервер B.
Этапы процесса аутентификации
1. Начало процесса аутентификации
Пользователь запускает клиентское приложение (настольное приложение), которое перенаправляет его в браузер для аутентификации через Google. После успешного входа Google возвращает JWT токен, который подтверждает личность пользователя.
2. Получение доступа через Гейт-сервер
Токен, полученный от Google, передаётся от клиентского приложения на Гейт-сервер C вместе с клиентским ID и необходимыми правами доступа (scope) для ресурсного сервера (например, game_server).
Клиент → Гейт-сервер C: {id_token, client_id, scope}3. Генерация токена доступа
Гейт-сервер C принимает идентификационный токен (id_token), проверяет его подлинность и создает токен доступа (например, в формате JWT), который предоставляет клиенту. Этот токен следует безопасно хранить на клиенте.
Гейт-сервер C → Клиент: {access_token}4. Доступ к игровому серверу
Каждый раз, когда клиентское приложение хочет получить доступ к игровому серверу B, оно передает токен доступа в своих запросах.
Клиент → Игровой сервер B: {access_token}Игровой сервер B проверяет токен доступа. Чтобы убедиться, что токен действителен, сервер B может отправить запрос к Гейт-серверу C для получения информации о токене и его содержимом (claims). Это обеспечит дополнительный уровень безопасности и проверку подлинности.
5. Валидация токена и доступ
Игровой сервер B, получив токен от клиента, проверяет его с помощью запроса к Гейт-серверу C:
Игровой сервер B → Гейт-сервер C: {access_token}Гейт-сервер C возвращает информацию о токене, подтверждая, что он действителен и не истек. После успешной проверки сервер B предоставляет доступ к игровым ресурсам.
Заключение
Эта схема аутентификации обеспечивает надежный способ управления доступом к ресурсам на основе OAuth2. Использование Гейт-сервера C для управления токенами позволяет централизовать процесс проверки и минимизировать риски, связанные с аутентификацией. Важно следить за безопасностью хранимых токенов на стороне клиента, чтобы предотвратить несанкционированный доступ.
Таким образом, двухэтапный процесс аутентификации с использованием внешнего провайдера и Гейт-сервера отвечает современным требованиям безопасности и удобству пользователей, обеспечивая устойчивую архитектуру для работы с ресурсами на сервере B.