If you’ve ever set up login for a web application, you’ve faced a choice: build authentication yourself, or delegate it to something else. That “something else” is an Identity Provider (IDP).
This post explains what an IDP actually does, when you need one, and why we built JustIAM the way we did.
What Does an IDP Do?
At its core, an IDP answers one question for every application in your stack: “Who is this user, and what are they allowed to do?”
It does this by:
- Authenticating — verifying that the user is who they claim to be (password, MFA, passkey, federated login via Google/GitHub/LDAP)
- Issuing tokens — giving the application a signed proof of identity (OIDC ID tokens, OAuth2 access tokens, SAML assertions)
- Managing the directory — storing users, groups, and their relationships in one place
- Enforcing policy — MFA requirements, session lifetimes, access restrictions
Without an IDP, every application manages its own user database, its own password hashing, its own session logic. You end up with N user tables, N login pages, and zero visibility into who has access to what.
When Do You Actually Need One?
You need an IDP when:
- You have more than one application — the moment you want SSO, you need a centralized identity source
- You have a team, not just yourself — onboarding and offboarding users across multiple systems is painful without a directory
- You care about security — MFA, session management, audit logs, and access revocation are hard to implement well in every app
- Compliance asks questions — “Who accessed what, and when?” requires centralized logging
If you’re a solo developer with a single app, authentication libraries (NextAuth, Passport.js) might be enough. The moment you scale to a team or multiple services, an IDP saves hours of glue code and security headaches.
The Landscape Today
The IDP market breaks into three categories:
Cloud-hosted (Auth0, Okta, WorkOS)
Managed for you. Fast to start. But: vendor lock-in, per-user pricing that scales linearly, your user data lives on someone else’s infrastructure, and customization is limited to what the vendor exposes.
Self-hosted heavyweights (Keycloak, FreeIPA)
Open source, feature-rich, battle-tested. But: Java runtime, complex deployment, steep learning curve, and extending behavior typically requires writing custom SPIs or navigating XML configuration. Automation beyond login usually means bolting on external tools.
Lightweight self-hosted (JustIAM, Authentik, Zitadel)
Newer entrants that aim for simpler deployment with modern stacks. This is where JustIAM lives.
Where JustIAM Fits
JustIAM is a self-hosted identity provider written in Go. Single binary, Docker Compose deployment, PostgreSQL for storage. It handles the standard IDP responsibilities — OIDC, SAML, MFA, directory, sessions — but it was designed from day one around one insight:
Authentication is only half the job. The other half is what happens after login.
In practice, teams spend more time on:
- Syncing users between the IDP and external tools (GitHub Teams, Datadog, LDAP)
- Customizing tokens with dynamic claims based on user attributes or group memberships
- Reacting to identity events (new user → create Slack channel, access revoked → notify manager)
- Managing temporary access (on-call engineer needs prod access for 4 hours)
- Protecting apps that don’t support OIDC (legacy tools, internal dashboards)
Most IDPs treat these as “someone else’s problem.” JustIAM treats them as core features.
What Makes JustIAM Different
1. Scripting, Not Configuration
JustIAM embeds a Go interpreter (Yaegi). You write real Go code — full standard library — that runs inside the identity provider:
- Post-render scripts modify tokens before they’re signed. Need to inject a custom claim based on an API call? Write 10 lines of Go.
- MFA selector scripts decide MFA policy per-user. VPN users skip MFA; external users require passkeys. Logic, not config toggles.
- Scheduled tasks sync users, rotate secrets, generate reports — on a cron schedule, with built-in retries and delivery tracking.
No plugin SDKs. No webhook relay services. No YAML policy languages.
2. Event-Driven Automation
Every identity event (login, group change, access grant, MFA enrollment) can trigger actions — HTTP webhooks, Slack messages, log entries, or script tasks. Conditions filter which events fire which actions. Delivery is tracked, retried, and visible in the admin UI.
This means “when a user is added to the ops group, POST to our provisioning API” is a 2-minute configuration in JustIAM, not a custom webhook consumer deployment.
3. Built-in Access Governance
Users request temporary access to a group or application. Approvers review. On approval, access is granted for a defined duration and automatically revoked when it expires. Full audit trail, discussion thread, and escalation policies — no external ticketing system required.
4. Proxy Provider
Some apps will never support OIDC. JustIAM’s forward-auth proxy sits in front of any HTTP application, handling authentication and injecting identity headers (X-Auth-User, X-Auth-Email, X-Auth-Groups). When access is revoked, it clears the downstream app’s session cookies too — forcing a clean re-authentication.
5. Terraform-Native
Every JustIAM resource has a Terraform resource. Users, groups, applications, claim mappings, access request templates, event actions, scheduled tasks — all manageable as code from day one.
Honest Trade-offs
JustIAM is not the right choice for everyone:
- If you need zero infrastructure management — a managed service (Auth0, WorkOS) eliminates operational burden. JustIAM requires you to run and maintain the deployment.
- If you need hundreds of pre-built integrations — large vendors have bigger connector catalogs. JustIAM compensates with scripting flexibility, but you’ll write the integration yourself.
- If you need FIPS/FedRAMP compliance certification — we don’t have those certifications (yet).
Getting Started
JustIAM runs anywhere Docker runs:
git clone https://github.com/justiam/justiam
docker compose up -d
You’ll have a working identity provider at http://localhost:8080 in under a minute. Add your first application, configure MFA, and start exploring the automation features from there.
The documentation covers everything from initial setup to advanced scripting patterns.
JustIAM is open source and self-hosted. If you’re evaluating identity providers and want something that doesn’t stop at login, give it a try.