Все
Истории
Дизайн
Код
Геймдев
Бизнес
Маркетинг
Управление
Кино
Музыка
Проектная фотография
Развитие
Здоровье
Деньги
Образование
EdTech
Корп. обучение
Блог Skillbox
Глоссарий
Спецпроекты
Профориентация
Что такое OAuth 2.0: определение и принцип работы
Как приложения обмениваются данными и обеспечивают вашу безопасность в интернете.
Эта статья предназначена для тех, кто слышал о технологии OAuth 2.0 и хочет понять, что это такое и как она работает. Мы постараемся рассказать о возможностях OAuth 2.0 простым языком и представим список ресурсов для дальнейшего, более углублённого изучения.
Содержание
Что такое OAuth 2.0
OAuth 2.0 (Open Authorization 2.0) — это протокол, который позволяет одному приложению получить ограниченный доступ к вашим данным на другом сервисе без передачи логина и пароля. Вместо этого приложение получает временный токен, разрешающий выполнять только те действия, на которые вы согласились.
Представьте фоторедактор, который хочет получить доступ к вашим фотографиям в облачном хранилище. Благодаря протоколу OAuth 2.0 программа не получает ваш логин и пароль от облачного сервиса. Она перенаправит вас на сайт облачного сервиса, например «Google Диск» или Dropbox, где вы войдёте в свой аккаунт.
После этого вам предложат разрешить приложению доступ к фотографиям. Если вы согласитесь, облачный сервис выдаст приложению временный токен, который позволит работать только с вашими фотографиями, не затрагивая другие данные.
Без OAuth 2.0 приложение запрашивало бы ваш логин и пароль от облачного сервиса, что могло бы быть использовано злоумышленниками. В этом случае вместе с фотографиями вы бы предоставили доступ ко всей информации в облаке, включая личные файлы. OAuth 2.0 защищает от таких рисков, предоставляя только необходимый и ограниченный доступ.
OAuth 2.0 является официальным стандартом авторизации, утверждённым организацией IETF (Internet Engineering Task Force). Ранее существовала первая версия протокола, которая требовала сложных криптографических подписей для каждой операции, что затрудняло её интеграцию. Во второй версии процесс упростился, стал более масштабируемым и получил концепцию различных типов токенов.
Помимо OAuth 2.0, существуют и другие протоколы для управления доступом и идентификацией пользователя. Например, SAML и OpenID. SAML (Security Assertion Markup Language) чаще используется в корпоративных системах для обмена данными между доменами при аутентификации и авторизации. OpenID сравнивают с OAuth 2.0, поскольку оба протокола связаны с авторизацией, но решают разные задачи. В следующем разделе мы рассмотрим разницу между OpenID и OAuth 2.0.
Основные различия между OpenID и OAuth 2.0
Протоколы OpenID и OAuth 2.0 связаны с аутентификацией и авторизацией. Поэтому сначала разберём эти понятия, а затем объясним различия между протоколами.
Аутентификация — это проверка личности пользователя, позволяющая системе убедиться, что он действительно тот, за кого себя выдаёт. Например, если некий Илон Маскович хочет войти в личный кабинет интернет-магазина через свой аккаунт в «Яндексе», система аутентификации проверит его данные и решит, разрешить вход или запретить.
Авторизация — это процесс определения того, какие действия и доступ к данным имеет пользователь или приложение на сервисе. Например, если Илон Маскович сфотографирует ракету и захочет загрузить её в облачное хранилище через приложение для синхронизации фотографий, авторизация позволит получить доступ только к нужным данным. Сервис получит временный токен, который ограничит его функции. В этом случае токен может разрешить только загрузку фотографий в облако, а доступ к другим данным, таким как личные документы или списки контактов, будет закрыт.
Авторизация также может предоставлять различные уровни доступа — например, приложение может иметь право только на чтение данных, но не на их изменение или только на изменение, но не на удаление. Такие ограничения помогают обеспечить дополнительный уровень безопасности и предотвратить несанкционированный доступ к личной информации.
Теперь о протоколах: OpenID — это протокол аутентификации, который подтверждает личность пользователя и передаёт эту информацию стороннему сервису. OAuth 2.0 — это протокол авторизации, который управляет доступом одного приложения к данным или функциям другого сервиса на основе предоставленных пользователем разрешений. Запомнить несложно: OpenID отвечает за аутентификацию, а OAuth 2.0 — за авторизацию.
Важно отметить, что эти протоколы часто работают вместе. Например, это реализовано в OpenID Connect — расширении OAuth 2.0. OpenID Connect сначала выполняет аутентификацию пользователя, а затем выдаёт разрешения на доступ к его данным.
Например, когда вы заходите на сайт через Google-аккаунт, OpenID Connect сначала выполняет проверку вашей личности (аутентификация), а затем предоставляет доступ к базовой информации профиля (авторизация). Это удобно, так как позволяет использовать одну учётную запись для множества сервисов, сохраняя при этом контроль над вашими данными.
Роли в OAuth 2.0
В реализации протокола OAuth 2.0 участвуют четыре ключевых роли: владелец ресурса, клиент, авторизационный сервер и ресурсный сервер. Рассмотрим каждую из них.
Владелец ресурса — это пользователь, который предоставляет приложению доступ к своим данным. Например, Илон Маскович будет владельцем ресурса, если разрешит приложению доступ к своим фотографиям в облачном хранилище.
Клиент — это приложение или сайт, который запрашивает доступ к данным владельца ресурса. Поскольку клиент не имеет прямого доступа к данным, он использует авторизационный токен, выданный владельцем ресурса. В нашем примере клиентом будет приложение, которое запрашивает доступ к фотографиям Илона для их синхронизации или выполнения других действий.
Авторизационный сервер — это система, которая проверяет личность владельца ресурса, выдаёт токены доступа и управляет разрешениями, предоставленными клиенту. Сервер удостоверяется, что Илон Маскович действительно является владельцем ресурса. После проверки он выдаёт временный токен или отказывает в доступе, если учётные данные не совпадают.
Ресурсный сервер — это система, которая хранит данные владельца ресурса и предоставляет к ним доступ на основе временных токенов. В нашем примере это облачное хранилище, где Маскович хранит свои фотографии. Ресурсный сервер принимает токен от приложения, проверяет его и открывает доступ к фотографиям. Он также может разрешать различные действия, такие как просмотр, загрузка или удаление файлов. Конкретный список разрешённых действий зависит от прав, предоставленных владельцем ресурса.
Как работает OAuth 2.0
В предыдущем разделе мы рассмотрели роли в OAuth 2.0, а теперь давайте разберём, как они взаимодействуют. Для этого рассмотрим упрощённую схему получения доступа к данным.
Направление на сервер авторизации. Клиентское приложение перенаправляет владельца ресурса на сервер авторизации через URL с уникальными параметрами запроса:
- client_id — идентификатор клиентского приложения;
- redirect_uri — URI для перенаправления после авторизации;
- scope — права доступа, которые запрашивает приложение.
По этим параметрам сервер распознаёт приложение и определяет, какие права оно запрашивает.
Ввод учётных данных. На сервере авторизации пользователь вводит логин и пароль или другие данные. После успешной проверки сервер запросит разрешение у владельца ресурса предоставить доступ клиенту.
Получение кода авторизации. После согласия сервер выдаёт код авторизации и перенаправляет пользователя обратно в приложение, передавая код через URL. Этот код имеет ограниченный срок действия и может быть использован только один раз.
Обмен кода на токен доступа. Клиентское приложение отправляет полученный код на сервер авторизации и обменивает его на токен доступа. Сервер проверяет код и выдаёт токен, который используется для запросов к ресурсному серверу.
Доступ к данным. Клиентское приложение использует токен для запроса данных у ресурсного сервера. В ответ сервер предоставляет доступ к запрашиваемым данным.
Рассмотрим процесс на примере фотографий Илона Масковича:
- Авторизация. Илон запускает приложение для синхронизации фотографий и направляется на сервер авторизации, например «Google Диск».
- Ввод учётных данных. На сервере Маскович вводит свои данные от аккаунта в Google. Сервер затем запросит разрешение предоставить приложению доступ к фотографиям.
- Получение кода авторизации. Если Илон соглашается, сервер выдаёт код авторизации и перенаправляет его обратно в приложение через URL.
- Обмен кода на токен доступа. Приложение отправляет код на сервер авторизации и получает токен.
- Доступ к данным. Приложение использует токен для запроса данных у серверов «Google Диска». Ресурсный сервер проверяет токен и предоставляет доступ к фотографиям.
Такое распределение ролей и последовательность процессов обеспечивают безопасный и контролируемый доступ к данным. Однако для начала работы с OAuth 2.0 необходимо зарегистрировать приложение. Далее мы рассмотрим, как это сделать.
Регистрация приложения
Чтобы начать использовать OAuth 2.0 в приложении, его необходимо зарегистрировать на сервере авторизации. Рассмотрим общие шаги и их последовательность. Для более подробного ознакомления рекомендуем обратиться к официальной спецификации, ссылка на которую приведена в последнем разделе статьи.
Шаг 1
Зарегистрируйте приложение на платформе, поддерживающей OAuth 2.0, такой как Google или GitHub. Обычно это можно сделать через консоль разработчика или раздел на сайте платформы:
- Войдите в учётную запись разработчика на выбранной платформе, например в Google Cloude Console.
- Создайте проект в консоли разработчика, который будет связан с вашим приложением. Проект служит контейнером для настроек и API, необходимых для управления приложением.
- Введите основную информацию о приложении: название, описание и другие данные, помогающие идентифицировать ваше приложение на платформе.
Читайте также:
Шаг 2
После добавления приложения на платформу настройте параметры OAuth 2.0:
- укажите URL для перенаправления пользователя после успешной авторизации (redirect_uri);
- перечислите права доступа, которые приложение запрашивает у пользователя (scope).
Шаг 3
После настройки параметров платформа предоставит:
- клиентский идентификатор (client_id) — уникальный идентификатор, используемый сервером авторизации для определения приложения, запрашивающего доступ;
- клиентский секрет (client_secret) — секретный ключ для подтверждения подлинности приложения при взаимодействии с сервером авторизации.
Шаг 4
Сохраните client_id и client_secret в безопасном месте и не передавайте их в браузер или на другое клиентское устройство. Утечка этих данных может привести к компрометации приложения и раскрытию конфиденциальной информации.
После завершения регистрации приложение сможет авторизовать пользователей и предоставлять доступ к защищённым ресурсам с помощью OAuth 2.0.
Авторизация в OAuth 2.0
В OAuth 2.0 авторизация позволяет клиентскому приложению получить доступ к ресурсам пользователя без предоставления его учётных данных. Вместо этого используется система токенов для безопасного и контролируемого управления доступом.
Есть два основных типа токенов:
- Токен доступа (access token). Этот токен выдаётся сервером авторизации и используется клиентом для доступа к ресурсам пользователя. Токен имеет ограниченный срок действия, что снижает риск злоупотребления в случае кражи. Если срок действия токена истекает, приложение может запросить новый токен, используя обновляющий токен.
- Обновляющий токен (refresh token). Этот токен позволяет получать новый токен доступа без участия пользователя. Обновляющий токен обычно имеет более длительный срок действия и позволяет приложению автоматически обновлять доступ по мере необходимости.
Использование токенов в OAuth 2.0 снижает риски, связанные с хранением и передачей учётных данных. Пользователь или сервер могут отозвать токен в любое время, немедленно прерывая доступ к данным. Кроме того, приложение не хранит логин и пароль пользователя, что значительно снижает риск их утечки.
Основные потоки в OAuth 2.0
Клиентское приложение может получать токен доступа различными способами и управлять процессом авторизации с помощью потоков протокола OAuth 2.0. Эти потоки предназначены для разных сценариев, типов приложений и требований безопасности. Рассмотрим в общих чертах основные потоки и их предназначение.
Поток авторизационного кода — это наиболее распространённый и безопасный поток, используемый для серверных приложений. Он подходит для приложений, способных безопасно хранить секретные ключи, такие как client_secret. Процесс в этом потоке следующий:
- пользователь перенаправляется на сервер авторизации, вводит учётные данные и соглашается предоставить доступ;
- сервер возвращает авторизационный код клиентскому приложению;
- клиентское приложение отправляет код на сервер авторизации и получает токен.
Упрощённый поток предназначен для одностраничных веб-приложений, где невозможно безопасно хранить секретный ключ. Этот поток быстрее, но менее безопасен, так как токен доступа передаётся через браузер и может быть уязвим для атак. Процесс в этом потоке:
- пользователь перенаправляется на сервер авторизации, вводит учётные данные и соглашается предоставить доступ;
- сервер сразу возвращает токен доступа в URL, добавляя его во фрагмент идентификатора после символа #. Это позволяет одностраничным приложениям получать токен напрямую, без обмена авторизационным кодом.
Читайте также:
Поток пароля владельца ресурса используется, когда пользователь доверяет приложению и готов предоставить свои учётные данные напрямую. В этом потоке приложение получает токен доступа, отправив учётные данные пользователя на сервер авторизации:
- пользователь вводит свои учётные данные непосредственно в приложении;
- приложение отправляет эти данные на сервер авторизации;
- сервер проверяет данные и выдаёт токен.
Этот поток менее безопасен, так как приложение получает доступ к чувствительной информации. Его следует использовать только при высоком уровне доверия и отсутствии других методов авторизации.
Поток учётных данных клиента используется для авторизации приложений, действующих от своего имени, а не от имени пользователя. Этот поток подходит для серверных приложений и сценариев, где требуется доступ к API или сервисам без участия пользователя:
- приложение отправляет запрос на сервер авторизации с учётными данными клиента (client_id и client_secret);
- сервер проверяет данные и выдаёт токен доступа;
- приложение использует токен для взаимодействия с ресурсами.
Поток авторизации устройства предназначен для устройств с ограниченными возможностями ввода, таких как телевизоры и игровые консоли. Процесс авторизации осуществляется с помощью другого устройства:
- устройство отображает код и URL для авторизации;
- пользователь переходит по указанному URL на компьютере или смартфоне, вводит код и соглашается предоставить доступ;
- после подтверждения на другом устройстве основное устройство получает токен доступа.
Поток обновления токена позволяет приложению получать новый токен доступа без повторной авторизации пользователя. Это упрощает доступ к ресурсам:
- приложение отправляет refresh token на сервер авторизации;
- сервер проверяет refresh token и выдаёт новый токен.
Чтобы лучше понять работу потоков в OAuth 2.0, рекомендуем ознакомиться с GIF-шпаргалкой от сообщества DEV Community.
Изображение: Hem / Dev
Безопасность OAuth 2.0
Для обеспечения надёжной защиты данных и минимизации рисков при использовании OAuth 2.0 важно следовать проверенным практикам безопасности. Далее мы рассмотрим основные из них.
Минимизация привилегий. Приложение должно запрашивать только те права доступа, которые необходимы для его работы. Это помогает ограничить потенциальный ущерб в случае утечки данных.
Использование HTTPS. Все взаимодействия, связанные с передачей токенов и других чувствительных данных, должны происходить через защищённый протокол HTTPS. Это защищает данные от перехвата злоумышленниками.
Иллюстрация: Polina Vari для Skillbox Media
Ограничение времени действия токенов. Токены доступа должны иметь ограниченный срок действия, обычно от нескольких минут до нескольких часов, в зависимости от типа приложения и уровня безопасности. Для приложений с высокими требованиями к безопасности рекомендуется использовать короткий срок действия. Для критически важных операций, таких как изменения в аккаунте или доступ к финансовым данным, предпочтительны одноразовые токены, действующие менее минуты.
Защита от повторного использования. Если токен использован, его следует немедленно аннулировать, чтобы предотвратить повторный доступ. Также важно регулярно обновлять токены, так как это сокращает время, в течение которого украденный токен может оставаться активным.
Использование PKCE (Proof Key for Code Exchange). Это расширение для потока авторизационного кода, которое защищает от атак на этапе перехвата кода авторизации. PKCE добавляет дополнительный уровень безопасности, предотвращая несанкционированный доступ к токенам. Это особенно критично для мобильных и клиентских веб-приложений.
Аутентификация клиента. Приложение должно пройти аутентификацию на сервере авторизации, предоставляя свои уникальные идентификаторы client_id и client_secret. Это помогает предотвратить использование протокола OAuth 2.0 неавторизованными приложениями.
Проверка и управление доступом. Приложение должно взаимодействовать только с надёжными серверами авторизации и ресурсными серверами. При обнаружении подозрительной активности пользователи должны получать уведомления и иметь возможность быстро заблокировать доступ.
Что дальше
Вы ознакомились с возможностями и принципами работы протокола OAuth 2.0. Для углублённого изучения предлагаем следующие бесплатные ресурсы:
- OAuth 2.0 RFC 6749 — это официальная спецификация OAuth 2.0 от IETF. Документ содержит технические детали и полное описание всех аспектов протокола.
- Учебник по OAuth 2.0 от команды Okta — это подробное руководство, предлагающее более краткое и понятное объяснение по сравнению с официальной спецификацией. На сайте доступна платформа OAuth 2.0 Playground для практики с процессами авторизации и получения токенов.
- OAuth 2.0 Playground от Google — это интерактивный тренажёр для практического изучения OAuth 2.0. Вы можете взаимодействовать с различными API, настраивать запросы и использовать токены доступа.
- OAuth 2.0 и OpenID Connect — это руководство для разработчиков от Google, объясняющее взаимодействие OAuth 2.0 и OpenID Connect. Содержит примеры кода и сценарии авторизации.
- Блог разработчиков OAuth — это сайт с множеством статей и видео, объясняющих использование OAuth 2.0 в различных приложениях.
Мы также рекомендуем иллюстрированное руководство Дэвида Нила, доступное в переводе на «Хабре». Эта небольшая статья будет полезна всем, кто только начинает знакомство с OAuth.
Больше интересного про код — в нашем телеграм-канале. Подписывайтесь!
