SAML service provider and OIDC relying party
Two protocol names for your app when it trusts another system to log users in: service provider in SAML, relying party in OIDC.
What it is
The same app gets a different job title in each SSO protocol. In SAML it is the service provider: it consumes an assertion from the identity provider. In OpenID Connect it is the relying party: it relies on the OpenID Provider's identity claims. In both cases, your app is the trusting side, not the system checking the password.
These names matter when filling out enterprise setup screens and reading specifications. A SAML customer asks for your SP entity ID, metadata, and Assertion Consumer Service URL. An OIDC provider asks for the RP's client ID and registered redirect URI.
The gotcha is treating the labels as interchangeable inside protocol configuration. An ACS URL receives a SAMLResponse POST; an OIDC redirect URI receives an authorization response containing a code. They serve a similar place in the login journey but carry different messages and require different validation.
Ask AI for it
Model this app as both a SAML 2.0 service provider and an OpenID Connect relying party behind one enterprise connection interface. For SAML, publish metadata with an entityID and Assertion Consumer Service URL, validate signed assertions with @node-saml/node-saml, and key users from the configured NameID or attribute mapping. For OIDC, use the openid-client package with discovery from `/.well-known/openid-configuration`, register an exact redirect URI, run Authorization Code with PKCE, and validate the ID token's `iss`, `aud`, `exp`, `nonce`, and signature against JWKS. Normalize both callbacks into one internal result containing tenant ID, issuer, provider subject, email verification state, and mapped profile fields before creating the local session.