Top identity Interview Questions & Answers

Okta is a cloud identity and access management (IAM) platform. It centralises user authentication, authorisation, and lifecycle across thousands of apps, replacing per-app passwords with single sign-on (SSO), MFA, and automated provisioning/deprovisioning.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.