OAuth 2.0 — это один из самых распространённых протоколов авторизации в вебе и мобильных приложениях. Им пользуются Google, GitHub, Discord, Spotify, Facebook и множество SaaS-сервисов. Без OAuth2 сегодня сложно представить любое приложение, где нужна авторизация пользователей через сторонние сервисы.

Но несмотря на популярность, механизм часто неправильно понимают: OAuth2 — не аутентификация, а протокол делегирования прав доступа. Он позволяет одному сервису получить ограниченный доступ к данным пользователя на другом сервисе — без передачи логина и пароля.

Разберём, почему OAuth2 стал стандартом, как он работает внутри и какие потоки (flows) используются сегодня.

OAuth2 решает главную проблему старых систем

До OAuth2 существовали два варианта интеграции:

1. Пользователь сообщает приложение свои логин/пароль от другого сервиса (антирешение, небезопасное).
2. Сервисы делают аппаратную интеграцию через API-ключи, которые дают слишком много прав.

OAuth2 решил обе проблемы:

• логин/пароль никогда не передаются стороннему приложению;
• владелец сервиса может выдать приложению ограниченные права — только на чтение, только на запись, только выбранные ресурсы;
• пользователь в любой момент может отозвать разрешение, не меняя свой основной пароль.

Эта модель оказалась настолько удачной, что стала отраслевым стандартом.

Основные элементы OAuth2

OAuth2 состоит из четырёх ключевых ролей:

• Resource Owner — пользователь.
• Client — приложение, которое хочет получить доступ.
• Authorization Server — сервис, который выполняет авторизацию (Google OAuth, GitHub OAuth).
• Resource Server — API, где хранятся данные (например, GitHub API).

Основной принцип работы: токены вместо паролей

OAuth2 работает через выдачу специальных токенов:

Access Token

Короткоживущий токен доступа (обычно 10 минут – 1 час). С его помощью клиент обращается к API.

Refresh Token

Долгоживущий токен для обновления access token'а. Клиент не хранит пароль пользователя — он хранит refresh token.

ID Token (в OpenID Connect)

JWT-токен с информацией о пользователе.
Важно: это уже аутентификация, а OAuth2 сам по себе её не предоставляет.

Потоки (flows) OAuth2: когда какой использовать

OAuth2 определяет несколько вариантов работы.

1. Authorization Code Flow (веб-приложения)

Самый безопасный и основной поток.

Порядок такой:

1. Клиент перенаправляет пользователя на страницу авторизации провайдера.
2. Пользователь логинится.
3. Провайдер возвращает authorization code.
4. Клиент отправляет этот код на сервер и получает access token + refresh token.

Преимущества:
— Токены не ходят через браузер.
— Очень безопасно при использовании PKCE.

Используется в: Google OAuth для веба, GitHub OAuth, Discord OAuth.

2. Authorization Code Flow + PKCE (мобильные и SPA)

PKCE добавляет защиту от подмены кода.

SPA нельзя хранить секреты, поэтому PKCE (Proof Key for Code Exchange) решает это ограничение.
Сегодня — стандарт де-факто для фронтенда и мобильных приложений.

3. Client Credentials Flow (сервер-сервер)

Используется, когда нет пользователя. Например:

• бэкенд запрашивает токен у другого API;
• сервисы общаются друг с другом.

client_id + client_secret → access token

Без refresh token.

4. Device Authorization Flow (TV, Xbox, IoT)

Для устройств без клавиатуры.

5. Implicit Flow (устарел)

Сейчас не рекомендуют использовать.
Токен передавался через URL → небезопасно → заменён PKCE.

Почему OAuth2 стал стандартом

1. Безопасность без передачи паролей

Пользователь вводит пароль только на доверенном сайте провайдера.

Приложение получает токены, а не учётные данные.

2. Гибкая система разрешений

Права (scopes) позволяют выдать минимум доступа.

Например GitHub:

• repo:read
• user:email
• gist
• repo:write

Это помогает:

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

3. Управление жизненным циклом токенов

OAuth2 позволяет:

• отозвать токен,
• ограничить срок действия,
• выдать новый через refresh token.

Это лучше, чем постоянные API-ключи.

4. Подходит для любой архитектуры

OAuth2 одинаково хорошо работает:

• в веб-приложениях,
• в мобильных приложениях,
• в SPA,
• в микросервисах,
• в сервер-сервер взаимодействии.

5. Масштабируемость

Провайдер авторизации вынесен отдельно, что делает систему гибкой и масштабируемой.

Пример OAuth2 в реальной жизни (Google OAuth)

1. Пользователь нажимает кнопку «Войти через Google».
2. Его перекидывает на accounts.google.com.
3. Он логинится.
4. Google спрашивает: «Выдать ли приложению доступ к email?»
5. Пользователь подтверждает.
6. Приложение получает authorization code.
7. Сервер обменивает код на токены.
8. Приложение получает email, имя, аватарку и использует их в профиле.

OpenID Connect: аутентификация поверх OAuth2

OAuth2 — про авторизацию (доступ к ресурсам).

Для аутентификации используется OpenID Connect (OIDC) — надстройка над OAuth2, которая добавляет:

• ID Token (JWT),
• стандартный UserInfo endpoint,
• единый формат данных о пользователе.

OIDC используют: Google, Microsoft, Amazon, Okta, Auth0.

Типичные ошибки разработчиков

Хранение access token в localStorage

→ уязвимо к XSS.

Использовать: cookies + httpOnly + secure.

Использование Implicit Flow в SPA

Устарело.
Использовать: Authorization Code Flow + PKCE.

Долгоживущие access tokens

Сейчас нормальный срок — 5–15 минут.

Вывод

OAuth2 стал стандартом, потому что решает ключевые задачи безопасности:

• никакой передачи паролей;
• ограничение прав через scopes;
• управляемые токены;
• поддержка разных типов клиентов;
• независимый сервер авторизации.

Это делает OAuth2 универсальным и безопасным инструментом для современных веб- и мобильных приложений.