Third-Party Identity
Third-party identity, also called federated identity, lets an application accept sign-ins from identity providers it does not run: consumer platforms for social login, or a partner organization's directory in business-to-business federation, over OpenID Connect (OIDC) or Security Assertion Markup Language (SAML) 2.0. The application stops handling passwords, and in exchange it accepts identity statements whose strength, lifetime and continued validity another party controls. That exchange makes assurance, account linking and the loss of a provider the design questions.
Trusting a Provider the Application Does Not Run
The external provider authenticates the user and sends the application a statement of who signed in: an ID Token over OpenID Connect, or an assertion over SAML 2.0 where a partner still runs it. When the application also calls the provider's APIs on the user's behalf, it receives an access token under OAuth 2.1 as well. The application holds no passwords and inherits the provider's multi-factor authentication (MFA) and fraud detection, which few applications would build as well themselves.
What sets this apart from Single Sign-On (SSO) is the direction of trust. In SSO an organization's applications all trust the one provider the organization runs. Here one application trusts providers it does not run, often several at once, and each of them decides for itself how users authenticate, how long sessions last and whether an account still exists. The application gets rid of credential handling and in exchange accepts identity statements whose quality it does not control. Most of the design work follows from that exchange.
Social Login and Partner Federation
Two deployments share the protocols and little else. In consumer social login the user picks a provider from a list, the account there is self-registered, and the application wants a sign-up without a new password. Whatever it needs beyond what the provider releases, it asks for later, when the user first needs the feature that requires it (progressive profiling). No one vouches for the person behind the account, and the application's relationship with the provider is the provider's terms of service.
In business-to-business (B2B) federation the provider is a partner organization's own directory, and the application chooses it, usually from the domain of the email address the user types (home realm discovery), rather than letting the user pick. The partner is accountable here: it vouches that the user works for it, it enforces its own MFA, and it deactivates the account when the person leaves. That accountability belongs in the partner agreement, because the application learns about a departure only at the next login, if there is one. A session that outlives the partner's offboarding, or a local account created at first login and never reconciled, keeps access that the partner believes it has revoked. Short sessions, back-channel logout, System for Cross-domain Identity Management (SCIM) where the partner is willing to provision and deprovision, and session-revoked events over the Shared Signals Framework (SSF) each close part of that gap.
An application that serves both populations should keep them apart in policy. What a partner's employee may do on the strength of the partner's login is not what a self-registered social-login user may do, even when both arrive through the same OpenID Connect code.
What a Provider's Login Proves
A social login proves that someone controls an account at the provider, and usually that the provider has checked an email address or phone number. It does not prove who the person is. It also says nothing about how strongly the user authenticated unless the ID Token carries acr and amr, and a provider may omit them or return the same value for every login. An application that needs MFA for a transaction cannot assume the provider performed it; the OpenID Connect article describes how to request a level with acr_values and check what came back.
NIST SP 800-63-4 keeps three questions apart that a sign-in button tends to merge, each with its own level: identity assurance (IAL, who the person is), authenticator assurance (AAL, how they logged in) and federation assurance (FAL, how the statement reached the application). A social login can be strong on the second and silent on the first. When an application needs a verified person, for regulated onboarding or a payment above a threshold, the provider's login is only the entry point. The assurance comes from identity proofing performed once and recorded against the account, from a provider that asserts verified attributes as verified_claims under OpenID Connect for Identity Assurance 1.0, a final specification, or from a verifiable credential the user presents. Partner federation differs in degree, since a partner has usually verified its employees at hiring, but the application knows that from the agreement and not from the token.
Linking Accounts Across Providers
Once a user can sign in with more than one provider, or with a provider and a local password, the application has to decide which logins belong to the same account. The stable identifier of a login is the pair of issuer and subject, iss and sub, and an account stores one such pair for every provider linked to it.
The dangerous shortcut is merging by email address, so that a login from provider B joins the account created through provider A because both assert the same address. That makes every configured provider a way into every account, and the weakest of them sets the security of all. A provider that lets users claim an address it has not verified, or a multi-tenant provider whose tenant administrators can set any address, then lets an attacker sign in as the victim. The same shortcut enables pre-account takeover, which starts before the victim arrives. The attacker registers the victim's address locally or through a lax provider, and when the victim later signs in through a legitimate provider, the automatic merge joins the victim's login to an account the attacker can still reach with their own password or linked login.
Linking should therefore be something the user does while signed in to both identities, or at least something that requires the existing account's owner to re-authenticate. An email match can propose a link, and complete one only when the provider asserts email_verified and the application trusts that provider's verification for that address. Unlinking needs a check as well: a user who removes their last login method has locked themselves out.
Validating Tokens From Several Issuers
Token validation itself is the same for one provider or ten, and the OAuth 2.1 and OpenID Connect articles cover it: the authorization code flow with Proof Key for Code Exchange (PKCE), signatures checked against the provider's JSON Web Key Set (JWKS), iss, aud, exp and nonce checked on every ID Token, and tokens held on the server rather than in browser storage. What several providers add is the possibility of confusing one with another. Each has its own keys, its own issuer value and its own client registration, and a response has to be validated against the provider the login started with, not against whichever configured provider's keys happen to verify it.
The attack specific to this setup is the mix-up attack. A client that talks to several authorization servers can be tricked into sending an authorization code obtained at an honest provider to one the attacker controls, because the redirect back to the client does not by itself say which provider issued the code. The defence is for the client to remember which provider each flow began with and for the provider to name itself in the response. RFC 9207 adds an iss parameter to the authorization response for this, and the OAuth 2.0 Security Best Current Practice (RFC 9700) tells clients that use more than one authorization server to check it. A distinct redirect URI per provider is the fallback it allows only where the provider does not return iss, because that defence is easier to get wrong. It is a check to confirm in whatever library the application uses, because an integration written for a single provider has no reason to perform it.
Privacy
The provider learns about every login: it sees that its user has an account with the application, and when they use it. For a consumer service that is a disclosure to a third party, and the privacy notice has to say so. Providers that issue pairwise subject identifiers, a different sub for each relying party, stop two applications from correlating a user through the identifier, though an email address released to both undoes that. Data minimization under the EU General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) comes down to requesting only the scopes and claims the application uses, and deleting an account at the application should also revoke the tokens the application still holds at the provider.
When a Provider Goes Away
A provider can stop serving an application's users in several ways. It withdraws a service or changes its terms, the partnership behind a B2B federation ends, the provider suspends a user's account there, or an outage stops logins for hours. Each time, the users who can only sign in through that provider are locked out of an account the application still holds.
The preparation is the same for all of these. The account belongs to the application under an internal identifier, and a provider's iss and sub are one login method attached to it, never the account's key. Users can add a second method, a passkey being the least burdensome, and the application keeps a verified contact address of its own. Recovery that runs through the missing provider is no recovery, and recovery through email alone is only as strong as the email account. This is also what keeps the choice of providers reversible, since an application whose accounts are keyed on one provider's identifiers cannot drop that provider without losing its users.
Migration has a trap of its own. A subject identifier means something only at the provider that issued it, and a provider using pairwise identifiers derives them from the application's sector identifier, which is the host of its registered redirect URI unless the application registers a sector_identifier_uri. Moving the application to a new host without registering a sector_identifier_uri on the old host gives every existing user a new sub, and the application sees strangers. Moving users from one provider to another means re-linking each of them at their next login, through a verified address or a login method they already have, and the old provider stays configured until the last of them has moved.
Beyond a Handful of Providers
Each supported provider is configured individually: its metadata, its client registration, its claim mapping. That is manageable for a handful and becomes the limiting factor in ecosystems with many participants, where OpenID Federation replaces per-provider configuration with membership resolved from signed statements.
The login is also a single moment. Zero Trust architectures keep evaluating after it, and the Shared Signals Framework carries a provider's signals, such as a revoked session or a compromised account, to the application while the user is still signed in. A provider sends those signals only if it supports them and has agreed to send them to this application, which is something to ask a partner for in the agreement and rarely something a consumer provider will offer. Without them, what the application knows about a user is what it learned at the last login, and the decision of which provider to accept is a decision about what that login is good enough for.