Identity federation
Identity federation lets a service authenticate a user by accepting an assertion from a trusted identity provider rather than directly checking that user's authenticator itself.
One system accepts another system’s assertion
An identity provider authenticates the user and sends an assertion to the relying party, the service that wants to sign the user in. The relying party validates that assertion under its configured trust relationship. Federation protocols such as SAML and OpenID Connect support this exchange.
The relationship must specify which provider is trusted and how the received identity maps to an account. A matching display name or email address is not a substitute for the protocol’s validation and account-matching rules.
Okta’s documentation distinguishes account linking, which associates an external identity with an existing account, from just-in-time provisioning, which can create a new account during sign-in. Neither automatically grants every application permission.
Federation and SSO answer different questions
Federation describes how systems share authentication information. Single sign-on describes the experience of accessing services without separately signing in to each one. Federation can enable SSO, but the terms are not interchangeable: a federated sign-in may still require another authentication step under the applicable policy.
The relying service also has to enforce authorization. Accepting an assertion does not mean allowing every requested action.
Changing a trusted provider or its account-matching rules can therefore change who gets accepted as a user. Treat that configuration as sensitive administrative work. The federation trust-change article explains the review and the separate permissions that apply after sign-in.