Which components are involved when a web application delegates login to an OpenID Provider, and what does each one hold?
On the client side the person and their browser (or smartphone app); on the application side the business application with OIDC-RP software and its OIDC configuration; at the identity provider the OP software, its OIDC configuration, its endpoints (authorization, token, optional UserInfo) and a user storage, usually an LDAP directory or a database.
Basic use case: a person uses a business application (say an e-learning platform) reachable by URL; only authenticated users may access it, and authentication is delegated to an identity provider.
| Side | Component | Holds or does |
|---|---|---|
| Client | Person, web browser or smartphone app (with OIDC client code) | Carries redirects; shows the login form; holds session cookies |
| Application (RP) | Business application | The actual service; trusts the RP software's verdict |
| Application (RP) | OIDC-RP software + OIDC configuration | Client ID, client secret, redirect URI, OP endpoints; runs the flow and validates tokens |
| Identity provider (OP) | OP software + OIDC configuration | Registered clients and their redirect URIs; signing keys; endpoints |
| Identity provider (OP) | User storage | User accounts and password hashes, typically an LDAP directory, a database or both |
Two practical observations: an identity provider usually speaks several protocols (OIDC, SAML...) on top of the same user storage. And the business application itself never touches the user storage or the user's password; it only ever receives tokens from the OP.
Go deeper:
Lightweight Directory Access Protocol (Wikipedia) — the directory protocol typically behind an identity provider's user storage.- OpenID Connect Dynamic Client Registration 1.0 — what an RP's configuration at the OP contains when registered through an API.