The work we take on.
Four practice areas across Okta and Auth0, and the ways to engage us on each.
Packaged Offerings
Every engagement is fixed-fee and outcome-based. You buy a result, not a block of hours, and we absorb the delivery risk.
Phase 0 POC
We review your current state, design the target architecture, and prove the approach on your real environment.
It is a low-risk way to start, and the work credits toward the build that follows.
SecureSessions
A focused Okta or Auth0 integration and architecture session with a senior architect.
You leave with concrete recommendations and a scoped next step, in a day.
Continuous Identity Modernization
Workstream-aligned delivery across a modernization roadmap.
A dedicated pod that knows your environment and stays with the account quarter over quarter.
FGA Assessment
We model authorization for CIAM, entitlements, and agentic use cases on Auth0 FGA.
We validate the model and the migration strategy across your business units, so the program is ready to build on.
Custom Scope
Not every program fits a package. Bring us the problem as you have it: a migration nobody wants to own, an architecture question, a program that has stalled.
We scope it with the architects who would deliver it and come back with a bespoke, fixed-fee proposal.
The four practice areas
Most organizations have work in all four at once. For each one, here is the problem we usually find and what we do about it.
Workforce Identity
The platform now carries every decision made since rollout
Workforce identity is where most enterprise IAM programs live. Okta governs employee access: joiner, mover, and leaver workflows, application integrations, adaptive access policies, device trust, and ITDR response.
The hard part is rarely the initial deployment. It is the complexity that accumulates over years of organic growth. Policies encode access assumptions that no longer hold. Integrations were added by engineers who have since left. Nobody can fully explain the group structure.
Policy drift compounds at every joiner, mover, and leaver event. Any migration has to account for dependencies nobody has fully mapped, in an environment where downtime is measured in revenue.
Assess, map, migrate, and hand over
Every engagement starts with a full read of the current Workforce Identity Cloud (WIC) tenant: the integrations, the policies, and the lifecycle workflows.
We map the dependencies and find the gaps between what the policies were meant to do and what they actually do. The plan is built around the tenant you have, not a tidy version of it.
Migration runs as a phased cutover with a rollback for every wave. When it is done we hand over how it all works, so your team can run it without us.
A global financial services firm consolidates its identity providers
A global financial services firm had inherited separate identity providers through acquisition. No single team could answer who had access to what.
We mapped every integration dependency, sequenced business units to move independently, and gave each wave its own rollback plan.
The firm now runs on one workforce identity platform, with a unified view of access across business units and geographies.
Customer Identity
24M
users and 250+ applications served by CIAM our architects have deliveredLogin has to be easy for customers and hard for attackers
Customer identity sits between security, user experience, and growth. Make registration or login clunky and customers leave. Leave it open to credential stuffing and the breach costs far more than the lost signups.
B2B is the harder version. Enterprise customers bring their own identity providers, expect strict tenant isolation, and ask about federation on the first sales call.
Federation is where most of the risk hides. A trust boundary set up wrong is a direct path into customer data.
Architecture design on Auth0, from login to fine-grained authorization
We design authentication architectures on Auth0 Customer Identity Cloud (CIC), from consumer applications with millions of users to B2B platforms with complex tenancy.
Universal Login centralizes the login experience. Auth0 Organizations model B2B tenancy and tenant isolation. Auth0 Actions carry custom logic at the right extensibility points.
Auth0 FGA enters where the access model needs more than roles: relationship-based authorization, modeled centrally instead of scattered across applications.
A healthcare SaaS platform redesigns patient authentication
A fast-growing health technology company had outgrown its original authentication architecture. Patients expected the low-friction login of consumer applications. The platform needed HIPAA-compliant handling of protected health information.
We redesigned the customer identity architecture: enterprise federation for hospital partners, progressive profiling to cut registration friction, and step-up verification only where risk warrants it.
New health systems now onboard through a standard federation process, and HIPAA audit evidence generates from authentication logs instead of manual documentation.
Authorization Modeling
100+
business units onto one Auth0 FGA authorization modelRoles multiply until nobody can answer who has access to what
Most organizations start with role-based access control, and it works until it doesn't. As products grow, roles multiply, permissions overlap, and exceptions pile up. Eventually nobody can answer the basic question: who has access to what?
At that point you have a modeling problem, not a tooling problem. Adding more roles or more policy conditions only makes it worse.
The fix is to step back and model access deliberately, then build that model in the platform instead of letting it accrete role by role.
The three models, and when each one fits
RBAC remains the right model for many contexts: a clean baseline that stops role sprawl and stays legible to engineers and auditors alike. We use it where it fits and do not over-engineer past it.
ReBAC is the right model for collaborative platforms, MSP hierarchies, and access that derives from a relationship. Alice can edit this document because she owns the project it belongs to, not because of her job title. We implement ReBAC on Auth0 FGA, based on the OpenFGA specification, modeling relations centrally so one authorization layer replaces logic scattered across applications.
PBAC is the right model for regulatory contexts: separation of duties, time-based access, and approval workflows. It produces audit-ready permission trails for SOX, HIPAA, PCI, and financial services regulations.
A Major MSP and Networking Service Provider centralizes authorization on Auth0 FGA
A Major MSP and Networking Service Provider had grown through acquisition into a security platform spanning more than 100 business units. Authorization logic had accumulated inside individual products, with conflicting sources of truth.
We designed a centralized model on Auth0 FGA that encodes the MSP relations directly: Accounts, Groups, Users, and the cross-tenant access the hierarchy requires. The full model was delivered, approved by client leadership, and validated across business units and MSP use cases.
"Anthony is our principal dev and he's not an easy person to impress, but he relayed to me that he's really impressed with JP. His knowledge, his demeanor, and how personable he is in meetings with other teams." - VP of IAM
For a national retailer, the same discipline consolidated a decade of accumulated roles into a composable model that engineers and auditors can reason about.
Agentic Identity Management
Agents reached production before the identity layer did
AI agents are moving from demos to production. Most operate on broad, static service-account credentials that bypass the access controls human users are held to.
An agent needs a real identity, not a shared service account. It acts on behalf of a person, and the identity system has to record that.
Agents increasingly reach enterprise tools through the Model Context Protocol, which makes the tool call the new authorization boundary.
A delegation chain with attribution at every hop
We model the full delegation chain: Human as principal, IdP as authority, Agent as actor, MCP proxy as control plane, Tool as resource. Every action is authorized by the human the agent acts for, and every hop records it.
The mechanics are open standards, available on current Okta infrastructure. OAuth Actor Tokens (RFC 8693) record the agent acting for the human. Resource indicators (RFC 8707) scope each token to a single audience. FIDO2 or CIBA adds phishing-resistant step-up where a call is high-risk.
We enforce the chain at a single point between agents and MCP servers. Zero changes to existing agents or downstream tools. Every decision logs the agent, the human principal, the tool, and the outcome.
Tell us which problem cannot wait
A 30-minute working session with a senior architect, scoped to the practice area you name.
Book a 30-minute working session