В этой статье я расскажу вам о протоколе авторизации OAuth 2.0, который в настоящее время используется в большинстве веб-приложений в Интернете. Мы подробно рассмотрим методы предоставления авторизации для серверных веб-приложений или клиентских приложений, таких как приложения Javascript или мобильные приложения.

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

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

Примечание об аутентификации и авторизации:

Слова «Аутентификация» и «Авторизация» иногда используются неправильно. Аутентификация - это просто раскрытие вашей личности контролирующему объекту, тогда как авторизация запрашивает разрешение на выполнение определенной задачи. Обычно, чтобы пользователь мог получить разрешение на просмотр или изменение ресурсов, он должен сначала пройти аутентификацию. Несмотря на то, что они объединены, их не следует путать друг с другом.

Роли в протоколе OAuth

В любом протоколе авторизации задействовано несколько объектов, включая, по крайней мере, сервер аутентификации и клиент. В OAuth задействованы 4 объекта:

  • Владелец ресурса: Владелец ресурса - это пользователь, который разрешает приложению доступ к своей учетной записи. Доступ приложения к учетной записи пользователя ограничен «объемом» предоставленной авторизации (например, доступ для чтения или записи).
  • Клиент: клиент - это приложение, которое хочет получить доступ к учетной записи пользователя. Прежде чем он сможет это сделать, он должен быть авторизован пользователем, и авторизация должна быть подтверждена API.
  • Сервер ресурсов. Сервер ресурсов содержит защищенные учетные записи пользователей и данные, которые должен получить клиент.
  • Сервер авторизации: сервер авторизации проверяет личность пользователя, затем выдает токены доступа клиенту.

С точки зрения разработчика приложения, API службы выполняет роли как сервера ресурсов, так и сервера авторизации.

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

Абстрактный поток протокола

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

Абстрактный протокол состоит из 6 простых шагов:

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

2- Пользователь соглашается на запрос авторизации

3- Клиент отправляет это соглашение на сервер авторизации, чтобы сообщить, что владелец ресурса доверяет клиенту.

4- Сервер авторизации соглашается (или нет) предоставить клиенту доступ к желаемому ресурсу, отправив обратно (или нет) токен доступа, который распознается сервером ресурсов.

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

6- Сервер ресурсов отвечает защищенным ресурсом

Стоит отметить два важных аспекта этого протокола:

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

Разрешение на авторизацию

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

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

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

Тип гранта: код авторизации

Пользователь входит в приложение 3P и хочет получить доступ к частному ресурсу. 3P-приложение отправляет запрос авторизации на сервер авторизации. Сервер аутентификации напрямую связывается с пользователем для аутентификации и дает свое согласие на предоставление 3P-приложению доступа к желаемому ресурсу. Если согласие предоставлено, сервер аутентификации отправляет код авторизации приложению 3P. Затем приложение 3P использует этот код со своим собственным секретом клиента для запроса токена с сервера аутентификации. После проверки сервер аутентификации отправляет токен доступа в 3P-приложение, которое, таким образом, сможет получить ресурс, используя этот токен доступа.

Client Secret похож на закрытый ключ, которым уже владеет 3P-приложение, и который сервер Auth использует для идентификации этого 3P-приложения среди других. Этот секрет создается сервером аутентификации для разработчиков 3P-приложения, которые жестко кодируют его в исходном коде 3P-приложения. Этот ключ делает метод кода авторизации наиболее безопасным.

Очень важно отметить, что трафик между веб-приложением и сервером аутентификации полностью скрыт от пользователя, поскольку мы рассматриваем здесь серверные приложения. Разработчики никогда не должны использовать разрешение на авторизацию с использованием кода авторизации в клиентских приложениях, таких как приложения React или Angular, или в мобильных приложениях, потому что трафик между приложением 3P и сервером аутентификации доступен пользователю. Это означает, что любой может получить секрет клиента при прослушивании сетевого трафика. Для приложений этого типа используется Неявный метод.

Тип гранта: неявный

Предоставление неявной авторизации проще, потому что оно содержит меньше обменов между 3P-приложением и сервером аутентификации. Обратной стороной является, как вы, наверное, догадались, меньшая безопасность, поскольку сервер Auth никогда не проверяет, действительно ли это 3P-приложение получило токен доступа. Этот метод сильно зависит от переадресации.

3P-приложение отправляет запрос на сервер Auth для получения токена доступа. Сервер аутентификации перенаправляет пользователя в приглашение, где он дает свое согласие. Затем сервер аутентификации перенаправляется в 3P-приложение с токеном доступа.

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

На этом этапе вы понимаете базовую механику наиболее распространенного протокола авторизации. В следующей статье я расскажу вам, как использовать OAuth для вызова API Google как из серверного приложения, так и из клиентского приложения Javascript.

Получайте уведомления об интересном содержании по электронной почте! Подпишитесь на мой информационный бюллетень.

Ресурсы: