<step>
     <para>
      The client responds by sending a SASLInitialResponse message, but this
      time the <structfield>auth</structfield> field in the message contains the
      bearer token that was obtained during the client flow.
     </para>
    </step>

    <step>
     <para>
      The server validates the token according to the instructions of the
      token provider. If the client is authorized to connect, it sends an
      AuthenticationOk message to end the SASL exchange.
     </para>
    </step>
   </procedure>
  </sect2>
 </sect1>

 <sect1 id="protocol-replication">
  <title>Streaming Replication Protocol</title>

  <para>
   To initiate streaming replication, the frontend sends the
   <literal>replication</literal> parameter in the startup message. A Boolean
   value of <literal>true</literal> (or <literal>on</literal>,
   <literal>yes</literal>, <literal>1</literal>) tells the backend to go into
   physical replication walsender mode, wherein a small set of replication
   commands, shown below, can be issued instead of SQL statements.
  </para>

  <para>
   Passing <literal>database</literal> as the value for the
   <literal>replication</literal> parameter instructs the backend to go into
   logical replication walsender mode, connecting to the database specified in
   the <literal>dbname</literal> parameter.  In logical replication walsender
   mode, the replication commands shown below as well as normal SQL commands can
   be issued.
  </para>

  <para>
   In either physical replication or logical replication walsender mode, only the
   simple query protocol can be used.
  </para>

  <para>
   For the purpose of testing replication commands, you can make a replication
   connection via <application>psql</application> or any other
   <application>libpq</application>-using tool with a connection string including
   the <literal>replication</literal> option,
   e.g.:
<programlisting>
psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
</programlisting>
   However, it is often more useful to use
   <xref linkend="app-pgreceivewal"/> (for physical replication) or
   <xref linkend="app-pgrecvlogical"/> (for logical replication).
  </para>

  <para>
   Replication commands are logged in the server log when
   <xref linkend="guc-log-replication-commands"/> is enabled.
  </para>

  <para>
   The commands accepted in replication mode are:

   <variablelist>
    <varlistentry id="protocol-replication-identify-system">
     <term><literal>IDENTIFY_SYSTEM</literal>
      <indexterm><primary>IDENTIFY_SYSTEM</primary></indexterm>
     </term>
     <listitem>
      <para>
       Requests the server to identify itself. Server replies with a result
       set of a single row, containing four fields:
      </para>

      <variablelist>
       <varlistentry>
        <term><literal>systemid</literal> (<type>text</type>)</term>
        <listitem>
         <para>
          The unique system identifier identifying the cluster. This
          can be used to check that the base backup used to initialize the
          standby came from the same cluster.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>timeline</literal> (<type>int8</type>)</term>
        <listitem>
         <para>
          Current timeline ID. Also useful to check that the standby is
          consistent with the primary.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>xlogpos</literal> (<type>text</type>)</term>
        <listitem>
         <para>
          Current WAL flush location. Useful to get a known location in the
          write-ahead log where streaming can start.
         </para>
        </listitem>
       </varlistentry>

       <varlistentry>
        <term><literal>dbname</literal> (<type>text</type>)</term>
        <listitem>
         <para>
          Database connected to or null.
         </para>
        </listitem>