OAuth

OAuth (в текущей версии OAuth 2.0) — это открытый протокол авторизации, который позволяет пользователю предоставить одному приложению ограниченный, чётко очерченный доступ к своим данным в другом приложении — не передавая при этом свой пароль запрашивающему приложению. Именно этот протокол лежит в основе любого сценария вида «Войти через Google», «Подключить Slack» или «Разрешить этому приложению доступ к вашему Gmail». OAuth по сути занимается авторизацией (что приложению разрешено делать), а это отдельное понятие от аутентификации (подтверждения того, кто есть пользователь) — хотя OpenID Connect (OIDC) добавляет слой аутентификации поверх OAuth 2.0, поэтому сценарии «Войти через Google» используют именно OIDC. Стандартный поток OAuth 2.0 «Authorization Code», наиболее актуальный для SaaS-разработчиков, интегрирующихся со сторонними API, работает так: ваше приложение перенаправляет пользователя на URL авторизации провайдера с запрошенным `scope` (например, `read:calendar`); пользователь подтверждает запрос на собственном экране согласия провайдера; провайдер перенаправляет обратно в ваше приложение с одноразовым кодом авторизации `code`; ваш бэкенд обменивает этот код (вместе с client secret вашего приложения) на `access_token` и `refresh_token`; далее приложение добавляет access token в заголовок `Authorization: Bearer {token}` при каждом последующем вызове API и использует refresh token для получения нового access token после истечения срока действия старого (обычно через 1 час). Конкретный пример: SaaS для планирования встреч хочет читать Google Календарь пользователя, чтобы проверять его занятость. Он перенаправляет на `https://accounts.google.com/o/oauth2/v2/auth?client_id=...&scope=https://www.googleapis.com/auth/calendar.readonly&response_type=code&redirect_uri=https://yourapp.com/oauth/callback`. Пользователь подтверждает; Google перенаправляет на `https://yourapp.com/oauth/callback?code=4/0AY0e-g7...`; ваш бэкенд отправляет этот код POST-запросом на токен-эндпоинт Google и получает в ответ `{"access_token": "ya29...", "refresh_token": "1//0g...", "expires_in": 3599}`. Приложение сохраняет refresh token в зашифрованном виде и вызывает Calendar API с access token, пока тот не истечёт, после чего незаметно его обновляет. Правильная организация хранения OAuth-токенов, логики их обновления и минимизации scope — частый источник уязвимостей в SaaS-интеграциях: утёкший refresh token равносилен постоянному «чёрному ходу» в подключённый аккаунт пользователя, поэтому в зрелых реализациях токены шифруют при хранении, каждый запрос ограничивают минимально необходимыми правами (никогда не запрашивают широкий «полный доступ к аккаунту», если достаточно доступа к календарю только на чтение) и поддерживают отзыв токенов, чтобы при отключении интеграции пользователем сохранённые учётные данные реально аннулировались, а не просто скрывался переключатель в интерфейсе. Из более новых спецификаций стоит знать PKCE (Proof Key for Code Exchange), которую теперь рекомендуют для всех OAuth-потоков, включая серверные, и device authorization grant (используется для телевизоров, CLI и других устройств с ограниченным вводом) — они расширяют базовый поток OAuth 2.0, закрывая конкретные пробелы в безопасности или поддерживая клиентов, которые не могут обработать стандартный редирект через браузер; любой SaaS-продукт, строящий публичную платформу для разработчиков, должен реализовывать PKCE по умолчанию, а не считать её нужной только для мобильных приложений.