That’s when you realize: your OpenID Connect (OIDC) setup depends on user-specific configuration, and you didn’t plan for it.
OIDC makes authentication simple—until you deal with real-world user config. Clients, scopes, claims, and dynamic redirect URIs all change based on who’s logging in and where they’re coming from. It’s not just wiring up an identity provider. It’s managing moving pieces that shift per tenant, per environment, and sometimes per request.
Why user config in OIDC isn’t trivial
OIDC assumes a handshake between the client and the identity provider. That’s easy if every user shares the same setup. If not, you need logic that adjusts Authority URLs, client IDs, and even token parsing at runtime. Static configs can’t handle this. You end up hardcoding, duplicating, or patching over edge cases until everything is fragile.
Common pitfalls
- Single client ID for all users — works in dev, fails when multi-tenant reality hits.
- Assuming static scopes — one size rarely fits all, especially if different users need different API access.
- Token structure drift — ID token claims can vary across providers or tenants, breaking validation if you parse without checks.
- Environment split — staging and production may need entirely separate OIDC app registrations.
A better approach
Stop treating OIDC config as static. Store per-user or per-tenant details in a config service. Load client parameters dynamically at login time. Use discovery endpoints to auto-update keys and avoid manual rotation pain. Validate claims against expected patterns instead of hardcoded assumptions.
Balancing security and flexibility
A dynamic OIDC config model can still be secure if you validate inputs before initiating a flow. Sanitize dynamic values. Only load trusted provider metadata. Restrict scope requests to a predefined, whitelisted set.
The outcome
When user config is handled right, your OIDC setup works across tenants, environments, and providers without brittle hacks. You stop firefighting broken login screens.
If you want to see a dynamic OIDC setup working without days of boilerplate, you can try it live with hoop.dev. Spin it up in minutes, test with real auth flows, and skip the endless config mismatches.