PostgreSQLLa base de données la plus sophistiquée au monde.
Documentation PostgreSQL 18 beta 2 » Administration du serveur » Authentification du client » Autorisation et authentification OAuth

20.15. Autorisation et authentification OAuth #

OAuth 2.0 est un cadre standardisé de l'industrie, défini dans la RFC 6749, qui permet à des applications tierces d'obtenir un accès limité à une ressource protégée. Le support du client Oauth doit être activé lors de la compilation de PostgreSQL ; voir Chapitre 17 pour plus d'informations.

Cette documentation utilise la terminologie suivante pour décrire l'écosystème OAuth :

Propriétaire de la ressource (ou utilisateur final)

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.

Client

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.

Serveur de ressources

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.

Fournisseur

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)

Serveur d'autorisation

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.

Émetteur

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.

Note

Pour les petits déploiements, il peut ne pas y avoir de distinction significative entre le « fournisseur », le « serveur d'autorisation » et l'« émetteur ». Toutefois, dans des configurations plus complexes, il peut exister une relation de type un-à-plusieurs (ou plusieurs-à-plusieurs) : un fournisseur peut déléguer plusieurs identifiants d'émetteur à différents locataires, puis fournir plusieurs serveurs d'autorisation - éventuellement avec des ensembles de fonctionnalités différents — pour interagir avec leurs clients.

PostgreSQL prend en charge les jetons de porteur, définis dans RFC 6750, qui sont un type de jeton d'accès utilisé avec OAuth 2.0, dans lequel le jeton est une chaîne opaque. Le format du jeton d'accès dépend de l'implémentation et est choisi par chaque serveur d'autorisation.

Les options de configuration suivantes sont prises en charge pour OAuth :

issuer

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.

Avertissement

Le client OAuth dans libpq exige que la valeur issuer configurée sur le serveur corresponde exactement à l'identifiant d'émetteur fourni dans le document de découverte, lequel doit à son tour correspondre à la configuration oauth_issuer du client. Aucune variation de casse ou de format n'est autorisée.

scope

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.

validator

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.

map

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.

delegate_ident_mapping

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.

Avertissement

delegate_ident_mapping offre une flexibilité supplémentaire dans la conception du système d'authentification, mais nécessite une implémentation rigoureuse du validateur Oauth, qui doit s'assurer que le jeton fourni confère bien les privilèges nécessaires à l'utilisateur, en plus des vérifications standard exigées pour tous les validateurs. À utiliser avec précaution.