which develops and/or
        administers the OAuth authorization servers and clients for a given application.
        Different providers typically choose different implementation details
        for their OAuth systems; a client of one provider is not generally
        guaranteed to have access to the servers of another.
       </para>
       <para>
        This use of the term "provider" is not standard, but it seems to be in
        wide use colloquially. (It should not be confused with OpenID's similar
        term "Identity Provider". While the implementation of OAuth in
        <productname>PostgreSQL</productname> is intended to be interoperable
        and compatible with OpenID Connect/OIDC, it is not itself an OIDC client
        and does not require its use.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Authorization Server</term>
      <listitem>
       <para>
        The system which receives requests from, and issues access tokens to,
        the client after the authenticated resource owner has given approval.
        <productname>PostgreSQL</productname> does not provide an authorization
        server; it is the responsibility of the OAuth provider.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term id="auth-oauth-issuer">Issuer</term>
      <listitem>
       <para>
        An identifier for an authorization server, printed as an
        <literal>https://</literal> URL, which provides a trusted "namespace"
        for OAuth clients and applications. The issuer identifier allows a
        single authorization server to talk to the clients of mutually
        untrusting entities, as long as they maintain separate issuers.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>

    <note>
     <para>
      For small deployments, there may not be a meaningful distinction between
      the "provider", "authorization server", and "issuer". However, for more
      complicated setups, there may be a one-to-many (or many-to-many)
      relationship: a provider may rent out multiple issuer identifiers to
      separate tenants, then provide multiple authorization servers, possibly
      with different supported feature sets, to interact with their clients.
     </para>
    </note>
   </para>

   <para>
    <productname>PostgreSQL</productname> supports bearer tokens, defined in
    <ulink url="https://datatracker.ietf.org/doc/html/rfc6750">RFC 6750</ulink>,
    which are a type of access token used with OAuth 2.0 where the token is an
    opaque string.  The format of the access token is implementation specific
    and is chosen by each authorization server.
   </para>

   <para>
    The following configuration options are supported for OAuth:
    <variablelist>
     <varlistentry>
      <term><literal>issuer</literal></term>
      <listitem>
       <para>
        An HTTPS URL which is either the exact
        <link linkend="auth-oauth-issuer">issuer identifier</link> of the
        authorization server, as defined by its discovery document, or a
        well-known URI that points directly to that discovery document. This
        parameter is required.
       </para>
       <para>
        When an OAuth client connects to the server, a URL for the discovery
        document will be constructed using the issuer identifier. By default,
        this URL uses the conventions of OpenID Connect Discovery: the path
        <literal>/.well-known/openid-configuration</literal> will be appended
        to the end of the issuer identifier. Alternatively, if the
        <literal>issuer</literal> contains a <literal>/.well-known/</literal>
        path segment, that URL will be provided to the client as-is.
       </para>
       <warning>
        <para>
         The OAuth client in libpq requires the server's issuer setting to
         exactly match the issuer identifier which is provided in the discovery
         document, which must in