An identity provider (IDP) connects authentication to the identity and authorization information that platform services need. For an engineering platform, it should act as a secure intermediary, not the sole source of truth: other systems can authenticate users and maintain team membership, while the IDP assembles the claims needed to access platform resources. section 4.3.3
Keep platform customer identity separate from cloud infrastructure identity. Developers should reach infrastructure through the platform control plane; the platform provisions resources for their teams rather than handing developers broad cloud permissions. The useful default permission boundary is team membership: adding someone to a team should give them access to that team's platform and developer resources without a series of manual requests. section 4.4 section 4.3.3
An incremental integration pattern is:
- Use corporate single sign-on to authenticate users, then choose where teams can manage membership. GitHub teams are one option when the development tool already provides a self-service experience. section 7.3.1
- Connect tools to that membership information where possible. CircleCI can use GitHub team permissions; tools without native support may need an API that synchronizes membership. section 7.3.1
- Configure the IDP to obtain team information after authentication and issue verifiable credentials for platform infrastructure and custom APIs. Manage production IDP configuration in code. section 7.3.1 section 7.3.2
Accessing team resources from a terminal
A developer starts a CLI login from a laptop. Because a terminal cannot handle the whole browser interaction, the flow uses OAuth 2.0 device authorization. The developer authenticates through GitHub and authorizes the device. The IDP retrieves the developer's GitHub organization teams and creates a verifiable JSON Web Token with team membership as a claim. The CLI can then obtain credentials for platform resources. Auth0 is one SaaS IDP option for this setup. section 7.3.2 section 7.5
Figure 7.9 In this authentication and authorization flow, the IDP acts just as a secure go-between. The user must authenticate through GitHub and grant their device authorization to receive a JSON Web Token.
Follow the handoff between GitHub authentication, device authorization and IDP-issued credentials; the IDP is the go-between, not the authentication source. section 7.3.2
Single sign-on is a starting point, not the whole onboarding system. Automate the remaining integrations so a team can manage membership once and receive consistent access across its tools and platform resources. section 4.4 section 7.3.1











