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 :
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.
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.
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
.
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.