Most engineers think…
Most people picture Okta as 'a login box' or 'a password manager'. That mental model falls apart the moment an interviewer asks you to draw the SSO flow.
Okta is a cloud identity provider (IdP): a per-customer org (tenant) that holds Universal Directory — the single source of truth for users, groups and devices, sourced and mastered from AD, LDAP and HR. It connects to apps through the Okta Integration Network (OIN) and, for each login, speaks a standard SSO protocol — SAML 2.0 or OIDC — to vouch for the user so the app never sees the password. Understanding that split — directory, org, app connections, and the redirect/assertion flow — is what lets you design SSO and answer the interview cleanly.
① What Okta actually is — the cloud identity provider
The single most important idea: Okta is one cloud identity provider (IdP) that sits between your people and every app. The app trusts Okta to answer one question — who is this user, and have they signed in? — so the app itself never stores or sees the password.
Every customer gets an org, which is Okta's word for a tenant. Your org has its own URL (your subdomain, e.g. acme.okta.com) and holds everything: the directory, the policies and the app connections. Around that org sit three things you must be able to name — the Universal Directory (who your users are), the Okta Integration Network (which apps you connect to), and the SSO protocols (SAML and OIDC) that carry the proof of identity to each app.
In an Okta SSO login, which statement is correct?
② Universal Directory and the org — the single source of truth
The Universal Directory (UD) is the centralized data layer of the whole platform: the single source of truth for users, groups and devices. Each user is a profile made of attributes you can customize, map and transform with expressions.
Where profiles come from
You rarely type users in by hand. UD sources and masters profiles from your systems of record — Active Directory, LDAP, and HR apps like Workday — and keeps them in sync, so one cloud directory mirrors many sources. The org is the tenant boundary around all of this: one private container, one URL, one set of policies. Larger or customer-facing estates may run a multi-tenant design with several orgs, but the default is one org per company.
Okta is the IdP — it authenticates the user and vouches for them to apps. The app (SP) trusts Okta and never sees the password.
The single source of truth for users, groups and devices. Profiles are sourced and mastered from AD, LDAP and HR, then kept in sync.
Your private container of all identity data with its own URL (subdomain). One org per company by default; multi-org for larger or CIAM estates.
A lightweight on-prem agent with an outbound-only HTTPS link to Okta. It imports users and does delegated auth — no inbound firewall ports.
In an interview, keep two layers distinct: Universal Directory answers 'who are the users and where do they come from' (AD/LDAP/HR), while SAML/OIDC answer 'how do we prove that user to an app'. Mixing them up is the most common stumble.
What is the single source of truth for users, groups and devices in Okta?
③ Connecting apps — the OIN and the directory agents
Okta connects to apps through the Okta Integration Network (OIN) — a catalog of 7,000+ pre-built app integrations. Instead of wiring each app by hand, you pick it from the OIN and Okta sets up SSO with the right protocol (SAML, OIDC or the older password-replay SWA). This is the 'hub' that makes one login reach every app.
Bridging on-prem directories
To pull users out of on-prem AD or LDAP, Okta uses a lightweight agent you install behind your firewall. It makes only an outbound HTTPS connection to Okta — so you never open inbound ports. The agent does two jobs: import users and groups into UD, and delegated authentication, where Okta forwards the password check to your AD/LDAP so credentials stay on-prem. The interview line: OIN connects apps; the AD/LDAP agent connects your old directory — both without exposing your network.
A password manager stores secrets and replays them. Okta is an IdP: it authenticates the user once and issues a signed SAML assertion or OIDC ID token so the app trusts Okta directly. Always answer with IdP-to-SP trust, not password replay.
You must import on-prem AD users into Okta without opening inbound firewall ports. What do you use?
④ How SSO actually works — SAML vs OIDC, redirect and assertion
In SSO, Okta is the identity provider (IdP) and the app is the service provider (SP). The browser does all the carrying — the SP never talks to Okta directly. In an SP-initiated SAML flow: the user hits the app, the app redirects the browser to Okta with a SAML request, the user authenticates at Okta, and Okta posts a signed SAML assertion back to the app's ACS URL. The app validates the signature and creates a session. In IdP-initiated, the user starts from the Okta dashboard and Okta posts the assertion straight to the SP — no SP request first.
SAML vs OIDC
SAML 2.0 carries an XML assertion and is the classic web-app SSO standard. OIDC is built on OAuth 2.0 and carries a JSON ID token (who the user is) alongside an access token (what they may call). Rule of thumb: SAML for traditional web apps, OIDC for modern web, mobile and API-driven apps. Remember the split — OIDC/OAuth2 do authentication vs authorization; SAML bundles authentication into one signed assertion.
Priya, an IT admin at a Pune SaaS firm, faces this
She connects a new vendor app to Okta over SAML, but every sign-in fails with an 'invalid SAML response' error at the app.
The app's ACS URL and the signing certificate on the Okta side don't match what the app expects — and the audience (entity ID) is wrong.
Open the Okta app's Sign On settings and the app's SAML config side by side — the ACS URL, audience URI and the IdP signing certificate must agree on both ends.
Okta Admin ▸ Applications ▸ (app) ▸ Sign On ▸ SAML settingsSet the correct ACS (Single Sign-On) URL and audience URI, upload Okta's current IdP signing certificate into the app, then re-test the SP-initiated flow.
Re-test: the browser redirects to Okta, the user authenticates, the signed assertion posts to the ACS and the app creates a session — login succeeds.
Never close an SSO ticket on 'should work'. Capture the SAML response (or decode the ID token) and check the audience, the ACS URL and that the signature validates against Okta's certificate. That single read answers most SSO failures.
▶ Watch one user single-sign-on into Salesforce via Okta
How an SP-initiated SAML login is brokered end-to-end. Press Play for the healthy path, then Break it to see the classic failure.
In an SP-initiated SAML flow, where does Okta send the signed assertion?
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why is Okta called an 'identity provider' rather than a 'password manager'? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Identity provider (IdP)
- The system that authenticates the user and vouches for them to apps. Okta is the IdP; the app trusts it and never sees the password.
- Service provider (SP)
- The application the user wants to reach. It trusts the IdP's signed assertion or token instead of checking the password itself.
- Universal Directory (UD)
- Okta's centralized data layer — the single source of truth for users, groups and devices, sourced and mastered from AD, LDAP and HR.
- Org (tenant)
- A private per-customer container of all identity data with its own unique URL (subdomain). One org per company by default.
- Okta Integration Network (OIN)
- A catalog of 7,000+ pre-built app integrations that connect apps to Okta using SAML, OIDC or SWA.
- AD / LDAP agent
- A lightweight on-prem agent with an outbound-only HTTPS link to Okta that imports users and runs delegated authentication — no inbound firewall ports.
- SAML 2.0
- An XML-based SSO standard where the IdP posts a signed assertion to the app's ACS URL; classic for traditional web apps.
- OIDC / OAuth 2.0
- OAuth 2.0 handles authorization (access token); OIDC adds authentication (a JSON ID token). Best for modern web, mobile and API apps.
- ACS (Assertion Consumer Service)
- The app endpoint where Okta posts the SAML response; the app validates it against Okta's signing certificate.
- SP-initiated vs IdP-initiated
- SP-initiated starts at the app (it redirects to Okta); IdP-initiated starts at the Okta dashboard (Okta posts the assertion to the app).
📚 Sources
- Okta Developer — Understanding SAML (SP-initiated vs IdP-initiated, the ACS and the assertion). developer.okta.com/docs/concepts/saml/
- Okta Developer — OAuth 2.0 and OpenID Connect overview (ID token vs access token, OIDC for SSO). developer.okta.com/docs/concepts/oauth-openid/
- Okta — Centralize identity management with Universal Directory (profiles, sourcing from AD/LDAP/HR). okta.com/products/universal-directory/
- Okta — Okta Integration Network: 7,000+ pre-built app integrations (SAML/OIDC/SWA). okta.com/solutions/okta-integration-network/
- Okta — Okta Directory Integration: an architecture overview (AD agent, outbound HTTPS, delegated auth, import). okta.com/resources/whitepaper/ad-architecture/
- Okta Developer — Multi-tenant solutions and the org model. developer.okta.com/docs/concepts/multi-tenancy/
What's next?
Got the architecture and SSO flow? Next, go deep on the policy layer that decides whether a login is allowed at all — MFA and adaptive, risk-based access policies — and separately on lifecycle management, SCIM provisioning and API Access Management.