Platform · Applications
Every application registered cleanly, and as code
We design and manage the Keycloak clients behind your web apps, mobile apps, APIs and SaaS integrations — the right client type, tight redirect URIs, least-privilege scopes, and changes that go through review instead of the admin console.
- OIDC & SAML clients
- Service accounts for machine-to-machine
- Clients as code with Terraform / OpenTofu
Standards & integrations
- OpenID Connect
- SAML 2.0
- OAuth 2.0 Client Credentials
- PKCE
- Pushed Authorization Requests
- FAPI 2.0
- Terraform / OpenTofu
Overview
Why client configuration deserves more attention than it gets
In Keycloak, every application is a client, and many identity incidents trace back to one: a wildcard redirect URI, a secret shared between environments, a public client that should have been confidential, or a token carrying roles nobody needed. We treat clients as part of your security boundary — designed deliberately, reviewed like code, and consistent from development to production.
What we deliver
- Client inventory and risk review of existing configuration
- Client templates for each application pattern
- Clients, scopes and mappers as Terraform / OpenTofu modules
- Client policies and profiles for high-assurance apps
- Per-environment realm configuration with separate secrets
- Onboarding guide and pull-request checklist for new apps
Capabilities
What Applications covers
Configured, tested and documented on upstream Keycloak — then handed over or operated by us.
The right client type
Public clients with PKCE for SPAs and mobile apps, confidential clients with client authentication for back ends, and APIs that simply validate the access tokens issued to other clients.
Machine-to-machine access
Service accounts and the client credentials grant for back-end jobs and integrations, authenticated with a client secret, a signed JWT or mutual TLS depending on the risk.
Redirect and origin hygiene
Exact redirect URIs, post-logout redirect URIs and web origins per environment — no wildcards in production and no localhost entries left in a live realm.
Scopes with intent
Client scopes, split into default and optional, decide what lands in each token, so an app receives the claims and audience it needs and nothing it could misuse.
Client policies and profiles
Keycloak client policies enforce rules automatically — PKCE required, confidential clients only, FAPI 2.0 or OAuth 2.1 profiles for high-assurance APIs — instead of relying on every admin to remember.
Onboarding as code
New clients arrive through a pull request against Terraform or OpenTofu, not a click-path. Where partners need self-service, dynamic client registration sits behind registration policies and initial access tokens.
How it works
From first call to production
Audit the clients you already have
We review every existing client for type, grants, redirect URIs, secrets, scopes and mappers, and flag what's over-permissioned, unused or duplicated across environments.
Define the standard and codify it
We agree a client template for each app pattern — SPA, mobile, back end, API, SAML SaaS — then express them in Terraform or OpenTofu, with client policies enforcing the rules.
Onboard and hand over
Existing clients are imported into code without changing their IDs or secrets, new apps follow a documented path, and your team owns the pipeline from then on.
Use cases
Where teams put it to work
API platforms and microservices
Service-to-service calls authenticated with client credentials, using audience-restricted tokens so one service's token can't be replayed against another.
Open banking and high-assurance APIs
FAPI-aligned client profiles with pushed authorization requests, signed request objects and sender-constrained tokens, enforced by client policies rather than convention.
Growing application portfolios
Teams that regularly add new internal tools get a repeatable, reviewed onboarding path instead of a backlog of hand-built clients.
FAQ
Applications questions, answered
Should our single-page app use a public or confidential client?
A browser app can't keep a secret, so it should be a public client using the authorization code flow with PKCE. If you want tokens kept out of the browser entirely, we pair it with a backend-for-frontend that acts as a confidential client.
How do we give a back-end service access without a user?
Enable a service account on a confidential client and use the client credentials grant. Roles are assigned to that service account directly, so its access is explicit, auditable and revocable on its own.
Can we bring existing clients under Terraform without recreating them?
Yes. Existing clients can be imported into Terraform or OpenTofu state with their client IDs and secrets intact, and are managed as code from that point on.
Do you use dynamic client registration?
Keycloak supports OpenID Connect dynamic client registration. We enable it only where there's a real need, such as partner self-service, and restrict it with client registration policies and initial access tokens.
Ready to roll out Applications?
Walk us through your requirements on a free strategy call. We'll come back with an architecture, a delivery plan and a fixed scope.