Что такое OAuth 2.0 и как он работает?

Тип вопроса: Тестирование безопасности Вероятность: 10% Категория: QA Тестировщик

Ответ

OAuth 2.0 — это стандартный протокол авторизации (не аутентификации!), который позволяет стороннему приложению (Client) получать ограниченный доступ к защищенным ресурсам пользователя (Resource Owner) на сервере (Resource Server) без передачи ему логина и пароля.

Ключевые роли и компоненты

  1. Resource Owner — пользователь, который владеет данными и дает разрешение.
  2. Client — приложение, запрашивающее доступ.
  3. Authorization Server — сервер, выдающий токены доступа (например, Auth0, Keycloak, сервисы Google/Facebook).
  4. Resource Server — API, которое хранит защищенные данные и принимает токены для доступа.
  5. Access Token — краткосрочный ключ для доступа к API.
  6. Refresh Token — долгосрочный ключ для получения новых Access Token'ов.

Наиболее распространенный поток: Authorization Code Flow (наиболее безопасный для веб-приложений)

sequenceDiagram
    participant User as Resource Owner (User)
    participant App as Client App
    participant Auth as Authorization Server
    participant API as Resource Server (API)

    User->>App: 1. Нажимает "Login with Google"
    App->>User: 2. Redirect to /authorize
    User->>Auth: 3. Аутентифицируется и дает согласие
    Auth->>User: 4. Redirect back with `code`
    User->>App: 5. Передает `code`
    App->>Auth: 6. Обменивает `code` + `client_secret` на `access_token`
    Auth->>App: 7. Возвращает `access_token` и `refresh_token`
    App->>API: 8. Запрос к API с заголовком `Authorization: Bearer <access_token>`
    API->>App: 9. Возвращает защищенные данные

Пример начального запроса авторизации (шаг 2):

GET https://auth-server.com/authorize?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=https://yourapp.com/callback&
  scope=read:profile email&
  state=xyz123abc HTTP/1.1

Преимущества OAuth 2.0: делегированный доступ, безопасность (пароли не раскрываются), стандартизация, поддержка множества сценариев через разные grant types (Client Credentials для M2M, Implicit — устарел, Resource Owner Password Credentials — не рекомендуется).

Ответ 18+ 🔞

А, слушай, смотри, вот эта вся хуйня с OAuth 2.0, которую все так любят впихивать куда ни попадя. Это, блядь, не про то, чтобы понять, кто ты такой — это уже аутентификация, ёпта! Это про то, чтобы дать какому-то левому приложению доступ к твоим данным, не передавая ему, как последнему мудаку, свой пароль от аккаунта. Понимаешь разницу? Не аутентификация, а авторизация! Как будто ты говоришь: «На, вот ключ от гаража, но только чтобы не трогал мою коллекцию винила, пидор».

Кто тут кто, или Парад главных ебланов этой оперы

  1. Resource Owner — это ты, владелец данных. Тот самый лох, который сейчас разрешает какому-то сервису читать его переписку.
  2. Client — это приложение-распиздяй, которое выпрашивает доступ. «Дай-дай-дай посмотреть твои фото, ну пожалуйста!».
  3. Authorization Server — главный раздатчик ключей. Типа Google, Facebook или какой-нибудь ваш корпоративный Keycloak. Он решает, давать токен или послать нахуй.
  4. Resource Server — это уже API, где лежат твои защищённые данные. Его задача — принимать токены и, если они не просроченные и не левые, отдавать контент.
  5. Access Token — это типа пропуск на вечеринку. Действует недолго, часов 5-10, потом протухает.
  6. Refresh Token — это, блядь, вечный (ну, почти) пропуск в гардероб, где можно получить новый Access Token, когда старый сдох. Хранить его надо как зеницу ока, а то опиздюлят твой аккаунт.

Самый правильный и безопасный танец: Authorization Code Flow

Именно его используют нормальные веб-приложения. Всякие Implicit потоки — это уже прошлый век и дыра в безопасности размером с мою неудовлетворённость жизнью.

sequenceDiagram
    participant User as Resource Owner (User)
    participant App as Client App
    participant Auth as Authorization Server
    participant API as Resource Server (API)

    User->>App: 1. Тыкает в кнопку «Войти через Гугл»
    App->>User: 2. Кидает тебя на страницу авторизации
    User->>Auth: 3. Ты логинишься и говоришь «Да, разрешаю»
    Auth->>User: 4. Возвращает тебя обратно с `code` в жопе URL
    User->>App: 5. Приложение этот `code` выковыривает
    App->>Auth: 6. Тайно, на бэкенде, меняет `code` + `client_secret` на `access_token`
    Auth->>App: 7. Выдаёт заветные токены
    App->>API: 8. Идёт к API с криком «Смотри, у меня есть токен!»
    API->>App: 9. Если токен не говно — отдаёт данные

Вот как выглядит этот первый пинок, который отправляет пользователя на сервер авторизации (шаг 2):

GET https://auth-server.com/authorize?
  response_type=code&
  client_id=your_client_id&
  redirect_uri=https://yourapp.com/callback&
  scope=read:profile email&
  state=xyz123abc HTTP/1.1

Обрати внимание на state — это, сука, очень важно! Чтобы тебя не поймали на CSRF, как лоха. Рандомную строку туда суй, а потом проверяй, что тебе её же и вернули.

А в чём, собственно, профит? Да в том, что твой пароль никуда не утекает. Приложение получает только токен с ограниченными правами (scope). Стандарт один, все его понимают. И есть разные сценарии: для машинки-машинки (Client Credentials), для десктопных приложений (Device Flow)… Правда, есть ещё поток Resource Owner Password Credentials — так вот, это пиздец, не используй его, это для ленивых дегенератов, которые хотят быстро накостылять и получить проблемы с безопасностью.

© ХакСобесов, 2026
support@hacksobesov.com