linkend="libpq-connect-connect-timeout"/>. Because then,
            if one of the nodes that are used for load balancing is not responding,
            a new node will be tried.
           </para>
          </listitem>
         </varlistentry>
        </variablelist>
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-oauth-issuer" xreflabel="oauth_issuer">
      <term><literal>oauth_issuer</literal></term>
      <listitem>
       <para>
        The HTTPS URL of a trusted issuer to contact if the server requests an
        OAuth token for the connection. This parameter is required for all OAuth
        connections; it should exactly match the <literal>issuer</literal>
        setting in <link linkend="auth-oauth">the server's HBA configuration</link>.
       </para>
       <para>
        As part of the standard authentication handshake, <application>libpq</application>
        will ask the server for a <emphasis>discovery document:</emphasis> a URL
        providing a set of OAuth configuration parameters. The server must
        provide a URL that is directly constructed from the components of the
        <literal>oauth_issuer</literal>, and this value must exactly match the
        issuer identifier that is declared in the discovery document itself, or
        the connection will fail. This is required to prevent a class of
        <ulink url="https://mailarchive.ietf.org/arch/msg/oauth/JIVxFBGsJBVtm7ljwJhPUm3Fr-w/">
        "mix-up attacks"</ulink> on OAuth clients.
       </para>
       <para>
        You may also explicitly set <literal>oauth_issuer</literal> to the
        <literal>/.well-known/</literal> URI used for OAuth discovery. In this
        case, if the server asks for a different URL, the connection will fail,
        but a <link linkend="libpq-oauth-authdata-hooks">custom OAuth flow</link>
        may be able to speed up the standard handshake by using previously
        cached tokens. (In this case, it is recommended that
        <xref linkend="libpq-connect-oauth-scope"/> be set as well, since the
        client will not have a chance to ask the server for a correct scope
        setting, and the default scopes for a token may not be sufficient to
        connect.) <application>libpq</application> currently supports the
        following well-known endpoints:
        <itemizedlist spacing="compact">
         <listitem><para><literal>/.well-known/openid-configuration</literal></para></listitem>
         <listitem><para><literal>/.well-known/oauth-authorization-server</literal></para></listitem>
        </itemizedlist>
       </para>
       <warning>
        <para>
         Issuers are highly privileged during the OAuth connection handshake. As
         a rule of thumb, if you would not trust the operator of a URL to handle
         access to your servers, or to impersonate you directly, that URL should
         not be trusted as an <literal>oauth_issuer</literal>.
        </para>
       </warning>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-oauth-client-id" xreflabel="oauth_client_id">
      <term><literal>oauth_client_id</literal></term>
      <listitem>
       <para>
        An OAuth 2.0 client identifier, as issued by the authorization server.
        If the <productname>PostgreSQL</productname> server
        <link linkend="auth-oauth">requests an OAuth token</link> for the
        connection (and if no <link linkend="libpq-oauth-authdata-hooks">custom
        OAuth hook</link> is installed to provide one), then this parameter must
        be set; otherwise, the connection will fail.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="libpq-connect-oauth-client-secret" xreflabel="oauth_client_secret">
      <term><literal>oauth_client_secret</literal></term>
      <listitem>
       <para>
        The client password, if any, to use when contacting the OAuth
        authorization server. Whether this parameter