F.31. Базовый валидатор токенов OAuth 2.0 для PostgreSQL#

F.31. Базовый валидатор токенов OAuth 2.0 для PostgreSQL
F.31. Базовый валидатор токенов OAuth 2.0 для PostgreSQL
Назад НаверхПредметный указатель F. Дополнительные поставляемые модули и расширенияНачало Далее

F.31. Базовый валидатор токенов OAuth 2.0 для PostgreSQL #

F.31.1. Обзор
F.31.2. Требования
F.31.3. Компиляция и установка
F.31.4. Конфигурация
F.31.5. Логика проверки токена
F.31.6. Расширяемость

F.31.1. Обзор #

Этот модуль реализует простой валидатор токенов OAuth 2.0 для встроенной поддержки потока авторизации устройства. Валидатор выполняет минимальную проверку, путем:

  • Извлечение полей sub (subject) и scope из полезной нагрузки JWT.

  • Сравнение областей действия токена с теми, которые требуются записью pg_hba.conf.

  • Сопоставление идентификатора аутентификации sub с ролью базы данных с использованием pg_ident.conf.

  • Разрешение или запрет доступа на основе сопоставления sub и области.

F.31.2. Требования #

  • PostgreSQL версии 18 или выше, настроенный с флагом --with-libcurl.

F.31.3. Компиляция и установка #

  1. Скомпилируйте и установите динамическую библиотеку валидатора. Выполните следующие команды в главной директории: 

    make
make install

    Валидатор будет установлен в каталог <postgres>/lib под именем файла oauth_validator.so.

  2. Добавьте валидатор в postgresql.conf, используя настройку oauth_validator_libraries: 

    oauth_validator_libraries='oauth_validator'

  3. Настройте файл pg_ident.conf. Например: 

    # MAPNAME    SYSTEM-USERNAME                           PG-USERNAME
oauthmap    "7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee"     "mydbuser"

  4. Настройте файл pg_hba.conf. Например: 

    local    all    all    oauth issuer="https://<address>/.well-known/openid-configuration" scope="openid postgres" map="oauthmap"

F.31.4. Конфигурация #

  • postgresql.conf должен содержать модуль валидатора в записи oauth_validator_libraries.

  • pg_hba.conf должен указывать oauth в качестве метода аутентификации и определять oauth_scope.

  • pg_ident.conf должен содержать сопоставления между значениями JWT sub и ролями PostgreSQL.

F.31.4.1. Пример записи в pg_ident.conf #

# MAPNAME    SYSTEM-USERNAME                           PG-USERNAME
oauthmap    "7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee"     "mydbuser"

Если токен содержит sub значение “7cf5b11f-adb2-4e67-83b7-5c75f7f1e6ee”, и проверка проходит, PostgreSQL сопоставит его с ролью mydbuser с использованием записи oauthmap.

F.31.4.2. Пример записи в pg_hba.conf #

local    all    all    oauth issuer="https://<address>/.well-known/openid-configuration" scope="openid postgres" map="oauthmap"

F.31.5. Логика проверки токена #

Основная логика проверки реализована через функцию validate_token. Она выполняет следующие шаги:

  1. Анализ полезной нагрузки токена: Строка необработанного токена анализируется для извлечения его полезной нагрузки. Если токен имеет неверный формат или полезная нагрузка не может быть извлечена, проверка завершается неудачей.

  2. Извлечение утверждений JWT: Полезная нагрузка должна содержать оба:

    • sub: Субъект (используется для идентификации пользователя)

    • scope: Разделенный пробелами список областей, предоставленных токеном

    Если любое из полей отсутствует, проверка завершается неудачей.

  3. Сравнение областей: Области из записи oauth_scope в pg_hba.conf сравниваются с областями, предоставленными токеном. Если некоторые отсутствуют в токене, проверка завершается неудачей.

    В приведенном выше примере конфигурации проверка будет успешной, если токен содержит оба скоупа: openid и postgres.

  4. Установка результата авторизации: Флаг res->authorized устанавливается в true, если области совпадают; в противном случае он устанавливается в false.

  5. Назначение идентификационной аутентификации: Значение sub присваивается res->authn_id, которое PostgreSQL использует для идентификации аутентифицированного пользователя.

  6. Отображение идентификации аутентификации: Это значение sub затем сопоставляется вне этого модуля с записями в pg_ident.conf для определения фактической роли базы данных, которую пользователь имеет право принять.

    Если сопоставление не удается, проверка не проходит.

  7. В противном случае проверка проходит успешно, и клиент авторизован и успешно подключен к базе данных.

F.31.6. Расширяемость #

Эта базовая реализация может быть расширена дополнительными проверками или пользовательской логикой, такими как:

  • Проверка подписей токенов

  • Проверка истечения срока действия токена (exp)

  • Проверка аудитории (aud) или издателя (iss)

  • Динамическое получение ролей пользователя

Назад Наверх Далее
F.30. mchar Начало F.32. online_analyze