OAuth

Что такое OAuth простыми словами

OAuth (Open Authorization) — это протокол авторизации, который позволяет одному приложению получить доступ к вашим данным на другом сервисе без передачи ему вашего логина и пароля. Вместо пароля приложение получает специальный временный ключ доступа (токен).

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

Классический пример — кнопка «Войти через Google» или «Войти через ВКонтакте» на любом сайте. Вы нажимаете кнопку, вас перенаправляют на страницу Google, где вы вводите свой пароль (но не на стороннем сайте!), подтверждаете доступ, и сайт получает только то, что вы разрешили — например, ваше имя и email. Ваш пароль остается в тайне.

OAuth решает главную проблему старых систем — раньше приложения просили ваш логин и пароль от другого сервиса, что было крайне небезопасно. Если приложение оказывалось мошенническим, вы теряли доступ ко всему аккаунту. OAuth дает только ограниченный доступ к конкретным данным на определенное время. По данным Okta, более 80% всех корпоративных приложений используют OAuth для авторизации, а количество OAuth-токенов, выдаваемых ежедневно, исчисляется миллиардами.

О том, как OAuth связан с безопасностью веб-приложений, читайте в статье Информационная безопасность.

Как работает OAuth

Процесс OAuth можно представить как получение цифрового пропуска. В нем участвуют четыре стороны:

• Владелец ресурса (Resource Owner): Это вы — пользователь, который владеет данными и дает разрешение.
• Клиент (Client): Стороннее приложение, которое хочет получить доступ к вашим данным (например, мобильное приложение или сайт).
• Сервер авторизации (Authorization Server): Сервер, который проверяет вашу личность и выдает токены (например, Google Accounts, GitHub).
• Сервер ресурсов (Resource Server): Сервер, где хранятся ваши данные (например, Google Диск или API профиля VK).

Процесс выглядит так:

1. Вы нажимаете «Войти через Google» на стороннем сайте.
2. Сайт перенаправляет вас на сервер Google, где вы вводите свой пароль.
3. Google спрашивает: «Вы разрешаете этому сайту доступ к вашему имени и email?»
4. Вы нажимаете «Разрешить».
5. Google выдает сайту временный код и перенаправляет вас обратно.
6. Сайт обменивает код на токен доступа (Access Token).
7. Сайт использует токен для запроса ваших данных у API Google.

О том, как работают токены, читайте в статье Токен.

Типы грантов OAuth 2.0

OAuth 2.0 поддерживает несколько потоков авторизации (грантов), которые выбираются в зависимости от типа приложения (веб, мобильное, серверное) и уровня доверия:

• Authorization Code Grant: Самый распространённый и безопасный поток для веб-приложений и мобильных приложений. Клиент получает код авторизации, который затем обменивает на токен доступа. Код передаётся через браузер пользователя, а токен — через защищённый канал между сервером клиента и сервером авторизации.
• Implicit Grant (устаревший): Упрощённый поток для одностраничных приложений (SPA), где токен возвращается напрямую в браузер. Считается менее безопасным и в современных реалиях не рекомендуется к использованию.
• Resource Owner Password Credentials Grant: Поток, где пользователь передаёт свой логин и пароль напрямую клиенту. Используется только для доверенных приложений (например, официальные мобильные приложения банков). Высокорисковый метод.
• Client Credentials Grant: Используется для сервер-серверных взаимодействий, где нет пользователя. Клиент аутентифицируется с использованием своих учётных данных (client ID и client secret) и получает токен для доступа к защищённым ресурсам.

Выбор правильного гранта — критически важный шаг при проектировании безопасности приложения. Неправильный выбор может привести к уязвимостям и компрометации данных.

OAuth 1.0 vs OAuth 2.0

OAuth 2.0 — это современная версия протокола, которая заменила OAuth 1.0. Основные отличия:

• Простота: OAuth 2.0 значительно проще для разработчиков. Не требуется сложная криптография для подписи запросов (в OAuth 1.0 нужно было генерировать цифровую подпись для каждого запроса).
• Гибкость: OAuth 2.0 поддерживает разные сценарии использования: веб-приложения, мобильные приложения, устройства без браузера (IoT), сервер-серверные взаимодействия.
• Токены: OAuth 2.0 использует токены доступа (Access Token) и токены обновления (Refresh Token), что позволяет продлевать доступ без повторного входа пользователя.
• Безопасность: OAuth 2.0 поддерживает передачу по HTTPS для защиты токенов и больше полагается на TLS для безопасности.

Сегодня OAuth 2.0 является стандартом де-факто для авторизации в интернете. Его используют Google, Facebook, GitHub, Microsoft, Яндекс и тысячи других сервисов. О том, как OAuth интегрируется с API, читайте в статье Инфраструктура.

Безопасность OAuth

Несмотря на то, что OAuth является безопасным протоколом, существуют риски, которые важно учитывать при его использовании:

• Перехват токена: Если злоумышленник перехватит токен доступа (например, через незащищённое соединение или атаку Man-in-the-Middle), он сможет использовать его до истечения срока действия. Использование HTTPS обязательно.
• Фишинг: Злоумышленники могут создавать поддельные страницы входа, имитирующие сервер авторизации, для кражи учётных данных. Важно всегда проверять URL перед вводом пароля.
• CSRF-атаки (Cross-Site Request Forgery): Атаки, при которых злоумышленник заставляет пользователя выполнить нежелательные действия на сайте, где он авторизован. Для защиты используется параметр state в OAuth-запросах.
• Компрометация client secret: Если злоумышленник получит client secret (секретный ключ приложения), он сможет выдавать себя за легитимное приложение. Храните client secret в безопасном месте.

Для усиления безопасности рекомендуется использовать короткое время жизни токенов доступа (например, 1 час) и токены обновления для продления сессии без повторного ввода пароля. Также важно использовать PKCE (Proof Key for Code Exchange) для защиты от перехвата кода авторизации в мобильных приложениях.