Какой знаешь пример Authorization?

Пример авторизации: OAuth 2.0 в REST API

Авторизация — это процесс проверки прав доступа пользователя или системы к конкретным ресурсам после успешной аутентификации. Классический и современный пример — протокол OAuth 2.0, особенно в контексте веб- и мобильных приложений. Рассмотрим сценарий, когда пользователь разрешает стороннему приложению доступ к его данным в Google (например, к контактам или календарю) без передачи логина и пароля.

Пошаговый пример потока Authorization Code Grant

1. Инициация запроса: Пользователь в приложении (Client) нажимает "Войти через Google". Приложение перенаправляет браузер на authorization endpoint провайдера (Google) с параметрами:

    *   `client_id` — идентификатор приложения, зарегистрированного в Google.
    *   `redirect_uri` — куда Google вернёт ответ.
    *   `scope` — запрашиваемые разрешения (например, `https://www.googleapis.com/auth/contacts.readonly`).
    *   `response_type=code` — указывает, что мы используем поток Authorization Code.
    *   `state` — случайная строка для защиты от CSRF-атак.

    Пример URL:

```http
https://accounts.google.com/o/oauth2/v2/auth?
client_id=your_client_id&
redirect_uri=https://yourapp.com/callback&
scope=https://www.googleapis.com/auth/contacts.readonly&
response_type=code&
state=xyz123
```

2. Согласие пользователя: Google показывает пользователю экран, где запрашивает разрешение на доступ к контактам для приложения "YourApp". Пользователь нажимает "Разрешить".

1. Получение кода авторизации: Google перенаправляет браузер обратно на redirect_uri приложения, добавляя в URL authorization code и state.

   https://yourapp.com/callback?code=4/0AThS5T...&state=xyz123
   

    Приложение проверяет, что параметр `state` совпадает с отправленным, что защищает от атак подмены.

1. Обмен кода на токен доступа (Access Token): Серверная часть приложения (backend) делает запрос напрямую к токенному endpoint Google, отправляя полученный код и свои секретные данные. Этот шаг выполняется "за кулисами", не в браузере, для безопасности.

   POST /token HTTP/1.1
   Host: oauth2.googleapis.com
   Content-Type: application/x-www-form-urlencoded
   
   code=4/0AThS5T...&
   client_id=your_client_id&
   client_secret=your_client_secret&
   redirect_uri=https://yourapp.com/callback&
   grant_type=authorization_code
   

2. Ответ с токенами: Google отвечает JSON-объектом, содержащим access token (и часто refresh token).

   {
     "access_token": "ya29.a0AfH6SMB...",
     "expires_in": 3599,
     "refresh_token": "1//03eD...",
     "scope": "https://www.googleapis.com/auth/contacts.readonly",
     "token_type": "Bearer"
   }
   

3. Доступ к защищённому ресурсу (Авторизация!): Теперь приложение может использовать полученный access_token для авторизованных запросов к API Google Contacts. Токен передаётся в заголовке Authorization.

   GET /v1/people/me/connections HTTP/1.1
   Host: people.googleapis.com
   Authorization: Bearer ya29.a0AfH6SMB...
   

    Сервер Google Contacts, получив запрос, **проверяет токен** (его подпись, срок действия, область доступа `scope`). Если токен валиден и область доступа включает чтение контактов, сервер **авторизует** запрос и возвращает данные контактов. В этом и заключается суть авторизации — проверка разрешений на действие.

Роль в тестировании (QA)

Как QA-инженер, я бы тестировал такую авторизацию, проверяя следующие критические сценарии:

• Позитивные сценарии: Успешный поток с корректными client_id, scope и redirect_uri.
• Негативные сценарии:

    *   Неверный или просроченный `authorization code`.
    *   Передача `access_token` с недостаточным `scope` для запрашиваемого эндпоинта API (должна быть ошибка `403 Forbidden`).
    *   Использование отозванного или поддельного `access_token` (ошибка `401 Unauthorized`).
    *   Попытка повторного использования `authorization code` (должен быть отклонён).
    *   Несовпадение параметра `state` (должен блокировать запрос).
    *   Истечение срока действия `access_token` и успешное использование `refresh_token` для получения нового.

• Безопасность: Убедиться, что client_secret никогда не передаётся в клиентском коде (frontend). Проверить наличие валидации redirect_uri на стороне провайдера.

Таким образом, OAuth 2.0 — это мощный стандарт делегированной авторизации, который отделяет роль владельца ресурса, клиентского приложения и провайдера ресурсов, обеспечивая гибкость и безопасность. Понимание его механизмов необходимо для тестирования современных приложений, интегрированных с внешними API.