Identity and access
Who your system believes a person is, and what they’re allowed to reach. We move you between providers, extend Keycloak, and build the access model underneath.
Identity and access is two questions, in that order: who is this person, and what are they allowed to do? Most companies buy the first answer and build the second. What you buy holds the accounts, the passwords, the logins that come from Google or from a customer’s own directory, and the tokens that tell your other services who’s on the other end of a request. Keycloak and Auth0 are the two we’re asked about most. Keycloak you run yourself; Auth0 you rent.
What you build is the access model: the rules about who may see and change what. It usually starts as a handful of roles written when the company was smaller, and it stops fitting when the business gets more complicated. The provider stops fitting too, usually for commercial reasons rather than technical ones. Neither can be changed quickly, because you can’t ask a live user base to wait. That’s the work we do: the move, the extension, and the access model underneath.
- Keycloak
- Auth0
- OIDC
- SAML
- Kubernetes
- Terraform
- Pulumi
- Datadog
What we do.
You’re moving off Keycloak, or onto it.
We’ve done both directions, and both go wrong in the same place: the parts of your old setup nobody wrote down. So before anything moves, we map what your current provider does today. Which token claims other services read, the custom flows, the scripts that run at login.
You need Keycloak to do something it doesn’t do out of the box.
Most serious Keycloak setups end up extended: custom authenticators, required actions, token mappers, a storage provider that reads the system that already holds your users. We’ve written all of these, and we know which ones survive an upgrade. That matters, because an extension that reaches into Keycloak’s internals pins you to the version you’re on.
A big customer wants to sign in with their own accounts.
Enterprise contracts come with an identity requirement attached: SAML or OIDC, their directory, their rules. We set up the federation, the claim mapping and the account linking, and we set it up so that by the tenth customer it’s a configuration change.
Your roles don’t describe who should see what anymore.
Adding more roles won’t fix it. We work out with you whether access should depend on the user, on the resource, or on the relationship between them, and we write that down somewhere your application can read it. We do it with the people who’ll maintain it afterwards.
We moved an optical retailer’s users from Keycloak to Auth0.
We worked alongside the client’s own engineers. Keycloak crossed nine major versions on the way, v15 to v24.
- Client
- Optical retail and omnichannel commerce, Germany
- Scope
- Keycloak to Auth0, 3M+ users, 30+ microservices
- Platform
- Keycloak on Kubernetes, v15 to v24
- Events
- Auth0 to AWS EventBridge, via Lambda
- Tooling
- Datadog, Pulumi, Terraform
Tell us what you’re building.
Send a note or book a call, whichever you prefer. You’ll hear from us within two business days. Our clients are in the DACH region and across the EU, and we work with all of them remotely.