Percona brings open source OIDC authentication to MySQL

Percona announced, in an article written by Michał Jankowski on the company's official blog, that Percona Server for MySQL will now include a fully open source OpenID Connect (OIDC) authentication plugin. The feature arrives in versions 8.4.11-11 and 9.7.2-2 (not yet released as of the source's publication date) and allows a MySQL account to authenticate against any Identity Provider (IdP) that supports the standard, instead of relying on a locally stored password.

The point that matters to anyone running databases in Brazil is straightforward: until now, this category of functionality only existed officially in Oracle's MySQL Enterprise Edition, which has offered OIDC since MySQL 9.1. Percona's implementation not only closes that gap without licensing costs but, in some respects, goes beyond Oracle's plugin.

What OIDC changes in database authentication

OpenID Connect is an identity layer built on top of OAuth 2.0. While OAuth deals with delegated access to resources, OIDC standardizes who the user is. After the person logs into the IdP, it issues a signed JSON Web Token (JWT), the ID token, carrying identity and attributes in a verifiable, tamper-proof way.

Applying this model to MySQL brings concrete advantages over password-based accounts:

• Alignment with corporate SSO. User lifecycle and password management are centralized in the IdP. Anyone already running Keycloak, Okta, Microsoft Entra ID, or Google Identity can now use the same identity plane for the database as well.
• No long-lived secrets on the wire. ID tokens are short-lived and cryptographically signed. There's no static password to steal, rotate, or accidentally leak in a configuration file committed to a repository.
• Hybrid deployments. A company running MySQL on-premises with applications in the cloud can authenticate on both sides using the same IdP, a common scenario in Brazilian infrastructure that migrated part of the stack to the cloud but kept the database on-premises.

This pitch, it's worth noting, isn't exclusive to Percona: Oracle sells the same proposition for its Enterprise plugin. The real difference lies in how much operational work the plugin takes off the DBA's shoulders.

How the flow works under the hood

Once configured, the authentication path doesn't depend on which IdP issued the token:

1. The user authenticates with the IdP and receives a signed ID token.
2. The token is written to a local file readable only by the client's operating system account.
3. The MySQL client, via a specific option, loads the token from the file and sends it during the authentication handshake.
4. The server validates the secure channel, decodes the token, verifies the signature with the IdP's public key, checks expiration, and validates the configured claims.
5. The server resolves the final identity as either a personal account or a group-based proxy target, and can also return roles mapped from the user's group.

The transport is always protected: only TCP over TLS, Unix sockets, and shared memory are accepted. Supported signing algorithms include RSASSA-PKCS1-v1_5, RSASSA-PSS, and ECDSA with SHA-256, SHA-384, and SHA-512.

The differentiator: self-synchronizing JWKS keys

IdPs periodically rotate their signing keys for security reasons. These public keys are exposed at the standard JWKS (JSON Web Key Set) endpoint. This is where Percona's first operational advantage lies: the plugin downloads the keys from the configured JWKS endpoint at load time and caches them, while also offering a UDF that refreshes this cache on demand or periodically via the Event Scheduler.

Oracle's plugin, by contrast, requires keys to be statically configured in the authentication_openid_connect_configuration variable, either as inline JSON or a file path. There's no automatic JWKS lookup. In other words: with every key rotation, the administrator has to manually update the configuration, and in the window right after rotation, tokens signed with the previous key remain valid but can't be verified until the update happens.

The configuration on Percona's side is lean. The IdP is defined with the JWKS endpoint:

{
  "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" ]
  }
}

And the key refresh is scheduled with the Event Scheduler turned on:

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

The static mode also exists in Percona's plugin, but the company itself recommends reserving it for testing or temporary setups, not for production.

IdP groups turning into roles and proxy users

It's in group handling that Percona's implementation diverges most from the Enterprise edition. Groups are managed by the corporate IdP, and membership can be carried in the ID token. OIDC doesn't define a standard claim for this, but most IdPs allow adding a group claim; the plugin lets you configure the name of that claim.

There are two ways to leverage this. The first is group-to-role mapping. The DBA creates roles, grants privileges, and defines in the configuration file the mapping between the IdP group and the MySQL role:

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" }
]

Any user who connects with a token containing "groups":["/accounting"] automatically receives the accounting role. This automates privilege management, although it still requires an account created for each user.

The second way is the proxy user: a single set of MySQL accounts is shared by many IdP users, eliminating the need for individual personal accounts. The proxied user selection is done via the group claim. A proxy user identified by the OIDC plugin is created (anonymous, ''@'', or by named group), along with proxied accounts whose name matches the group's, with no login plugin, and the PROXY privilege is granted.

Where OIDC doesn't solve the problem

The article is honest about the limits, and the DBA needs to know them before scaling this to production:

Any authentication plugin acts only at the moment of connection. In the case of OIDC, the token is validated when the user connects, and a session that remains open can outlive the ID token that opened it.

>

-- Michał Jankowski, Percona

In practice, this means three pitfalls. First: there's no ready-made mechanism to force reauthentication after a certain time (aside from idle connection timeout). Second: group-to-role mapping is resolved at connection time, so adding or removing a user from a group in the IdP only takes effect after they reconnect. Third: in proxy mode, the trust boundary becomes group membership rather than the token's subject, any token signed by a configured IdP that carries the group is accepted.

There's also a design limitation: the current implementation assumes the proxied user's name matches the group's name, which breaks down when the group name isn't a valid MySQL username (too long or with forbidden characters). Percona says it plans to add explicit group-to-account mapping in future versions. And the client plugin doesn't verify the token before connecting, nor does the server report the reason for denied access (for security reasons), the recommendation is to obtain a fresh token before connecting.

The verdict for operators

Functionally, Percona's plugin covers the same core as the Enterprise edition: signed tokens, claim validation, subject matching, and secure transport. It goes further on four points: it's open source, it keeps keys updated via JWKS, it lets IdP groups drive role grants, and it offers proxy users.

For Brazilian teams that have already standardized identity on Keycloak or Entra ID and want to stop managing database passwords in a silo, the logical path is to start with group-to-role mapping in a controlled environment, measure reconnection behavior, and only then evaluate proxy users, treating group membership with the rigor that the trust boundary demands. The foundation remains the same as always: well-designed roles and minimal privileges. OIDC automates distribution, it doesn't replace correct design.