OAuth 1.0

OAuth 1.0 — это открытый протокол авторизации, позволяющий предоставить стороннему приложению (клиенту) ограниченный доступ к ресурсам пользователя на сервере без передачи ему логина и пароля. Протокол основан на обмене токенами доступа и подписи каждого запроса с использованием криптографических методов, что обеспечивает аутентификацию и целостность передаваемых данных. OAuth 1.0 был разработан как альтернатива базовой аутентификации (HTTP Basic Auth) и стал предшественником более современного протокола OAuth 2.0.

История

Протокол OAuth 1.0 был создан в 2006–2007 годах группой разработчиков, включая Блейна Кука (Blaine Cook) из Twitter и Криса Мессину (Chris Messina). Первоначальная версия была опубликована в декабре 2007 года как черновик. Основной целью было решение проблемы «делегированной авторизации»: пользователи хотели разрешить сторонним сервисам (например, приложениям для публикации фотографий) доступ к своим данным на других платформах (например, Twitter или Flickr), не раскрывая свои учётные данные.

В апреле 2010 года спецификация была формализована в документе RFC 5849 «The OAuth 1.0 Protocol» под эгидой IETF. Однако уже к этому времени были выявлены некоторые уязвимости, в частности атаки с фиксацией сессии (session fixation). В ответ на это в 2011 году вышла уточнённая версия — OAuth 1.0a, описанная в RFC 5849 (с исправлениями). Основное отличие OAuth 1.0a заключалось в добавлении параметра oauth_verifier для защиты от атак с перехватом токенов. Впоследствии протокол широко использовался такими компаниями, как Twitter, Flickr, Google (до перехода на OAuth 2.0) и другими.

Архитектура и основные понятия

OAuth 1.0 определяет четыре роли участников:

• Владелец ресурса (Resource Owner) — пользователь, который владеет данными и может предоставлять к ним доступ.
• Клиент (Client) — стороннее приложение, запрашивающее доступ к ресурсам от имени владельца.
• Сервер ресурсов (Resource Server) — сервер, на котором хранятся защищённые данные (например, API).
• Сервер авторизации (Authorization Server) — сервер, выдающий токены доступа после успешной аутентификации владельца.

В отличие от OAuth 2.0, в OAuth 1.0 сервер авторизации и сервер ресурсов часто являются одним и тем же сервером.

Токены

Протокол использует два типа токенов:

• Временный токен (Request Token) — используется на начальном этапе для получения разрешения от владельца ресурса. После авторизации он обменивается на токен доступа.
• Токен доступа (Access Token) — постоянный (или долгоживущий) токен, который клиент использует для доступа к защищённым ресурсам.

Каждый токен имеет свой секретный ключ (token_secret), который используется для подписи запросов.

Процесс авторизации (OAuth 1.0a)

Протокол OAuth 1.0a состоит из трёх этапов:

Этап 1: Получение временного токена

Клиент отправляет запрос на сервер авторизации с указанием своих учётных данных (consumer key и consumer secret). В ответ сервер выдаёт временный токен (request token) и его секрет.

Этап 2: Авторизация пользователя

Клиент перенаправляет владельца ресурса на страницу сервера авторизации, передавая временный токен. Пользователь вводит свои учётные данные (логин и пароль) и подтверждает, что разрешает клиенту доступ. После этого сервер возвращает пользователя обратно на клиент с параметром oauth_verifier — одноразовым кодом подтверждения.

Этап 3: Обмен на токен доступа

Клиент отправляет на сервер авторизации запрос, содержащий временный токен, его секрет и oauth_verifier. Сервер проверяет данные и выдаёт токен доступа (access token) и его секрет. После этого клиент может использовать этот токен для подписи запросов к серверу ресурсов.

Подпись запросов

Одной из ключевых особенностей OAuth 1.0 является обязательная подпись каждого HTTP-запроса. Подпись вычисляется на основе:

• HTTP-метода (GET, POST и т.д.)
• URL запроса
• Параметров запроса (включая OAuth-параметры)
• Секретных ключей (consumer secret и token secret)

Для подписи используются различные алгоритмы:

• HMAC-SHA1 — наиболее распространённый, использует симметричный ключ.
• RSA-SHA1 — использует асимметричное шифрование.
• PLAINTEXT — передача ключа в открытом виде (не рекомендуется).

Подпись включается в заголовок Authorization или в тело запроса. Это обеспечивает защиту от подделки запросов и атак повторного воспроизведения (replay attacks), так как каждый запрос уникален благодаря временной метке (oauth_timestamp) и одноразовому числу (oauth_nonce).

Безопасность и уязвимости

OAuth 1.0a считается более безопасным с точки зрения криптографии, чем его преемник OAuth 2.0, поскольку он требует обязательной подписи каждого запроса. Однако протокол имеет ряд недостатков:

• Сложность реализации — разработчикам необходимо вручную вычислять подписи и управлять временными метками.
• Отсутствие поддержки мобильных и одностраничных приложений — протокол плохо адаптирован для сред, где невозможно безопасно хранить секреты клиента (например, в JavaScript-приложениях).
• Атаки с фиксацией сессии — в ранних версиях OAuth 1.0 (до 1.0a) злоумышленник мог перехватить временный токен и выдать себя за легитимного пользователя.
• Проблемы с масштабируемостью — каждый запрос требует вычисления подписи, что увеличивает нагрузку на сервер.

Сравнение с OAuth 2.0

Применение

OAuth 1.0 использовался в основном в эпоху Web 2.0 для интеграции социальных сетей и API. Наиболее известные примеры:

• Twitter API (до перехода на OAuth 2.0 в 2020 году)
• Flickr API
• Google Data API (до перехода на OAuth 2.0)
• Yahoo! API

В настоящее время протокол считается устаревшим для новых проектов. Большинство современных сервисов перешли на OAuth 2.0, который проще в реализации и лучше адаптирован для различных типов клиентов (мобильные приложения, SPA, серверные приложения). Тем не менее, OAuth 1.0 всё ещё поддерживается в некоторых старых системах и API, где требуется обратная совместимость.

Интересные факты

• Название «OAuth» расшифровывается как «Open Authorization» (открытая авторизация).
• Первая версия протокола была создана всего за несколько недель как неофициальный проект.
• OAuth 1.0a стал основой для стандарта RFC 5849, который до сих пор используется в некоторых корпоративных системах.
• Протокол не поддерживает обновление токенов (refresh tokens) — после истечения срока действия токена доступа пользователь должен пройти авторизацию заново.

Источники

• RFC 5849 — The OAuth 1.0 Protocol (2010)
• RFC 5849 (исправленный) — OAuth 1.0a (2011)
• Документация Twitter API — OAuth 1.0a (историческая)
• «OAuth: The Definitive Guide» — Ryan Boyd (2012)
• IETF OAuth Working Group — официальные материалы