Что такое OAuth 2.0 и как работает авторизация через токены

В свое время, лет 20 назад, пользователям онлайн-сервисов приходилось создавать отдельный логин и пароль практически для каждого онлайн-сервиса или веб-площадки в сети. К счастью, те времена давно в прошлом, сегодня почти все сервисы позволяют залогиниться в один клик – через Google или Facebook. 

Именно так работает магия OAuth 2.0 – универсального стандарт авторизации, который обеспечивает безопасность и удобство миллионам пользователей. Эта технология лишила рядового пользователя потребности создавать десятки аккаунтов и запоминать десятки паролей, гарантируя не только комфорт, но и безопасность данных. 

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

Основы OAuth 2.0

Начнём с базовых вопросов. Что такое OAuth 2.0? Это открытый стандарт авторизации, позволяющий пользователям предоставлять доступ к своим данным на одной платформе для другой без передачи пароля. Первая версия OAuth в 2006 году была создана командой Twitter. Вторая версия вышла под руководством рабочей группы IETF в 2012 году – она стала ответом на потребности сети в максимально доступной и безопасной системе авторизации для веб- и мобильных приложений.

Можно ли в двух словах объяснить, как работает OAuth 2.0? Принцип работы прост: вместо пароля для входа используются токены доступа (access token). Пользователь подтверждает разрешение через свой аккаунт (например, Facebook или Google), после чего сервис получает временный токен. Этот токен и является ключом к данным или действиям от имени пользователя. Таким образом, пароли остаются в безопасности, а сторонние приложения имеют лишь ограниченные права доступа.

В отличие от OAuth 1.0, использовавшего сложные криптографические подписи, OAuth 2.0 упрощает авторизацию через токены и HTTPS, что повышает производительность и масштабируемость. Он поддерживает различные сценарии (веб, мобильные приложения, IoT) и более гибкие потоки авторизации, но не совместим с OAuth 1.0 из-за перемен в архитектуре.

OAuth 2.0 применяется во всех случаях, где возникает необходимость делегировать доступ: 

• Единый вход (Single Sign-On, SSO. Когда пользователю необходимо предоставить доступ к одному сервису (например, Trello или Miro) через учетную запись другого (например, Google или Slack).

• Доступ к API. Когда стороннее приложение (например, мобильная игра) должно получить доступ к пользовательскому профилю в социальной сети, чтобы, к примеру, опубликовать результат пользователя или найти друзей.

• Интеграция сервисов. Когда пользователь позволяет одному сервису получать данные из другого. Например, фитнес-приложение получает доступ к стриминговому сервису Spotify, чтобы запустить плейлист пользователя. 

• Системы с микросервисной архитектурой. Для безопасного и бесшовного доступа одних микросервисов к ресурсам других.

• Доступ к пользователю. Например, когда приложение для обработки фотографий получает доступ к личной галерее в Google Photos без необходимости предоставления логина/пароля.

• Системы IoT. Для авторизации смарт-устройств и безопасного доступа к облачным сервисам.

Ключевые термины и роли в процессе авторизации

Давайте углубимся во внутреннюю механику OAuth2. Как работает, из чего состоит этот стандарт? Понимание ключевых понятий и ролей поможет лучше уловить суть технологии, чтобы использовать ее безопасно и эффективно. Разберем главных участников процесса и их функции.

• Resource Owner (Владелец ресурсов)

Владелец ресурсов – это пользователь, обладающий определенными данными (например, контактами или файлами) и наделенный полномочиями предоставлять доступ к ним. Например, владелец Google-аккаунта предоставляет стороннему приложению доступ к своим контактам, фото или календарю. В логике OAuth 2.0 Resource Owner не передает сторонним системам пароль к аккаунту, а лишь подтверждает согласие на доступ.

• Клиент (Клиент)

Клиент – это приложение (веб, мобильное или серверное), которое хочет получить доступ к данным владельца ресурсов. В качестве клиента может выступать что угодно: мобильная игра, платформа CRM, фитнес-приложение и т.д. Клиент регистрируется на сервере авторизации, получая идентификатор (Client ID) и, при необходимости, секретный ключ (Client Secret). Он инициирует процесс авторизации, перенаправляя пользователя на сервер авторизации. Он также использует полученный access token для запросов к серверу ресурсов. Например, приложение для управления проектами выступает клиентом, когда запрашивает доступ к Google Drive.

• Авторизационный сервер (Authorization Server)

Это ключевой компонент безопасности, сервис выдачи access token. Его основная задача – проверить личность пользователя (с логином/паролем, многофакторной аутентификацией и т.п.) и корректно выдать клиенту токен доступа. К примеру, это сервер Google, подтверждающий, что пользователь залогинился и разрешил доступ к ресурсам. Авторизационный сервер никогда не хранит ваши данные, он только управляет разрешениями.

• Сервер ресурсов 

Это хранилище, где содержатся пользовательские данные: фото в Google Drive, контакты в Facebook история транзакций в банковском приложении и т.д. Сервер ресурсов проверяет токен доступа OAuth2, полученный от клиента, и если проблем не обнаружено – предоставляет доступ к данным.  Сервер ресурсов не занимается авторизацией пользователя; он только проверяет подлинность токена. В некоторых случаях серверы авторизации и ресурсов могут быть частью одной системы (как у Google), но их функции разделены для безопасности.

Так авторизация через токены в итоге обеспечивает пользователям гибкость, простоту и безопасность данных. 

Потоки авторизации в OAuth 2.0

OAuth 2.0 не является одним универсальным сценарием на все случаи жизни. Он предлагает целый набор различных потоков (flows), подходящих для разных типов приложений и уровней безопасности. Поток в конце-концов определяет, как клиент получает токен авторизации. Рассмотрим ключевые потоки авторизации OAuth.

• Authorization Code Flow: самый распространенный вариант

Этот поток считается золотым стандартом для веб- и мобильных приложений. В его логике клиент перенаправляет пользователя на сервер авторизации, где он подтверждает доступ. Сервер выдает временный код авторизации, который клиент обменивает на токен доступа через защищенный канал. 

Например, реализация потока Authorization Code позволяет приложению для управления проектами получать доступ к Google Calendar. Этот поток идеален для приложений с серверной частью, поскольку обеспечивает высокий уровень безопасности.

• Implicit Flow: когда нужна скорость

Этот вариант упрощает авторизацию для клиентских приложений (например, SPA или мобильных приложений без серверной логики). Пользователь аутентифицируется, и сервер авторизации сразу выдает токен доступа через URL. Так достигается высокая скорость обработки запроса, но одновременно возникает дополнительный риск безопасности, ведь токен передается через браузер.

Раньше Implicit Flow нередко использовали в веб-приложениях SPA, но этот поток считается устаревшим. Сегодня его почти вытеснил PKCE (Proof Key for Code Exchange), который добавляет слой безопасности к Authorization Code Flow. Давайте их сравним: 

• Client Credentials Flow: доступ без участия пользователя

Это специфический поток, предназначенный для машинного взаимодействия – без прямого участия пользователя.  Клиент (например, серверное приложение) аутентифицируется с помощью Client ID и Client Secret – API авторизация через токен доступа производится автоматически.

Client Credentials Flow – простой и безопасный метод для взаимодействия "сервер-сервер", он часто используется для внутренних сервисов бизнеса. Например, когда CRM-система запрашивает данные с корпоративного сервера, то получает доступ к API через токен.

• Resource Owner Password Credentials Flow

В логике этого потока пользователь вводит свой логин и пароль в клиентском приложении, а тот передает их авторизационному серверу в обмен на токен. Это очень простой подход, но очень опасный: клиент фактически получает полные учетные пользовательские данные, что создает риски компрометации данных. 

В большинстве сценариев применять незащищенный Resource Owner OAuth-поток не рекомендуется. Исключениями могут быть редкие случаи, когда клиент крайне надежен (например, официальное приложение непубличного сервиса), или когда необходимо провести миграцию со старых систем с прямым паролем. 

Что такое токен доступа (Access Token)

Мы уже не раз упоминали в тексте токен доступа – без него OAuth-авторизация просто невозможна. Его можно представить в качестве цифрового пропуска или специального ключа, который дает приложению-клиенту временное разрешение на доступ к вашим ресурсам. Давайте взглянем на этот компонент повнимательнее. 

Токены доступа могут иметь разные форматы, но самым популярным является JWT (веб-токен JSON). Он состоит из трех частей:

• Заголовок (Header): содержит информацию о типе токена и алгоритме подписи.

• Полезная нагрузка (Payload): здесь хранится информация о пользователе и разрешениях (например, имя пользователя и срок действия токена).

• Подпись (Signature): обеспечивает цельность и достоверность токена.

Такая структура позволяет серверам ресурсов быстро проверять подлинность токена без дополнительных запросов к серверу авторизации.

Токен доступа выдается сервером авторизации после успешной аутентификации пользователя и его согласия предоставить доступ. В рамках Authorization Code Flow, например, клиент обменивает код авторизации на токен через защищенный запрос. В Implicit Flow токен возвращается сразу через URL. Выдача производится после проверки Client ID и, при необходимости, Client Secret.

При этом токены доступа имеют ограниченный срок действия (обычно от нескольких минут до нескольких часов). Эта особенность является важной мерой безопасности. Даже если токен будет скомпрометирован, опасность будет максимально ограничена во времени. 

Именно поэтому клиентские приложения должны хранить токен в безопасном месте. Для веб-приложений это обычно не Local Storage, который уязвим для XSS-атак, а HttpOnly cookie или специализированные хранилища, гарантирующие защиту.

В OAuth используется две разновидности токенов: для доступа и обновления. Главное отличие между access token и refresh token продиктовано их назначением. 

• Access Token – это кратковременный ключ. Он используется для непосредственного доступа к ресурсам и имеет небольшой срок годности.

• Refresh Token — это долговременный ключ, предназначенный для получения нового токена доступа без необходимости повторного ввода логина и пароля. Это позволяет приложению поддерживать пользовательскую сессию в течение длительного времени, при этом обеспечивая безопасность. 

Как работает авторизация через токены

На сегодня токены – самый лучший способ авторизации в приложении, пришедший на смену устаревшим механизмам с сессиями и файлами cookie. Давайте остановимся на том, как токен передается, защищается и проверяется.

В самом простом виде пошаговый процесс получения токена OAuth выглядит так: 

1. Запрос на авторизацию: Пользователь входит в приложение-клиент и инициирует вход (например, через Google).
2. Предоставление согласия: Пользователь перенаправляется на сервер авторизации, подтверждает свою личность и дает согласие на доступ.
3. Выдача токена: Сервер авторизации выдает токен доступа и отправляет его клиентскому приложению.

Как токен передается  между клиентом и сервером? Когда клиентскому приложению требуется получить доступ к данным (например, загрузить фотографии или получить список друзей), оно отправляет запрос на сервер ресурсов. Токен обычно передается в заголовке HTTP-запроса:

Authorization: Bearer <access_token>

Этот способ передачи данных является стандартом. Слово Bearer  указывает, что доступ предоставляется тому, кто владеет этим токеном.

Несет ли передача токена риски кибербезопасности? В OAuth 2.0 предусмотрены все необходимые предосторожности, чтобы минимизировать угрозу перехвата. Для защиты токена используется HTTPS, шифрующий данные во время передачи. Токены хранятся в безопасных хранилищах (например, Keychain на iOS или зашифрованных базах). Ограниченный срок действия токена также снижает риски утечки. 

Как проверить access token? Каждый раз, когда приложение обращается с токеном к серверу ресурсов, последний проводит ряд проверок: 

1. Проверка формата. Сервер подтверждает, что токен отвечает целевому стандарту (например, JWT);
2. Проверка подписи. Если речь идет о JWT-токене, сервер проверяет цифровую подпись, чтобы гарантировать его целостность;
3. Проверка срока действия. Cервер отклоняет токен, если его срок действия истек;
4. Проверка разрешений. Сервер проверяет, разрешает ли данный токен доступ к запрашиваемым ресурсам.

Так на базе токенов выстраивается защищенный и удобный клиентский доступ OAuth, что делает возможным пользовательскую авторизацию в пару кликов. 

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

Хотя в логике OAuth2 безопасность является самым высоким приоритетом, этот стандарт не может гарантировать абсолютной защиты от всех киберугроз. Надежность зависит от правильной реализации. Игнорирование рекомендаций безопасности может привести к серьезным уязвимостям: 

• Перехват кода авторизации. При обмене авторизационного кода на токен злоумышленники могут перехватить данный код. Для public-клиентов (например мобильных приложений) это может быть серьезной проблемой. 

  • Как избежать угрозы: Используйте расширение PKCE (Proof Key for Code Exchange). Оно добавляет дополнительный секретный ключ, который делает перехваченный код бесполезным для злоумышленника.

• Утечка токена доступа. Если токен попадает в чужие руки, злоумышленник может успеть получить несанкционированный доступ к данным. 

  • Как избежать угрозы: Храните токены только в защищенных местах (например, HttpOnly cookie, и не Local Storage). Используйте Keychain (iOS) или Keystore (Android) для мобильных приложений.

• Межсайтовая подделка запроса (CSRF). Злоумышленник может заставить пользователя инициировать запрос на авторизацию, чтобы получить доступ к его аккаунту и совершить от его имени те или иные действия.

  • Как избежать угрозы: Используйте параметр state в запросе авторизации. Это уникальный временный идентификатор, позволяющий убедиться, что ответ поступает именно от инициированного пользователем запроса.

Определяющее значение для безопасности OAuth 2.0 отыгрывает протокол HTTPS. Весь трафик, связанный с авторизацией, должен быть зашифрован посредством HTTPS/SSL. Это касается не только страниц входа, но и всех API-запросов, где передаются токены. Нешифрованный трафик может быть легко перехвачен, а злоумышленник получит доступ ко всем данным, включая токены. 

Что еще можно сделать для безопасности OAuth 2.0? Следующие рекомендации по хранению и обновлению токена никогда не будут лишними:

• Для обновления Access Token используйте Refresh Token, сохраняя его только на сервере.

• Установите короткий срок действия для Access Token (например, не более часа) и регулярно обновляйте его через Refresh Token.

Примеры применения OAuth 2.0

Сегодня сложно найти онлайн-сервис или приложение, где не используется OAuth2. Пример его реализации встретит вас на любом сайте, в любом онлайн-магазине, на любой диджитал-платформе. Сервис авторизации через токен стал повсеместным – мы бессознательно пользуемся им буквально каждый день. 

Самый очевидный пример применения OAuth 2.0 – возможность войти в сервис с помощью аккаунтов крупных платформ. Когда вы нажимаете кнопку “Войти через Google” или “Войти через Facebook”, именно протокол OAuth 2.0 обеспечивает выдачу токенов, подтверждающих вашу личность и позволяющих сервису получить только необходимые данные (например, email или имя). Интеграция OAuth2 с Google, Facebook и Twitter/X упростила жизнь миллионов пользователей; она также помогает бизнесам строить бесшовный пользовательский опыт в диджитале. 

В веб-приложениях любого назначения OAuth 2.0 часто используется для предоставления доступа к сторонним API без передачи пароля пользователя. Например, SaaS-платформа для управления проектами может интегрироваться так с Google Drive, чтобы пользователи могли прикреплять файлы. Безопасная авторизация API сегодня реализуется через поток Authorization Code Flow с PKCE. 

Применение OAuth2 для мобильных приложений также стало базовым стандартом, поскольку обеспечивает бесшовную и безопасную аутентификацию. К примеру, приложение для фитнеса может использовать Facebook Login для доступа к профилю пользователя. Authorization Code Flow с PKCE применяется для безопасности, а токены хранятся в Keychain (iOS) или Keystore (Android). Refresh Token позволяет обновлять доступ без повторного входа, улучшая пользовательский опыт.

Выводы

Технологии OAuth остаются незаметными для массового пользователя, но они невероятно изменили наш ежедневный опыт жизни в диджитале. Речь идет не только об удобной и безопасной авторизации через аккаунт в любимой соцсети. 

OAuth 2.0 стал основой для интеграции разных сервисов. Сегодня фитнес-приложение может синхронизироваться с музыкальным стримингом, а приложение для планирования задач – с вашим календарем. Данный стандарт позволяет приложениям безопасно взаимодействовать между собой, образуя единую цифровую экосистему.

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

Для создания таких решений необходима опытная команда разработчиков с реальными успешными кейсами. Если вашему бизнесу нужна практическая инструкция по внедрению OAuth2 – не медлите, обращайтесь за консультацией в WEZOM прямо сейчас. Наши специалисты имеют огромный опыт настройки Oauth2 для API под разные продукты: десктопный софт, сайты, SPA, мобильные приложения и т.д. Мы с радостью изучим ваш запрос и подскажем практические решения. 

FAQ