Identity and Access Management
Sign-in, roles and permissions for applications that have grown over the years.
Login systems are rarely designed on a drawing board. They arrive with the first application, collect an exception with every system that follows, and at some point nobody can say with confidence who is allowed to access which data. I retire structures like that and replace them with a model you can explain and audit.
What I take on
Microsoft Entra ID as identity provider
Connecting applications to Entra ID, cutting app registrations, scopes and claims cleanly, and matching them against the roles the business side actually needs.
OAuth2 and OpenID Connect on the consumer side
Authorization code flow with PKCE, token renewal, expiry times and sessions. The bugs rarely sit in the standard, they sit in the details of the implementation.
Replacing grown login solutions
Migrating home-grown user tables and legacy systems onto a central identity provider without users losing access.
Central role and permission models
One model for all applications instead of separate logic per system. Permissions become traceable and audits become answerable.
Connecting heterogeneous API landscapes
Consolidating services that each bring their own authentication mechanism behind a single consistent layer.
Typical starting points
If you recognise your situation in one of these, a conversation is worth it.
- Every application brings its own user management.
- Onboarding means creating access by hand in several systems.
- Nobody can reliably answer who is allowed to access which data.
- A legacy system is due for replacement, but the user accounts have to survive it.
- A team needs reinforcement with exactly this experience for a fixed-term project.
Let us talk about your project
A first conversation costs nothing and commits you to nothing.
Get in Touch