Common interview slip
Many candidates confuse SAML and OIDC, or assume 'MFA is just a second password prompt'. Both slips lose marks in an Okta interview.
SAML 2.0 is an XML-based federation protocol used for SSO to legacy enterprise apps — Okta sends a signed assertion containing user attributes to the Service Provider's ACS URL. OIDC is a modern JSON/JWT identity layer on top of OAuth 2.0 — the app gets an ID token (who you are) and an access token (what you can do). Use SAML for legacy SaaS and on-prem apps; use OIDC for mobile apps, SPAs, and APIs. And Adaptive MFA is not a static second factor — it evaluates device trust, network zone, geo-location risk signals, and ThreatInsight scores to decide dynamically whether step-up authentication is needed, meaning low-risk users on trusted devices may skip the prompt entirely. These distinctions are exactly what Okta interviewers probe.
① Architecture & Universal Directory — the identity store and multi-source model
Q: What is Okta Universal Directory and why does it matter for enterprise identity?
Model answer: Okta Universal Directory (UD) is the central identity store that underpins the entire Okta platform. It consolidates users from Active Directory (via Okta AD Agent), LDAP, HR systems like Workday or BambooHR, and a built-in Okta cloud directory — all in one place. The key selling point for an interview: UD supports unlimited custom user attributes (string, number, boolean, array) at the profile level, which lets you model any org's identity schema without schema rigidity. In 2026, Okta extended UD to support non-human identities — service accounts and AI agents can be registered with defined ownership and lifecycle controls, an emerging topic interviewers are starting to probe.
Q: What are Okta sources and how does profile mastering (profile mapping) work?
Model answer: A source is any upstream identity system connected to Okta — Active Directory, LDAP, a SCIM-enabled HR app, or a custom app using Anything-as-a-Source (XaaS). XaaS is Okta's 2024+ capability that lets you connect any custom HR database or application as a canonical identity source, not just the pre-built connectors. Profile mastering (now called Profile Sourcing in Okta Identity Engine) defines which source owns which attribute. If AD is the master for displayName and Workday owns department, Okta merges them on the Universal Directory profile using profile mapping rules — attribute expressions that can transform, concatenate, or default values. The interview point: attribute mastering prevents conflicts, and expressions like String.toUpperCase(source.firstName) are valid transformations in the mapper.
Q: How does the Okta AD Agent work, and what is its role in a hybrid identity deployment?
Model answer: The Okta AD Agent is a lightweight, outbound-only Windows service installed in the domain. It establishes an outbound HTTPS connection to Okta (no inbound firewall ports needed) and handles AD import (syncing users and groups into UD), delegated authentication (Okta passes the credential to AD on a Just-In-Time basis so AD remains the password authority), and password sync (hashing changes back to AD or from AD to Okta). In a hybrid deployment this is critical: AD stays the authoritative source, Okta brokers the cloud SSO, and the agent is the bridge — all traffic flows outbound from the domain, which satisfies most enterprise security teams.
When asked about Universal Directory, say it clearly: 'UD aggregates identities from AD, HR systems, LDAP, and custom apps via Anything-as-a-Source. Profile mapping rules define which source is the master for each attribute — AD owns displayName, Workday owns department — and transformations are written in Okta Expression Language.' That answer shows you understand both the architecture and the attribute governance.
Which Okta capability allows a custom HR database to be used as a canonical identity source for Universal Directory?
② SSO, MFA & adaptive policies — SAML vs OIDC and step-up authentication
Q: Compare SAML 2.0 SP-initiated vs IdP-initiated SSO in Okta, and contrast SAML with OIDC.
Model answer: In SP-initiated SSO, the user hits the app's URL first; the app (Service Provider) redirects to Okta with an AuthnRequest, Okta authenticates the user, then posts a signed SAML Assertion (XML, containing the NameID and attribute statements) to the app's Assertion Consumer Service (ACS) URL. In IdP-initiated SSO, the user starts at the Okta dashboard, clicks an app tile, and Okta posts the assertion directly — there is no AuthnRequest, so the app must trust unsolicited responses. SAML vs OIDC: SAML uses XML and is the standard for legacy enterprise SaaS and on-prem apps. OIDC is the modern alternative — a JSON/JWT-based identity layer on OAuth 2.0. The app gets an ID token (who the user is) and an access token (what the user can do with APIs). Use SAML for older SaaS and on-prem web apps; use OIDC for SPAs, mobile apps, and APIs.
Q: How does Okta Adaptive MFA and the sign-on policy decide whether to challenge a user?
Model answer: An Okta Sign-On Policy is a set of rules evaluated top-down, first-match per app or org. Each rule targets a group, network zone, device state, and authenticator. Adaptive MFA brings in contextual signals: network zone (is the IP in a trusted corporate range or an anonymising proxy?), device trust (is the endpoint managed/enrolled in Okta Device Trust or MDM?), geo-velocity / geo-location (impossible-travel detection), and ThreatInsight risk score (Okta's IP reputation service that flags credential-stuffing and suspicious login patterns). A rule can say: 'if user is in the Contractors group AND not on a trusted network AND device is not managed → require Okta Verify push AND set session to 4 hours.' Low-risk trusted users skip the extra prompt entirely. The interview gold line: Adaptive MFA = context-aware sign-on policy rules that step up or skip factors based on network, device, geo, and risk signals — not a static second factor.
Q: What is Okta Verify and how does it compare to FIDO2/WebAuthn as phishing-resistant MFA?
Model answer: Okta Verify is Okta's first-party authenticator app (iOS/Android/macOS/Windows) that supports TOTP (time-based one-time passwords) and Okta FastPass — a device-bound, passwordless push notification backed by a cryptographic key on the device. FastPass provides phishing resistance because the private key never leaves the device and the challenge is bound to the origin. FIDO2/WebAuthn is the FIDO Alliance open standard for hardware-bound authenticators (YubiKey, Windows Hello, Apple Touch/Face ID as a platform authenticator). FIDO2 is the gold standard for phishing resistance because the credential is origin-bound — a phishing proxy cannot replay it. In Okta Identity Engine, both Okta FastPass and FIDO2 are configured as phishing-resistant authenticators in the authenticator enrollment policy. The interview distinction: Okta FastPass = Okta's managed phishing-resistant push, FIDO2/WebAuthn = open-standard hardware/platform key.
Okta's central cloud identity store — aggregates AD, HR systems, LDAP, and custom apps (XaaS) into one profile with unlimited attributes. Profile mapping rules define which source owns each attribute.
SAML 2.0 = XML assertion posted to the ACS URL; used for legacy SaaS and on-prem. OIDC = JWT ID token + access token on OAuth 2.0; used for SPAs, mobile, and APIs. Know both flows cold.
Sign-on policy rules evaluate network zone, device trust, geo-location, and ThreatInsight risk score. High-risk or unmanaged contexts trigger step-up; trusted managed devices may skip the prompt entirely.
Okta Workflows = async no-code automation canvas triggered by events (Joiner-Mover-Leaver). Inline Hooks = synchronous HTTP callouts during an Okta process that can modify or block token issuance, registration, or import.
Treating MFA as a static second factor misses Okta's Adaptive MFA model. The correct framing: sign-on policy rules evaluate network zone, device trust, geo-location, and ThreatInsight risk in real time. A trusted managed device on the corporate network might skip MFA entirely; a contractor on an anonymous proxy must pass Okta Verify push. Static MFA is a UX tax; Adaptive MFA is context-aware.
In Okta Adaptive MFA, a sign-on policy rule checks that a device is 'managed'. What does 'managed' mean in this context?
③ Lifecycle, Workflows & API access — provisioning, automation and Hooks
Q: What is Okta Lifecycle Management and how does SCIM provisioning work?
Model answer: Okta Lifecycle Management automates account provisioning and deprovisioning across connected apps as employees join, move, or leave — the classic Joiner-Mover-Leaver model. When a user is created in AD or an HR system and synced to Okta, provisioning rules push account creation to downstream apps (Salesforce, Google Workspace, Slack) automatically. SCIM (System for Cross-domain Identity Management) is the REST+JSON standard protocol Okta uses for this — the app exposes a SCIM 2.0 endpoint, and Okta calls POST /Users to create, PATCH /Users/{id} to update attributes or activate/deactivate, and DELETE /Users/{id} or a deactivate PATCH to deprovision. The lifecycle actions in Okta are: Create user, Update user attributes, Deactivate user account, Reactivate, Sync password (where supported). The interview point: SCIM is the protocol; Lifecycle Management is the Okta feature; Joiner-Mover-Leaver is the business process they implement together.
Q: What are Okta Workflows and how do they differ from Inline Hooks?
Model answer: Okta Workflows is a no-code / low-code automation canvas built into the Okta admin console. You build flows triggered by Okta events (user created, group membership changed, app assigned) and connect pre-built action cards for Okta, Slack, ServiceNow, Jira, Microsoft 365, Salesforce, and more — including custom HTTP calls. Workflows are asynchronous: an Okta event fires, the workflow runs in the background; it does not block the Okta flow. Inline Hooks are the opposite: they are synchronous HTTP callouts that Okta makes to your external service during an Okta process — for example a Token Inline Hook fires just before Okta issues an OAuth 2.0 token, allowing your service to add custom claims or deny issuance. Other types include Registration Inline Hook (validate a self-service registration), User Import Inline Hook (transform or reject an imported user), and SAML Assertion Inline Hook. The clean split: Workflows = async background automation (no-code); Inline Hooks = sync external decisions that can modify or block an in-flight Okta process.
Q: How would you automate full offboarding of a departing employee in Okta in near real time?
Model answer: Near-real-time offboarding uses Okta Workflows + Lifecycle Management together. Trigger: an event in the HR system (Workday, BambooHR) fires when an employee's end date arrives — either Okta imports the deactivation flag on the next scheduled sync, or an Okta Workflow subscribes to a Workday webhook for immediate notification. The Workflow then: (1) deactivates the Okta user (suspends sign-in), (2) clears all active sessions (revokes tokens), (3) deprovisions downstream apps via SCIM deactivate calls, (4) removes group memberships (which in turn pulls app access for group-assigned apps), (5) optionally transfers OneDrive or Google Drive ownership via a connector card. For an employer who also wants a Slack message to IT when this completes, add a Slack action card. The key for interviewers: don't rely on the nightly import for offboarding — use Workflows event subscription or a Webhook to the HR system to act within minutes, and show you understand that deactivating the Okta account is the chokepoint because all app sessions flow through Okta.
Confirm you know the difference: Okta Workflows is asynchronous (event triggers a background automation, cannot block or modify an in-flight Okta process). Inline Hooks are synchronous (Okta calls your endpoint and waits for a response before continuing). Token Inline Hook = sync, can add claims. Workflows = async, cannot alter the token. Getting this backwards in an interview is a red flag.
▶ Watch an OIDC login reach an API — and find why a token claim is missing
Step through how a user authenticates via Okta OIDC, receives an access token, and calls a protected API. Press Play for the healthy path, then Break it to see the classic 'missing scope on Custom Auth Server' mistake.
You want to add custom claims to an access token in real time — for example, enriching it with a user's entitlements from an external database just before the token is issued. Which Okta feature do you use?
④ Security & scenarios — API AuthZ, ThreatInsight and break-glass
Q: Explain Okta API Access Management — Custom Authorization Server vs Org Authorization Server, scopes and claims.
Model answer: Okta API Access Management makes Okta an OAuth 2.0 Authorization Server that issues access tokens for your own APIs, not just for app SSO. Okta ships two types: the Org Authorization Server (the built-in one at /oauth2/v1/) which is limited to Okta's own API scopes and cannot be customised, and Custom Authorization Servers (at /oauth2/{authServerId}/) which you define — including custom scopes (what access is requested), custom claims (attributes embedded in the token), and access policies (which clients and users can request which scopes). A claim is a key-value pair in the JWT — you can add dynamic claims using Okta's Expression Language (e.g. user.department, appuser.role). For a microservices architecture, each service validates the JWT's signature (using Okta's JWKS endpoint) and checks the scope/claim. The interview summary: Custom Auth Server = your own OAuth 2.0 AS with custom scopes, claims, and policy; Org AS = built-in, Okta APIs only, no customisation.
Q: What is ThreatInsight and how does it protect an Okta tenant?
Model answer: Okta ThreatInsight is a network-layer threat intelligence service baked into every Okta tenant. It aggregates login behaviour signals across the entire Okta customer network — IP reputation, credential-stuffing patterns, bot signatures — and assigns a risk level (None / Low / Medium / High) to each authentication event in real time. You configure ThreatInsight to either log only (passive) or block and log (active) — in block mode, high-risk IPs attempting authentication are dropped before they even reach a password check, thwarting large-scale credential-stuffing campaigns. ThreatInsight works alongside Network Zones (IP allowlists/blocklists) and Adaptive MFA sign-on policies that can step up authentication when a medium-risk signal is present. The 2026 framing: ThreatInsight is Okta's built-in crowd-sourced IP reputation layer — it does not require a separate purchase and should always be enabled in active mode for production tenants.
Q: A senior engineer asks: how would you design a break-glass (emergency admin) account strategy for an Okta org?
Model answer: This is a classic security architecture question. The answer has four pillars. 1. Dedicated break-glass accounts — create two Super Admin accounts NOT linked to real employees, using generic names like breakglass1@yourdomain.com. They must not be sourced from AD or any directory (so a directory outage doesn't affect them) and must never be used day-to-day. 2. Phishing-resistant MFA only — enroll FIDO2 hardware security keys (YubiKeys) on these accounts; print and vault the recovery codes. Do NOT use SMS or email as MFA factors on break-glass accounts. 3. Credential vaulting and split custody — store the password in a PAM tool or physical safe, with split custody between two executives; rotate the password quarterly. 4. Monitoring and alerting — configure a System Log alert (via Okta Workflows or a SIEM integration) that fires within minutes any time a break-glass account logs in, sends a Slack message and an email to the security team, and opens a ServiceNow ticket. Interviewers want you to name all four pillars: dedicated non-AD accounts, hardware MFA, vaulted split-custody credentials, and real-time alerting on any use.
Priya at FinServe India in Bengaluru faces this
FinServe India just went live on Okta. A week after launch, the security team sees hundreds of failed logins from Eastern European IP ranges — a classic credential-stuffing pattern. Simultaneously, a departing VP's access was not revoked until three days after their last day because the HR system sync runs only nightly. Priya is the IAM Engineer and must fix both gaps before the next board review.
ThreatInsight was left in log-only mode (not block mode) during the initial rollout, so suspicious IPs are logged but not blocked. Offboarding relied on the scheduled AD sync rather than an event-driven Workflow, creating a multi-day access window.
In Okta System Log, filter event type user.session.start with outcome FAILURE grouped by client.ipAddress — hundreds of attempts from a narrow IP range in minutes, confirming credential stuffing. The VP's account shows it was active for 72 hours post-departure because the nightly sync ran once and the next run was the following evening.
1. Switch ThreatInsight to Block and Log immediately — high-risk IPs are now dropped at the network layer. 2. Build an Okta Workflow that subscribes to the Workday termination webhook: on trigger, deactivate the Okta user, clear all sessions (revoke tokens), remove group memberships, and send a Slack alert to IT. 3. Set the Lifecycle Management import to run every 15 minutes as a belt-and-suspenders fallback.
System Log now shows blocked credential-stuffing attempts with event type security.threat.detected. Test the offboarding Workflow with a dummy user: deactivation, session revocation, app deprovisioning, and the Slack alert all complete within 2 minutes of the HR event.
An Okta tenant is experiencing a large-scale credential-stuffing attack from rotating IP addresses. What is the first built-in Okta control to enable to block these at the network layer before authentication?
🤖 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: what is the difference between Okta Workflows and an Inline Hook? 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
- Universal Directory (UD)
- Okta's central cloud identity store that aggregates users from Active Directory, HR systems, LDAP, and custom apps (via XaaS) into one profile with unlimited custom attributes.
- Profile Mastering / Sourcing
- The Okta mechanism that assigns each attribute to one upstream source (owner). Profile mapping rules written in Expression Language transform and merge attribute values into the Universal Directory profile.
- SAML 2.0 / ACS URL
- XML-based federation protocol for SSO. Okta (IdP) sends a signed SAML Assertion to the app's Assertion Consumer Service (ACS) URL. Supports SP-initiated and IdP-initiated flows.
- OIDC / OAuth 2.0
- OpenID Connect is the modern identity layer on OAuth 2.0. Okta issues a JWT ID token (who the user is) and an access token (what APIs they can call) via the authorization code + PKCE flow.
- Adaptive MFA
- Okta sign-on policy rules that evaluate network zone, device trust, geo-location, and ThreatInsight risk score to decide whether to step up authentication or allow access with fewer factors.
- SCIM 2.0
- System for Cross-domain Identity Management — the REST+JSON protocol Okta uses to provision (POST), update (PATCH), and deprovision (DELETE or PATCH deactivate) users in connected apps.
- Okta Workflows
- Okta's no-code async automation canvas. Event-triggered flows connect Okta actions with pre-built cards for Slack, ServiceNow, Salesforce, M365, and custom HTTP. Used for Joiner-Mover-Leaver automation.
- Inline Hook
- A synchronous HTTP callout Okta makes during a process (token issuance, registration, import) and waits for a response before continuing. Can add claims, reject users, or transform import data.
- Custom Authorization Server
- An Okta OAuth 2.0 Authorization Server (at /oauth2/{id}/) where you define custom scopes, claims, and access policies for your own APIs. Distinct from the built-in Org Authorization Server.
- ThreatInsight
- Okta's built-in cross-tenant IP reputation and bot-detection service. In block-and-log mode it drops authentication attempts from high-risk IPs before they reach the credential check.
📚 Sources
- Okta — Universal Directory: unlimited attributes, profile mastering, and Anything-as-a-Source (XaaS). okta.com/products/universal-directory
- Okta Developer — SAML 2.0 SP-initiated and IdP-initiated SSO, ACS URL, and assertion signing. developer.okta.com/docs/concepts/saml
- Okta Developer — OIDC and OAuth 2.0 authorization code flow with PKCE, ID token, access token, and Custom Authorization Servers. developer.okta.com/docs/concepts/oauth-openid
- Okta — Adaptive MFA and sign-on policy: network zones, device trust, ThreatInsight risk signals. help.okta.com/en-us/content/topics/security/mfa/mfa-home.htm
- Okta Developer — Okta Workflows, Inline Hooks, and Lifecycle Management SCIM provisioning. developer.okta.com/docs/concepts/inline-hooks
- Okta Developer — Identity Engine API release notes 2026: non-human identities, API Access Management, and ThreatInsight. developer.okta.com/docs/release-notes/2026-okta-identity-engine
What's next?
Done with the interview prep? Go deeper on Okta design — Okta Identity Engine, SAML vs OIDC federation, advanced Workflows automation, API Access Management, and securing your Okta tenant with ThreatInsight and device trust.