Even if authorization fails, a module may choose to continue to pull
       authentication information from the token for use in auditing and
       debugging.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Authenticate the End User</term>
     <listitem>
      <para>
       Finally, the validator should determine a user identifier for the token,
       either by asking the provider for this information or by extracting it
       from the token itself, and return that identifier to the server (which
       will then make a final authorization decision using the HBA
       configuration). This identifier will be available within the session via
       <link linkend="functions-info-session-table"><function>system_user</function></link>
       and recorded in the server logs if <xref linkend="guc-log-connections"/>
       is enabled.
      </para>
      <para>
       Different providers may record a variety of different authentication
       information for an end user, typically referred to as
       <emphasis>claims</emphasis>. Providers usually document which of these
       claims are trustworthy enough to use for authorization decisions and
       which are not. (For instance, it would probably not be wise to use an
       end user's full name as the identifier for authentication, since many
       providers allow users to change their display names arbitrarily.)
       Ultimately, the choice of which claim (or combination of claims) to use
       comes down to the provider implementation and application requirements.
      </para>
      <para>
       Note that anonymous/pseudonymous login is possible as well, by enabling
       usermap delegation; see
       <xref linkend="oauth-validator-design-usermap-delegation"/>.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>
  </sect2>

  <sect2 id="oauth-validator-design-guidelines">
   <title>General Coding Guidelines</title>
   <para>
    Developers should keep the following in mind when implementing token
    validation:
   </para>
   <variablelist>
    <varlistentry>
     <term>Token Confidentiality</term>
     <listitem>
      <para>
       Modules should not write tokens, or pieces of tokens, into the server
       log. This is true even if the module considers the token invalid; an
       attacker who confuses a client into communicating with the wrong provider
       should not be able to retrieve that (otherwise valid) token from the
       disk.
      </para>
      <para>
       Implementations that send tokens over the network (for example, to
       perform online token validation with a provider) must authenticate the
       peer and ensure that strong transport security is in use.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Logging</term>
     <listitem>
      <para>
       Modules may use the same <link linkend="error-message-reporting">logging
       facilities</link> as standard extensions; however, the rules for emitting
       log entries to the client are subtly different during the authentication
       phase of the connection. Generally speaking, modules should log
       verification problems at the <symbol>COMMERROR</symbol> level and return
       normally, instead of using <symbol>ERROR</symbol>/<symbol>FATAL</symbol>
       to unwind the stack, to avoid leaking information to unauthenticated
       clients.
      </para>
     </listitem>
    </varlistentry>
    <varlistentry>
     <term>Interruptibility</term>
     <listitem>
      <para>
       Modules must remain interruptible by signals so that the server can
       correctly handle authentication timeouts and shutdown signals from
       <application>pg_ctl</application>. For example, blocking calls on sockets
       should generally be replaced with code that handles both socket events
       and interrupts without races (see <function>WaitLatchOrSocket()</function>,
       <function>WaitEventSetWait()</function>,