OpenID Connect (OIDC) is an identity layer built on OAuth 2.0. In an engineering platform, an OIDC integration lets users log in through an identity provider (IDP) while the platform receives the identity and authorization claims it needs to make access decisions. Authentication establishes who the user is; authorization determines what that user may do. section 4.3.3
The IDP need not be the source of truth for every attribute it returns. Configure its authorization server to consult the platform’s authorization data and include relevant claims after a successful login. This keeps identity verification and access decisions connected without requiring every platform component to manage users independently. section 4.3.3
For a platform integration, settle these choices before adding more access points:
- Choose where users authenticate and where team membership is authoritative; they need not be the same system. section 8.5
- Configure the IDP to return the authorization claims the platform needs, rather than treating a successful login as sufficient access. section 4.3.3
- Favor systems whose authorization configuration can be automated. Ticket-driven role assignment adds friction to the developer experience. section 4.3.3
GitHub-backed control-plane access
A developer authenticates through GitHub using an OIDC integration. GitHub teams supply team membership for authorization, and a ClusterRoleBinding grants the platform-building team access to the control plane. An organization could instead synchronize Active Directory groups into GitHub groups, making Active Directory the place where membership changes. Either way, the platform must decide which teams are its customers before it can automate their namespaces and RoleBindings. section 8.5
Figure 4.8 We want the IDP to be the go-between rather than the source of truth, and we will need to be able to customize the results from the authorization service.
The diagram reinforces the IDP’s role as a go-between: configure what the authorization service returns instead of assuming the IDP owns the underlying data. section 4.3.3












