20.15. Авторизация/аутентификация по OAuth #
OAuth 2.0 — стандартизированный механизм, определённый в RFC 6749, который позволяет сторонним приложениям получать ограниченный доступ к защищённым ресурсам. Поддержка клиента OAuth должна быть включена при сборке PostgreSQL; за дополнительными сведениями обратитесь к Главе 17.
Для описания экосистемы OAuth в документации используются следующие термины:
- Владелец ресурса (или конечный пользователь)
Пользователь или система, которая владеет защищёнными ресурсами и может предоставлять доступ к ним. В документации также используется термин конечный пользователь, если владельцем ресурса является человек. Если для подключения к БД по OAuth используется psql, вы являетесь владельцем ресурса/конечным пользователем.
- Клиент
Система, которая обращается к защищённым ресурсам, используя токены доступа. Приложения, использующие libpq, например psql, являются клиентами OAuth при подключении к кластеру PostgreSQL.
- Сервер ресурса
Система, где размещены защищённые ресурсы, к которым обращается клиент. Сервером ресурса является кластер PostgreSQL, к которому происходит подключение.
- Поставщик
Организация, поставщик продукта или иной субъект, который разрабатывает и/или администрирует серверы и клиенты авторизации OAuth для определённого приложения. Разные поставщики обычно выбирают разные способы реализации своих OAuth-систем. Как правило, не гарантируется, что клиент одного поставщика сможет обращаться к серверам другого поставщика.
Использование термина «поставщик» (provider) в этом смысле не является стандартным, но, по всей видимости, уже широко используется. (Его не следует путать с термином «поставщик удостоверений» (identity provider) в контексте OpenID. Хотя OAuth в PostgreSQL реализован взаимно совместимым с протоколом OpenID Connect/OIDC, сам по себе клиентом OIDC он не является и не требует его использовать.)
- Сервер авторизации
Система, получающая запросы от клиента и выпускающая токены доступа для него, после получения одобрения от аутентифицированного владельца ресурса. PostgreSQL не предоставляет сервер авторизации — за это отвечает поставщик OAuth.
- Издатель
Идентификатор сервера авторизации (в виде URL c
https://
), предоставляющего доверенное «пространство имён» для клиентов и приложений OAuth. Идентификатор издателя позволяет одному серверу авторизации взаимодействовать с клиентами недоверяющих друг другу субъектов, использующих разных издателей.
Примечание
Для небольших окружений существенных различий между понятиями «поставщик», «сервер авторизации» и «издатель» может не быть. Однако в более сложных возможны взаимосвязи один-ко-многим (или многие-ко-многим): поставщик может выпускать несколько идентификаторов издателей разным арендаторам и затем предоставлять несколько серверов авторизации (возможно, с разными наборами поддерживаемой функциональности) для взаимодействия с клиентами.
PostgreSQL поддерживает токены типа bearer, которые определены в RFC 6750 как тип токенов доступа, используемых с протоколом OAuth 2.0, где токен является непрозрачной строкой. Формат токена доступа зависит от реализации и выбирается каждым сервером авторизации.
Для протокола OAuth доступны следующие параметры конфигурации:
issuer
Адрес с HTTPS, который либо полностью совпадает с идентификатором издателя сервера авторизации, как определено в документе обнаружения, либо является известным URI, который указывает прямо на документ обнаружения. Это обязательный параметр.
Когда клиент OAuth подключается к серверу, адрес для документа обнаружения создаётся с помощью идентификатора издателя. По умолчанию этот адрес соответствует соглашениям OpenID Connect Discovery: путь
/.well-known/openid-configuration
добавляется в конце идентификатора издателя. Как вариант, если параметрissuer
содержит сегмент пути/.well-known/
, адрес предоставляется клиенту как есть.Предупреждение
Клиент OAuth в libpq требует, чтобы значение параметра сервера
issuer
полностью совпадало с идентификатором издателя, который содержится в документе обнаружения. А значение идентификатора издателя, в свою очередь, должно совпадать со значением параметра oauth_issuer клиента. При этом совпадение должно быть строгое — варианты регистра и форматирования не допускаются.scope
Разделённый пробелами список сфер действия OAuth, необходимых серверу для авторизации клиента и аутентификации пользователя. Корректные значения определяет сервер авторизации и используемый модуль проверки OAuth (за дополнительной информацией о модулях проверки обратитесь к Главе 50). Это обязательный параметр.
validator
Библиотека для проверки токенов типа bearer. Если задаётся, имя должно полностью совпадать с одной из библиотек, указанных в oauth_validator_libraries. Этот параметр является обязательным, только если в
oauth_validator_libraries
указано больше одной библиотеки.map
Позволяет сопоставлять имена поставщиков удостоверений OAuth с именами пользователей БД. За дополнительной информацией обратитесь к Разделу 20.2. Если сопоставление не указано, имя пользователя, связанное с токеном (как определено модулем проверки OAuth), должно полностью совпадать с именем запрашиваемой роли. Это необязательный параметр.
-
delegate_ident_mapping
Дополнительный параметр, не предназначенный для широкого использования.
Если задано значение
1
, стандартное сопоставление пользователей при помощиpg_ident.conf
пропускается и за сопоставление удостоверений конечных пользователей с ролями БД начинает отвечать модуль проверки OAuth. Если модуль проверки авторизует токен, сервер доверяет тому, что пользователю разрешено подключаться с запрошенной ролью и что подключение должно состояться вне зависимости от статуса аутентификации пользователя.Этот параметр несовместим с
map
.Предупреждение
Параметр
delegate_ident_mapping
обеспечивает дополнительную гибкость в проектировании системы аутентификации, однако требует аккуратной реализации модуля проверки OAuth. Такой модуль должен определять, обеспечивает ли токен достаточный уровень прав конечного пользователя в дополнение к стандартным проверкам, которые должны выполнять все модули проверки. Используйте этот параметр с осторожностью.