<acronym>GSSAPI</acronym> encryption has been successfully
    established, use <function>gss_wrap()</function> to
    encrypt the usual StartupMessage and all subsequent data, prepending the
    length of the result from <function>gss_wrap()</function> as a four byte
    integer in network byte order to the actual encrypted payload.  Note that
    the server will only accept encrypted packets from the client which are less
    than 16kB; <function>gss_wrap_size_limit()</function> should be used by the
    client to determine the size of the unencrypted message which will fit
    within this limit and larger messages should be broken up into multiple
    <function>gss_wrap()</function> calls.  Typical segments are 8kB of
    unencrypted data, resulting in encrypted packets of slightly larger than 8kB
    but well within the 16kB maximum.  The server can be expected to not send
    encrypted packets of larger than 16kB to the client.
   </para>

   <para>
    While the protocol itself does not provide a way for the server to
    force <acronym>GSSAPI</acronym> encryption, the administrator can
    configure the server to reject unencrypted sessions as a byproduct
    of authentication checking.
   </para>
  </sect2>
 </sect1>

 <sect1 id="sasl-authentication">
  <title>SASL Authentication</title>

  <para>
   <firstterm>SASL</firstterm> is a framework for authentication in connection-oriented
   protocols. At the moment, <productname>PostgreSQL</productname> implements three
   SASL authentication mechanisms: SCRAM-SHA-256, SCRAM-SHA-256-PLUS, and
   OAUTHBEARER. More might be added in the future. The below steps illustrate how SASL
   authentication is performed in general, while the next subsections give
   more details on particular mechanisms.
  </para>

  <procedure>
   <title>SASL Authentication Message Flow</title>

   <step id="sasl-auth-begin">
    <para>
     To begin a SASL authentication exchange, the server sends an
     AuthenticationSASL message. It includes a list of SASL authentication
     mechanisms that the server can accept, in the server's preferred order.
    </para>
   </step>

   <step id="sasl-auth-initial-response">
    <para>
     The client selects one of the supported mechanisms from the list, and sends
     a SASLInitialResponse message to the server. The message includes the name
     of the selected mechanism, and an optional Initial Client Response, if the
     selected mechanism uses that.
    </para>
   </step>

   <step id="sasl-auth-continue">
    <para>
     One or more server-challenge and client-response message will follow. Each
     server-challenge is sent in an AuthenticationSASLContinue message, followed
     by a response from client in a SASLResponse message. The particulars of
     the messages are mechanism specific.
    </para>
   </step>

   <step id="sasl-auth-end">
    <para>
     Finally, when the authentication exchange is completed successfully, the
     server sends an optional AuthenticationSASLFinal message, followed
     immediately by an AuthenticationOk message. The AuthenticationSASLFinal
     contains additional server-to-client data, whose content is particular to the
     selected authentication mechanism. If the authentication mechanism doesn't
     use additional data that's sent at completion, the AuthenticationSASLFinal
     message is not sent.
    </para>
   </step>
  </procedure>

  <para>
   On error, the server can abort the authentication at any stage, and send an
   ErrorMessage.
  </para>

  <sect2 id="sasl-scram-sha-256">
   <title>SCRAM-SHA-256 Authentication</title>

   <para>
    <literal>SCRAM-SHA-256</literal>, and its variant with channel
    binding <literal>SCRAM-SHA-256-PLUS</literal>, are password-based
    authentication mechanisms. They are described in
    detail in <ulink url="https://datatracker.ietf.org/doc/html/rfc7677">RFC 7677</ulink>
    and <ulink url="https://datatracker.ietf.org/doc/html/rfc5802">RFC 5802</ulink>.
   </para>