OAuth 2.0 é uma estrutura padronizada do setor, definida no RFC 6749, para permitir que aplicações de terceiros obtenham acesso limitado a um recurso protegido. O suporte a cliente OAuth precisa ser ativado quando o PostgreSQL é construído Veja Instalação a partir do código-fonte para obter mais informações.
Esta documentação utiliza a seguinte terminologia ao abordar o ecossistema OAuth:
O usuário ou sistema que possui recursos protegidos e pode conceder acesso a eles. Esta documentação também utiliza o termo usuário final quando o dono do recurso é uma pessoa. Ao usar o psql para se conectar ao banco de dados usando OAuth, quem usa se torna o dono do recurso/usuário final.
O sistema que acessa os recursos protegidos usando fichas (tokens) de acesso. Aplicações que utilizam a libpq, como o psql, atuam como clientes OAuth ao se conectarem a uma instância do PostgreSQL.
O sistema que hospeda os recursos protegidos acessados pelo cliente. A instância do PostgreSQL à qual se está conectando é o servidor de recursos.
A organização, o fornecedor do produto ou outra entidade que desenvolve e/ou administra os servidores de autorização e os clientes OAuth para uma determinada aplicação. Diferentes provedores geralmente escolhem detalhes de implementação distintos para seus sistemas OAuth; geralmente não há garantia que o cliente de um provedor tenha acesso aos servidores de outro provedor.
Este uso do termo “provedor” não é padrão, mas parece ser amplamente utilizado na linguagem coloquial. (Não deve ser confundido com o termo semelhante do OpenID “Identity Provider” (Provedor de Identidade). Enquanto a implementação do OAuth no PostgreSQL pretenda ser interoperável e compatível com o OpenID Connect/OIDC, ela não é, por si só, um cliente OIDC e não requer o uso desse protocolo.)
O sistema que recebe solicitações do cliente e emite fichas (tokens) de acesso para ele, após o dono do recurso autenticado ter concedido a aprovação. O PostgreSQL não fornece um servidor de autorização; isto é responsabilidade do provedor de OAuth.
Um identificador para um servidor de autorização, expresso como
uma URL https://, que fornece um
“espaço de nomes” confiável para clientes e
aplicações OAuth.
O identificador do emissor permite que um único servidor de
autorização interaja com clientes de entidades que não confiam
mutuamente entre si, desde que elas mantenham emissores distintos.
Para implantações de pequeno porte, pode não haver uma distinção significativa entre o “provedor”, o “servidor de autorização” e o “emissor”. Entretanto, para configurações mais complexas, pode haver uma relação de um para muitos (ou de muitos para muitos): um provedor pode delegar múltiplos identificadores de emissor para diferentes clientes e, em seguida, disponibilizar múltiplos servidores de autorização — possivelmente com conjuntos de recursos com suporte distintos — para interagir com os clientes deles.
O PostgreSQL oferece suporte a fichas de portador (bearer tokens), definido no RFC 6750, que são um tipo de ficha de acesso utilizado com o OAuth 2.0, onde a ficha é uma cadeia de caracteres opaca. O formato da ficha de acesso é específico da implementação sendo escolhido por cada servidor de autorização.
As seguintes opções de configuração têm suporte para OAuth:
issuerUma URL HTTPS que seja exatamente o identificador do emissor do servidor de autorização, conforme definido pelo seu documento de descoberta, ou de um URI bem conhecido que aponte diretamente para este documento de descoberta. Este parâmetro é requerido.
Quando um cliente OAuth se conecta ao servidor, uma URL para o
documento de descoberta será construída usando o
identificador do emissor.
Por padrão, esta URL utiliza as convenções do
“OpenID Connect Discovery”: o caminho
/.well-known/openid-configuration
será anexado ao final do identificador do emissor.
Como alternativa, se o issuer contiver um
segmento de caminho /.well-known/,
esta URL será fornecida ao cliente no estado em que se encontra.
O cliente OAuth na libpq requer que a configuração do emissor do servidor corresponda exatamente ao identificador do emissor fornecido no documento de descoberta, que por sua vez deve corresponder à definição de oauth_issuer do cliente. Não são permitidas variações de maiúsculas/minúsculas ou de formatação.
scopeUma lista, separada por espaços, dos escopos de OAuth necessários para que o servidor autorize o cliente e autentique o usuário. Os valores apropriados são determinados pelo servidor de autorização e pelo módulo de validação OAuth utilizados (veja Módulos de validação OAuth para obter mais informações sobre validadores). Este parâmetro é requerido.
validator
Os valores apropriados são determinados pelo servidor de
autorização e pelo módulo de validação OAuth utilizados.
Se fornecido, o nome deve corresponder a uma das bibliotecas
listadas em oauth_validator_libraries.
Este parâmetro é opcional, a menos que
oauth_validator_libraries contenha mais de
uma biblioteca; neste caso, ele é requerido.
mapPermite o mapeamento entre o provedor de identidade OAuth e os nomes de usuário do banco de dados. Veja Mapas de nome de usuário para obter mais informações. Se não for especificado um mapeamento, o nome de usuário associado à ficha (conforme determinado pelo validador OAuth) deve corresponder exatamente ao nome da função solicitada. Este parâmetro é opcional.
delegate_ident_mapping
Uma opção avançada que não se destina ao uso comum.
Quando definido como 1, o mapeamento de
usuário padrão com pg_ident.conf é ignorado,
e o validador OAuth assume total responsabilidade pelo mapeamento
de identidades de usuários finais para funções de banco de dados.
Se o validador autorizar a ficha, o servidor irá confiar que o
usuário tem permissão para se conectar com a função de banco
de dados solicitada, e a conexão tem permissão para prosseguir,
independentemente do status de autenticação do usuário.
Este parâmetro é incompatível com map.
delegate_ident_mapping fornece maior
flexibilidade no projeto do sistema de autenticação, mas
também exige uma implementação cuidadosa do validador OAuth,
que deve determinar se a ficha fornecida contém privilégios
suficientes para o usuário final, além das
verificações padrão
exigidas de todos os validadores.
Deve ser usado com cautela.