Hi there,
We need full administrative access to the keycloak admin REST API on the simplest possible terms. We’re currently using client credentials flow, but the Access Token gets uncomfortably large. What other option do we have?
I have seen various approaches to provide API key functionality to clients, but they use tokens under the hood.
Can we get a service account authenticated using Basic auth headers? What SPIs would we need to implement, what would we need to configure?
Yes you can.
Create a new client, activate ‘Service Account’. This activates a new tab “Service Account Roles” where you need to define access on the client ‘realm-management’. Choose what you need there (like (manage-users, manage-realms, etc.).
Note that you need the same rights on the “Scope” tab for this client, if Full Scope is not enabled.
You can now connect with the client_id/client_secrets of this client (a service account client). It will give you a short time access token, no refresh token, when time is out request a new one. No need for refresh token system here as you do not act for a user (no user creds), just request access tokens each time you need it.
This is the right way to generate REST API accounts, and you can even reduce the scope (by not taking all access roles on this service account roles tab).
Hey regilero,
Yeah thanks, that’s what we are already using. I was looking for an option that does away with access tokens altogether, so I could maybe for every access use client_id and client_secret (or similar). As I mentioned, the tokens get uncomfortably large.
Why are they becoming large? You should try to keep it small, a JWT should not become too large (else you may end up with security equipments removing your HTTP headers, or the whole requests).
Choose which attributes should or should not be added to the access tokens, maybe use a special ‘client scope’ for that, like a client scope ‘service’ with limited attributes added to the acces_token. Then request specifically this scope on connection, or enforce it for that client (and remove the others).
else you may end up with security equipments removing your HTTP headers, or the whole requests
I know, that’s why I say it’s becoming too large. 
To be precise, we want to support thousands of realms. And a single client in the master realm must be able to manage all of them. Since every realm is a separate client we will have somewhere between 10 and 15 roles times the number of realms in the roles > client_acces claim of the access token. Even if we’d reduce it to a single role per realm, the size will still scale linearly with the number of realms.
We are looking for a way around that.
And removing that claim from the access_token? Do you need this information on the access_token, on this specific usage? If not just remove it. That’s why I was talking of making an alternate client scope.
Yes that claim is required, otherwise we can’t manage other realms.
We thought about using one client per realm, but that would require us managing a large number of tokens on the REST client side. That’s our last option.
AFAIK the admin REST API is implemented with token-based authentication only.
Thats also my understanding.
Is there maybe an option to implement an SPI which would check BASIC auth headers first and then defer to token?
@lordvlad I ran into the same issue recently when attempting to automate realm creation using a client with a service account. For my case I found the only solution was to use the built-in admin-cli client with a username/password instead of creating a client and using that. The admin rest api has special handling for the admin-cli (and security-admin-console) clients so roles aren’t included in the jwt: [KEYCLOAK-1268] Token for admin becomes to large with many realms - Red Hat Issue Tracker. It sounds like this is the wrong solution for your situation since you are presumably trying to create clients for external use and wouldn’t be comfortable creating admin accounts instead for those clients. So, sorry this wasn’t the actual answer to your question but I hope it at least points in some helpful directions.
FWIW it seems like the keycloak maintainers are aware of the issue although I don’t know that I’ve seen any indication of when it would be fixed 
maybe it will magically be fixed by map storage in KC 21 
I would look into token exchange here:
Use an account in the master realm to login to e.g. your special-master client and then exchange the token for <realm>-admin tokens as needed. Or just use one of the superadmin clients directly.
@bpedersen2 Yeah token-exchange was one option we quickyl found, but that would also require laborious management of clients (one client per realm)
For my case I found the only solution was to use the built-in admin-cli client with a username/password instead of creating a client and using that
Cool, I did not know that admin-cli has special handling. That is handy! Will try using that