Engineering Journal

Case Study: Building Our Own Custom IAM Service for Enterprise Applications

Published January 19, 20243 min read

  • case-study
  • iam
  • security
  • architecture
  • platform-engineering
Bhanuteja Reddy

Bhanuteja Reddy

Full Stack Lead Software Engineer

Situation

As our application portfolio grew, identity and access behavior became inconsistent across products:

Custom IAM as traffic gate: problem, IAM core, and outcome

  • Different apps implemented login, session, and permission checks differently.
  • User provisioning and deprovisioning required repeated manual effort.
  • Authorization changes were hard to audit across systems.

Objective

Build an in-house IAM service that could become the common identity and authorization backbone for all internal applications.

Why We Chose to Build It Ourselves

We had specific organizational requirements that generic IAM-only adoption did not fully satisfy:

  • Unified tenant and business-unit models across legacy and modern systems.
  • Fine-grained permission mapping aligned to real operational capabilities.
  • Product-level onboarding standards that development teams could adopt quickly.
  • Controlled extension points for SSO and external identity integrations.

Platform Model We Designed

  • Central identity service for account lifecycle, authentication policy, and session governance.
  • Authorization service for role, permission, and policy mapping.
  • Common SDK and middleware patterns used by APIs and web apps.
  • Admin workflows for access requests, approvals, and role assignment audits.

Core Capabilities Delivered

Identity Lifecycle

  • User onboarding with scoped defaults by organization and function.
  • Password and credential policy enforcement.
  • Session controls for timeout, revocation, and suspicious access handling.
  • Multi-path login support: password, OTP login, forgot-password OTP, and reset-password flows.

Authorization Engine

  • Capability-based permission design instead of broad role-only access.
  • Role templates per function with environment-aware restrictions.
  • Consistent API guard pattern for permission checks and traceable denials.
  • RS256 JWT strategy with JWKS publishing for verifier services.
  • Token introspection support for revocation-aware validation on sensitive APIs.

Service-to-Service Security

  • API-key authenticated token issuance for registered internal microservices.
  • Scoped service tokens with controlled TTL for inter-service communication.
  • RFC 7662-style token introspection endpoint for high-risk operations.

Governance and Auditability

  • Access change logs with actor, reason, timestamp, and scope.
  • Role simulation and pre-release verification workflows.
  • Periodic access review support for compliance and risk reduction.

Integration Strategy

The custom IAM service is the central authority for authentication and authorization across our applications.

Our strategy combines stateless verification with revocation-aware controls:

  • Public JWKS endpoint (.well-known/jwks.json) for key distribution and verifier compatibility.
  • RS256-signed access tokens with session-aware revocation.
  • Redis-backed logout/global logout propagation across pods.
  • OTP-based recovery and secondary login flows for operational resilience.
  • Service-token and introspection endpoints for trusted internal services.

Business and Engineering Outcomes

  • Faster onboarding for new products due to reusable identity and auth components.
  • Lower security drift across teams by standardizing permission enforcement.
  • Reduced provisioning turnaround through centralized workflows.
  • Improved compliance posture through auditable access operations.

Lessons Learned

  • IAM must be treated as a product, not only an infrastructure utility.
  • Permission taxonomy decisions made early save significant rework later.
  • API-side enforcement and audit metadata are essential for trust at scale.

Executive Snapshot

A custom IAM service creates long-term leverage when identity, authorization, and governance are designed as shared product capabilities.

IAM platform principle

Provisioning Speed

FasterCentral workflows reduced user onboarding and role assignment delays.

Auth Consistency

HigherReusable guards and policy patterns standardized behavior across services.

Audit Readiness

ImprovedAccess operations became traceable with actor and scope metadata.

IAM Baseline Assessment

Discovery phase

We identified inconsistencies across authentication flows, permission models, and onboarding patterns.

Custom IAM Platform Build

Core architecture

We implemented identity lifecycle, RS256/JWKS token infrastructure, service-token APIs, and governance workflows.

Cross-Application Adoption

Scale-out phase

Product teams onboarded onto shared IAM standards with revocation-aware auth and service introspection patterns.