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

Когда в Postgres Pro задействуется SCRAM-SHA-256, сервер игнорирует имя пользователя, которое клиент передаёт в client-first-message. Вместо этого используется имя, переданное ранее в стартовом сообщении. Согласно спецификации SCRAM, имя пользователя должно быть в UTF-8, но Postgres Pro поддерживает разные кодировки символов, и значит, имя пользователя Postgres Pro не всегда будет представимо в UTF-8.

В спецификации SCRAM говорится, что пароль также должен передаваться в UTF-8 и обрабатываться алгоритмом SASLprep. Однако Postgres Pro не требует, чтобы пароль представлялся в UTF-8. Когда устанавливается пароль пользователя, он обрабатывается алгоритмом SASLprep как пароль в UTF-8, вне зависимости от фактической кодировки. Однако если он представлен недопустимой для UTF-8 последовательностью байтов либо содержит комбинации байтов UTF-8, которые не принимает алгоритм SASLprep, это не будет считаться ошибкой — при аутентификации будет использоваться исходный пароль, без обработки SASLprep. Это позволяет нормализовать пароли, представленные в UTF-8, и при этом использовать пароли не в UTF-8, а также не требует, чтобы система знала, в какой кодировке задан пароль.

Связывание каналов поддерживается в Postgres Pro при сборке с использованием SSL. Для SCRAM со связыванием каналов в качестве имени механизма SASL выбрано SCRAM-SHA-256-PLUS. Postgres Pro использует тип связывания tls-server-end-point.

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

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

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

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

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

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