must
    already exist in the database before BSD Authentication can be used
    for authentication. The BSD Authentication framework is currently
    only available on OpenBSD.
   </para>

   <para>
    BSD Authentication in <productname>PostgreSQL</productname> uses
    the <literal>auth-postgresql</literal> login type and authenticates with
    the <literal>postgresql</literal> login class if that's defined
    in <filename>login.conf</filename>. By default that login class does not
    exist, and <productname>PostgreSQL</productname> will use the default login class.
   </para>

   <note>
    <para>
     To use BSD Authentication, the PostgreSQL user account (that is, the
     operating system user running the server) must first be added to
     the <literal>auth</literal> group.  The <literal>auth</literal> group
     exists by default on OpenBSD systems.
    </para>
   </note>
  </sect1>

  <sect1 id="auth-oauth">
   <title>OAuth Authorization/Authentication</title>

   <indexterm zone="auth-oauth">
    <primary>OAuth Authorization/Authentication</primary>
   </indexterm>

   <para>
    OAuth 2.0 is an industry-standard framework, defined in
    <ulink url="https://datatracker.ietf.org/doc/html/rfc6749">RFC 6749</ulink>,
    to enable third-party applications to obtain limited access to a protected
    resource.

    OAuth client support has to be enabled when <productname>PostgreSQL</productname>
    is built, see <xref linkend="installation"/> for more information.
   </para>

   <para>
    This documentation uses the following terminology when discussing the OAuth
    ecosystem:

    <variablelist>

     <varlistentry>
      <term>Resource Owner (or End User)</term>
      <listitem>
       <para>
        The user or system who owns protected resources and can grant access to
        them. This documentation also uses the term <emphasis>end user</emphasis>
        when the resource owner is a person. When you use
        <application>psql</application> to connect to the database using OAuth,
        you are the resource owner/end user.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Client</term>
      <listitem>
       <para>
        The system which accesses the protected resources using access
        tokens. Applications using libpq, such as <application>psql</application>,
        are the OAuth clients when connecting to a
        <productname>PostgreSQL</productname> cluster.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Resource Server</term>
      <listitem>
       <para>
        The system hosting the protected resources which are
        accessed by the client. The <productname>PostgreSQL</productname>
        cluster being connected to is the resource server.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>Provider</term>
      <listitem>
       <para>
        The organization, product vendor, or other entity 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