SASL 是用于面向连接协议的认证框架。目前，PostgreSQL 只实现了一种 SASL 认证机制：SCRAM-SHA-256，未来可能增加更多机制。以下步骤说明 SASL 认证的一般过程，下一小节则提供有关 SCRAM-SHA-256 的更多细节。
SASL认证消息流
要开始一个SASL认证交换，服务器发送一个AuthenticationSASL消息。它包括服务器可以接受的SASL认证机制列表，按照服务器的首选顺序排列。
客户端从列表中选择一个支持的机制，并向服务器发送一个SASLInitialResponse消息。 该消息包括所选机制的名称，以及如果所选机制使用的话，还包括一个可选的初始客户端响应。
一个或多个服务器挑战和客户端响应消息将随后而来。每个服务器挑战都是在一个 AuthenticationSASLContinue 消息中发送的，随后是客户端在一个 SASLResponse 消息中的响应。这些消息的具体内容是特定于机制的。
最后，当认证交换成功完成时，服务器会发送可选的 AuthenticationSASLFinal 消息，随后立即发送 AuthenticationOk。AuthenticationSASLFinal 包含机制特定的附加数据；若该机制不需要完成时附加数据，则不会发送 AuthenticationSASLFinal。
在错误情况下，服务器可以在任何阶段中止认证，并发送一个ErrorMessage。
SCRAM-SHA-256（下文简称 SCRAM）是目前唯一已实现的 SASL 机制。RFC 7677 和 RFC 5802 对它有详细描述。
当在PostgreSQL中使用SCRAM-SHA-256时，服务器将忽略客户端在client-first-message中发送的用户名。 而是使用已经在启动消息中发送的用户名。 PostgreSQL支持多种字符编码，而SCRAM规定用户名必须使用UTF-8，因此可能无法用UTF-8表示PostgreSQL用户名。
SCRAM规范规定密码也必须是UTF-8编码，并且使用SASLprep算法处理。 然而，PostgreSQL不要求密码必须使用UTF-8编码。 当用户设置密码时，无论实际使用的编码是什么，都会像使用UTF-8一样使用SASLprep进行处理。 但是，如果密码不是合法的UTF-8字节序列，或者包含SASLprep算法禁止的UTF-8字节序列， 则会使用原始密码而不进行SASLprep处理，而不是抛出错误。这样可以在密码为UTF-8时对其进行规范化， 但仍允许使用非UTF-8密码，并且不需要系统知道密码使用的编码方式。
尚未实现通道绑定。
示例
服务器发送 AuthenticationSASL 消息，其中包含服务器可接受的 SASL 认证机制列表。
客户端发送 SASLInitialResponse 消息作为响应，指明所选择的机制 SCRAM-SHA-256。该消息的初始客户端响应字段包含 SCRAM client-first-message。
服务器发送一个AuthenticationSASLContinue消息，其中包含一个SCRAMserver-first-message作为内容。
客户端发送一个SASLResponse消息，其中包含SCRAM client-final-message作为内容。
服务器发送一个AuthenticationSASLFinal消息，带有SCRAM server-final-message，紧接着是一个AuthenticationOk消息。