OAuth 2.0: что это и как работает протокол авторизации

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

В двух словах объясним, как это работает. Например, вы хотите отредактировать фото с помощью фоторедактора и предоставляете приложению доступ к снимкам в облаке. Программа не будет запрашивать учетные данные от облачного сервиса — она просто перенаправит вас в этот сервис, где вы войдете в аккаунт под своими логином и паролем. Затем у вас запросят разрешение на доступ к фото. Если согласитесь, облачный сервис выдаст фоторедактору временный токен, который позволит оперировать снимками без доступа к другой информации.

Такая схема возможна благодаря протоколу OAuth 2.0. Без него фоторедактор запрашивал бы логин/пароль от облака. В таком случае велики риски, что учетные данные могли перехватить злоумышленники и получить доступ не только к фотографиям, но и к другим личным файлам.

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

OAuth 2.0 часто сравнивают и даже путают с OpenID. Но они выполняют разные задачи. OpenID отвечает за аутентификацию, OAuth 2.0 — за авторизацию. Расшифровываем понятия:

• Аутентификация — процедура, которая позволяет системе убедиться, что пользователь действительно тот, кем представляется. Например, вы входите в свой аккаунт в социальной сети. Сначала идентифицируетесь — вводите логин. Затем подтверждаете свои права на аккаунт — указываете пароль или еще какие-то данные, которые запрашивает система. Это как раз и есть аутентификация. Если указали верные данные, система разрешит вход в аккаунт.

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

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

Эти протоколы часто работают в паре. Например, у OAuth 2.0 есть расширение OpenID Connect, которое сначала проводит аутентификацию пользователя, затем выдает сервисам разрешение на доступ к данным этого пользователя.

Приведем примеры с Google-аккаунтом. Вы заходите через него в сторонний сервис, OpenID Connect проводит аутентификацию. Затем протокол позволяет сервису, в который вы вошли, получить доступ к данным из Google-аккаунта. Схема удобная, поскольку не нужно создавать под каждое приложение отдельную учетную запись. При этом сохраняется контроль доступа к личной информации.

В протоколе авторизации OAuth 2.0 существует четыре роли:

• Владелец ресурса. Это пользователь, который разрешает приложению оперировать своими данными. Вернемся к примеру с фоторедактором. Если облако с фотографиями ваше, то вы должны разрешить сервису работать со снимками.

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

• Авторизационный сервер. Система, которая проводит аутентификацию владельца ресурса, выдает временные токены доступа для клиента и управляет пользовательскими разрешениями. Сервер сначала проверяет, действительно ли пользователь владеет ресурсом. Если учетные данные верные, то выдает клиенту (фоторедактору) временный токен для доступа к фото в облаке.

• Ресурсный сервер. Система, которая хранит информацию владельца ресурса, проверяет временные токены клиента и предоставляет доступ. В нашем примере это облачное хранилище фотографий. Сервер предоставляет не только доступ, но и дает клиенту разрешение на выполнение действий, которые одобрил владелец ресурса.

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

Виды токенов в OAuth 2.0

Мы уже говорили о временном токене, который выдается сервером авторизации. Он действует определенное время, после чего использовать его уже нельзя.

Приложение может повторно запросить временный токен с помощью обновляющего токена (refresh token). Такой инструмент позволяет приложению без участия пользователя запрашивать автоматическое обновление токена для доступа к данным другого сервиса. 

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

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

Authorization Code Grant 

Это поток авторизационного кода — наиболее распространенный и безопасный. Он используется для серверных приложений. Для тех, что способны хранить секретные ключи. 

Как выглядит процесс в Authorization Code Grant: 

1. Пользователь попадает на сервер авторизации, где вводит логин/пароль и разрешает приложению доступ к данным.

2. Сервер отправляет клиентскому приложению авторизационный код.

3. Клиентское приложение меняет авторизационный код на временный токен. 

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

Implicit Grant 

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

Процесс в Implicit Grant:

1. Пользователь переходит на сервер авторизации, где вводит учетные данные и дает разрешение на доступ.

2. Сервер сразу возвращает токен доступа в URL и добавляет его во фрагмент идентификатора после символа #.

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

Resource Owner Password Credentials Grant

Это поток пароля владельца ресурса. Он используется, если пользователь готов напрямую предоставить приложению учетные данные. 

Процесс в потоке Resource Owner Password Credentials Grant:

1. Пользователь прямо в приложении вводит свои учетные данные. 

2. Приложение отправляет полученные данные на сервер авторизации.

3. Сервер проверяет подлинность указанных данных и выдает временный токен.

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

Client Credentials Grant

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

Как происходит процесс: 

• Один сервер собирается получить доступ к другому API, например, к платежному шлюзу.

• Сервер напрямую обращается к серверу авторизации, используя свой собственный «пароль» (Client ID и Client Secret) и получает токен.

Такой поток применяется для сообщения серверов в фоновом режиме без немедленного взаимодействия с пользователем.

Общая схема получения доступа к данным с помощью протокола авторизации:

Приложение-клиент перенаправляет владельца ресурса на сервер авторизации. Это делается через URL с такими параметрами, как идентификатор client_id, URI для перенаправления после успешной авторизации — redirect_uri, запрашиваемые права доступа — scope. По этим параметрам сервер авторизации понимает, какое приложение запрашивает доступ и какие права нужны.

Владелец ресурса вводит учетные данные для входа в аккаунт на основном сервисе. После аутентификации пользователя сервер запросит разрешение на предоставление доступа приложению-клиенту.

Сервер предоставляет одноразовый код авторизации и перенаправляет пользователя в приложение-клиент.

Приложение-клиент на сервере обменивает код авторизации на временный токен. Этот токен может использоваться для запросов к ресурсному серверу.

Приложение-клиент предоставляет запрашиваемый сервером временный токен, в ответ получает доступ к нужным файлам.

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

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

Чтобы реализовать OAuth 2.0, нужно зарегистрировать приложение на платформе, которая поддерживает этот протокол. Например, Google.

Как действовать:

1. Войдите в аккаунт разработчика на платформе, где будете регистрировать приложение. Например, Google Cloude Console.

2. Создайте проект, свяжите его со своим приложением.

3. Укажите подробные данные о приложении, чтобы можно было точно идентифицировать его на платформе.

4. Настройте параметры OAuth 2.0 — URL для перенаправления пользователя и права, которые будет запрашивать приложение.

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

Использование OAuth 2.0 само по себе не гарантирует безопасности, поэтому нужно принять меры для защиты данных. Например:

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

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

• Ограничивать время действия токенов. Временные токены должны действовать от нескольких минут до нескольких часов в зависимости от требований к защите данных. Чем короче срок действия, тем меньше вероятность инцидента ИБ. Если речь об операциях с финансами или персональными данными, токен в идеале должен действовать до одной минуты.

• Аннулировать использованные токены. Как только клиент выполнит необходимые действия в сервисе, токен следует немедленно отозвать. Это предотвращает повторный, уже несанкционированный доступ к данным.

• Использовать расширение PKCE. Оно предотвращает несанкционированный доступ к временным токенам. Его используют, чтобы защититься от атак с перехватом кода авторизации. Это особенно актуально для мобильных приложений, например, банковских.

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

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

Защита конфиденциальных данных должна быть комплексной, поэтому рекомендуем применять все описанные меры. Особенно если речь о доступе к платежным сервисам и приложениям, которые хранят чувствительную информацию.

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

Преимущества OAuth 2.0

OAuth 2.0 стал стандартом благодаря фокусу на безопасности и гибкости. Обобщим сильные стороны протокола:

• Повышенная безопасность. Пароли от основных сервисов не фигурируют на сторонних. Аутентификация происходит на сайте доверенного провайдера. Это снижает риски утечки учетных данных.

• Ограниченный доступ. Стороннее приложение запрашивает только необходимые ему права. Пользователь видит этот запрос и должен явно его одобрить.

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

• Поддержка разных платформ. OAuth 2.0 адаптирован для таких типов клиентов, как традиционные веб-серверы, мобильные и десктопные приложения, одностраничные веб-приложения, а также для взаимодействий «сервер-сервер».

• Улучшенный пользовательский опыт. Пользователям не нужно создавать новые логины и пароли для каждого приложения. Они могут использовать свою существующую, доверенную учетную запись.

В качестве преимущества можно отметить и четкое разделение ролей, о котором мы говорили выше.

Недостатки и риски OAuth 2.0

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

Из-за неправильной реализации протокола возникают следующие риски:

• Ошибочная валидация redirect_uri. Если сервер авторизации недостаточно строго проверяет redirect_uri, злоумышленник может перехватить токен или код авторизации.

• Отсутствие параметра state (проверка случайной строки). Если такая опция не используется, приложение в процессе авторизации становится уязвимым для CSRF-атак. Они подразумевают подделку межсайтовых запросов.

• Небезопасное хранение токенов. Если временные токены или refresh-токены ненадлежащим образом хранятся на клиенте, они могут быть украдены через XSS-атаку (межсайтовый скриптинг).

• Использование неявных потоков (Implicit Flow). Такие потоки передают токен прямо в URL, что повышает риски перехвата и несанкционированного доступа к данным приложения.

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

Еще одна «брешь» протокола OAuth 2.0 в том, что он только выдает разрешения, но не располагает информацией о пользователях. Нивелировать этот минус позволяет стандарт OpenID Connect (OIDC), который добавляет ID Token и данные о пользователе.

В цифровом окружении работа с OAuth 2.0 — обязательный навык для специалистов, связанных с веб-разработкой, DevOps и безопасностью. Понимание протокола помогает правильно строить архитектуру безопасности, выявлять и предотвращать уязвимости, безопасно интегрироваться с внешними сервисами и партнерами. Например, с помощью OAuth можно настраивать интеграцию Identity and Access Management от Cloud.ru со сторонними провайдерами.