Question 1

What is Okta and what problem does it solve?

Accepted Answer

Okta is a SaaS identity and access management (IAM) platform. It acts as the identity provider (IdP) for SSO across SaaS apps, enforces MFA in one place, automates joiner/mover/leaver lifecycle, and issues OAuth tokens for APIs.

Question 2

Differentiate SSO, MFA, and provisioning.

Accepted Answer

SSO lets a user log in once and access multiple apps without re-entering credentials. MFA requires two or more factors at authentication. Provisioning automatically creates / updates / deactivates app accounts based on HR or directory state.

Question 3

Explain the difference between SSO and federation.

Accepted Answer

SSO is the user experience — authenticate once, access multiple apps. Federation is the technical mechanism — apps trust tokens issued by a central IdP. Okta achieves SSO via federation (SAML 2.0 or OIDC).

Question 4

What is the difference between SAML and OIDC?

Accepted Answer

Both are federation protocols. SAML 2.0 uses XML assertions (common in enterprise apps). OIDC is a thin identity layer on top of OAuth 2.0 using JSON Web Tokens (common in modern cloud and mobile apps). Choose OIDC for new builds when both are supported.

Question 5

What is an Okta org?

Accepted Answer

An Okta org is your tenant — a unique URL like https://yourcompany.okta.com. All users, groups, apps, and policies live inside it. Each company has one production org (plus dev/stage).

Question 6

What is an Okta Org?

Accepted Answer

An Org is an Okta tenant — an isolated instance with its own admin console, user directory, and apps. Each org has a unique URL and its own API token set.

Question 7

How does Okta handle MFA?

Accepted Answer

Okta supports multiple factor types: password, SMS, voice, email, Okta Verify (push/TOTP), WebAuthn/FIDO2, and custom OIDC IdPs. Authentication policies enforce which factor(s) a user must complete. Adaptive MFA adds risk-based escalation.

Question 8

How do Group Rules differ from manual group assignments?

Accepted Answer

Manual assignments are static — an admin clicks a user into a group. Group Rules are dynamic — membership is computed from user attributes and re-evaluated whenever the user is created or updated. This makes access decisions repeatable and auditable.Example rule: users.department == "Sales" → assign to group Sales-Users.Rules cascade: re-evaluating a user can move them out of groups they no longer qualify for.Order of rules matters when membership conditions overlap.

Question 9

What is a SAML assertion?

Accepted Answer

A signed XML document the IdP (Okta) sends to the SP (app) at SSO time. It contains the user identity and any attributes the SP needs (email, groups, custom claims). The SP validates the signature and trusts the identity.

Question 10

Explain the role of an Authorisation Server in Okta.

Accepted Answer

An Authorisation Server is a token-issuing endpoint in Okta used for OAuth 2.0 / OIDC flows. Each custom authorisation server has its own issuer URL, scopes, claims, and access policies. You typically create one per environment and one per trust boundary.

Question 11

What is the difference between authentication and authorisation policies?

Accepted Answer

Authentication policies decide HOW a user proves identity (factors, sequencing, session). Authorisation policies decide WHETHER the user can attempt auth at all (e.g. only corporate network may attempt prod AWS console).

Question 12

How does Okta handle user deprovisioning?

Accepted Answer

When a user is deactivated in Okta, Okta pushes a deactivation event to every app that has LCM enabled. SCIM apps receive a PATCH /Users with active: false. For SAML-only apps, the user is removed from group assignments so they no longer satisfy the SAML assertion conditions.

Question 13

How do you automate joiner/mover/leaver flows?

Accepted Answer

Use HR (Workday, BambooHR) as the source of truth. Sync to Okta via the HR integration. Define group rules and app assignment rules in Okta. Lifecycle events trigger automatically on profile change.

Question 14

What is the difference between SWA, SAML, and OIDC apps in Okta?

Accepted Answer

SWA — Okta stores the password and replays it. No federation, fragile.
SAML 2.0 — Federated SSO using XML assertions; app trusts Okta as the IdP.
OIDC — Federated SSO via OAuth 2.0 + JWT ID tokens; app trusts Okta as the OP.

Question 15

Explain SCIM provisioning.

Accepted Answer

SCIM is a standard for pushing user/group create/update/delete operations from an IdP to apps. Okta acts as the SCIM client. The app implements the SCIM /Users and /Groups endpoints. Eliminates manual provisioning.

Question 16

Design a high-assurance authentication policy for an admin console.

Accepted Answer

Combine three Okta constructs:Authentication policy scoped to admins only: require WebAuthn (FIDO2) as the only allowed factor.Session policy: 1h idle timeout, 4h max, no persistent session.Behavioural risk: if risk = high, require re-authentication with a second factor even within the session.Authorisation policy: only allow sign-in from the corporate IP range or a managed device.This is roughly what SOC2 Type II and FedRAMP Moderate environments expect from an admin console.

Question 17

What is the Okta System Log?

Accepted Answer

The System Log records every admin action, user event, and authentication attempt. Stream it to your SIEM (Splunk, Sentinel, Sumo Logic) for real-time correlation. Also use it for incident investigation.

Question 18

How would you implement just-in-time (JIT) provisioning with Okta?

Accepted Answer

JIT provisioning creates a user account in the target app the first time they successfully authenticate via SSO. Steps:Configure the SAML/OIDC app to send the required attributes in the assertion / ID token.In the target app, enable JIT and map the IdP claims to local user attributes.Set Okta group rules so the right users are routed to the app on first login.Define an audit event for first-time JIT creations so you can verify the policy.

Question 19

How does adaptive MFA work?

Accepted Answer

Behavioural signals (impossible travel, new device, unfamiliar IP, unusual hours) trigger step-up authentication. Pair with phishing-resistant factors for the strongest protection. Configure in Authentication Policies.

Question 20

How do you perform zero-downtime migration from a legacy IdP to Okta?

Accepted Answer

Run a parallel IdP strategy in three waves:Wave 1 (coexistence): Add Okta as a secondary IdP. Existing IdP remains primary.Wave 2 (gradual cutover): Migrate one app at a time. For SAML apps, point SP metadata at Okta. For OIDC apps, swap the issuer URL.Wave 3 (decommission): Freeze new logins on the legacy IdP, drain sessions, then shut it down.Plan for users with active sessions in both IdPs during the transition. Use short session lifetimes on the legacy IdP to accelerate the drain.

Question 21

What is an authorisation server?

Accepted Answer

A custom OAuth 2.0 token-issuing endpoint you create in Okta for API access management. Each server has its own policy, scopes, and access token lifetime. Apps use the access token to call your APIs.

Question 22

Explain how Okta Workflows differ from Okta Hooks.

Accepted Answer

Workflows is a no-code / low-code orchestration engine for asynchronous multi-step processes. Hooks are synchronous callbacks fired at protocol-level points that can transform or block the request. Use Hooks when the decision affects the auth flow itself; use Workflows for after-the-fact automation.

Question 23

What is a token hook?

Accepted Answer

An Okta Hook that Okta calls at token issuance. Your endpoint enriches the token with custom claims before Okta returns it. Common uses: dynamic scope narrowing, risk signal injection, compliance attributes.

Question 24

What is Okta Hooks and when would you use one?

Accepted Answer

Hooks are HTTPS endpoints you register with Okta that Okta calls at lifecycle moments (inline token hook, registration hook, password import hook, etc.). Use them to customise token claims, sync to external systems on user creation, or enforce custom password policies. They are an extensibility layer above Okta's built-in features.

Question 25

Explain the difference between authentication and authorisation policies in OIE.

Accepted Answer

Authentication policies decide HOW a user proves identity (factors, factor sequencing, session timing). Authorisation policies decide WHETHER a user can attempt authentication at all (e.g. only corporate-network users can attempt the prod AWS console). OIE combines both via access policies for end-to-end policy control.

Question 26

What is the Okta Workflows no-code platform used for?

Accepted Answer

Workflows is Okta's no-code / low-code automation platform. Connect Okta lifecycle events to SaaS apps (Slack, Jira, ServiceNow) without writing integration code. Common uses: auto-provision to SaaS, deprovision on offboarding, ticket creation on access requests, custom notifications.

Question 27

How does SCIM provisioning work with Okta?

Accepted Answer

Okta acts as the SCIM client. For each connected app, Okta pushes user/group create/update/delete operations via SCIM HTTP calls. The app implements the SCIM /Users and /Groups endpoints. This is the foundation of automated joiner/mover/leaver flows.

Question 28

What is profile sourcing in Okta?

Accepted Answer

Profile sourcing defines where user attributes come from. The most common source is HR (Workday, BambooHR, ADP) — attributes flow into Okta profile, then into downstream apps via profile mappings. Just-in-time provisioning can create users on first login when no upstream source is configured.

Question 29

How would you secure the Okta admin console?

Accepted Answer

Require phishing-resistant MFA (WebAuthn) for all org admins. Use Admin Session policies with strict timeouts. Enable attack protection features (brute force lockout, suspicious IP blocklist, anonymised network). Stream System Log to SIEM. Bind admin roles to specific IP ranges where possible.

Question 30

What is the Okta System Log used for?

Accepted Answer

The System Log records every admin action, user event, and authentication attempt. Stream it to your SIEM (Splunk, Sentinel, Sumo Logic) for correlation with other security signals. Also use it for incident investigation — "who did what, when, from where".