{"Entry":{"collection":"auth","key":"oauth","name":"oauth","aliases":[],"metadata":{"aliases":[],"category":"Authentication and access control","content_hash":"adcc9e3a1de9c0fb61793cd1ddaf7b9442b64cbfee41a896c84a61309f46c424","derived_content_hash":"0b241d9e73f6329d4aae6fef8d17cb678c8d45ff31a9ae2f2c1b698f70363868","imported_at":"2026-09-30T00:40:33.311433+08:00","name":"oauth","name_zh":"","slug":"oauth","summary":"Authorize and optionally authenticate using a third-party OAuth 2.0 identity provider. See Section 20.14 for details."}},"Definition":{"Collection":"auth","Key":"oauth","SourceDatabase":"center","Version":"18","SourceTable":"authentication_method","SourceKey":"oauth","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"aliases":[],"attributes":{"configuration":"pg_hba.conf","inventory":"User-visible source authentication method","method":"oauth"},"comparison_data":{"documented_option_names":["Authorization Server","Client","Issuer","Provider","Resource Owner (or End User)","Resource Server","delegate_ident_mapping","issuer","map","scope","validator"],"method":"oauth"},"comparison_hash":"614b1b99c2894fb23e3ddaf7706a1e06dd6cc3fd020965f4d8e18ed32ea3a772","description":["Authorize and optionally authenticate using a third-party OAuth 2.0 identity provider. See Section 20.15 for details."],"description_zh":"认证方法 oauth。","description_zh_html":"\u003cp\u003e\n    OAuth 2.0 是一个行业标准框架，定义见\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6749\" target=\"_top\"\u003eRFC 6749\u003c/a\u003e，它允许第三方应用获得对受保护资源的受限访问。在构建 \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 时必须启用 OAuth 客户端支持；详见\u003ca class=\"xref\" href=\"/zh/docs/18/installation.html\" title=\"第 17 章 从源代码安装\"\u003e第 17 章\u003c/a\u003e。\n   \u003c/p\u003e\u003cp\u003e\n    本文档在讨论 OAuth 生态系统时使用下列术语：\n\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e 支持在\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6750\" target=\"_top\"\u003eRFC 6750\u003c/a\u003e\n    中定义的 Bearer 令牌，这是一类用于 OAuth 2.0 的访问令牌，其本体是一个不透明字符串。访问令牌的格式取决于具体实现，由各个授权服务器自行决定。Bearer 令牌以明文形式发送，容易被网络嗅探截获。因此，OAuth 只能通过 SSL 连接使用。\n   \u003c/p\u003e\u003cp\u003e\n    OAuth 支持下列配置选项：\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cdd\u003e\u003cp\u003e\n          使用第三方 OAuth 2.0 身份提供方进行授权，并可选地完成认证。由于 Bearer 令牌以明文形式在网络上传输，不应在不可信网络上使用此方式。详细信息请参见\u003ca class=\"xref\" href=\"/zh/docs/18/auth-oauth.html\" title=\"20.15. OAuth 授权/认证\"\u003e第 20.15 节\u003c/a\u003e。\n         \u003c/p\u003e\u003c/dd\u003e","documentation_revision":{"inputs":[{"file":"auth-oauth.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"125b8285c400613818a4142ab551efc124ef706077278738123e05eea7b7ffda","version":"18.7"},{"file":"auth-pg-hba-conf.html","kind":"same-version-reviewed-manual","locale":"en","sha256":"914d0e35215d0466517afa1fdf26b2b88d3b1fb423777622d524dcd96d164f21","version":"18.7"},{"file":"auth-oauth.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"bac1d44bb72aa9d8503c09cfc818523d34bdb7932fd39f774e3f908ede73a3ae","version":"18.7"},{"file":"auth-pg-hba-conf.html","kind":"same-version-reviewed-manual","locale":"zh-Hans","sha256":"78dffb0de9c1f2f5c1b0b0b1f0efd49cfc71f7b3b6028bc21687c396ae1a98f5","version":"18.7"}],"release":"18.7","runtime_remeasured":false,"source_revision":"pgdoc:b9f0e7232f60f380d642ac9b99226606c254b552"},"facts":[{"label":"Method","value":"oauth"},{"label":"Configuration","value":"pg_hba.conf"},{"label":"Inventory","value":"User-visible source authentication method"}],"facts_zh":[{"label":"方法","value":"oauth"},{"label":"配置","value":"pg_hba.conf"},{"label":"清单","value":"用户可见的源码认证方法"}],"manual_html":"\u003cp\u003e\n    OAuth 2.0 is an industry-standard framework, defined in\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6749\" target=\"_top\"\u003eRFC 6749\u003c/a\u003e,\n    to enable third-party applications to obtain limited access to a protected\n    resource.\n\n    OAuth client support has to be enabled when \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e\n    is built, see \u003ca class=\"xref\" href=\"/docs/18/installation.html\" title=\"Chapter 17. Installation from Source Code\"\u003eChapter 17\u003c/a\u003e for more information.\n   \u003c/p\u003e\u003cp\u003e\n    This documentation uses the following terminology when discussing the OAuth\n    ecosystem:\n\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e supports bearer tokens, defined in\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6750\" target=\"_top\"\u003eRFC 6750\u003c/a\u003e,\n    which are a type of access token used with OAuth 2.0 where the token is an\n    opaque string.  The format of the access token is implementation specific\n    and is chosen by each authorization server.  The bearer token is sent\n    in clear-text, and is vulnerable to network sniffing.  For this reason\n    OAuth should only be used over SSL connections.\n   \u003c/p\u003e\u003cp\u003e\n    The following configuration options are supported for OAuth:\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cdd\u003e\u003cp\u003e\n          Authorize and optionally authenticate using a third-party OAuth 2.0\n          identity provider.  Since the bearer token is sent in clear text over\n          the network, this should not be used on untrusted networks.  See\n          \u003ca class=\"xref\" href=\"/docs/18/auth-oauth.html\" title=\"20.15. OAuth Authorization/Authentication\"\u003eSection 20.15\u003c/a\u003e for details.\n         \u003c/p\u003e\u003c/dd\u003e","manual_path":"/docs/18/auth-oauth.html","related":[],"release":{"catalog_fingerprint":"65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502","channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sections":[],"sections_zh":[],"signature":"","sources":[{"label":"Matching PostgreSQL source archive","sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"auth-oauth.html","sha256":"1e2e63530e79522cd93d2c34bc34a464927dbe46de9b01cdbf324648f1adda8d","url":"/docs/18/auth-oauth.html"},{"label":"PostgreSQL 18 English manual","path":"auth-pg-hba-conf.html","sha256":"6340d4abea2e0a3482afc31bcd1599a0fa10dc28a6f1e05d79ba831e2dd0b4c9","url":"/docs/18/auth-pg-hba-conf.html"}],"tables":[{"columns":[{"key":"name","label":"Option or term"},{"key":"description","label":"Meaning"}],"key":"method-options","rows":[{"description":"The user or system who owns protected resources and can grant access to them. This documentation also uses the term end user when the resource owner is a person. When you use psql to connect to the database using OAuth, you are the resource owner/end user.","name":"Resource Owner (or End User)"},{"description":"The system which accesses the protected resources using access tokens. Applications using libpq, such as psql , are the OAuth clients when connecting to a PostgreSQL cluster.","name":"Client"},{"description":"The system hosting the protected resources which are accessed by the client. The PostgreSQL cluster being connected to is the resource server.","name":"Resource Server"},{"description":"The organization, product vendor, or other entity which develops and/or administers the OAuth authorization servers and clients for a given application. Different providers typically choose different implementation details for their OAuth systems; a client of one provider is not generally guaranteed to have access to the servers of another. This use of the term \"provider\" is not standard, but it seems to be in wide use colloquially. (It should not be confused with OpenID's similar term \"Identity Provider\". While the implementation of OAuth in PostgreSQL is intended to be interoperable and compatible with OpenID Connect/OIDC, it is not itself an OIDC client and does not require its use.)","name":"Provider"},{"description":"The system which receives requests from, and issues access tokens to, the client after the authenticated resource owner has given approval. PostgreSQL does not provide an authorization server; it is the responsibility of the OAuth provider.","name":"Authorization Server"},{"description":"An identifier for an authorization server, printed as an https:// URL, which provides a trusted \"namespace\" for OAuth clients and applications. The issuer identifier allows a single authorization server to talk to the clients of mutually untrusting entities, as long as they maintain separate issuers.","name":"Issuer"},{"description":"An HTTPS URL which is either the exact issuer identifier of the authorization server, as defined by its discovery document, or a well-known URI that points directly to that discovery document. This parameter is required. When an OAuth client connects to the server, a URL for the discovery document will be constructed using the issuer identifier. By default, this URL uses the conventions of OpenID Connect Discovery: the path /.well-known/openid-configuration will be appended to the end of the issuer identifier. Alternatively, if the issuer contains a /.well-known/ path segment, that URL will be provided to the client as-is. Warning The OAuth client in libpq requires the server's issuer setting to exactly match the issuer identifier which is provided in the discovery document, which must in turn match the client's oauth_issuer setting. No variations in case or formatting are permitted.","name":"issuer"},{"description":"A space-separated list of the OAuth scopes needed for the server to both authorize the client and authenticate the user. Appropriate values are determined by the authorization server and the OAuth validation module used (see Chapter 50 for more information on validators). This parameter is required.","name":"scope"},{"description":"The library to use for validating bearer tokens. If given, the name must exactly match one of the libraries listed in oauth_validator_libraries . This parameter is optional unless oauth_validator_libraries contains more than one library, in which case it is required.","name":"validator"},{"description":"Allows for mapping between OAuth identity provider and database user names. See Section 20.2 for details. If a map is not specified, the user name associated with the token (as determined by the OAuth validator) must exactly match the role name being requested. This parameter is optional.","name":"map"},{"description":"An advanced option which is not intended for common use. When set to 1 , standard user mapping with pg_ident.conf is skipped, and the OAuth validator takes full responsibility for mapping end user identities to database roles. If the validator authorizes the token, the server trusts that the user is allowed to connect under the requested role, and the connection is allowed to proceed regardless of the authentication status of the user. This parameter is incompatible with map . Warning delegate_ident_mapping provides additional flexibility in the design of the authentication system, but it also requires careful implementation of the OAuth validator, which must determine whether the provided token carries sufficient end-user privileges in addition to the standard checks required of all validators. Use with caution.","name":"delegate_ident_mapping"}],"title":"Documented method options and alternatives"}],"tables_zh":[{"columns":[{"key":"name","label":"选项或术语"},{"key":"description","label":"含义"}],"key":"method-options","rows":[{"description":"拥有受保护资源并能够授予访问权限的用户或系统。当资源所有者是人时，本文档也使用 终端用户 一词。当你使用 psql 通过 OAuth 连接数据库时，你就是资源所有者/终端用户。","name":"Resource Owner (or End User)"},{"description":"使用访问令牌访问受保护资源的系统。使用 libpq 的应用（例如 psql ）在连接 PostgreSQL 集簇时，就是 OAuth 客户端。","name":"Client"},{"description":"托管受保护资源并供客户端访问的系统。被连接的 PostgreSQL 集簇就是资源服务器。","name":"Resource Server"},{"description":"为特定应用开发或管理 OAuth 授权服务器与客户端的组织、产品厂商或其他实体。不同提供者通常采用不同的 OAuth 实现细节，因此一个提供者的客户端通常不能保证访问另一个提供者的服务器。这种“提供者”用法不是标准术语，但在实际交流中广泛使用。请勿将其与 OpenID 中类似的“身份提供者（Identity Provider）”混淆。PostgreSQL 的 OAuth 实现旨在与 OpenID Connect/OIDC 互操作并兼容，但它本身不是 OIDC 客户端，也不要求使用 OIDC。","name":"Provider"},{"description":"在资源所有者完成认证并给出批准之后，接收客户端请求并向其发放访问令牌的系统。 PostgreSQL 不提供授权服务器；这属于 OAuth 提供方的职责。","name":"Authorization Server"},{"description":"授权服务器的一个标识符，以 https:// URL 形式出现，为 OAuth 客户端和应用提供一个可信的“命名空间”。签发者标识符使得单个授权服务器能够同时与彼此互不信任的实体的客户端通信，只要这些实体维护各自独立的签发者即可。","name":"Issuer"},{"description":"一个 HTTPS URL，它要么是授权服务器发现文档所定义的精确 签发者标识符 ，要么是一个直接指向该发现文档的 well-known URI。此参数为必需项。 当 OAuth 客户端连接到服务器时，会基于签发者标识符构造发现文档的 URL。默认情况下，该 URL 采用 OpenID Connect Discovery 的约定：会在签发者标识符末尾追加路径 /.well-known/openid-configuration 。另一种情况是，如果 issuer 本身包含 /.well-known/ 路径段，那么该 URL 会原样提供给客户端。 警告 libpq 中的 OAuth 客户端要求服务器的 issuer 设置必须与发现文档中提供的签发者标识符完全一致，而该标识符又必须与客户端的 oauth_issuer 设置完全一致。不允许大小写或格式上的任何差异。","name":"issuer"},{"description":"一个以空格分隔的 OAuth 授权范围列表，服务器需要借此既能授权客户端，又能认证用户。合适的取值由授权服务器以及所使用的 OAuth 验证模块决定（关于验证器的更多信息，见 第 50 章 ）。此参数为必需项。","name":"scope"},{"description":"用于验证 Bearer 令牌的库。如果指定，其名称必须与 oauth_validator_libraries 中列出的某个库完全匹配。除非 oauth_validator_libraries 中包含多个库，否则该参数是可选的；如果包含多个库，则该参数为必需项。","name":"validator"},{"description":"允许在 OAuth 身份提供方用户名和数据库用户名之间建立映射。详见 第 20.2 节 。如果未指定映射，则与令牌关联的用户名（由 OAuth 验证器决定）必须与请求的角色名完全一致。此参数是可选的。","name":"map"},{"description":"这是一个高级选项，不适合常规使用。 当设置为 1 时，会跳过基于 pg_ident.conf 的标准用户映射，而由 OAuth 验证器完全负责把终端用户身份映射到数据库角色。如果验证器授权该令牌，服务器就会信任该用户被允许以请求的角色进行连接，并且无论该用户自身的认证状态如何，连接都将继续进行。 此参数与 map 不兼容。 警告 delegate_ident_mapping 为认证系统设计带来了额外灵活性，但也要求对 OAuth 验证器进行谨慎实现。验证器不仅必须执行所有验证器都需要进行的 标准检查 ，还必须判断所提供的令牌是否携带了足够的终端用户权限。请谨慎使用。","name":"delegate_ident_mapping"}],"title":"手册中的方法选项与替代方式"}],"zh_from":"same-version-manual"},"ManualEvidence":{"manual_path":"/docs/18/auth-oauth.html","release":{"catalog_fingerprint":"65c93d6048ef30e61023a84f9680fa6a92b1c383b7eb226741170077eb078502","channel":"stable","label":"18.6","major":"18","ref":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f"},"sources":[{"label":"Matching PostgreSQL source archive","sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"auth-oauth.html","sha256":"1e2e63530e79522cd93d2c34bc34a464927dbe46de9b01cdbf324648f1adda8d","url":"/docs/18/auth-oauth.html"},{"label":"PostgreSQL 18 English manual","path":"auth-pg-hba-conf.html","sha256":"6340d4abea2e0a3482afc31bcd1599a0fa10dc28a6f1e05d79ba831e2dd0b4c9","url":"/docs/18/auth-pg-hba-conf.html"}]},"MeasuredEvidence":{}},"Text":{"Collection":"auth","Key":"oauth","SourceDatabase":"center","Version":"18","Locale":"en","Title":"oauth","Summary":"Authorize and optionally authenticate using a third-party OAuth 2.0 identity provider. See Section 20.15 for details.","BodyHTML":"\u003cp\u003e\n    OAuth 2.0 is an industry-standard framework, defined in\n    \u003ca href=\"https://datatracker.ietf.org/doc/html/rfc6749\" rel=\"nofollow\"\u003eRFC 6749\u003c/a\u003e,\n    to enable third-party applications to obtain limited access to a protected\n    resource.\n\n    OAuth client support has to be enabled when \u003cspan\u003ePostgreSQL\u003c/span\u003e\n    is built, see \u003ca href=\"/docs/18/installation.html\" rel=\"nofollow\"\u003eChapter 17\u003c/a\u003e for more information.\n   \u003c/p\u003e\u003cp\u003e\n    This documentation uses the following terminology when discussing the OAuth\n    ecosystem:\n\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003cspan\u003ePostgreSQL\u003c/span\u003e supports bearer tokens, defined in\n    \u003ca href=\"https://datatracker.ietf.org/doc/html/rfc6750\" rel=\"nofollow\"\u003eRFC 6750\u003c/a\u003e,\n    which are a type of access token used with OAuth 2.0 where the token is an\n    opaque string.  The format of the access token is implementation specific\n    and is chosen by each authorization server.  The bearer token is sent\n    in clear-text, and is vulnerable to network sniffing.  For this reason\n    OAuth should only be used over SSL connections.\n   \u003c/p\u003e\u003cp\u003e\n    The following configuration options are supported for OAuth:\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cdd\u003e\u003cp\u003e\n          Authorize and optionally authenticate using a third-party OAuth 2.0\n          identity provider.  Since the bearer token is sent in clear text over\n          the network, this should not be used on untrusted networks.  See\n          \u003ca href=\"/docs/18/auth-oauth.html\" rel=\"nofollow\"\u003eSection 20.15\u003c/a\u003e for details.\n         \u003c/p\u003e\u003c/dd\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"3997abbffb2b05dfaad7b73b4ba15088392ef7e0aca198f180cfb471deee994e","Payload":{"description":["Authorize and optionally authenticate using a third-party OAuth 2.0 identity provider. See Section 20.15 for details."],"manual_html":"\u003cp\u003e\n    OAuth 2.0 is an industry-standard framework, defined in\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6749\" target=\"_top\"\u003eRFC 6749\u003c/a\u003e,\n    to enable third-party applications to obtain limited access to a protected\n    resource.\n\n    OAuth client support has to be enabled when \u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e\n    is built, see \u003ca class=\"xref\" href=\"/docs/18/installation.html\" title=\"Chapter 17. Installation from Source Code\"\u003eChapter 17\u003c/a\u003e for more information.\n   \u003c/p\u003e\u003cp\u003e\n    This documentation uses the following terminology when discussing the OAuth\n    ecosystem:\n\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\n\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e supports bearer tokens, defined in\n    \u003ca class=\"ulink\" href=\"https://datatracker.ietf.org/doc/html/rfc6750\" target=\"_top\"\u003eRFC 6750\u003c/a\u003e,\n    which are a type of access token used with OAuth 2.0 where the token is an\n    opaque string.  The format of the access token is implementation specific\n    and is chosen by each authorization server.  The bearer token is sent\n    in clear-text, and is vulnerable to network sniffing.  For this reason\n    OAuth should only be used over SSL connections.\n   \u003c/p\u003e\u003cp\u003e\n    The following configuration options are supported for OAuth:\n    \u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cdd\u003e\u003cp\u003e\n          Authorize and optionally authenticate using a third-party OAuth 2.0\n          identity provider.  Since the bearer token is sent in clear text over\n          the network, this should not be used on untrusted networks.  See\n          \u003ca class=\"xref\" href=\"/docs/18/auth-oauth.html\" title=\"20.15. OAuth Authorization/Authentication\"\u003eSection 20.15\u003c/a\u003e for details.\n         \u003c/p\u003e\u003c/dd\u003e","related":[],"sections":[],"tables":[{"columns":[{"key":"name","label":"Option or term"},{"key":"description","label":"Meaning"}],"key":"method-options","rows":[{"description":"The user or system who owns protected resources and can grant access to them. This documentation also uses the term end user when the resource owner is a person. When you use psql to connect to the database using OAuth, you are the resource owner/end user.","name":"Resource Owner (or End User)"},{"description":"The system which accesses the protected resources using access tokens. Applications using libpq, such as psql , are the OAuth clients when connecting to a PostgreSQL cluster.","name":"Client"},{"description":"The system hosting the protected resources which are accessed by the client. The PostgreSQL cluster being connected to is the resource server.","name":"Resource Server"},{"description":"The organization, product vendor, or other entity which develops and/or administers the OAuth authorization servers and clients for a given application. Different providers typically choose different implementation details for their OAuth systems; a client of one provider is not generally guaranteed to have access to the servers of another. This use of the term \"provider\" is not standard, but it seems to be in wide use colloquially. (It should not be confused with OpenID's similar term \"Identity Provider\". While the implementation of OAuth in PostgreSQL is intended to be interoperable and compatible with OpenID Connect/OIDC, it is not itself an OIDC client and does not require its use.)","name":"Provider"},{"description":"The system which receives requests from, and issues access tokens to, the client after the authenticated resource owner has given approval. PostgreSQL does not provide an authorization server; it is the responsibility of the OAuth provider.","name":"Authorization Server"},{"description":"An identifier for an authorization server, printed as an https:// URL, which provides a trusted \"namespace\" for OAuth clients and applications. The issuer identifier allows a single authorization server to talk to the clients of mutually untrusting entities, as long as they maintain separate issuers.","name":"Issuer"},{"description":"An HTTPS URL which is either the exact issuer identifier of the authorization server, as defined by its discovery document, or a well-known URI that points directly to that discovery document. This parameter is required. When an OAuth client connects to the server, a URL for the discovery document will be constructed using the issuer identifier. By default, this URL uses the conventions of OpenID Connect Discovery: the path /.well-known/openid-configuration will be appended to the end of the issuer identifier. Alternatively, if the issuer contains a /.well-known/ path segment, that URL will be provided to the client as-is. Warning The OAuth client in libpq requires the server's issuer setting to exactly match the issuer identifier which is provided in the discovery document, which must in turn match the client's oauth_issuer setting. No variations in case or formatting are permitted.","name":"issuer"},{"description":"A space-separated list of the OAuth scopes needed for the server to both authorize the client and authenticate the user. Appropriate values are determined by the authorization server and the OAuth validation module used (see Chapter 50 for more information on validators). This parameter is required.","name":"scope"},{"description":"The library to use for validating bearer tokens. If given, the name must exactly match one of the libraries listed in oauth_validator_libraries . This parameter is optional unless oauth_validator_libraries contains more than one library, in which case it is required.","name":"validator"},{"description":"Allows for mapping between OAuth identity provider and database user names. See Section 20.2 for details. If a map is not specified, the user name associated with the token (as determined by the OAuth validator) must exactly match the role name being requested. This parameter is optional.","name":"map"},{"description":"An advanced option which is not intended for common use. When set to 1 , standard user mapping with pg_ident.conf is skipped, and the OAuth validator takes full responsibility for mapping end user identities to database roles. If the validator authorizes the token, the server trusts that the user is allowed to connect under the requested role, and the connection is allowed to proceed regardless of the authentication status of the user. This parameter is incompatible with map . Warning delegate_ident_mapping provides additional flexibility in the design of the authentication system, but it also requires careful implementation of the OAuth validator, which must determine whether the provided token carries sufficient end-user privileges in addition to the standard checks required of all validators. Use with caution.","name":"delegate_ident_mapping"}],"title":"Documented method options and alternatives"}]}},"RequestedLocale":"en","Fallback":false,"Versions":["18","19","20"],"Locales":["en","zh-Hans"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}