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.
  </para>

  <para>
   The following sections describe each of these authentication methods
   in more detail.
  </para>
 </sect1>

  <sect1 id="auth-trust">
   <title>Trust Authentication</title>

   <para>
    When <literal>trust</literal> authentication is specified,
    <productname>PostgreSQL</productname> assumes that anyone who can
    connect to the server is authorized to access the database with
    whatever database user name they specify (even superuser names).
    Of course, restrictions made in the <literal>database</literal> and
    <literal>user</literal> columns still apply.
    This method should only be used when there is adequate
    operating-system-level protection on connections to the server.
   </para>

   <para>
    <literal>trust</literal> authentication is appropriate and very
    convenient for local connections on a single-user workstation.  It
    is usually <emphasis>not</emphasis> appropriate by itself on a multiuser
    machine.  However, you might be able to use <literal>trust</literal> even
    on a multiuser machine, if you restrict access to the server's
    Unix-domain socket file using file-system permissions.  To do this, set the
    <varname>unix_socket_permissions</varname> (and possibly
    <varname>unix_socket_group</varname>) configuration parameters as
    described in <xref linkend="runtime-config-connection"/>.  Or you
    could set the <varname>unix_socket_directories</varname>
    configuration parameter to place the socket file in a suitably
    restricted directory.
   </para>

   <para>
    Setting file-system permissions only helps for Unix-socket connections.
    Local TCP/IP connections are not restricted by file-system permissions.
    Therefore, if you want to use file-system permissions for local security,
    remove the <literal>host ... 127.0.0.1 ...</literal> line from
    <filename>pg_hba.conf</filename>, or change it to a
    non-<literal>trust</literal> authentication method.
   </para>

   <para>
    <literal>trust</literal> authentication is only suitable for TCP/IP connections
    if you trust every user on every machine that is allowed to connect
    to the server by the <filename>pg_hba.conf</filename> lines that specify
    <literal>trust</literal>.  It is seldom reasonable to use <literal>trust</literal>
    for any TCP/IP connections other than those from <systemitem>localhost</systemitem> (127.0.0.1).
   </para>

  </sect1>

  <sect1 id="auth-password">
   <title>Password Authentication</title>

   <indexterm>
    <primary>MD5</primary>
   </indexterm>
   <indexterm>
    <primary>SCRAM</primary>
   </indexterm>
   <indexterm>
    <primary>password</primary>
    <secondary>authentication</secondary>
   </indexterm>

   <para>
    There are several password-based authentication methods.  These methods
    operate similarly but differ in how the users' passwords are stored on the
    server and how the password provided by a client is sent across the
    connection.