KeyConf26: Scalable API Keys without Keycloak Clients #53988

ahus1 · 2026-10-14T19:05:45Z

ahus1
Oct 14, 2026
Collaborator

This was discussed as part of

KeyConf26: Wicked Keycloak Challenges – Session Results #53984

The group wants API consumers to get by with an API key instead of a Keycloak client and the Client Credentials Grant.
Group representative: Hanna Short (CERN)

Context

A system exposes an API. Every non-human consumer needs a confidential client in Keycloak to obtain tokens via the OAuth 2.0 Client Credentials Grant.
Many of these consumers are people writing scripts against the API.

Problems

The Client Credentials Grant is more complex than an API key, especially for the consumer. In return it is arguably more secure, because the long-lived credential (the client secret) is only sent to the identity provider, never to the API.
Client authentication is moving away from shared secrets towards stronger methods such as signed JWTs. This makes the consumer's burden even heavier.
From the consumer's point of view, "API + API key" should be enough. Instead they face an identity provider, a client registration and a grant.
Keycloak offers no alternative to the Client Credentials Grant for this use case.

Open questions

Can Keycloak issue API keys for APIs directly, as GitLab and many other products do?
How can Keycloak take part while validation on the API side stays as simple as with OAuth 2.0, for example validating a JWT?
What are the advantages and disadvantages of API keys compared with the Client Credentials Grant?

Sources and related GitHub issues

#51838 Native Stateful API Key Management with Fine-Grained Permissions: detailed proposal with create, list, revoke, rotate and introspect endpoints and per-key permissions; closest match to approach A.
#43612 User "API Key" equivalent functionality: self-service, role-scoped keys in the user profile, modelled on GitHub tokens; originates from discussion #41308.
Discussion #45275 Static API keys with Keycloak Impersonation: exchanging a static key for an access token at a gateway, and why current token exchange makes this hard.
#27255 Create a personal access token (closed as not planned).
Personal Access Token (PAT) (Keycloak Forum; the old Discourse URL now points here).
How to use API keys with Keycloak (Keycloak Forum)
Why you should migrate to OAuth 2.0 from API keys (Reddit)

Solution approaches

A. API keys in Keycloak. The group suggests pursuing the idea under this name, because it reflects the consumer's perspective.

Self-service similar to GitLab: a page and an API in Keycloak that list existing API keys and allow creating and revoking them.
Each key is bound to a client, carries scoped permissions and has an expiry date.
Keys must be opaque, not JWTs, so the API has to use token introspection. Open: is there another way to enforce Introspection?
Open: is this essentially the Client Credentials Grant exposed in the Account Console or Admin Console, with the resulting token serving as the API key?
Two entry points:
- Personal (Account Console): what I as a user may do with an API.
- Machine or client context (Admin Console, Clients): keys managed by administrators.

B. Simplify the Client Credentials Grant without API keys.

Ship a CLI or SDK that hides the grant, so client credentials feel like username and password.
In professional environments, the infrastructure registers the client, performs the grant and attaches the access token to each API call. This keeps the authentication method towards the identity provider replaceable instead of locking it to a password. Open: how realistic is this for the consumers in question?

Next steps

Post the KeyConf consumer perspective on Feature Request: Native Stateful API Key Management with Fine-Grained Permissions #51838 and propose merging User "API Key" equivalent functionality #43612 into it
Compare approaches A and B, including token exchange at a gateway
Prototype API key self-service in the Account Console

Suggested improvements

List the security requirements for keys: stored only as hashes, a recognizable prefix for secret scanning, rotation, revocation and audit events. Feature Request: Native Stateful API Key Management with Fine-Grained Permissions #51838 already covers most of these and can serve as the baseline.
Consider token exchange (RFC 8693) as a bridge: a gateway exchanges the opaque API key for a short-lived JWT. The API keeps validating JWTs, and introspection happens once per exchange instead of once per call. Discussion Static API keys with Keycloak Impersonation #45275 describes current limitations of this route.
Prefer an authoritative source (for example OWASP or an IETF document) over the Reddit thread.

Navigation Menu

Repository navigation

KeyConf26: Scalable API Keys without Keycloak Clients #53988

Uh oh!

{{title}}

Uh oh!

Replies: 0 comments

Select a reply

Uh oh!

KeyConf26: Scalable API Keys without Keycloak Clients #53988

Uh oh!

ahus1 Oct 14, 2026 Collaborator

Context

Problems

Open questions

Sources and related GitHub issues

Solution approaches

Next steps

Suggested improvements

Replies: 0 comments

ahus1
Oct 14, 2026
Collaborator