You know that sinking feeling when your team finally gets access control “mostly configured,” yet half the internal tools still throw login errors? Compass OIDC fixes that mess if you wire it up right. Most engineers treat identity as a checkbox. It’s not. It’s the nervous system of your infrastructure.
Compass handles authorization at scale. OIDC, short for OpenID Connect, handles authentication and identity federation. Together, they cleanly separate who you are from what you’re allowed to do. Set them up properly and users glide into dashboards, APIs, and ephemeral environments with zero friction. Set them up poorly and you spend your weekend untangling tokens.
How Compass OIDC actually flows
Compass OIDC connects your identity provider—Okta, Google Workspace, or Azure AD—to Compass’s access layer. When someone logs in, OIDC passes an identity token that Compass validates against its policies. Permissions come from claims or group mappings, not local configs. That means every request carries context like role, team, or environment, verified at the edge. No stale credentials. No mystery users.
Instead of storing secrets on every service, Compass becomes the gatekeeper. It calls your identity provider for proof, logs the decision, and enforces policy automatically. AWS IAM works the same way under the hood, only Compass makes it available across non-AWS systems too. Once configured, your audit logs start reading like clean sentences instead of paranoid riddles.
Quick tip: managing roles and mappings
If your roles feel duplicated between Compass and your IdP, map them with OIDC claims. One claim equals one permission set. Rotate secrets quarterly and test new scopes in a sandbox before pushing live. That prevents token mismatch errors and keeps SOC 2 reviewers happy.