[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-oauth::ru":3,"gloss-cluster-oauth::ru":20,"gloss-next-oauth::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"oauth","saas","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:\u002F\u002Faccounts.google.com\u002Fo\u002Foauth2\u002Fv2\u002Fauth?client_id=...&scope=https:\u002F\u002Fwww.googleapis.com\u002Fauth\u002Fcalendar.readonly&response_type=code&redirect_uri=https:\u002F\u002Fyourapp.com\u002Foauth\u002Fcallback`. Пользователь подтверждает; Google перенаправляет на `https:\u002F\u002Fyourapp.com\u002Foauth\u002Fcallback?code=4\u002F0AY0e-g7...`; ваш бэкенд отправляет этот код POST-запросом на токен-эндпоинт Google и получает в ответ `{\"access_token\": \"ya29...\", \"refresh_token\": \"1\u002F\u002F0g...\", \"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 по умолчанию, а не считать её нужной только для мобильных приложений.","OAuth — протокол авторизации, позволяющий пользователю дать приложению ограниченный доступ к данным в другом сервисе, не раскрывая пароль.",null,[11,14,17],{"slug":12,"name":13},"api-first","API-first (API-ориентированность)",{"slug":15,"name":16},"sso","Единый вход (SSO)",{"slug":18,"name":19},"webhook","Вебхук (Webhook)",[21,25,29,32,33,36,39,43,46,49,52,55],{"slug":22,"category":5,"name":23,"updated_at":24},"activation","Активация","2026-08-24T02:46:36+00:00",{"slug":26,"category":5,"name":27,"updated_at":28},"aha-moment","Ага-момент","2026-08-24T02:46:37+00:00",{"slug":30,"category":5,"name":31,"updated_at":28},"annual-contract-value","Годовая стоимость контракта (ACV)",{"slug":12,"category":5,"name":13,"updated_at":24},{"slug":34,"category":5,"name":35,"updated_at":24},"arpa","Средний доход на аккаунт (ARPA)",{"slug":37,"category":5,"name":38,"updated_at":24},"arr","Годовой периодический доход (ARR)",{"slug":40,"category":5,"name":41,"updated_at":42},"auto-renewal-clause","Пункт об автопродлении","2026-08-24T02:46:38+00:00",{"slug":44,"category":5,"name":45,"updated_at":42},"build-vs-buy","Build vs. buy (создать или купить)",{"slug":47,"category":5,"name":48,"updated_at":28},"burn-multiple","Коэффициент сжигания (Burn Multiple)",{"slug":50,"category":5,"name":51,"updated_at":42},"burn-rate","Burn Rate (скорость сжигания денег)",{"slug":53,"category":5,"name":54,"updated_at":24},"cac","Стоимость привлечения клиента (CAC)",{"slug":56,"category":5,"name":57,"updated_at":24},"cdn","Сеть доставки контента (CDN)"]