Back to blog
Security

SSO Implementation: How We Did It Across All Our Applications

Employees managing separate passwords for a dozen internal tools is a security incident waiting to happen. We implemented Single Sign-On across our entire application stack — here's what the journey looked like.

October 2, 2023
6 min read

Before SSO, our team was dealing with the classic enterprise problem: every tool had its own credentials. Password reuse was rampant. Offboarding was manual and error-prone — deprovisioning access meant logging into each service individually. The security risk was obvious, but so was the daily productivity drain.

Understanding SSO

Single Sign-On is an authentication method that lets users access multiple applications with a single set of login credentials. Instead of maintaining separate passwords for each tool, a user authenticates once against a central identity provider, and that session is trusted by all connected applications.

The two dominant protocols you'll encounter are SAML 2.0 (older, XML-based, widely supported by enterprise software) and OIDC/OAuth 2.0 (modern, JSON/JWT-based, preferred for web applications and APIs). We used both — legacy tools needed SAML, newer services used OIDC.

Why we needed it

  • Password overload — engineers maintaining 10+ sets of credentials for internal tools
  • Security risk — shared and reused passwords across services
  • Productivity loss — time spent on password resets and login flows
  • Compliance requirements — audit logs needed to show who accessed what and when
  • Offboarding risk — departing employees retained access until manual deprovisioning

Our implementation journey

We broke the implementation into phases to avoid disrupting ongoing work. Phase one was a full audit: cataloguing every internal application, its authentication method, and whether it supported SAML or OIDC. This took longer than expected — there were more tools than anyone had a complete list of.

Phase two was selecting the identity provider. We evaluated Keycloak (self-hosted, open source), Okta (SaaS, mature), and Authentik (self-hosted, modern). We chose Keycloak for the control it gives over data residency and the flexibility to add custom flows without vendor lock-in.

yaml
# keycloak helm deployment
helm repo add bitnami https://charts.bitnami.com/bitnami
helm install keycloak bitnami/keycloak \
  --set auth.adminUser=admin \
  --set auth.adminPassword=${ADMIN_PASSWORD} \
  --set postgresql.enabled=true

Phase three was integration — connecting applications one by one, starting with the lowest-risk internal tools before touching anything customer-facing. We built a rollback plan for each integration before enabling it.

Results

The impact was immediate and measurable. Onboarding new engineers dropped from a half-day of account provisioning to a single Keycloak user creation. Offboarding became instant — one account disabled, access revoked everywhere simultaneously. Support tickets related to password resets dropped to near zero.

  • Onboarding time reduced significantly — one identity, all tools
  • Offboarding is now instant and complete
  • Full audit log of authentication events across all applications
  • Compliance requirements met without additional tooling
  • Engineers report noticeably less friction in day-to-day work
All articles