Okta Certified Administrator · Part I

Identity and Access Management

36% of the exam — the single largest domain.

Identity & Access Management

Module 2: Single Sign-On (SSO) Federation

4 sub-topics · this deck covers sub-topic 1 of 4

The Exam Bullet

"Demonstrate knowledge of how to configure Okta as a service provider"

A company already has a separate identity system somewhere — maybe a social login, maybe another SAML provider, maybe another Okta org entirely. This sub-topic is about Okta acting as the consumer of someone else's authentication, instead of being the one doing the authenticating.

The Mechanism

An Identity Provider (IdP) is a service that manages user accounts. Okta can let users authenticate through an external IdP before they ever touch an Okta-connected app — that's the whole point of federation.

This is what "Okta as a service provider" means: Okta stops being the one verifying the password, and instead configures inbound SAML to accept an assertion from that external IdP.

The Admin Capabilities

As an admin, three things fall under this configuration:

→ Add social logins, letting users self-register through an external account.

→ Configure Okta as SP via inbound SAML.

→ Set up routing rules that direct users to a specific IdP based on context — location, device, or email domain.

The IdP Types

Okta supports federating against several different kinds of identity providers, not just one flavor:

Social login providers · SAML 2.0 identity providers · Smart card authentication · OpenID Connect providers · Other Okta instances

Knowing this list matters — a scenario question describing "users from a partner company sign in with their own Okta org" is still just another IdP type, not a special case.

The Connection — Separation of Concerns

This architecture deliberately separates identity management from application access — a foundational principle in federated SSO.

Routing rules are what make this practical: they add intelligent user direction, improving both security and user experience by contextualizing which IdP a given login attempt should go to.

The Exam Angle

Watch for scenario questions built around these traps:

→ "Users from an acquired company need to sign in with their existing credentials, not new Okta accounts." = configure Okta as SP against their IdP.

→ "Different departments/locations should route to different login systems automatically." = routing rules based on context.

One Line To Remember

Okta as SP = Okta consumes someone else's authentication via inbound SAML, instead of doing the authenticating itself. Supports social, SAML 2.0, smart card, OIDC, and other-Okta-org IdPs. Routing rules send users to the right IdP based on context.

Sources: help.okta.com — Identity_Providers.htm

Next: Sub 2 →