OAuth 2 или «Открытая авторизация» — это стандарт, разработанный для предоставления сайту или приложению доступа к ресурсам, размещенным другими веб-приложениями. Он появился в 2012 году, заменив версию 1.0, и стал отраслевым стандартом для онлайн-авторизации. OAuth 2.0 обеспечивает доступ и ограничивает действия клиентских приложений над ресурсами, выполняемыми от имени пользователя. При этом учетные данные пользователя не передаются.
Принципы OAuth2.0
OAuth 2.0 является протоколом авторизации, важно не путать его с протоколом аутентификации. Он служит средством предоставления доступа к набору ресурсов (удаленные API, или данным пользователя).
В OAuth 2.0 используются токены (это часть данных, которая является авторизацией для доступа от имени конечного пользователя). OAuth 2.0 не определяет конкретный формат токенов. Однако часто используется формат JSON Web Token (JWT), что позволяет эмитентам включать данные в сам токен. Кроме того, по соображениям безопасности токены могут иметь ограниченный срок действия.
Роли OAuth2.0
Роли - часть основной спецификации фреймворка авторизации OAuth2.0. Они определяют основные компоненты системы OAuth 2.0 и распределяются так:
- Владелец ресурса: пользователь или система, которая владеет защищенными данными и может предоставлять к ним доступ.
- Клиент: Это система, которой требуется доступ к защищенным ресурсам. Чтобы его получить, Клиент должен иметь соответствующий Тoкен.
- Сервер авторизации: сервер, который получает запросы от Клиента на получение токенов и выдает их после успешной аутентификации, а также согласия владельца. Здесь присутствуют две конечные точки: точка авторизации, которая обрабатывает интерактивную аутентификацию и согласие пользователя, и точка токена, которая участвует во взаимодействии между машинами.
- Сервер ресурсов: сервер, который защищает ресурсы пользователя и получает запросы на доступ от клиента. Он принимает и проверяет токен, после чего возвращает соответствующие ресурсы.
Области действия OAuth 2.0
Области используются для точного указания причины, по которой может быть предоставлен доступ к ресурсам. Допустимые значения области и ресурсы, к которым они относятся, зависят от сервера.
Токены и авторизационный код
Напрямую возвращать токен владельцу после успешного входа на сервер OAuth 2 небезопасно. Вместо этого возвращается код, который затем обменивается на токен. Кроме того, сервер может выдать токен обновления. В отличие от тoкенов доступа, тoкены обновления обычно имеют длительный срок действия. Они могут быть обменены на новые после его истечения. По этой причине их следует хранить в безопасном месте.
Как работает OAuth 2.0?
Прежде чем использовать OAuth 2.0, клиент должен получить свои учетные данные, идентификатор (ID), а также секрет с сервера, чтобы идентифицировать и аутентифицировать себя при запросе токена.
При использовании OAuth 2.0 запросы на доступ инициируются клиентом, например, мобильным приложением, сайтом, приложением Smart TV и т. д. Запрос, обмен, ответ происходят в следующем порядке:
- Клиент посылает запрос на авторизацию с сервера передавая ID и секрет; он также предоставляет области действия и URI конечной точки (URI перенаправления) для отправки токена или авторизационного кода.
- Сервер авторизации аутентифицирует Клиента, а также проверяет, разрешены ли запрошенные области.
- Владелец ресурса взаимодействует с сервером для предоставления доступа.
- Сервер авторизации перенаправляет обратно код или токен, в зависимости от типа предоставления. Также может быть возвращен Refresh Token.
- С токеном клиент запрашивает доступ к ресурсу с сервера ресурсов.
Типы грантов в OAuth 2.0
Гранты — это набор шагов, которые должен выполнить клиент, чтобы получить доступ к ресурсам. Платформа авторизации предоставляет несколько типов грантов для различных сценариев:
- Предоставление кода авторизации: сервер возвращает одноразовый код клиенту, который затем обменивается на токен. Это предпочтительный вариант для традиционных веб-приложений, где обмен может безопасно происходить на стороне сервера. Поток кода может использоваться одностраничными приложениями (SPA) и мобильными/собственными приложениями. Однако здесь секрет не может быть надежно сохранен, поэтому аутентификация во время обмена ограничивается использованием идентификатора. Лучшей альтернативой является код авторизации с грантом PKCE.
- Неявное предоставление: упрощенный процесс, в котором токен возвращается непосредственно клиенту. В неявном потоке сервер может вернуть его в качестве параметра в URI обратного вызова или в качестве ответа на сообщение формы.
- Предоставление кода авторизации с ключом подтверждения для обмена кодами (PKCE). Этот поток авторизации аналогичен предоставлению кода, но с дополнительными шагами, которые делают его более безопасным для мобильных/собственных приложений и SPA.
- Тип гранта учетных данных владельца ресурса: этот грант требует, чтобы клиент сначала получил учетные данные владельца, которые передаются на сервер. Поэтому он ограничен Клиентами, которым полностью доверяют. Его преимущество заключается в том, что не используется перенаправление на сервер, поэтому оно применимо, когда перенаправление невозможно.
- Тип гранта учетных данных клиента: используется для неинтерактивных приложений, например, автоматизированных процессов, микросервисов и т. д. В этом случае приложение аутентифицируется само по себе с использованием идентификатора и секрета.
- Поток авторизации устройства: позволяет использовать приложения на устройствах с ограниченным вводом, таких как смарт-телевизоры.
- Предоставление токена обновления: поток, который включает обмен старого на новый.
В чём отличие с OpenID
OAuth служит для авторизации, то есть с его помощью одно приложение получает доступ к другому. А OpenID является надстройкой к нему, которая добавляет информацию о логине и профиле вошедшего пользователя. С его помощью становятся возможными сценарии, при которых один логин может использоваться в нескольких приложениях (подход single sign-on).
Поток в OpenID выглядит аналогично OAuth, но в запросе применяется единый opened, а клиент получает access token и id token.
