在内置的设备授权客户端流程期间，替换默认的用户提示。data指向一个PGpromptOAuthDevice实例：

typedef struct _PGpromptOAuthDevice
{
    const char *verification_uri;   /* verification URI to visit */
    const char *user_code;          /* user code to enter */
    const char *verification_uri_complete;  /* optional combination of URI and
                                             * code, or NULL */
    int         expires_in;         /* seconds until user code expires */
} PGpromptOAuthDevice;

可被包含在libpq中的 OAuth Device Authorization 流程要求最终用户使用浏览器访问一个 URL，然后输入一个代码，以允许libpq代表其连接到服务器。默认提示只是把verification_uri和user_code打印到标准错误。替换实现可以按任意偏好的方式展示这些信息，例如使用 GUI。

该回调只会在内置设备授权流程中被调用。如果应用程序安装了自定义 OAuth 流程，或者libpq构建时未启用内置流程支持，则不会使用这种 authdata 类型。

如果提供了非空的verification_uri_complete，则可以选择把它用于非文本形式的验证（例如显示二维码）。在这种情况下，仍应向最终用户显示 URL 和用户代码，因为该代码需要由提供者手工确认，而 URL 也使得用户在无法使用非文本方式时仍可继续。更多信息见 RFC 8628 第 3.3.1 节。

添加一个自定义流程实现；如果内置流程已安装，则用它替换内置流程。该钩子应当要么直接返回一个适用于当前 user/issuer/scope 组合的 Bearer 令牌（如果能在不阻塞的情况下获得），要么设置一个异步回调来获取令牌。

data指向一个PGoauthBearerRequest实例，应该由实现填充：

typedef struct PGoauthBearerRequest
{
    /* Hook inputs (constant across all calls) */
    const char *openid_configuration; /* OIDC discovery URL */
    const char *scope;                /* required scope(s), or NULL */

    /* Hook outputs */

    /*
     * Callback implementing a custom asynchronous OAuth flow. The signature is
     * platform-dependent: PQ_SOCKTYPE is SOCKET on Windows, and int everywhere
     * else.
     */
    PostgresPollingStatusType (*async) (PGconn *conn,
                                        struct PGoauthBearerRequest *request,
                                        PQ_SOCKTYPE *altsock);

    /* Callback to clean up custom allocations. */
    void        (*cleanup) (PGconn *conn, struct PGoauthBearerRequest *request);

    char       *token;   /* acquired Bearer token */
    void       *user;    /* hook-defined allocated data */
} PGoauthBearerRequest;

libpq会向该钩子提供两项信息：openid_configuration包含描述授权服务器所支持流程的 OAuth 发现文档 URL，而scope包含访问服务器所需的 OAuth scope 列表（以空格分隔，可以为空）。两者中的任意一个或两个都可能为NULL，表示无法发现该信息。（在这种情况下，实现可以通过其他预先配置的知识来确定要求，或者选择失败。）

该钩子的最终输出是token，它必须指向一个可在该连接上使用的有效 Bearer 令牌。（该令牌应由oauth_issuer所指定的发行者签发，并持有所请求的 scope，否则连接会被服务器的验证器模块拒绝。）分配得到的令牌字符串必须在libpq完成连接之前始终有效；该钩子应设置cleanup回调，以便在libpq不再需要该令牌时调用。

如果某个实现无法在首次调用钩子时立即产生token，则应设置async回调，以处理与授权服务器之间的非阻塞通信。 ^[16] 从钩子返回后，将立即调用该回调以启动流程。当回调在不阻塞的情况下无法继续推进时，它应在设置*altsock后返回PGRES_POLLING_READING或PGRES_POLLING_WRITING，其中*altsock是当可以再次取得进展时会被标记为可读/可写的文件描述符。（然后，这个描述符会通过PQsocket()提供给顶层轮询循环。）当流程完成时，在设置好token之后返回PGRES_POLLING_OK；如果失败，则返回PGRES_POLLING_FAILED。

实现可能希望在多次调用async和cleanup回调之间保存额外的数据用于记账。为此提供了user指针；libpq不会触碰其内容，应用程序可以按自己的需要使用它。（记得在令牌清理时释放相关分配。）