as <literal>ann</literal>. User
   <literal>bryanh</literal> would be allowed to connect as either
   <literal>bryanh</literal> or as <literal>guest1</literal>.
  </para>

  <example id="example-pg-ident.conf">
   <title>An Example <filename>pg_ident.conf</filename> File</title>
<programlisting>
# MAPNAME       SYSTEM-USERNAME         PG-USERNAME

omicron         bryanh                  bryanh
omicron         ann                     ann
# bob has user name robert on these machines
omicron         robert                  bob
# bryanh can also connect as guest1
omicron         bryanh                  guest1
</programlisting>
  </example>
 </sect1>

 <sect1 id="auth-methods">
  <title>Authentication Methods</title>

  <para>
   <productname>PostgreSQL</productname> provides various methods for
   authenticating users:

   <itemizedlist>
    <listitem>
     <para>
      <link linkend="auth-trust">Trust authentication</link>, which
      simply trusts that users are who they say they are.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-password">Password authentication</link>, which
      requires that users send a password.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="gssapi-auth">GSSAPI authentication</link>, which
      relies on a GSSAPI-compatible security library.  Typically this is
      used to access an authentication server such as a Kerberos or
      Microsoft Active Directory server.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="sspi-auth">SSPI authentication</link>, which
      uses a Windows-specific protocol similar to GSSAPI.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-ident">Ident authentication</link>, which
      relies on an <quote>Identification Protocol</quote>
      (<ulink url="https://datatracker.ietf.org/doc/html/rfc1413">RFC 1413</ulink>)
      service on the client's machine.  (On local Unix-socket connections,
      this is treated as peer authentication.)
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-peer">Peer authentication</link>, which
      relies on operating system facilities to identify the process at the
      other end of a local connection.  This is not supported for remote
      connections.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-ldap">LDAP authentication</link>, which
      relies on an LDAP authentication server.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-radius">RADIUS authentication</link>, which
      relies on a RADIUS authentication server.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-cert">Certificate authentication</link>, which
      requires an SSL connection and authenticates users by checking the
      SSL certificate they send.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-pam">PAM authentication</link>, which
      relies on a PAM (Pluggable Authentication Modules) library.
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-bsd">BSD authentication</link>, which
      relies on the BSD Authentication framework (currently available
      only on OpenBSD).
     </para>
    </listitem>
    <listitem>
     <para>
      <link linkend="auth-oauth">OAuth authorization/authentication</link>,
      which relies on an external OAuth 2.0 identity provider.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
   Peer authentication is usually recommendable for local connections,
   though trust authentication might be sufficient in some circumstances.
   Password authentication is the easiest choice for remote connections.
   All the other options require some kind of external security
   infrastructure (usually an authentication server or a certificate
   authority for issuing SSL certificates), or are platform-specific.