Как происходит клиент-серверное взаимодействие в OAuth 2.0?

Как происходит клиент-серверное взаимодействие в OAuth 2.0?

• протокол авторизации, предоставляющий доступ к ресурсам
• три основные стороны: клиентское приложение, сервер авторизации и ресурсный сервер
• клиент получает разрешение пользователя, являющегося владельцем ресурса
• после аутентификации пользователя сервер авторизации выпускает токен доступа
• с помощью токена клиент обращается к ресурсному серверу
• токен подтверждает разрешённые права без раскрытия пароля
• предоставляет безопасный делегированный доступ к API и пользовательским ресурсам

Подробный ответ

Основной ответ

OAuth 2.0 — протокол авторизации, с помощью которого клиентское приложение получает ограниченный доступ к ресурсам пользователя на сервере без непосредственной передачи его учетных данных. Взаимодействие клиента и сервера в OAuth 2.0 основано на выдаче и проверке токенов доступа, благодаря чему авторизацию проще контролировать и защищать.

Ключевые моменты

• В схеме взаимодействия участвуют четыре основные стороны: Resource Owner (Пользователь), Client (Клиентское приложение), Authorization Server (Сервер авторизации) и Resource Server (Сервер ресурсов). Клиент обращается к серверу авторизации за разрешением действовать от имени пользователя, после чего получает токен доступа.
• Последовательность обычно выглядит так: клиент запрашивает разрешение пользователя, передаёт серверу авторизации код или иные учетные данные, затем сервер возвращает access token и, при необходимости, refresh token. Полученный токен клиент предъявляет для обращения к ресурсу.
• В OAuth 2.0 предусмотрено несколько грантов (flows): Authorization Code Flow применяется в серверных приложениях с backend, Implicit Flow предназначен для SPA, но считается устаревшим, Client Credentials Flow используется во взаимодействии сервер-сервер без пользователя, а Resource Owner Password Credentials применяется редко и считается небезопасным. Каждый flow соответствует определённому сочетанию требований к безопасности, удобству и контексту приложения.

Практический контекст

В прикладных проектах, например в React 18 SPA, для OAuth 2.0 часто выбирают Authorization Code Flow с PKCE, чтобы защититься от перехвата кода. Сервер авторизации обычно строят на OpenID Connect — надстройке над OAuth 2.0, используя, например, Keycloak или Auth0. Срок действия Access token делают коротким, например 5-15 минут, а refresh token сохраняют дольше, чтобы обновлять доступ без повторного входа. На Resource Server настраивают проверку токенов — JWT или introspection — перед предоставлением доступа к API.