An identity provider (IdP) is a trusted application that centralizes authentication for other applications. It manages user credentials, verifies identities, and provides identity information or tokens that relying applications use to authorize access. This separation lets one login serve multiple applications instead of making each application implement its own credential management. section 12.0 section 12.1
Figure 12.3 Before accessing an app, the IdP authenticates the user. The other apps rely on it to provide the details required to authorize the user for the specific features they offer.
Use this flow to distinguish responsibilities: the IdP authenticates the user, while the relying application uses the resulting details to authorize features. section 12.1
An IdP typically:
- Authenticates users through a centralized credential store. section 12.1
- Recognizes and authenticates client applications, which may each have their own credentials. section 12.3
- Issues tokens that act as proof of successful authentication and support communication with client applications or backends. section 12.5
- Publishes configuration such as authorization and token endpoints, accepted redirect URIs, permitted grant types, and client scopes. section 12.3
One login across applications
Patrick uses his Google credentials to sign in to shopping, ticketing, and media applications. Google acts as the IdP: Patrick authenticates there once, and participating applications rely on the resulting authentication rather than each collecting separate credentials. In an employee setting, the same arrangement can provide one login for several workplace applications. section 12.0
OAuth2 and OpenID Connect commonly connect the IdP with its clients. The authorization code flow uses redirects and an authorization code before exchanging it for tokens, avoiding direct exposure of the token in browser history or logs. Access tokens authorize backend requests; ID tokens carry user information. Tokens may be readable and locally validated, or opaque and checked through token introspection. section 12.4 section 12.5
