The Hows and Whys of Running Our Own OpenID Connect Identity Provider
summary
Shows how an organisation built and runs its own OpenID Connect identity provider using IdentityServer to retain control instead of a cloud SaaS. Covers concrete design choices: which identity and access token flows to use, a custom profile service that aggregates claims from cookies, internal APIs and external IdPs (e.g. Google), and how external subjects are mapped and provisioned as local users. Also explains multi-tenant operation via authorization-context values and startup hooks for per-tenant branding, notes cookie-size limits, on-prem hosting considerations, and licensing tradeoffs.
AI-written summary · about
chapters (7)
- 0:00Running own OIDC provider
- 5:55Why build identity provider
- 17:33Key reasons to run own
- 28:10Avoiding vendor lock-in
- 33:50Demo: external provider integration
- 37:45Customizing login screens
- 44:59Dynamic external providers
related talks
57mBuilding Clients for OpenID Connect/OAuth 2-based Systems
01h 00mImplementing OpenID Connect and OAuth 2.0 – Tips from the Trenches
34mWho Are You? I Really Want to Know… the Magic Behind OIDC
47mWho's your user? OpenID from the ground-up
24mIntroduction to OpenID Connect
57mOpenID Connect Architectural Patterns
58mBuilding JavaScript and mobile/native Clients for Token-based Architectures
01h 12mIdentity 2.0: the what, why and how of social and federated login