Identity for people and agents
Your product must know who is asking and what they’re allowed to do, whether that’s a customer, a service or an agent. We build that layer with you and run it on a live product.
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 and the passwords. It handles logins through Google or through a customer’s own directory. And it issues the tokens that tell your other services who is 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. 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 login and single sign-on, the access model underneath, and the change when either stops fitting.
The same two questions now apply to agents, and to any program that acts on your data: an MCP server, a service calling your API. We give each one its own identity at your provider, or let it act for a user with rights narrowed to that task. The token it carries names the tools or APIs it may call, and nothing more. We log every call against that identity, so afterwards you can show what the agent did and what it was allowed to do. Without this, an agent ends up holding more rights than the person who asked it.
- Keycloak
- Auth0
- OIDC
- OAuth
- SAML
- JWT
- Kubernetes
- Docker
- AWS
- Terraform
- Pulumi
- Datadog
What we do.
You’re building a product and want the login done properly from the start.
We set up the identity provider, run by you or rented, and the ways people sign in: password, Google, or a customer’s own directory. We decide with you what your other services need to know about a user, and put that in the token. And we write the first access model with you, so it fits the business and not just the first release.
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 what access should depend on: the user, the resource, or the relationship between them. Then we write that down somewhere your application can read it, together with the people who’ll maintain it afterwards.
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 ties you to the version you’re on.
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’re about to give an agent access to customer data, and you can’t say what it may do.
We give the agent its own identity, or let it act for the user who asked, with rights narrowed to that task. The token it carries names the tools and APIs it may call and nothing else. We log every call against that identity. When someone asks afterwards what the agent did and what it was allowed to do, you can show both.
Tell us what you’re building.
Our clients are in the DACH region and across the EU, and we work with all of them remotely.