Which protocol does Okta use to create and deactivate accounts in downstream apps?

Correct: b. SCIM 2.0 is the JSON-over-REST standard Okta uses as a client to provision (create/update) and deprovision (deactivate) accounts in OIN apps. SAML is for SSO; LDAP and RADIUS are different protocols.

In the lifecycle flow, what role does an HR system like Workday usually play?

Correct: a. HR is typically the profile master: it records hires, moves and exits, and Okta sources the user profile from it. That single source of truth is what makes automated provisioning and deprovisioning reliable.

You must auto-assign apps to users based on their department attribute. Which Okta feature do you use?

Correct: c. Group rules are attribute-based if-this-then-that rules (e.g. department = Sales → Sales group) that auto-assign the apps tied to that group. Authorization servers and inline hooks are API Access Management features, not app assignment.

Why is it risky to combine built-in SCIM provisioning and Okta Workflows provisioning on the same app in one flow?

Correct: c. Okta documents that if out-of-the-box provisioning and Workflows provisioning act on the same app in the same flow, the actions can conflict (e.g. one creates while the other deactivates). Pick one path per app and use the other for the steps it can't do.

An interviewer asks the single biggest security reason to automate the leaver process. Best answer?

Correct: b. Manual, app-by-app offboarding misses accounts; an active account after someone leaves is a classic breach path. Automated deprovisioning cuts access everywhere the moment HR marks termination — and reclaims licences as a bonus.

For protecting your own API with API Access Management, what is the strongest reason to use a custom authorization server with scopes?

Correct: c. A custom authorization server lets you define granular scopes and issue short-lived access tokens, so a client gets only the permission it needs and a leaked token is narrow and expires fast — far safer than shared keys or broad, long-lived credentials.

Okta Lifecycle Management & SCIM Provisioning — Joiner-Mover-Leaver, Workflows & API Access (2026)

Q: Why is automated deprovisioning the security headline of lifecycle management?

Correct: c. When someone leaves, an active account they still control (or that nobody remembers) is a breach waiting to happen. Automated deprovisioning deactivates every app account the moment HR marks them terminated — no orphans, no missed contractor accounts.

Q: In a SCIM integration with Okta, which role does Okta play?

Correct: a. Okta is the SCIM client (identity provider) that sends create/update/deactivate operations; the downstream app is the SCIM service provider that receives them and changes the account.

Q: A new hire's HR record shows department = Sales. You want them to get the Sales apps automatically. What configures that?

Correct: b. Group rules are if-this-then-that rules on profile attributes. 'If department = Sales, add to Sales group' assigns the Sales apps automatically — access by policy, not by hand.

Q: Why do scopes and short-lived access tokens improve API security over shared API keys?

Correct: d. A scoped, short-lived token grants only what the scope allows and stops working soon. A leaked long-lived API key is full access forever; a leaked scoped token is narrow and expires — far less blast radius.

Most engineers think…

Most people think 'lifecycle management' just means creating a user in Okta so they can log in. That mental model fails you in an interview and leaves dangerous access lying around in production.

Okta Lifecycle Management is about automating access across every connected app for the whole journey: a joiner is provisioned on day one, a mover has access adjusted when they change role, and a leaver is deprovisioned the instant HR marks them terminated. The engine behind it is SCIM (create/update/deactivate accounts in downstream apps), driven by an HR-as-master source through Universal Directory, with group rules and Okta Workflows doing the automation. Automated deprovisioning is the security headline: orphaned accounts are how breaches happen.

① What lifecycle management actually is — joiner, mover, leaver

The core idea: Okta Lifecycle Management is access that follows the person, automatically, for their whole time at the company. Okta describes this as the joiner-mover-leaver model. A joiner gets the right apps on day one. A mover who is promoted or transfers has access added and old access removed. A leaver is deprovisioned — their accounts deactivated everywhere — the moment they are terminated.

The thing that makes this trustworthy is a single source of truth. Usually that is an HR system (Workday, SAP SuccessFactors, BambooHR) acting as the profile master. HR records the hire, the promotion, the exit; Okta reads that and pushes the resulting access out to every app. The security headline is the leaver: automated deprovisioning means no orphaned accounts sitting active after someone walks out — which is exactly how data leaves through an ex-employee or a missed contractor account.

Figure 1 — Joiner-mover-leaver — the lifecycle loop

HR records the event, Okta reads it, and access is provisioned, adjusted or revoked automatically across every app.

Figure 2 — The three lifecycle stages, one source of truth

An HR profile master drives all three stages so access always matches the person's real status.

Quick check · Q1 of 10 · Understand

Why is automated deprovisioning the security headline of lifecycle management?

a) It makes logins fasterb) It encrypts the HR databasec) It removes a leaver's access everywhere at once, so no orphaned accounts stay actived) It lets users reset their own passwords

Correct: c. When someone leaves, an active account they still control (or that nobody remembers) is a breach waiting to happen. Automated deprovisioning deactivates every app account the moment HR marks them terminated — no orphans, no missed contractor accounts.

👉 So far: Lifecycle management = access that follows the person: joiner (provision on day one), mover (adjust on role change), leaver (deprovision on exit), all driven by an HR profile master.

② SCIM provisioning — how Okta creates and kills accounts in apps

The engine that actually changes accounts in other apps is SCIM (System for Cross-domain Identity Management), an open standard with a JSON REST API. Okta acts as the SCIM client (identity provider) and the app is the SCIM service provider. The current standard is SCIM 2.0; Okta also still supports older SCIM 1.1 integrations.

The four operations you must name

SCIM does CRUD on accounts: Create a user in the app when they are assigned, Read to match existing accounts, Update attributes when the profile changes, and Deactivate (set active = false) to deprovision. Because hundreds of apps in the Okta Integration Network (OIN) already speak SCIM, you assign a user to an app and Okta provisions them; you unassign or terminate them and Okta deprovisions them — no manual account admin per app.

Figure 3 — One Okta, many SCIM-connected apps

Okta is the SCIM client; each OIN app is a service provider that Okta provisions and deprovisions with the same operations.

🧩

SCIM 2.0

tap to flip

The open standard Okta uses to create, read, update and deactivate accounts in downstream apps over a JSON REST API. Okta is the client; the app is the service provider.

🗂️

Profile master (HR-as-master)

tap to flip

The system designated as the source of truth for a user's profile — usually HR (Workday, SuccessFactors). It drives joiner-mover-leaver into Universal Directory.

⚙️

Group rules

tap to flip

If-this-then-that rules on profile attributes (e.g. department = Sales → Sales group) that auto-assign the right apps, so access is granted by policy not by hand.

🔑

Custom authorization server

tap to flip

An API Access Management OAuth 2.0 server where you define your own scopes, claims and access policies to issue short-lived tokens that protect your own APIs.

Deactivate, don't delete

SCIM deprovisioning sets active = false rather than hard-deleting the account. That cuts access instantly but preserves the record for audit, licence reclaim and any later rehire. In an interview, say 'deactivate' — it shows you understand the safe deprovisioning path.

Quick check · Q2 of 10 · Remember

In a SCIM integration with Okta, which role does Okta play?

a) The SCIM client / identity provider that pushes operations to the appb) The SCIM service provider that receives operationsc) A passive log collectord) The end-user's browser

Correct: a. Okta is the SCIM client (identity provider) that sends create/update/deactivate operations; the downstream app is the SCIM service provider that receives them and changes the account.

👉 So far: SCIM 2.0 is the engine: Okta is the client/IdP that pushes create, read, update and deactivate (active = false) to OIN apps. Deactivate to deprovision, not delete.

③ Sourcing, group rules & Workflows — where the automation lives

Three Universal Directory features turn 'we have SCIM' into 'access is granted by policy, not by hand'. Profile sourcing (mastering) designates a system — usually HR — as the master for a user's profile, so HR owns the truth; you can even do attribute-level sourcing (title from HR, email from AD). Attribute mapping defines how source attributes flow into the Okta profile and out to each app. Group rules are if-this-then-that rules on attributes: if department = Sales, then add to the Sales group, and that group is assigned the Sales apps — so the right apps appear automatically.

When the standard path is not enough, Okta Workflows is the no-code automation platform: a drag-and-drop canvas of triggers, logic and connectors (Slack, Box, Salesforce, Office 365, or any public API) to build flows like 'on deactivation, archive the mailbox, post to the manager in Slack, revoke Box shares'. The rule of thumb: use built-in SCIM provisioning for standard create/update/deactivate, and reach for Workflows for the custom, cross-app steps SCIM can't express.

Figure 4 — Built-in SCIM provisioning vs Okta Workflows

Use SCIM for standard account lifecycle; reach for Workflows for custom, cross-app automation that SCIM can't express.

Mixing built-in provisioning and Workflows in one flow

Okta warns that if out-of-the-box lifecycle provisioning and Workflows provisioning act on the same app in the same flow, the actions can conflict. Pick one path per app: SCIM for the standard create/update/deactivate, Workflows for the custom cross-app steps around it — don't have both fighting over the same account.

▶ Watch a new hire get provisioned end-to-end

How one HR hire becomes live app access. Press Play for the healthy joiner path, then Break it to see the classic failure.

① HR hireHR (Workday) creates a new employee record with department = Sales and a start date of today.

▼

② ImportOkta imports the profile from the HR master into Universal Directory; HR owns the source attributes.

▼

③ Group ruleA group rule sees department = Sales and adds the user to the Sales group, which is assigned the Sales apps.

▼

④ SCIM provisionOkta sends SCIM Create operations to Salesforce and Slack; the new hire has working accounts on day one.

Press Play to step through the healthy joiner path. Then press Break it.

Quick check · Q3 of 10 · Apply

A new hire's HR record shows department = Sales. You want them to get the Sales apps automatically. What configures that?

a) A custom OAuth scopeb) A group rule that adds them to the Sales group, which is assigned the Sales appsc) An MFA factor enrollmentd) A manual app assignment by the helpdesk

Correct: b. Group rules are if-this-then-that rules on profile attributes. 'If department = Sales, add to Sales group' assigns the Sales apps automatically — access by policy, not by hand.

👉 So far: Profile sourcing names HR the master; attribute mapping moves the fields; group rules auto-assign apps by attribute. Use SCIM for standard lifecycle, Okta Workflows for custom cross-app automation.

④ API Access Management — protecting your own APIs with OAuth 2.0

Lifecycle is about access to apps; API Access Management is about access to your own APIs. It is Okta's implementation of OAuth 2.0 (with OpenID Connect for login). Instead of sharing passwords or API keys, clients get a short-lived access token that they send in the HTTP Authorization header, and your API trusts the token.

The pieces you must name

You create a custom authorization server — unlike the basic org server, it lets you define your own scopes (granular permissions, e.g. com.techclick.orders.read), claims (user facts placed into the token, like role or department) and access policies (which client, which scopes, which user gets a token). The API validates the token's audience and scopes and serves only what the scope allows. The interview line: scopes and short-lived tokens replace shared secrets, so a leaked token is limited in power and time.

Figure 5 — How a client gets and uses an access token

A custom authorization server issues a scoped, short-lived token; your API validates it and serves only what the scope allows.

Priya, an IAM admin at a Pune fintech, faces this

A contractor left three weeks ago but is still showing up in the Salesforce active-user export, and finance is asking why a licence is still being billed.

Likely cause

The contractor was deactivated in Okta, but Salesforce was assigned manually and was never SCIM-provisioned, so the deactivation never propagated — an orphaned account.

Diagnosis

Check the Okta system log and the app's provisioning settings: Salesforce shows no SCIM deprovisioning event because provisioning was never enabled for that assignment.

Okta Admin ▸ Applications ▸ Salesforce ▸ Provisioning + Reports ▸ System Log

Fix

Enable SCIM provisioning on the Salesforce app, drive assignment through the HR-mastered group, and let deactivation set active = false downstream; add an Okta Workflow to alert IT if a deprovision step errors.

Verify

Re-run the Salesforce active-user export: the ex-contractor is now deactivated, the licence is reclaimed, and the system log shows the deprovision event.

Prove access from the token, not a hunch

Never assume an API call is authorised. Validate the access token's audience (aud) and the scopes it carries — the API should serve only what the scope allows. The token itself is the evidence of who may do what, so read it instead of guessing.

Quick check · Q4 of 10 · Analyze

Why do scopes and short-lived access tokens improve API security over shared API keys?

a) They are easier to typeb) They never expire, so you set them oncec) Tokens are stored in the URL for visibilityd) A token grants only the scoped permissions and expires quickly, so a leak is limited in power and time

Correct: d. A scoped, short-lived token grants only what the scope allows and stops working soon. A leaked long-lived API key is full access forever; a leaked scoped token is narrow and expires — far less blast radius.

👉 So far: API Access Management protects your own APIs with OAuth 2.0: a custom authorization server defines scopes, claims and policies and issues short-lived tokens — scopes + expiry shrink the blast radius of a leak.

🤖 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.

🧠 In your own words

Type one line: why is automated deprovisioning the security headline of Okta Lifecycle Management? Then compare with the expert version.

Expert version: Because access that lingers after someone leaves is exactly how data walks out. When a leaver is offboarded by hand, app by app, something always gets missed — an ex-employee, a forgotten contractor, a directly-assigned app that was never SCIM-connected — and that orphaned account stays live and unwatched. Automated deprovisioning, driven by the HR profile master through Universal Directory and pushed over SCIM (active = false) to every connected app, cuts all of it the moment HR marks termination. You close the gap instantly, you have a system-log record for audit, and you reclaim the licences. That is why the leaver, not the joiner, is the part interviewers and auditors care about most.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Okta at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Lifecycle management: Provisioning and deprovisioning app access automatically as a user joins, changes role and leaves — the joiner-mover-leaver model.
Joiner-mover-leaver (JML): The three lifecycle stages: grant day-one access (joiner), adjust on role change (mover), and revoke on exit (leaver).
SCIM 2.0: System for Cross-domain Identity Management — the open JSON-over-REST standard Okta uses to create, read, update and deactivate accounts in downstream apps.
Deprovisioning: Removing a user's access; in SCIM this sets active = false to deactivate (not hard-delete) the downstream account, preserving it for audit.
Profile master (HR-as-master): The system designated as the authoritative source for a user's profile — usually an HR system like Workday or SuccessFactors.
Profile sourcing / mastering: Designating which system owns a user's profile or individual attributes (e.g. title from HR, email from AD) in Universal Directory.
Group rules: Attribute-based if-this-then-that rules that auto-assign users to groups (and the apps those groups carry), e.g. department = Sales → Sales group.
Okta Workflows: A no-code drag-and-drop automation platform of triggers, logic and connectors for custom identity processes SCIM can't express.
API Access Management: Okta's OAuth 2.0 (plus OIDC) layer for protecting your own APIs using custom authorization servers, scopes, claims and access policies.
Scope: A granular OAuth permission requested by a client and granted in an access token, e.g. com.techclick.orders.read — the API serves only what the scope allows.

📚 Sources

Okta Developer — Understanding SCIM (SCIM 2.0, create/read/update/deactivate, Okta as SCIM client). developer.okta.com/docs/concepts/scim
Okta Developer — Overview of lifecycle management in the OIN (provisioning and deprovisioning, SCIM vs Connector Builder). developer.okta.com/docs/guides/oin-lifecycle-mgmt-overview
Okta — Lifecycle Management and App Provisioning product page (joiner-mover-leaver, HR as source of truth). okta.com/products/lifecycle-management
Okta Help — Profile sourcing & attribute sourcing in Universal Directory (HR-as-master, attribute-level mastering). help.okta.com
Okta Help — Okta Workflows: provision and deprovision use case (triggers, connectors, conflict warning). help.okta.com/wf
Okta Developer — API Access Management & Create an authorization server (custom authz server, scopes, claims, access tokens). developer.okta.com/docs/concepts/api-access-management

What's next?

Got provisioning? Next, go deep on Okta MFA and adaptive access policies — factors, device trust and risk-based sign-on — to see how Okta decides whether to challenge, allow or block at the moment of login.

Next · All interview lessons → Practice on exam.techclick.in →

Okta Lifecycle Management & SCIM Provisioning — Joiner-Mover-Leaver, Workflows & API Access

🎯 By the end you will be able to

Pick where you want to start

What lifecycle is

SCIM provisioning

Sourcing & Workflows

API Access Mgmt

① What lifecycle management actually is — joiner, mover, leaver

② SCIM provisioning — how Okta creates and kills accounts in apps

The four operations you must name

③ Sourcing, group rules & Workflows — where the automation lives

▶ Watch a new hire get provisioned end-to-end

④ API Access Management — protecting your own APIs with OAuth 2.0

The pieces you must name

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?