SCRAM-SHA-256, и его вариант с привязкой к каналу SCRAM-SHA-256-PLUS, являются механизмами аутентификации на основе пароля. Они подробно описаны в RFC 7677 и RFC 5802.

Когда в PostgreSQL используется SCRAM-SHA-256, сервер игнорирует имя пользователя, которое клиент отправляет в client-first-message. Вместо этого используется имя пользователя, которое уже было отправлено в сообщении о запуске. Tantor SE поддерживает несколько кодировок символов, в то время как SCRAM требует использования UTF-8 для имени пользователя, поэтому может быть невозможно представить имя пользователя PostgreSQL в UTF-8.

Спецификация SCRAM предписывает, что пароль также должен быть в кодировке UTF-8 и обрабатываться с помощью алгоритма SASLprep. Однако Tantor SE не требует использования UTF-8 для пароля. При установке пароля пользователя он обрабатывается с помощью SASLprep, как если бы он был в кодировке UTF-8, независимо от фактической кодировки. Однако, если это не является допустимой последовательностью байтов UTF-8 или содержит последовательности байтов UTF-8, запрещенные алгоритмом SASLprep, будет использоваться исходный пароль без обработки SASLprep, вместо генерации ошибки. Это позволяет нормализовать пароль, когда он находится в кодировке UTF-8, но все же позволяет использовать пароль, не находящийся в кодировке UTF-8, и не требует знания системой кодировки пароля.

Привязка канала поддерживается в сборках PostgreSQL с поддержкой SSL. Имя механизма SASL для SCRAM с привязкой канала - SCRAM-SHA-256-PLUS. Тип привязки канала, используемый PostgreSQL - tls-server-end-point.

В SCRAM без привязки канала сервер выбирает случайное число, которое передается клиенту для смешивания с предоставленным пользователем паролем в переданном хеше пароля. Это предотвращает успешное повторное передачу хеша пароля в последующей сессии, но не предотвращает поддельный сервер между реальным сервером и клиентом от передачи случайного значения сервера и успешной аутентификации.

SCRAM с привязкой канала предотвращает подобные атаки "человек посередине", смешивая подпись сертификата сервера в передаваемый хеш пароля. Хотя фальшивый сервер может повторно передать сертификат реального сервера, у него нет доступа к закрытому ключу, соответствующему этому сертификату, и поэтому он не может доказать, что является владельцем, что приводит к сбою SSL-соединения.

OAUTHBEARER является механизмом на основе токенов для федеративной аутентификации. Он подробно описан в RFC 7628.

Типичный обмен отличается в зависимости от того, есть ли у клиента уже сохраненный маркер доступа для текущего пользователя. Если его нет, обмен будет происходить через два соединения: первое соединение "обнаружения" для получения метаданных OAuth с сервера, и второе соединение для отправки маркера после того, как клиент его получит. (libpq в настоящее время не реализует метод кеширования как часть своего встроенного процесса, поэтому использует обмен через два соединения.)

Этот механизм инициируется клиентом, как и SCRAM. Начальный ответ клиента состоит из стандартного заголовка "GS2", используемого SCRAM, за которым следует список key=value пар. Единственный ключ, поддерживаемый сервером в настоящее время, это auth, который содержит токен носителя. OAUTHBEARER дополнительно указывает три необязательных компонента начального ответа клиента (это authzid заголовка GS2, и ключи host и port), которые в настоящее время игнорируются сервером.

OAUTHBEARER не поддерживает привязку канала, и не существует механизма "OAUTHBEARER-PLUS". Этот механизм не использует данные сервера во время успешной аутентификации, поэтому сообщение AuthenticationSASLFinal не используется в обмене.