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

«Что такое 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 — не рекомендуется).