L'utilisateur ou le système qui possède des ressources protégées et peut accorder un accès à celles-ci. Cette documentation utilise également le terme utilisateur final lorsque le propriétaire de la ressource est une personne. Lorsque vous utilisez psql pour vous connecter à la base de données via OAuth, vous êtes le propriétaire de la ressource / utilisateur final.

Le système qui accès aux ressources protégées en utilisant des jetons d'accès. Les applications utilisant libpq, comme psql, sont les clients OAuth lorsqu'elles se connectent à une instance PostgreSQL.

Le système hébergeant les ressources protégées auxquelles le client accède. L'instance PostgreSQL auquel on se connecte est le serveur de ressources.

L'organisation, l'éditeur de produit ou toute autre entité qui développe et/ou administre les serveurs d'autorisation OAuth et les clients pour une application donnée. Les différents fournisseurs choisissent généralement des détails d'implémentation différents pour leurs systèmes OAuth ; un client d'un fournisseur n'a généralement pas accès aux serveurs d'un autre.

Cette utilisation du terme « fournisseur ; n'est pas standard, mais elle semble largement répandue de manière informelle. (À ne pas confondre avec le terme similaire d'OpenID « fournisseur d'identité ». Bien que l'implémentation OAuth dans PostgreSQL soit conçue pour être interopérable et compatible avec OpenID Connect / OIDC, elle n'est pas elle-même un client OIDC et ne requiert pas son utilisation)

Le système qui reçoit les requêtes du client et émet des jetons d'accès après que le propriétaire de la ressource s'est authentifié et a donné son accord. PostgreSQL ne fournit pas de serveur d'autorisation ; cela relève de la responsabilité du fournisseur OAuth.

Un identifiant pour un serveur d'autorisation, présenté sous forme d'URL https://, qui fournit un « espace de noms » de confiance pour les clients et les applications OAuth. L'identifiant d'émetteur permet à un serveur d'autorisation unique de communiquer avec les clients d'entités mutuellement indépendantes, à condition qu'elles maintiennent des identifiants distincts.

Une URL HTTPS correspondant soit exactement à l'identifiant d'émetteur du serveur d'autorisation, tel que défini dans son document de découverte, soit à un URI bien connu pointant directement vers ce document de découverte. Ce paramètre est requis.

Lorsqu'un client OAuth se connecte au serveur, une URL pour le document de découverte est construite à partir de l'identifiant d'émetteur. Par défaut, cette URL suit les conventions d'OpenID Connect Discovery : le chemin /.well-known/openid-configuration est ajouté à la fin de l'identifiant d'émetteur. Alternativement, si l'attribut issuer contient un segment de chemin /.well-known/, cette URL est utilisée telle quelle.

Une liste d'étendues OAuth, séparées par des espaces, nécessaires au serveur pour autoriser le client et authentifier l'utilisateur. Les valeurs appropriées sont déterminées par le serveur d'autorisation et le module de validation OAuth utilisé (voir Chapitre 50 pour plus d'informations sur les validateurs). Ce paramètre est requis.

La bibliothèque à utiliser pour valider les jetons de porteur. Si elle est fournie, son nom doit correspondre exactement à l'une des bibliothèques listées dans oauth_validator_libraries. Ce paramètre est optionnel, sauf si oauth_validator_libraries contient plus d'une bibliothèque, auquel cas il est requis.

Permet de faire la correspondance entre l'identité OAuth et les utilisateurs de la base de données. Voir Section 20.2 pour plus de détails. Si aucune correspondance n'est spécifiée, le nom d'utilisateur associé au jeton (tel que déterminé par le validateur OAuth) doit correspondre exactement au nom du rôle demandé. Ce paramètre est optionnel.

Une option avancée qui n'est pas destinée à un usage courant.

Lorsqu'elle est définie à 1, la correspondance utilisateur standard via pg_ident.conf est ignorée, et le validateur OAuth prend l'entière responsabilité de la correspondance entre les identités et les rôles. Si le validateur autorise le jeton, le serveur fait confiance à l'autorisation de connexion sous le rôle demandé, et la connexion est acceptée, quelle que soit l'authentification de l'utilisateur.

Ce paramètre est incompatible avec map.