Обзор основ и потоков OAuth
22 октября 2022 г.OAuth2.0 — это система авторизации с открытым стандартом, которая была опубликована в 2010 году, и ее быстро приняли такие корпорации, как Google и Twitter. Он определяет, как различные службы могут безопасно получать доступ к активам данных (через аутентификацию) без раскрытия каких-либо учетных данных. Это иногда называют делегированной авторизацией. Это помогает с грубой авторизацией, предоставляя ограниченный и регулируемый доступ к определенным API при создании приложений.
OAuth особенно удобен, поскольку его можно эффективно включить в действия по отмене предоставления идентификационных данных, которые теперь являются важным компонентом любой настройки B2B.
Потоки OAuth — это, по сути, поддерживаемые OAuth методы проверки разрешений и информации о владельце ресурсов.
Существуют разные протоколы для различных потоков OAuth. Существуют потоки OAuth, которые позволяют клиентам вводить учетные данные прямо в приложение через экран входа OAuth. Некоторые серверные фреймворки даже помогают проводить валидацию без взаимодействия с клиентом. Прежде чем мы перейдем к многочисленным видам потоков OAuth, давайте рассмотрим основы.
Основы OAuth
Протокол OAuth использует следующие роли:
- Владелец ресурса — это лицо, которое предоставляет доступ к защищенному ресурсу. Обычно это пользователь.
- Сервер ресурсов. Сервер ресурсов — это сервер, на котором хранится ресурс, доступ к которому необходим владельцу ресурса. Обычно он предоставляет API, а OAuth помогает предоставить безопасный доступ к этому API.
- Клиент — это приложение, которое запрашивает доступ к защищенным ресурсам для владельца ресурса с помощью приложения.
- Сервер авторизации — это сервер, отвечающий за сбор учетных данных от владельца ресурса и определение того, разрешен ли ему доступ к защищенному ресурсу. Если это так, они дают токен доступа, чтобы разрешить доступ. Это основной механизм, управляющий потоком OAuth.
Типы потоков OAuth
Двигаясь дальше, как насчет того, чтобы мы углубились в типы потоков OAuth, о которых вам следует знать, прежде чем мы начнем все развертывать и работать с вашим конкретным вариантом использования?
1. Поток кода авторизации
В потоке кода авторизации вы должны передать секрет клиента приложения, который обменивается на код авторизации или токен. Этот поток отличается от большинства других потоков тем, что сначала требуется, чтобы приложение запустило браузер, чтобы начать поток.
Случаи использования
Серверные веб-приложения и мобильные приложения, исходный код которых не является общедоступным.
Как работает этот поток OAuth?
- Приложение запускает браузер и подключает пользователя к серверу OAuth.
- Пользователь видит всплывающее окно авторизации и дает разрешение на запрос приложения.
- Пользователь перенаправляется обратно в приложение с кодом авторизации в строке запроса.
- Приложение обменивает код авторизации на токен доступа.
2. Поток учетных данных клиента
Поток учетных данных клиента позволяет приложениям передавать свой секрет клиента и идентификатор клиента на сервер авторизации для подтверждения пользователя и возврата токена авторизации. Это происходит без вмешательства пользователя.
Случаи использования
Приложения для межмашинного взаимодействия (M2M) (такие как демоны, серверное администрирование и интерфейсы командной строки). В этих приложениях поток авторизации подтверждает и предоставляет согласие в фоновом режиме без участия пользователя, поскольку «пользователь» часто является машиной или административной задачей. Представляется неуместным отображать запрос на вход или использовать вход через социальные сети.
Как работает этот поток OAuth?
- Приложение проходит аутентификацию на сервере авторизации OAuth, отправляя секрет клиента и идентификатор клиента.
- Сервер авторизации проверяет секрет клиента и идентификатор клиента и возвращает токен доступа приложению.
- Токен доступа позволяет приложению получить доступ к целевому API с ожидаемыми данными пользователя.
Поток пароля владельца ресурса
В этом потоке OAuth пользователям предлагается отправить свои учетные данные через форму, которая затем отправляется на серверную часть и может быть сохранена для будущего использования. Затем для пользователя создается токен доступа. Таким образом, важно, чтобы приложению можно было полностью доверять. Поэтому этот поток обычно не рекомендуется.
Случаи использования
Приложения с высоким уровнем доверия, в которых нельзя использовать другие потоки, основанные на перенаправлениях.
Как работает этот поток OAuth?
- Пользователь выбирает вариант входа в приложение и вводит учетные данные в форме, предоставленной приложением.
- Приложение сохраняет учетные данные, а затем передает их на сервер авторизации.
- Сервер авторизации проверяет учетные данные, а затем возвращает токен доступа (и параметр «Обновить токен»).
- Затем приложению разрешается доступ к целевому API с информацией о пользователе.
Неявный поток с публикацией формы
В этом потоке используется OIDC (OpenID Connect) для выполнения веб-входа с такими функциями, как WS-FED (федерация веб-служб) и SAML (язык разметки безопасных утверждений). OpenID Connect — это простой уровень идентификации, построенный поверх протокола OAuth. Это позволяет Клиентам аутентифицировать Конечных пользователей на основе аутентификации Сервера авторизации и получать доступ к базовой информации профиля о Конечных пользователях совместимым способом, подобным REST.
OpenID Connect может использоваться клиентами различных типов, в том числе веб-клиентами, мобильными клиентами и клиентами JavaScript, для запроса и получения информации об аутентифицированных сеансах и конечных пользователях. Стандартный пакет можно расширить, что позволяет участникам использовать дополнительные возможности, такие как шифрование идентификационных данных, обнаружение поставщика OpenID и выход из системы по мере необходимости.
Внешний интерфейс используется веб-приложением для запроса и получения токенов без необходимости дополнительных внутренних вызовов или секретов. При таком подходе вам не нужно использовать, поддерживать, приобретать или защищать секреты в приложении.
Случаи использования
Приложения, которые предпочитают не управлять секретами локально.
Гибридный поток
Этот метод удобен для приложений, которым необходимо безопасно хранить секреты клиента. Он обеспечивает мгновенный доступ к токену идентификатора, а также позволяет постоянно получать дополнительные токены доступа и обновления.
Это полезно для приложений, которым требуется немедленный доступ к пользовательским данным, но которые должны сначала выполнить некоторую обработку, прежде чем им будет предоставлен доступ к защищенным ресурсам на длительный период времени.
Случаи использования
Приложения, которым требуется быстрый доступ к пользовательским данным, но которые также должны использовать эти данные на постоянной основе.
Поток авторизации устройства
Вы можете использовать этот поток для аутентификации пользователей, не запрашивая их учетные данные. Это повышает удобство работы пользователей на мобильных устройствах, где ввод учетных данных может быть затруднен. Эти приложения могут инициировать процесс авторизации и получить токен, указав свой идентификатор клиента в потоке авторизации устройства.
Случаи использования
Интернет-приложения, которые работают на устройствах с ограниченным вводом данных и обеспечивают простую аутентификацию с использованием учетных данных, сохраненных на устройстве.
Поток кода авторизации с помощью PKCE
Когда общедоступные клиенты (например, собственные и одностраничные приложения) запрашивают токены доступа, возникают различные дополнительные проблемы безопасности, с которыми поток кода авторизации не может справиться самостоятельно, включая следующие:
Нативные приложения
- Секреты клиента нельзя безопасно хранить. Декомпиляция приложения раскрывает секрет клиента, который привязан к приложению и одинаков для всех пользователей и устройств.
- Настраиваемая схема URL (например, MyApp://) может использоваться для записи перенаправления, что может позволить вредоносным приложениям получить код авторизации с вашего сервера авторизации.
Одностраничные приложения
- Клиентские секреты нельзя безопасно хранить, поскольку браузер имеет доступ к их полному источнику.
Учитывая эти обстоятельства, OAuth 2.0 включает версию потока кода авторизации, в которой используется ключ подтверждения для обмена кодом (PKCE).
Поток кода авторизации с расширенным PKCE предоставляет секрет, созданный вызывающим приложением, который может быть подтвержден сервером авторизации, который называется Code Verifier. Кроме того, вызывающее приложение создает значение преобразования Code Verifier, называемое Code Challenge, и доставляет его по протоколу HTTPS для получения кода авторизации. Злоумышленник может перехватить код авторизации и обменять его на токен только в том случае, если нет верификатора кода.
Случаи использования
Приложения, которые должны обслуживать неизвестных общедоступных потребителей, которые могут представлять дополнительные риски безопасности, которые не обрабатывает поток кода аутентификации.
Заключение
Как вы могли догадаться, потоки OAuth следует выбирать тщательно, чтобы улучшить ваш вариант использования и решить конкретные проблемы. Например, у вас может быть одно приложение, которому требуются токены доступа для многих серверов активов. Потребуется несколько вызовов /approve.
Потоки OAuth — это метод получения токенов доступа, и соответствующий поток для вашего варианта использования определяется типом приложения. Другими соображениями, которые следует учитывать, являются уровень доверия к приложению и предполагаемый пользовательский опыт.
Сегодня неправильное решение может иметь серьезные последствия для безопасности и согласованности.
Оригинал