Before we talk about doing it “just in time”, we need to understand the job itself: getting an account to exist in the right place.

An account is a record

Almost every app keeps a list of people it knows about. Each entry in that list is called an account. An account usually holds a name, an email address, a role, and some settings. When you open an app, it looks you up in its list. If you are not there, you are turned away, even if you work at the company and have the right password somewhere else.

Provisioning means creating, updating and, at the end, removing those accounts. The word comes from “provide”. The company provides each person with what they need to do their work. The opposite word is deprovisioning, which means taking access away when a person leaves or changes jobs.

Why it becomes a headache

A small team of ten people can create accounts by hand. A company with ten thousand people and eighty apps cannot. Every new hire needs accounts in many places, every role change needs updates in many places, and every departure needs removals in many places. Mistakes are easy to make. A forgotten account for a former employee is a real security risk, and a missing account for a new hire wastes the first morning of a paid worker.

JIT means an account is created only when the person first tries to use the app, not before.

The phrase “just in time” comes from manufacturing. A car factory does not store thousands of tires for months. It receives tires at the moment the assembly line needs them. JIT provisioning applies the same idea to accounts. Instead of building an account for every person in advance, the system builds it at the exact moment of the first login.

Here is the basic idea in four steps. A person tries to sign in. A trusted identity system confirms who they are. It also sends a few facts about the person, such as name, email and department. The app sees that no account exists yet, so it uses those facts to create one right away and lets the person in.

What “Basic” means here

When people say “JIT provisioning (basic) in Okta”, they mean the simple, standard form of this feature. The basic form does three things. It creates the account at first login. It fills the account from a short list of attributes. It may refresh those attributes at later logins. The basic form does not include advanced extras such as bulk imports, scheduled syncs, or automatic removal of accounts. Those belong to other tools that we will compare later.

Where it came from

Early single sign-on systems proved identity but left account creation to people. As companies moved to cloud apps in the late 2000s and early 2010s, the number of apps per person exploded. Software vendors responded in two ways. Some let the app trust the identity message and create the account on first login. That is JIT. Others built a separate web service that an identity provider could call to create, change and delete accounts ahead of time. That second approach is the standard called SCIM. Okta, founded in 2009, supports both styles.

Three common myths

Myth one: JIT is a feature that Okta turns on by itself. In the usual SAML case, the switch lives inside the app, and Okta only supplies the facts. Without the app’s cooperation, nothing is created.

Myth two: JIT keeps accounts up to date forever. It only sees a person when they log in. A person who never returns is never refreshed, and a person who has left is never removed.

Myth three: JIT is less secure than other methods. The creation step is safe when the identity message is signed, the default role is low, and the right people are assigned. The real weakness is the missing removal step, which can be fixed with other tools.

JIT is only one of several ways to get accounts into place. Seeing them side by side shows when each one shines.

Reading the table in plain words

Manual creation is simple but slow. Bulk import is fast once but quickly becomes out of date. JIT is quick and needs little setup, but it only handles the arrival. SCIM handles the whole life of an account, which is why it is the favorite for important systems. Directory sync is a bridge between two lists of people.

A dozen small words carry most of the meaning in this topic. Learn them once and the rest reads easily.

A JIT login touches the person, their browser, Okta, and the app that receives them. Each piece has a clear job.

JIT is not a separate product with its own box on the diagram. It is a behavior that appears when an identity message arrives at a system that is willing to create accounts. That means two sides must agree: the sender must include enough facts, and the receiver must be switched on to build accounts from them.

flowchart LR
    U["Person"] --> B["Web Browser"]
    B --> OK["Okta Sign-in"]
    subgraph TEN ["Okta Tenant"]
        OK --> POL["Authentication Policy and MFA"]
        POL --> UD["Universal Directory Profile"]
        UD --> MAP["Attribute Mapping"]
        MAP --> AI["SAML App Integration"]
    end
    AI --> AS["Signed Assertion with Attributes"]
    AS --> APP["Application"]
    APP --> CHK{"Account exists?"}
    CHK -->|"No"| NEW["Create account from attributes"]
    CHK -->|"Yes"| UPD["Open existing account"]
    

The parts, one by one

The person and the browser. The person starts the journey, and the browser carries messages between Okta and the app. The app and Okta rarely speak to each other directly during a login.

Okta sign-in and policy. Okta checks who the person is and applies rules such as multi-factor authentication. Only after these pass will Okta prepare an assertion.

Universal Directory. This holds the person’s profile. The facts that end up in the new account start here, so their quality matters. A typo in the directory becomes a typo in every JIT-created account.

Attribute mapping. The app integration contains a short list of rules saying which directory fields are sent and what names they carry. The names must match what the app expects, character for character.

The SAML app integration. This is the object an administrator creates for each app. It holds the addresses, the identifier format, and the attribute rules. It is the file Okta keeps on how to talk to that one app.

The application. The app receives the assertion, checks the signature, and then decides whether to build an account. This final decision belongs to the app, not to Okta, which is why JIT works only with apps that offer it.

Follow one new employee through their very first login to a chat app that supports JIT.

sequenceDiagram
    participant U as New Employee Browser
    participant A as Chat Application
    participant O as Okta
    U->>A: Open the app for the first time
    A-->>U: Redirect to Okta for sign-in
    U->>O: Arrive with the app request
    O-->>U: Ask for password and extra factor
    U->>O: Prove identity
    O->>O: Check assignment and read profile attributes
    O-->>U: Return signed assertion with name, email and role
    U->>A: Deliver the assertion
    A->>A: Verify signature and look for an account
    A->>A: No account found so create one from the attributes
    A-->>U: Start a session and show the workspace
    

Okta can be the sender of identity or the receiver of identity. JIT appears in both roles, and beginners often mix them up.

Direction one: Okta sends, the app creates

This is the case in Chapters 5 and 6. A person signs in to Okta, and Okta sends an assertion to a business app. The app creates the account. Here, Okta’s job is to send good attributes. The creation itself happens in the app, and its availability depends on the app. Several well-known business apps, including Salesforce and Zoom, offer a JIT setting for SAML logins, but each names and handles it a little differently.

Direction two: Okta receives, Okta creates

Now reverse the roles. Sometimes people sign in to Okta using an outside identity system: a partner company, a parent company’s directory, or a social identity. Okta then acts as the service provider and treats the outside system as the identity provider. This setup is called inbound federation, and in the Okta admin screens the outside system is added under the identity providers area. When a person arrives from that outside system and has no Okta account yet, Okta can create one on the spot. That is Okta’s own JIT provisioning.

flowchart LR
    P["Partner employee"] --> X["External Identity Provider"]
    X --> A["Signed assertion"]
    A --> OK["Okta as service provider"]
    OK --> Q{"Matching Okta user?"}
    Q -->|"Yes"| L["Link and sign in"]
    Q -->|"No"| J["JIT: create Okta user"]
    J --> G["Assign groups from rules"]
    G --> D["Okta dashboard and apps"]
    L --> D
    

This is the common case: Okta sends an assertion, and the app builds the account. Screen labels vary by app and by Okta version.

What a good attribute list looks like

When an outside identity provider sends people to Okta, the identity provider settings inside Okta decide whether accounts are created.

In the Admin Console, outside identity providers live in the identity providers area. An administrator adds a SAML identity provider by giving Okta the outside system’s sign-in address, its unique name, and its certificate. After that comes a group of settings that control JIT. The names differ a little between Okta versions, but the ideas are the same.

Choosing who is the master

A person’s profile can only have one boss. If the outside system is the master, Okta overwrites its copy of name and email each time the person signs in. If Okta is the master, it keeps its own values. Mixing the two leads to fights where each side keeps changing the value back. Decide once, write it down, and apply it to all identity providers of the same kind.

Routing people to the right door

Okta can look at the email domain the person types and send them to the matching outside identity provider. This is done with routing rules. For example, anyone who types an address ending in a partner’s domain is sent to the partner’s sign-in page. Without these rules, people may be confused about where to sign in.

What goes into a new account decides what the person can do. The attributes are the real power behind JIT.

Required and optional facts

Every app has a short list of facts it must have to create an account. Usually that means a name and an email. It may also want a department, a phone number or a manager. Okta lets you add optional attributes, but a shorter list is better. Each extra field is one more place for a typo or a privacy problem.

Choosing a role at creation time

Apps need to know what a new person may do. There are three common ways to decide:

• A fixed default. Every JIT-created account gets the same basic role. This is the safest choice because it never gives extra rights by accident.
• A role attribute. Okta sends a field called role, and the app maps its values to internal roles.
• Group names. Okta sends the names of the person’s groups, and the app turns matching names into roles.

Keeping attribute names tidy

Many bugs come from small differences such as “firstName” versus “first_name” or “Email” versus “email”. Agree on one naming habit for your company, and copy the exact spelling from each app’s documentation. Capital letters matter.

The most common JIT surprise is the double: two accounts for the same person. Understanding why it happens makes it easy to prevent.

When an assertion arrives, the app or Okta must decide whether the person already has an account. It does this by comparing one value, usually an email or a username. If that value is spelled differently, the comparison fails, the system thinks the person is new, and JIT happily creates a second account.

Why the match fails

• The email in Okta is “sam.lee@example.com” but the old app account used “samlee@example.com”.
• The person changed their name after marriage and Okta now has a new email.
• The app compares capital letters strictly, while Okta lower-cases them.
• An older account was created with a personal email before the company adopted SSO.

How to prevent and fix it

Before turning on JIT for an app that already has users, export its user list and compare it with the Okta list. Fix mismatches first. Pick one stable identifier and use it everywhere. When duplicates do appear, merge or remove them following the app’s own rules, because the data inside each account, such as messages or files, may need to be moved by hand.

flowchart TD
    A["Assertion arrives"] --> B["Read the Name ID value"]
    B --> C{"Exact match in the account list?"}
    C -->|"Yes"| D["Open the existing account"]
    C -->|"No"| E{"JIT switched on?"}
    E -->|"Yes"| F["Create a new account"]
    E -->|"No"| G["Refuse the login"]
    F --> H["Risk: a duplicate if the value was spelled differently"]
    

An account created by JIT has a whole life. Knowing its stages shows what JIT handles well, and what it leaves for someone else.

The deprovisioning gap

Step six is the weak point. JIT only listens when a person arrives. When they leave, nobody tells the app. The old account stays, and it may even be usable through another path, such as a saved password, an access token or a mobile app that never expires its session. This is why security teams do not rely on JIT alone for important systems.

Ways to close the gap

• Pair JIT with SCIM, so that Okta can disable the account when the person is unassigned.
• Keep app sessions short, so that old sessions end quickly.
• Run a regular review that compares each app’s account list with the list of people assigned in Okta.
• Use the app’s own tools to disable accounts that have not logged in for a long period.

Creating accounts automatically is powerful, so it needs guard rails. Most JIT incidents come from trust that was too wide, not from broken technology.

Trust only what you must

When JIT is on, whoever controls the identity message controls who gets accounts. For direction one, that is Okta, and the app must check the signature on every assertion. For direction two, that is the outside identity provider, and Okta trusts its certificate. If that outside system is poorly secured, an attacker there could create accounts in your Okta. Only connect identity providers you trust, and review them like any other partner.

Limit what a new account can do

The principle of least privilege means giving people only the access they need. For JIT this means a basic default role, a small default group, and no automatic path to administrator rights. Higher rights should be granted later by a deliberate action.

Protect the assignment door

Account creation happens only for people who can reach the app. Control that by assigning apps to groups, restricting group membership to administrators, and using authentication policies such as multi-factor authentication. Those policies run before Okta issues any assertion, so a failed check means no account is ever created.

Think about attribute injection

An attacker may try to supply extra or changed attributes to gain a higher role. Defenses are simple: sign and verify assertions, never trust fields that users can edit, and let only Okta groups decide roles. For inbound federation, ignore group claims from the outside system unless you filter them to a known list.

Mind the domain

Allow JIT only for expected email domains. An identity provider that vouches for any address at all can lead to accounts for strangers. Use routing rules and match settings to keep each door for its own set of people.

Watch for abuse of seat limits

Some apps charge for each account. A wide group assignment combined with JIT can create hundreds of paid accounts in a day. Assign the app only to the people who need it.

When a JIT login fails, the person sees a blunt message. The real reason is nearly always findable in a few places.

Where to look

The Okta System Log. This records sign-in attempts, assignments, user creation and changes made by administrators. For direction two, user creation events show up here. For direction one, look for the single sign-on event for that person and app.

The app’s own logs. For direction one, the app decided whether to create the account, so its audit or sign-in log holds the reason for a refusal.

The assertion itself. A free browser extension for viewing SAML messages shows what attributes Okta really sent. Handle those captures with care, since they contain personal data.

Common symptoms and fixes

What to watch over time

• Number of accounts created per day in each app. A sudden spike deserves a look.
• Accounts without a matching Okta user, which signals leavers who were never removed.
• Failed creation attempts, which usually point to a missing attribute.
• Administrator changes to JIT settings, which should be rare and reviewed.

JIT is a good tool for some jobs and a poor tool for others. These lists help you choose.

Trade-offs to think about

Teams that use JIT well share a handful of habits. Teams that struggle share a handful of mistakes.

Patterns that work

Anti-patterns to avoid

Common beginner mistakes

• Forgetting to switch on JIT inside the app, while the Okta side looks perfect.
• Using attribute names that differ slightly from the app’s expected names.
• Assigning the app to everyone in the company when only one team needs it.
• Letting two systems both act as the master of a profile.
• Allowing JIT from an identity provider that is not fully trusted.
• Never reviewing the account list after the first week.

Basic JIT is light work for the systems involved. A few extra topics still decide whether it stays smooth as the company grows.

Performance and scale

Creating one account is a tiny job: one lookup, one write, one confirmation. The cost of JIT is spread across the days when people first arrive, so it rarely creates a heavy load. The exception is a mass event, such as a merger or the first week of a school term, when thousands of people log in for the first time within a few hours. In those moments the app’s own account creation can slow down, and some apps limit how many accounts they accept per minute. Plan a staged rollout by assigning the app to a few groups at a time, instead of everyone on the same morning.

Availability and reliability

JIT depends on two systems being reachable at login time: Okta and the app. If either is unavailable, a new person cannot get in, while a returning person with a live app session may not notice anything. Keep a short written plan for first-day access during an outage. For critical tools, create the accounts of key staff ahead of time so that important people are not blocked.

Stronger options when the basics are not enough

Measuring success

Good teams track a few simple numbers after enabling JIT. How many people reach the app without help-desk contact? How long does a new hire wait for access? How many accounts exist in the app compared with the number of people assigned in Okta? If the last number grows faster than the first two, leavers are piling up and it is time to add removal tools.

JIT shows up wherever many people need many apps and some of those people change often. These are typical scenarios.

Collaboration tools, customer relationship tools and video meeting tools are the usual homes of JIT, because each person needs only a basic account and the apps usually offer a setting for it. Business suites with deep per-person setup, such as finance or HR systems, more often use SCIM or a planned import, because their accounts need careful preparation.

Just-In-Time provisioning is a simple and useful idea: do not build an account until the person actually shows up. In Okta it appears in two ways. Okta sends good attributes and the app creates the account, or Okta receives a login from an outside identity provider and creates the user itself. The basic version is quick to set up and easy to understand, but it only handles the arrival of people, not their departure.