OAuth — это стандарт авторизации, который позволяет приложению получить ограниченный доступ к данным пользователя без передачи логина и пароля. Его используют в сценариях вроде «Войти через Google» или «Разрешить доступ к календарю», когда сервису нужен доступ только к части данных аккаунта.
Содержание статьи
Что такое OAuth простыми словами
OAuth — это протокол открытой авторизации, при котором пользователь разрешает приложению доступ к защищённым ресурсам через специальные токены доступа. Приложение получает не пароль от аккаунта, а ограниченное разрешение на конкретные действия.
Такой подход нужен, когда один сервис хочет работать с данными из другого сервиса. Например, приложение может запросить доступ к контактам, календарю, фотографиям или публикациям в соцсети. Пользователь видит запрос на согласие и сам решает, какой доступ выдать.
OAuth применяют не только на сайтах. Он используется в мобильных приложениях, API, серверных системах, нативных программах и даже на устройствах вроде Smart TV. В отдельных сценариях доступ выдаётся не от имени человека, а от имени организации или служебного аккаунта.
Почему OAuth важен
OAuth снижает риск утечки учётных данных, потому что стороннему приложению не нужно знать пароль пользователя. Вместо этого доступ выдаётся через токен с заданными ограничениями.
Это упрощает безопасное взаимодействие между сервисами. Если приложению нужен только список контактов, ему не требуется полный доступ ко всему аккаунту. Такой принцип уменьшает объём лишних разрешений.
Исторически OAuth появился как альтернатива старой практике, когда пользователи передавали логин и пароль сторонним сервисам. Первая версия протокола, OAuth 1.0, была опубликована в 2007 году и в основном решала задачи веб-приложений.
Позже стандарт расширили. В 2012 году IETF опубликовала OAuth 2.0 в документах RFC 6749 и RFC 6750. Эта версия стала основой для более широкого круга сценариев: веб-приложений, API, мобильных клиентов и устройств. Сейчас именно OAuth 2.0 считается отраслевым стандартом.
Как работает OAuth
OAuth работает через токены доступа. Пользователь подтверждает согласие, сервер авторизации выдаёт токен, а приложение использует его для доступа только к тем ресурсам, которые разрешены.
В этой схеме нет необходимости передавать приложению пароль от основного аккаунта. Вместо этого система опирается на токен — набор данных, который определяет, что именно клиенту разрешено делать. Во многих реализациях для токенов применяют формат JWT (JSON Web Token), потому что он удобен для безопасной передачи данных между сторонами.
У OAuth есть несколько базовых ролей:
- Владелец ресурса — пользователь или другая сущность, которая контролирует данные.
- Сервер ресурсов — система, где хранятся защищённые данные.
- Клиент — приложение, которое запрашивает доступ.
- Сервер авторизации — система, которая проверяет согласие и выдаёт токены.
- Область доступа — набор разрешений, который ограничивает, к чему именно будет доступ.
Как выглядит типичный сценарий OAuth
Обычный поток OAuth состоит из запроса доступа, подтверждения согласия и выдачи токена. После этого приложение обращается к нужному ресурсу уже с токеном, а не с паролем пользователя.
- Пользователь хочет разрешить приложению доступ к определённым данным.
- Сервер авторизации запрашивает согласие на этот доступ.
- После подтверждения сервер авторизации выдаёт приложению токен доступа.
- Приложение отправляет этот токен серверу ресурсов.
- Сервер ресурсов проверяет токен и открывает доступ только в пределах выданных разрешений.
Ключевая деталь здесь — ограниченность доступа. Если пользователь разрешил приложению читать контакты, это ещё не означает доступ ко всей остальной информации аккаунта.
Какие бывают типы grant в OAuth
Grant type, или тип предоставления авторизации, — это способ, которым приложение получает токен доступа. Разные варианты нужны для разных клиентов: веб-приложений, мобильных приложений, серверных сервисов и API.
Authorization Code
Authorization Code обычно используют веб-приложения и мобильные приложения. В этом потоке клиент сначала получает одноразовый код авторизации, а затем обменивает его на токен доступа на специальной конечной точке сервера авторизации.
Такой подход отделяет момент согласия пользователя от получения токена. За счёт этого поток подходит для приложений, где важно аккуратно разделить шаги и не передавать токен напрямую в браузер раньше времени.
PKCE
PKCE усиливает поток Authorization Code и добавляет дополнительную защиту при работе публичных клиентов. Его применяют для защиты от подмены кода авторизации и похожих атак.
Суть в том, что клиент подтверждает, что именно он начал процесс авторизации и именно он должен получить токен. Это особенно важно для мобильных и других приложений, где хранение секретов клиента ограничено.
Client Credentials
Client Credentials используют там, где нет конечного пользователя. Это поток для взаимодействия между приложениями, сервисами, микросервисами и автоматизированными процессами.
В таком сценарии клиент получает доступ к системным ресурсам от своего имени. Например, одному сервису может понадобиться доступ к API другого сервиса для выполнения служебной задачи. Доступ к пользовательским данным при этом обычно не подразумевается.
Implicit Grant
Implicit Grant — упрощённый поток, который использовали в веб-приложениях на JavaScript. В нём токен доступа выдаётся без отдельного шага обмена кода авторизации.
После согласия пользователя токен передавался через URI перенаправления. Это упрощало схему, но делало её менее предпочтительной для ряда сценариев. По этой причине в современных реализациях чаще используют Authorization Code вместе с PKCE.
Refresh Token
Refresh token нужен для получения нового токена доступа после истечения срока действия старого. Это позволяет приложению продолжить работу без повторного запроса согласия у пользователя при каждом обновлении доступа.
Такой механизм отделяет краткоживущий токен доступа от более длительного разрешения на его обновление. За счёт этого можно лучше контролировать сессии и срок действия выданных прав.
Чем OAuth отличается от SSO
OAuth и SSO решают разные задачи. OAuth отвечает за авторизацию, а SSO отвечает за аутентификацию, то есть за подтверждение личности пользователя.
SSO, или единый вход, позволяет пользователю один раз пройти вход и затем получать доступ к нескольким системам. Во многих корпоративных сценариях для этого используют провайдера идентификации, а также протоколы вроде SAML.
OAuth сам по себе не подтверждает, кто именно вошёл в систему. Он определяет, какие ресурсы разрешено использовать клиенту. Поэтому связка может выглядеть так: сначала система аутентифицирует пользователя через SSO, а потом по OAuth выдаёт приложению доступ к данным или сервисам.
Что такое OpenID Connect и как он связан с OAuth
OpenID Connect, или OIDC, — это протокол аутентификации, построенный поверх OAuth 2.0. Он добавляет к модели OAuth механизм подтверждения личности пользователя.
Если упростить, связка выглядит так: OIDC отвечает на вопрос «кто это», а OAuth — на вопрос «что этому клиенту разрешено». Поэтому вход через крупные платформы часто использует оба подхода одновременно.
Это различие важно не только для разработчиков. Пользователь видит одну кнопку входа, но под капотом могут работать разные уровни: подтверждение личности, выдача токена, ограничение прав и доступ к конкретным API.
Какие термины в OAuth нужно знать
Чтобы понимать документацию по OAuth, достаточно разобраться в нескольких базовых терминах. Они описывают участников процесса и типы выдаваемых разрешений.
| Термин | Что означает |
| Access token | Токен доступа, который даёт приложению право обращаться к ресурсу в пределах выданных разрешений |
| Refresh token | Токен, с помощью которого приложение может запросить новый access token после истечения срока действия старого |
| Scope | Область доступа, то есть набор конкретных разрешений |
| Authorization server | Сервер, который получает согласие и выдаёт токены |
| Resource server | Сервер, который хранит данные и проверяет, можно ли выдать к ним доступ |
| Client | Приложение или сервис, запрашивающий доступ |
Где OAuth используют чаще всего
OAuth применяют везде, где одному сервису нужен ограниченный доступ к данным или функциям другого сервиса. Чаще всего это веб-приложения, мобильные приложения, API и межсервисное взаимодействие.
Самый узнаваемый сценарий — вход через внешний аккаунт. Но на практике область применения шире: доступ к календарям, почте, контактам, облачным файлам, корпоративным сервисам и внутренним API.
Для разработчика OAuth — это способ выстроить доступ по разрешениям. Для пользователя — способ не раздавать пароль каждому новому приложению. Именно в этом и состоит его главная ценность.
