to, or list the roles
    that a user may assume, and duplicating that knowledge into local usermaps
    for every server may not be desirable.
   </para>
   <para>
    To bypass username mapping entirely, and have the validator module assume
    the additional responsibility of authorizing user connections, the HBA may
    be configured with <xref linkend="auth-oauth-delegate-ident-mapping"/>.
    The module may then use token scopes or an equivalent method to decide
    whether the user is allowed to connect under their desired role. The user
    identifier will still be recorded by the server, but it plays no part in
    determining whether to continue the connection.
   </para>
   <para>
    Using this scheme, authentication itself is optional. As long as the module
    reports that the connection is authorized, login will continue even if there
    is no recorded user identifier at all. This makes it possible to implement
    anonymous or pseudonymous access to the database, where the third-party
    provider performs all necessary authentication but does not provide any
    user-identifying information to the server. (Some providers may create an
    anonymized ID number that can be recorded instead, for later auditing.)
   </para>
   <para>
    Usermap delegation provides the most architectural flexibility, but it turns
    the validator module into a single point of failure for connection
    authorization. Use with caution.
   </para>
  </sect2>
 </sect1>

 <sect1 id="oauth-validator-init">
  <title>Initialization Functions</title>
  <indexterm zone="oauth-validator-init">
   <primary>_PG_oauth_validator_module_init</primary>
  </indexterm>
  <para>
   OAuth validator modules are dynamically loaded from the shared
   libraries listed in <xref linkend="guc-oauth-validator-libraries"/>.
   Modules are loaded on demand when requested from a login in progress.
   The normal library search path is used to locate the library. To
   provide the validator callbacks and to indicate that the library is an OAuth
   validator module a function named
   <function>_PG_oauth_validator_module_init</function> must be provided. The
   return value of the function must be a pointer to a struct of type
   <structname>OAuthValidatorCallbacks</structname>, which contains a magic
   number and pointers to the module's token validation functions. The returned
   pointer must be of server lifetime, which is typically achieved by defining
   it as a <literal>static const</literal> variable in global scope.
<programlisting>
typedef struct OAuthValidatorCallbacks
{
    uint32        magic;            /* must be set to PG_OAUTH_VALIDATOR_MAGIC */

    ValidatorStartupCB startup_cb;
    ValidatorShutdownCB shutdown_cb;
    ValidatorValidateCB validate_cb;
} OAuthValidatorCallbacks;

typedef const OAuthValidatorCallbacks *(*OAuthValidatorModuleInit) (void);
</programlisting>

   Only the <function>validate_cb</function> callback is required, the others
   are optional.
  </para>
 </sect1>

 <sect1 id="oauth-validator-callbacks">
  <title>OAuth Validator Callbacks</title>
  <para>
   OAuth validator modules implement their functionality by defining a set of
   callbacks. The server will call them as required to process the
   authentication request from the user.
  </para>

  <sect2 id="oauth-validator-callback-startup">
   <title>Startup Callback</title>
   <para>
    The <function>startup_cb</function> callback is executed directly after
    loading the module. This callback can be used to set up local