Percona traz autenticação OIDC open source para o MySQL

A Percona anunciou, em artigo assinado por Michał Jankowski no blog oficial da empresa, que o Percona Server for MySQL↳MySQL8 conteúdosMySQL + Adminer + Docker Compose: montando rapidamente um ambiente para usoData · abr 2019Banco de dados MYSQL no PHPStormDev (Back & Front) · jul 2019Criando um ambiente de desenvolvimento PHP mínimo com Docker – Parte 3Dev (Back & Front) · out 2019Ver tudo em Data → passa a incluir um plugin de autenticação OpenID Connect (OIDC) totalmente open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →. O recurso chega nas versões 8.4.11-11 e 9.7.2-2 (ainda não lançadas na data da publicação da fonte) e permite que uma conta MySQL autentique contra qualquer Identity Provider (IdP) compatível com o padrão, em vez de depender de uma senha armazenada localmente.

O ponto que interessa a quem opera banco no Brasil é direto: até agora, essa categoria de funcionalidade só existia oficialmente na MySQL Enterprise Edition, da Oracle, que oferece OIDC desde o MySQL 9.1. A implementação da Percona não apenas fecha esse gap sem custo de licença como, em alguns aspectos, vai além do plugin da Oracle.

O que OIDC muda na autenticação do banco

OpenID Connect é uma camada de identidade construída sobre o OAuth 2.0. Enquanto o OAuth trata de acesso delegado a recursos, o OIDC padroniza quem é o usuário. Depois que a pessoa faz login no IdP, este emite um JSON Web Token (JWT) assinado, o ID token, carregando identidade e atributos de forma verificável e à prova de adulteração.

Aplicar esse modelo ao MySQL traz vantagens concretas sobre contas baseadas em senha:

• Alinhamento com SSO corporativo. O ciclo de vida do usuário e a gestão de senha ficam centralizados no IdP. Quem já roda Keycloak, Okta, Microsoft Entra ID ou Google Identity passa a usar o mesmo plano de identidade também no banco.
• Sem segredos de longa duração no fio. ID tokens são de vida curta e assinados criptograficamente. Não há senha estática para roubar, rotacionar ou vazar acidentalmente num arquivo de configuração commitado no repositório.
• Deployments híbridos. Empresa que roda MySQL on-premises com aplicações na nuvem autentica pelos dois lados usando o mesmo IdP, cenário comum na infraestrutura brasileira que migrou parte da stack para cloud mas manteve o banco em casa.

Esse discurso, vale dizer, não é exclusivo da Percona: a Oracle vende a mesma proposta para o plugin Enterprise. A diferença real está em quanto trabalho operacional o plugin tira das costas do DBA.

Como o fluxo funciona por baixo

Uma vez configurado, o caminho de autenticação independe de qual IdP emitiu o token:

1. O usuário autentica no IdP e recebe um ID token assinado.
2. O token é gravado num arquivo local legível apenas pela conta de sistema operacional do cliente.
3. O cliente MySQL, via opção específica, carrega o token do arquivo e o envia no handshake de autenticação.
4. O servidor valida o canal seguro, decodifica o token, verifica a assinatura com a chave pública do IdP, checa a expiração e valida os claims configurados.
5. O servidor resolve a identidade final como conta pessoal ou como alvo de proxy baseado em grupo, podendo ainda retornar roles mapeadas a partir do grupo do usuário.

O transporte é sempre protegido: só são aceitos TCP sobre TLS, sockets Unix e memória compartilhada. Os algoritmos de assinatura suportados incluem RSASSA-PKCS1-v1_5, RSASSA-PSS e ECDSA com SHA-256, SHA-384 e SHA-512.

O diferencial: chaves JWKS sincronizadas sozinhas

IdPs rotacionam suas chaves de assinatura periodicamente por segurança. Essas chaves públicas ficam expostas no endpoint padrão JWKS (JSON Web Key Set). Aqui mora a primeira vantagem operacional da Percona: o plugin baixa as chaves do endpoint JWKS configurado no carregamento e as mantém em cache, além de oferecer uma UDF que atualiza esse cache sob demanda ou periodicamente via Event Scheduler.

O plugin da Oracle, por contraste, exige chaves configuradas estaticamente na variável authentication_openid_connect_configuration, como JSON inline ou caminho de arquivo. Não há busca automática no JWKS. Ou seja: a cada rotação de chave, o administrador precisa atualizar manualmente a configuração, e na janela logo após a rotação, tokens assinados com a chave anterior continuam válidos mas não podem ser verificados até a atualização.

A configuração do lado Percona é enxuta. Define-se o IdP com o endpoint JWKS:

{
  "example-keycloak": {
    "issuer-name": "https://keycloak.example.com/realms/master",
    "jwks-url": "https://keycloak.example.com/realms/master/protocol/openid-connect/certs",
    "audiences": [ "mysql-oidc" ]
  }
}

E agenda-se a atualização das chaves com o Event Scheduler ligado:

CREATE EVENT update_oidc_keys
  ON SCHEDULE EVERY 1 HOUR
  DO SELECT update_jwks("example-keycloak");

O modo estático também existe no plugin da Percona, mas a própria empresa recomenda reservá-lo para testes ou setups temporários, não para produção.

Grupos do IdP virando roles e proxy users

É no tratamento de grupos que a implementação da Percona mais se distancia da Enterprise. Grupos são geridos pelo IdP corporativo e a filiação pode ser carregada no ID token. O OIDC não define um claim padrão para isso, mas a maioria dos IdPs permite adicionar um claim de grupo; o plugin deixa configurar o nome desse claim.

Há duas formas de explorar isso. A primeira é mapeamento de grupo para role. O DBA cria roles, concede privilégios e define no arquivo de configuração o mapeamento entre grupo do IdP e role do MySQL:

CREATE ROLE accounting;
GRANT ALL PRIVILEGES ON accounting_database.* TO accounting;
CREATE ROLE sales;
GRANT ALL PRIVILEGES ON sales_database.* TO sales;

"group-claim": "groups",
"group-role": [
  { "/accounting": "accounting" },
  { "/marketing": "marketing" }
]

Qualquer usuário que conecte com um token contendo "groups":["/accounting"] recebe automaticamente a role accounting. Isso automatiza a gestão de privilégios, embora ainda exija uma conta criada para cada usuário.

A segunda forma é o proxy user: um mesmo conjunto de contas MySQL é compartilhado por muitos usuários do IdP, dispensando conta pessoal individual. A seleção do usuário proxied é feita pelo claim de grupo. Cria-se um usuário proxy identificado pelo plugin OIDC (anônimo, ''@'', ou por grupo nomeado), contas proxied cujo nome bate com o do grupo e sem login plugin, e concede-se o privilégio PROXY.

Onde OIDC não resolve o problema

O artigo é honesto quanto aos limites, e o DBA precisa conhecê-los antes de escalar isso para produção:

Qualquer plugin de autenticação atua somente no momento da conexão. No caso do OIDC, o token é validado quando o usuário conecta, e uma sessão que permanece aberta pode sobreviver ao ID token que a abriu.

Michał Jankowski, Percona

Na prática, isso significa três armadilhas. Primeira: não há mecanismo pronto para forçar reautenticação após certo tempo (fora o timeout de conexão ociosa). Segunda: o mapeamento grupo-role é resolvido na conexão, então adicionar ou remover um usuário de um grupo no IdP só reflete depois que ele reconecta. Terceira: no modo de proxy, a fronteira de confiança passa a ser a filiação ao grupo, não o subject do token, qualquer token assinado por um IdP configurado que carregue o grupo é aceito.

Há ainda uma limitação de desenho: a implementação atual assume que o nome do usuário proxied bate com o nome do grupo, o que quebra quando o nome do grupo não é um username válido no MySQL (muito longo ou com caracteres proibidos). A Percona diz que pretende adicionar mapeamento explícito grupo-conta em versões futuras. E o plugin cliente não verifica o token antes de conectar, nem o servidor informa o motivo de acesso negado (por segurança), a recomendação é obter um token fresco antes de conectar.

O veredito para quem opera

Funcionalmente, o plugin da Percona cobre o mesmo núcleo da Enterprise: tokens assinados, validação de claims, correspondência de subject e transporte seguro. Vai além em quatro pontos: é open source, mantém as chaves atualizadas via JWKS, permite que grupos do IdP dirijam concessões de role e oferece proxy users.

Para a equipe brasileira que já padronizou identidade em Keycloak ou Entra ID e quer parar de gerenciar senhas de banco em silo, o caminho lógico é começar com mapeamento grupo-role em ambiente controlado, medir o comportamento na reconexão e só então avaliar proxy users, tratando a filiação a grupo com o rigor que a fronteira de confiança exige. A base continua sendo a mesma de sempre: roles bem desenhadas e privilégios mínimos. O OIDC automatiza a distribuição, não substitui o desenho correto.

Fonte: Percona Database Blog