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>

   <para>
    When SCRAM-SHA-256 is used in PostgreSQL, the server will ignore the user name
    that the client sends in the <structname>client-first-message</structname>. The user name
    that was already sent in the startup message is used instead.
    <productname>PostgreSQL</productname> supports multiple character encodings, while SCRAM
    dictates UTF-8 to be used for the user name, so it might be impossible to
    represent the PostgreSQL user name in UTF-8.
   </para>

   <para>
    The SCRAM specification dictates that the password is also in UTF-8, and is
    processed with the <firstterm>SASLprep</firstterm> algorithm.
    <productname>PostgreSQL</productname>, however, does not require UTF-8 to be used for
    the password. When a user's password is set, it is processed with SASLprep
    as if it was in UTF-8, regardless of the actual encoding used. However, if
    it is not a legal UTF-8 byte sequence, or it contains UTF-8 byte sequences
    that are prohibited by the SASLprep algorithm, the raw password will be used
    without SASLprep processing, instead of throwing an error. This allows the
    password to be normalized when it is in UTF-8, but still allows a non-UTF-8
    password to be used, and doesn't require the system to know which encoding
    the password is in.
   </para>

   <para>
    <firstterm>Channel binding</firstterm> is supported in PostgreSQL builds with
    SSL support. The SASL mechanism name for SCRAM with channel binding is
    <literal>SCRAM-SHA-256-PLUS</literal>.  The channel binding type used by
    PostgreSQL is <literal>tls-server-end-point</literal>.
   </para>

   <para>
    In <acronym>SCRAM</acronym> without channel binding, the server chooses
    a random number that is transmitted to the client to be mixed with the
    user-supplied password in the transmitted password hash.  While this
    prevents the password hash from being successfully retransmitted in
    a later session, it does not prevent a fake server between the real
    server and client from passing through the server's random value
    and successfully authenticating.
   </para>

   <para>
    <acronym>SCRAM</acronym> with channel binding prevents such
    man-in-the-middle attacks by mixing the signature of the server's
    certificate into the transmitted password hash. While a fake server can
    retransmit the real server's certificate, it doesn't have access to the
    private key matching that certificate, and therefore cannot prove it is
    the owner, causing SSL connection failure.
   </para>

   <procedure>
    <title>Example</title>
    <step id="scram-begin">
     <para>
      The server sends an AuthenticationSASL message. It includes a list of
      SASL authentication mechanisms that the server can accept.
      This will be <literal>SCRAM-SHA-256-PLUS</literal>
      and <literal>SCRAM-SHA-256</literal> if the server is built with SSL
      support, or else just the latter.
     </para>
    </step>