How do we set up SSO (OpenID Connect) for Coder and map roles for platform admins vs developers?

Quick Answer: Configure SSO for Coder by registering Coder as an OpenID Connect client in your IdP, then enabling OIDC on the Coder control plane with the provider’s issuer/client details. Map platform admins vs developers using Coder RBAC roles tied to IdP groups or claims, so identity and permissions stay centralized.

Frequently Asked Questions

How do we enable SSO (OpenID Connect) for Coder on our infrastructure?

Short Answer: Register Coder as an OIDC client in your identity provider, then point the Coder control plane (coderd) at that provider using its issuer URL, client ID, and client secret. When users sign in, Coder defers authentication to your IdP and enforces access with RBAC.

Expanded Explanation:
Coder is self-hosted on your infrastructure (cloud or air‑gapped on‑prem), so you own the control plane and the trust relationship with your IdP. To enable SSO, you first create an OpenID Connect application in your IdP (e.g., Okta, Azure AD, Google, Keycloak). You configure redirect/callback URLs that point back to your Coder deployment, then grant the app access to standard OIDC scopes and any group/role claims you want to use for authorization.

On the Coder side, you enable OIDC support on coderd by providing the IdP’s issuer URL, client credentials, and allowed redirect URLs. From that point forward, Coder no longer manages passwords; it trusts the OIDC identity token and uses claims (like email, subject, and groups) to create and authorize users. All developer and platform admin access starts at your SSO entry point.

Key Takeaways:

• Coder delegates authentication to your OpenID Connect provider; it does not become another password silo.
• SSO is wired into the coderd control plane, so every workspace session maps back to a trusted, auditable identity.

---

What is the step‑by‑step process to configure OIDC SSO for Coder?

Short Answer: Define an OIDC app in your IdP, configure redirect URIs, enable OIDC in coderd with the IdP details, then test sign‑in end‑to‑end before rolling it out to your teams.

Expanded Explanation:
Think of this as wiring your identity plane into your dev environment control plane. The IdP issues signed tokens; Coder verifies them and applies RBAC. The critical pieces are: consistent redirect URLs, the correct OIDC scopes, and making sure the claims you need for role mapping (like group membership) are present in ID tokens.

Once you’ve enabled OIDC, you should validate the flow with a non‑admin test user, confirm that Coder picks up the expected username/email, and verify that no one can bypass SSO. After that, you can enforce SSO as the only login path and start tightening RBAC around workspaces and templates.

Steps:

1. Create an OIDC app in your IdP:

   • Application type: OpenID Connect (Web).
   • Set redirect/callback URLs to your Coder URL, e.g.:
     • https://coder.example.com/oauth2/callback
     • Or your ingress URL if fronted by a reverse proxy.
   • Enable openid and profile scopes; add email and groups/roles if you’ll map RBAC from them.

2. Enable OIDC in the Coder control plane:

   • Deploy or update coderd with OIDC flags/env vars, for example:
     • CODER_OIDC_ISSUER_URL – your IdP issuer (e.g., https://login.example.com/realms/dev).
     • CODER_OIDC_CLIENT_ID / CODER_OIDC_CLIENT_SECRET – from the IdP app registration.
     • Any configured redirect URL must exactly match what your IdP expects.
   • If you’re using Helm on Kubernetes, set these in your values file and redeploy.

3. Test and enforce SSO:

   • Log in via SSO with a regular developer account and verify user creation.
   • Confirm that sign‑out/sign‑in cycles always go through your IdP.
   • Once validated, disable local logins (if previously used) so all access flows through OpenID Connect and your IdP policies.

---

What’s the difference between platform admin roles and developer roles in Coder?

Short Answer: Platform admins manage the Coder control plane—templates, infrastructure policies, and RBAC—while developers consume those governed workspaces; admins shape the rails, developers run on them.

Expanded Explanation:
In Coder, RBAC separates “owning the platform” from “using the platform.” Platform admins have rights to install and upgrade coderd, define Terraform-based workspace templates, set dev URL access levels, and manage RBAC and organization‑wide settings. They’re typically your platform engineering or central DevEx team, plus security stakeholders.

Developers operate inside the boundaries those admins create. They self‑serve workspaces, choose from approved images and templates, connect via VS Code Remote, JetBrains Gateway, Jupyter, Cursor, or Windsurf, and run workloads on the compute pools admins expose. They don’t control the underlying infrastructure or global security posture.

Comparison Snapshot:

• Platform Admins: Configure templates, workspace classes, AI Bridge, org‑level policies, and RBAC; integrate with cloud/Kubernetes/VM fleets and SIEM; upgrade Coder.
• Developers: Provision and manage their own workspaces based on approved templates; connect IDEs; stop/start environments; request access where required.
• Best for:
  • Platform Admin roles: Platform/SRE/security leads who govern infrastructure and access.
  • Developer roles: Individual contributors, data scientists, and AI coding agents that need governed environments, not platform control.

---

How do we map IdP groups to Coder roles for platform admins vs developers?

Short Answer: Use your IdP as the source of truth: create distinct groups for platform admins and developers, ensure those groups are exposed in OIDC claims, then configure Coder RBAC to assign admin‑level or developer‑level roles based on those claims.

Expanded Explanation:
The cleanest pattern is “identity and roles live in the IdP; Coder consumes them.” You define groups like coder-platform-admins and coder-developers in your IdP, assign users appropriately, and configure the OIDC app so these groups appear in a groups (or similar) claim on the ID token. Coder reads that claim at login and evaluates RBAC rules to determine effective permissions.

That way, onboarding and offboarding are centralized: add a new hire to coder-developers and they get developer rights in Coder; move an engineer into coder-platform-admins and they gain platform control. If someone leaves or changes teams, removing them from the IdP group immediately revokes or changes access in Coder the next time they authenticate.

What You Need:

• Group‑backed claims from your IdP:
  • At least one claim (e.g., groups, roles, memberOf) that lists Coder‑relevant groups.
  • OIDC configuration set so the claim shows up in ID tokens, not just in the user profile API.
• Coder RBAC rules tied to those claims:
  • A rule mapping coder-platform-admins (or equivalent) to an admin‑level role with control plane permissions.
  • A default or explicit mapping for regular developers (e.g., coder-developers) that limits them to workspace usage within defined boundaries.

---

How should we design our overall SSO and role mapping strategy for Coder?

Short Answer: Keep Coder thin and governed: centralize identity and group management in your IdP, map those groups to Coder RBAC roles, and treat SSO as the mandatory front door for all platform admin and developer access.

Expanded Explanation:
If you want remote development that scales without compromising control, treat SSO and RBAC as part of your infrastructure architecture, not just a login feature. Start by defining which populations exist—platform admins, developers, contractors, AI coding agents—and then design IdP groups and Coder roles around those. Use OIDC SSO so all access is strongly authenticated and centrally audited.

In practice, platform teams get leverage: they standardize Terraform workspace templates, workspace classes, dev URL access levels, and AI Bridge policies, and then trust that only the right people can change them. Developers get fast, IDE‑agnostic access to governed workspaces without ever copying source code or data to their laptops. Security teams see a reduced attack surface—no scattered SSH keys, fewer secrets on endpoints, and a single identity plane controlling who can touch production‑adjacent environments.

Why It Matters:

• Stronger governance with less drift:
  • All access to workspaces, templates, and AI Bridge flows through OIDC and RBAC, which ties actions back to specific identities and groups.
  • Coder’s control plane can be wired into your SIEM so SSO events, workspace activity, and AI agent usage form a complete audit trail.
• Faster, safer operations at scale:
  • Platform teams like those at the U.S. DoD, Dropbox, and Skydio use this pattern to accelerate onboarding (up to 4x faster) and replace fragile VDI setups while keeping code and data inside their infrastructure.
  • A clean SSO + RBAC design lets you add more clusters, templates, and AI workloads without rethinking how you authenticate and authorize each new use case.

---

Quick Recap

To set up SSO (OpenID Connect) for Coder and cleanly separate platform admins from developers, you first register Coder as an OIDC app in your IdP and enable OIDC on the Coder control plane. Then you use Coder RBAC driven by IdP groups/claims to map platform admins—who govern templates, infrastructure, and AI Bridge—from developers, who self‑serve workspaces within those guardrails. Centralizing identity and role mapping in your IdP, with Coder enforcing boundaries, gives you fast developer onboarding and strong governance over compute, access, and context.

Next Step

Get Started