Providers and relying parties
All domains and identifiers in these examples are fictional.
When you select Continue with your photo account, the same organizations take part as when you connected the printer to your photos. What changes is the job each one is doing. OpenID Connect gives those jobs their own names, and you will meet them in specifications, provider documentation, and configuration screens.
New names for familiar roles
| OpenID Connect role | In our example | OAuth role it builds on |
|---|---|---|
| End-User | You, signing in to the printer. | Resource owner |
| Relying Party | The printer, which relies on the photo service's statement about who you are. | Client |
| OpenID Provider | The photo service's authorization server, which authenticates you and issues ID tokens. | Authorization server |
| UserInfo endpoint | An endpoint at the photo service that returns information about you to a client holding a suitable access token. | Protected resource |
The OpenID Provider is an authorization server that has taken on a second job. It still issues access tokens. It now also authenticates people on behalf of other applications and reports the result to them. Many organizations simply call it their identity provider, the general term from Trust across systems for a service that authenticates people for others. Specifications shorten the two main roles to OP and RP. This series mostly writes them out.
The relying party is still a client in the OAuth sense. The printer's registration, client ID, redirect URIs, and client authentication all carry over unchanged. Being a relying party adds responsibilities on top: checking the ID token, connecting it to an account, and running a session of its own.
The issuer
A relying party needs an exact name for the provider it trusts. In OpenID Connect, that name is the issuer identifier, an HTTPS URL:
https://auth.photos.exampleEvery ID token the photo service creates names this value in its iss claim, and the printer compares it character for character with the issuer it has configured. The provider's other addresses, its endpoints and the location of its public keys, are published in a document the printer finds from the issuer, as Provider discovery will show. Everything the printer trusts about the photo service hangs from this one value.
An issuer is more specific than a company. A provider can run separate issuers for testing and production, and providers that serve many organizations often give each one its own issuer. Two issuers are two providers, even when the same company operates both, and a relying party configures each separately. You met the same idea in Correlating requests and responses, where the printer checked which authorization server had answered before using its response.
What each side decides
The provider authenticates you. It decides how: perhaps your password and an authenticator app, perhaps a passkey, perhaps nothing new at all because you signed in this morning and its session is still valid. It also decides what to tell the printer about you, which can depend on what you agree to share.
The relying party decides everything that happens in its own application. It decides whether to accept the provider's answer at all, which printer account the answer refers to, and what that account may do. The photo service can say that the person in the browser is user-2048 and authenticated a minute ago. It cannot say whether that person may cancel a photo book that has already shipped. That remains the printer's own authorization decision, as Deciding what someone can do described.
The arrangement looks a little different depending on who chooses the provider. When you select Continue with your photo account, you are using a provider you already have, and the printer simply offers it as a choice. At Lantern Studio, from JWT and SAML assertion grants, the organization makes the choice. Its designers sign in to the project portal through Lantern's own identity provider, because that is where Lantern manages their accounts. The roles are the same in both settings: Lantern's identity provider is an OpenID Provider, and the portal is a relying party.
Each provider a relying party accepts is a separate trust relationship, with its own issuer, registration, and keys. If the printer later accepts sign-ins from a second provider, it trusts that provider to speak only for its own accounts, never for accounts at the photo service.
What the provider sends to the relying party is an ID token, and it often arrives next to an access token that looks much the same.