Before learning the answer, it helps to feel the pain of the question.

Life before automatic provisioning

In the early days of business software, every application kept its own private list of users. If a company used ten applications, there were ten separate lists. When a new person joined, an administrator had to open each application, click “Add user”, type the name, the email, the department and the role, and then repeat the process nine more times. When the person changed teams, the same tour had to happen again. When the person left, the administrator had to remember every single application and close each account by hand.

This manual style has three big problems. First, it is slow, because a new joiner may wait days before they can do any work. Second, it is error-prone, because people mistype names, forget applications or skip steps when they are busy. Third, and most dangerous, it is insecure. If an administrator forgets to close one account after an employee leaves, that former employee may still be able to log in weeks or months later. Security experts call such forgotten accounts “orphan accounts”, and they are a favourite target for attackers.

What the letters stand for

SCIM stands for System for Cross-domain Identity Management. That is a long name, so let us break it down. “Identity management” means looking after the digital identities of people, such as their names, emails, groups and whether their account is active. “Cross-domain” means the identity information moves between different systems that belong to different companies or products. “System” simply means it is an organised standard, not a single product.

SCIM is an open standard published by the Internet Engineering Task Force, the same community that publishes many of the rules the internet runs on. Two documents define it: one describes the shape of the data (what a “user” looks like and what fields it has), and the other describes the protocol (how to ask a server to create, read, change or delete those users). Because the rules are public, any vendor can build to them, and any identity provider can talk to any compliant application without special custom work for each pair.

The word “Basic” is the part that confuses most beginners, so let us clear it up first.

Basic is not a separate kind of SCIM

There is no special product called “Basic SCIM” that is smaller or weaker than normal SCIM. The word “Basic” in this phrase comes from Basic Authentication, which is one of the ways a client can prove who it is to a server. When you browse the Okta integration catalogue, you will find template applications named things like “SCIM 2.0 Test App (Basic Auth)”, “SCIM 2.0 Test App (Header Auth)” and “SCIM 2.0 Test App (OAuth Bearer Token)”. All three speak the very same SCIM language. The only difference is the method Okta uses to show its credentials to the application’s SCIM service.

So when someone says “SCIM (Basic) in Okta”, they usually mean this: an Okta application integration that provisions users using the SCIM standard, where Okta authenticates to the target application’s SCIM service using a username and password pair, which is exactly what Basic Authentication means.

What Basic Authentication is

Basic Authentication is one of the oldest and simplest ways to prove identity on the web. The client takes a username and a password, joins them together, converts the result into a text format called Base64, and attaches it to every request in a header. The server receives the header, reverses the conversion, checks the username and password against its records, and decides whether to allow the request.

Why anyone chooses Basic

Many smaller or older applications offer only a simple SCIM service that checks a fixed username and password. Setting it up takes minutes: an administrator creates a service account inside the application, gives it permission to manage users, and pastes the credentials into Okta. There is no token to refresh and no authorisation server to configure. For that reason Basic is very common for quick pilots, internal tools and vendors who have not yet built a more modern option.

Every new field has its own vocabulary. Here is the small dictionary you will use for the rest of this guide.

The words around the edges

Three more words appear often. A connector is the configured link between Okta and one particular application. An attribute is a single piece of information about a person, such as a first name, a job title or an email address. A mapping is the rule that says which Okta attribute should fill which application attribute. Mappings are important because Okta and the application may use different names for the same idea. Okta might call a field “firstName” while the application expects “givenName”.

Underneath the friendly idea is a very ordinary web conversation made of requests and answers.

SCIM rides on normal web requests

SCIM is built on the same technology that powers websites: HTTP requests sent to web addresses. There is nothing exotic about it. Okta, acting as the client, sends a request to the application’s SCIM service. The application, acting as the server, does the work and sends back an answer. The data travels in a text format called JSON, which is a tidy way of writing lists of named fields. Because SCIM reuses familiar web tools, almost any programming language and any web server can support it.

The four everyday actions

SCIM borrows the standard HTTP verbs and gives each one a clear job. Think of them as four buttons on a remote control.

Standard places to knock

A SCIM service exposes a small set of well-known addresses. The Users address handles people. The Groups address handles collections of people. There are also helper addresses that describe the service itself: one that lists what features the service supports, one that lists the schemas it understands and one that lists the types of resources it manages. Okta and other clients can read these helper addresses to learn what the service can do, a bit like reading the menu before ordering.

Finding people with filters and pages

Okta often needs to ask a question such as “do you already have a person whose username is this?” SCIM supports filters for exactly this. The client sends a filter saying which field should match which value, and the server returns only the matching records. When a list is long, the server returns it in pages, and the client asks for the next page, just as you turn the pages of a long phone book. Okta depends on the filter for the username field working correctly, because it is how Okta avoids creating duplicates.

Users and Groups

A User resource carries identity details: a unique username, a name, one or more emails, a flag saying whether the account is active, and any extra fields the application wants. A Group resource carries a name and a list of members. Groups matter because most applications grant access by group, such as “Support Agents” or “Finance Team”. When Okta pushes a group, it can create the group in the application and keep the member list in step with Okta.

Several pieces inside Okta cooperate whenever a SCIM provisioning action happens.

The cast of characters

Everything starts with the Universal Directory, which is Okta’s central store of people and their attributes. Next comes the application integration, which is the configured link to one specific application and holds its base URL, its authentication details and its settings. Then there is the provisioning engine, the part of Okta that notices changes and decides which requests to send. Finally there is the application’s SCIM service, which receives those requests and updates the real application.

flowchart LR
  A["Admin or HR system"] --> B["Okta Universal Directory"]
  B --> C["Okta Provisioning Engine"]
  C --> D["Attribute Mappings"]
  D --> E["SCIM Request over HTTPS with Basic Auth"]
  E --> F["Application SCIM Service"]
  F --> G["Application User Database"]
        

Reading the diagram

The journey begins when something changes about a person. Perhaps an HR system adds a new hire, or an administrator edits a department. That change lands in the Universal Directory. The provisioning engine notices the change, checks whether the person is assigned to the application, and applies the attribute mappings to translate Okta’s field names into the application’s field names. It then builds a SCIM request, attaches the Basic Authentication header and sends it over HTTPS to the application. The application’s SCIM service verifies the credentials, performs the change in its own database and replies with the result.

Assignment is the trigger

An important idea is that Okta only provisions people to an application when those people are assigned to it. Assignment can be done one person at a time or, far more commonly, through a group. When a person is assigned, Okta creates their account in the application. When the assignment is removed, Okta can deactivate or remove the account. This makes access easy to reason about: if you are in the right group, you get the application, and if you leave the group, you lose it.

The two directions

Okta can move information in two directions. “To App” is the usual direction: Okta is the source of truth and pushes changes into the application. “To Okta” is the reverse: Okta imports existing users and some attributes from the application, which is useful when you first connect an application that already has a crowd of accounts. Not every integration enables both directions, and the available options depend on how the integration was built.

Provisioning is not a single event. It follows a person’s whole time at the company.

Security teams describe a person’s journey with three simple words: joiner, mover and leaver. SCIM, driven by Okta, handles each stage automatically.

One conversation, step by step

The diagram below shows what happens on the wire when a new person is assigned to an application. Notice that Okta first asks a question before it creates anything.

sequenceDiagram
  participant O as Okta
  participant S as App SCIM Service
  participant D as App Database
  O->>S: Search for user by username (Basic Auth)
  S->>D: Look up username
  D-->>S: Not found
  S-->>O: Empty result
  O->>S: Create user with mapped attributes
  S->>D: Insert new account
  D-->>S: Saved with new ID
  S-->>O: Created, here is the user ID
  Note over O: Okta stores the app user ID for future updates
        

Why the stored ID matters

When the application creates the account, it replies with its own internal identifier for that person. Okta remembers this identifier. From then on, whenever Okta needs to update or deactivate that person, it uses the identifier to point at exactly the right record. This is more reliable than searching by name each time, because names can change but the identifier does not.

Since “Basic” is in the name, it deserves a close look at how it behaves and where it is weak.

How Okta uses it

When you configure a SCIM (Basic) integration, you enter the base URL of the application’s SCIM service, a username and a password. Okta stores these securely. Every time it sends a SCIM request, it combines the username and password, encodes them and places them in the request header. The application’s SCIM service checks them on every single call. Okta also provides a “Test API Credentials” button, which sends a harmless request to confirm that the link, the address and the credentials all work before you save anything.

The three authentication styles side by side

Okta’s template integrations offer three styles. They all carry the same SCIM messages but differ in how they prove identity.

What makes Basic risky if handled carelessly

The password in a Basic setup does not expire on its own. If it leaks through a screenshot, a shared document or a misconfigured server log, whoever holds it can create, change or deactivate users in the application until someone notices and changes it. Basic credentials also usually grant broad power, because the service account must be able to manage every user. For these reasons, teams that choose Basic should treat the service account as a highly sensitive secret and apply extra care, which we cover in the security chapter.

A SCIM connection unlocks a family of provisioning features. Which ones you see depends on the application.

Matching existing accounts

Imagine you connect an application that already has two thousand accounts. You do not want Okta to create two thousand duplicates. During import, Okta compares each application account with the people it already knows, using a matching rule such as the email address or username. Matches are linked together, and anything unmatched can be reviewed by an administrator. This simple step is what turns a messy start into a clean, connected one.

Attribute mappings explained

Mappings are where a lot of the real-world care goes. For each application field, the administrator chooses what value should be sent. It might be a plain copy of an Okta attribute, a combination of two attributes or a fixed value. A mapping can also be set so that Okta controls the field fully, or so that it only sets the field once when the account is first created. Choosing carefully avoids surprises, such as overwriting a title that a manager had already corrected inside the application.

Here is the journey from nothing to a working SCIM (Basic) connection, told without any code.

When the application is behind a firewall

Some applications live inside a company’s private network and cannot be reached from the internet. Okta cannot knock on a door it cannot see. For these cases Okta offers an on-premises provisioning agent, a small program installed inside the private network that makes an outbound connection to Okta and relays SCIM requests to the internal application. The idea is the same, but a helper stands inside the building to open the door.

SCIM holds the power to create and remove accounts, so protecting it matters greatly.

Why SCIM is a juicy target

An attacker who controls a SCIM connection can add a fake user with high privileges, change an existing user’s email to take over an account, or deactivate real staff to cause disruption. That is why the credentials behind SCIM deserve the same care as an administrator password.

Protecting personal data

SCIM carries personal details such as names and emails. Many countries have privacy rules about how such data may be stored and shared. Send only the fields the application needs, make sure the vendor handles data responsibly, and remember that deactivating an account does not always erase the data. Some organisations add a separate deletion step to satisfy privacy requests.

When to prefer something stronger

If the application supports an OAuth-based or token-based option, and the data is sensitive, consider moving away from Basic. Short-lived tokens limit the damage of a leak. Basic remains acceptable for low-risk uses when it is protected with the controls above, but it should be a conscious choice rather than a default.

A connection that nobody watches will eventually break quietly.

Where to look when something goes wrong

Okta records provisioning activity in its System Log. Each attempt to create, update or deactivate a user appears as an event, along with whether it succeeded or failed and often a reason. Administrators can also view provisioning errors on the application’s page, where failed tasks are listed so they can be retried after the cause is fixed. The application’s own SCIM service should keep logs too, showing which requests arrived, from where and what happened to them.

flowchart TD
  A["Provisioning event in Okta"] --> B{"Request succeeded?"}
  B -->|Yes| C["Event logged as success"]
  B -->|No| D["Error logged with reason"]
  D --> E["Admin reviews failed task"]
  E --> F["Fix cause: credentials, mapping or app issue"]
  F --> G["Retry the task"]
  G --> A
        

Numbers worth tracking

Common errors and what they usually mean

Experienced teams repeat good habits and avoid a few well-known traps.

Patterns that work

Traps to avoid

Every choice has a price. Here is an honest look at both sides.

Choosing wisely

The right question is not “is Basic bad?” but “is Basic good enough for this application and its data?” For a low-risk internal tool, with a locked-down service account, Basic is often perfectly reasonable. For a system holding sensitive customer or financial data, a token-based or OAuth option is usually the wiser choice. Treat the authentication method as a risk decision, not just a convenience.

A short checklist in plain words that saves a lot of future headaches.

Good habits

• Document who owns each SCIM connection, where its secret is stored and when it was last rotated.
• Test with a pilot group, including a full joiner, mover and leaver cycle.
• Review attribute mappings every time the application adds new fields.
• Alert on a rising count of failed provisioning tasks.
• Keep a written plan for rotating credentials so it never becomes an emergency.
• Periodically compare Okta’s user list with the application’s list to catch drift.

Frequent mistakes

Picture how SCIM looks inside everyday organisations.

Short answers to the questions beginners ask most often.

No. Single Sign-On lets people log in once and open many applications. SCIM manages the accounts behind the scenes. Companies commonly use both together: SSO for logging in, SCIM for creating and removing the accounts.

No. Basic refers only to Basic Authentication, the username-and-password method used to connect. The SCIM features available are the same ones the application’s SCIM service supports.

It is safe enough when used over HTTPS with a dedicated, least-privilege service account and a strong, rotated password. It is weaker than token-based options because the secret is long-lived, so use stronger methods for sensitive data when they are available.

Version 2.0 is the modern, standardised version with a clearer schema and protocol, and it is the one most vendors support today. Okta supports both, but new integrations should normally use 2.0 when the application offers it.

Some integrations support syncing passwords, but it depends on the application and how the integration was built. Many modern setups avoid passwords altogether by using single sign-on instead.

Usually the account is marked inactive, which blocks login but keeps the data. Whether the application later deletes the record is determined by the application’s own rules.

Not if the application already offers a SCIM service. You configure the connection in Okta’s admin console. Code is only needed by the application’s developers if they must build the SCIM service itself.

Use Okta’s on-premises provisioning agent, which sits inside your network and relays requests securely so Okta does not need direct access.

Make sure the application’s SCIM service supports filtering on the username, import existing users before turning on creation, and confirm the matching rule uses a stable, unique attribute.

Follow your organisation’s secret-rotation policy, and always rotate after anyone with access leaves or when exposure is suspected. Update Okta immediately after changing the application side.

We began with a school secretary struggling to update many notebooks and ended with an automatic messenger who does it perfectly every time. SCIM is that messenger’s open, shared language for creating, updating and deactivating accounts across applications. In Okta, “SCIM (Basic)” simply means a SCIM provisioning connection where Okta proves its identity with a username and password over HTTPS. It is quick to set up and very common, and it works best when protected with a dedicated service account, least privilege, encryption, regular rotation and good monitoring. Understand the joiner, mover and leaver journey, pilot before you roll out, and choose the authentication style that fits the sensitivity of the data.