liveBook · Manning

Openid connect

As explained in Effective Platform Engineering

OpenID Connect is an identity layer built on OAuth 2.0 that enables clients to verify user identity and obtain standardized identity claims.

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.
A diagram of a diagram

AI-generated content may be incorrect.

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

How Effective Platform Engineering covers it

How deep it goes
Explains authentication, authorization, IDP configuration, and returned claims, but does not detail an OIDC protocol exchange.
Examples
Uses GitHub authentication, team-based control-plane access, and optional Active Directory group synchronization.
What it assumes
Assumes familiarity with platform access systems while defining identity, authentication, and authorization explicitly.
What you can do after
Apply it via a GitHub OIDC integration to authenticate control-plane users and connect their access to team membership.
How it connects
Ties OIDC to identity providers, authorization claims, GitHub teams, Active Directory groups, and Kubernetes RoleBindings.

Also explained in

Compare how 13 books explain openid connect →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.