Authentication verifies who a developer is. In an engineering platform, it should give developers a consistent way to sign in across tools, infrastructure, and custom APIs. It does not, by itself, decide what they may access: that is authorization. Centralizing sign-in helps avoid separate access requests for every resource, but only if the integrations reach beyond SaaS tools. section 4.3.3 section 8.5
Separate the decisions that are easy to conflate:
- Use corporate identity or single sign-on to authenticate an individual. Keep the platform’s customer identity separate from the identifiers of its underlying infrastructure. section 4.3.3 section 7.3.1
- Choose where team membership is maintained, then use it to authorize access. One workable arrangement authenticates users through GitHub while maintaining teams in GitHub’s role-based access controls. section 7.3.1
- Connect that team information to each access point. Some tools support the connection directly; others may need an API that synchronizes membership. Infrastructure and custom APIs need the same access model. section 7.3.1
One sign-in, team-scoped access
A developer authenticates with personal GitHub credentials through an OIDC integration. Their GitHub team supplies the authorization used to access the control plane. CircleCI can connect permissions directly to GitHub teams; other SaaS tools may require membership synchronization. When a team is onboarded, the goal is for its members to receive access to platform features within that team’s bounds, rather than requesting each resource separately. section 7.3.1 section 8.5
Figure 7.8 For Epetech, we would like our IDP service to have built-in or easily configurable means of integrating with GitHub, requiring authentication through whatever means we have set up in GitHub. As a result of (1) successful authentication, we want the IDP to (2) get the list of all teams the user is a member of in our GitHub organization. Finally, we want to (3) return to the user a secure means of accessing the platform infrastructure or custom API resources.
Follow the identity-provider flow: authenticate through GitHub, retrieve the user’s teams, then provide a secure way to access infrastructure or custom APIs. The steps show where identity verification ends and team-based access begins. section 7.3.1
Treat sign-in as a starting point, not the whole access experience. Decide which system owns team membership, identify integrations that cannot consume it directly, and automate the remaining connections. An identity provider can bridge systems without becoming the source of truth for every authorization decision. section 4.3.3 section 8.5
