Before details, let us settle the meaning of the word, why companies need one, and how “org” and “tenant” relate.

The problem identity systems solve

Every company uses dozens or hundreds of apps: email, chat, payroll, code hosting, customer tools. Without a central system, each app keeps its own list of users and its own passwords. People forget passwords, leavers keep access, and nobody can answer a simple question like “who can open the finance system today?”

An identity provider fixes this by keeping one trusted list of people and one set of sign-in rules. Apps ask the identity provider “is this person who they say they are?” instead of checking passwords themselves. Okta, founded in 2009, is one of the best-known cloud identity providers.

Org and tenant: two words, one idea

Okta delivers its service from shared cloud infrastructure. Each customer gets a logically separate, private slice of it. Okta calls that slice an org. The industry word for such a slice is a tenant, which is why people write “Okta org (tenant)”. They mean the same thing: your own isolated identity space inside a shared service.

A handful of plain ideas explain almost everything in an org. Learn these words once and the rest becomes easy.

Three protocols you will hear about

Apps and Okta talk using agreed languages called protocols. SAML is an older, XML-based language common in business apps. OpenID Connect, or OIDC, is a modern language built on top of OAuth 2.0 that works well for web, mobile and APIs. SCIM is a language for creating, updating and removing user accounts inside apps automatically. SAML and OIDC are about signing in. SCIM is about keeping accounts in step.

Open an org and you will find the same set of building blocks every time. Here is the map.

Everything in this table belongs to the org and does not appear in any other org. That is the key point of the tenant idea: your configuration and your data are yours, separate from every other customer.

Every org has a web address, and the address tells you a surprising amount about it.

The web addresses of an org

Each org gets its own subdomain name that you choose when it is created, for example “yourcompany”. That name sits in front of an Okta domain. Production orgs usually use the main Okta domain. Preview, or test, orgs usually use a separate preview domain. Some regions and sectors use their own domains too, such as an EU domain or a government domain. The administrator uses a separate admin address that adds a suffix to the org name, so people and admins land on different pages.

Many companies also set up a custom domain, such as a sign-in address under their own company name. Users then never see an Okta address. Custom domains also allow emails to come from your own address and help you feel more in control of branding.

Identifiers

Inside an org, every object receives a unique identifier. The first letters of the identifier hint at the type of object. Users commonly start with 00u, groups with 00g and applications with 0oa. These identifiers are only meaningful inside the org that created them. A user id from one org means nothing in another.

Here we zoom out to see how the org sits between people, apps and the places where user data originates.

flowchart LR
  subgraph PEOPLE["People and devices"]
    U1["Employees"]
    U2["Contractors"]
    U3["Customers"]
  end
  subgraph ORG["Okta org"]
    AUTH["Authentication service"]
    POL["Policy engine"]
    UD["Universal Directory"]
    AS["Authorization servers"]
    PROV["Provisioning engine"]
    LOG["System Log"]
    ADM["Admin Console and API"]
  end
  subgraph SRC["Sources of truth"]
    HR["HR system"]
    AD["On premises directory"]
  end
  subgraph APPS["Applications"]
    A1["Cloud apps via SAML or OIDC"]
    A2["Apps via SCIM provisioning"]
    A3["Custom APIs using tokens"]
  end
  U1 --> AUTH
  U2 --> AUTH
  U3 --> AUTH
  AUTH --> POL
  AUTH --> UD
  POL --> AS
  HR --> UD
  AD --> UD
  UD --> PROV
  PROV --> A2
  AUTH --> A1
  AS --> A3
  AUTH --> LOG
  PROV --> LOG
  ADM --> POL
  ADM --> UD

Read the diagram left to right. People arrive at the authentication service. It looks the person up in the Universal Directory and asks the policy engine what rules apply. If sign-in succeeds, the org either sends the app a signed statement (for SAML or OIDC apps) or hands out tokens for APIs. Separately, the provisioning engine watches the directory and creates or removes accounts in connected apps. Every important step is written to the System Log. Admins change everything through the Admin Console or the API.

Agents and connectors

Some systems live inside a company’s own network and cannot be reached from the cloud directly. For these, Okta uses small programs called agents that run inside the network and make outbound connections to the org. Common agents connect to on-premises directories, to databases through provisioning connectors, and to older apps through a gateway. Because the connection is outbound, the company does not have to open inbound holes in its firewall.

The most common thing an org does is sign people in to apps. Let us follow that story slowly.

sequenceDiagram
  participant User as User in browser
  participant App as Application
  participant Org as Okta org
  participant Dir as Universal Directory
  User->>App: Open the application
  App-->>User: Redirect to Okta org sign in
  User->>Org: Request sign in page
  Org->>Org: Check for existing session
  Org-->>User: Ask for credentials
  User->>Org: Send password
  Org->>Dir: Look up user and verify
  Dir-->>Org: User found
  Org->>Org: Evaluate policies and MFA need
  Org-->>User: Ask for second factor
  User->>Org: Approve with authenticator
  Org-->>User: Redirect back with signed assertion or code
  User->>App: Present assertion or code
  App-->>User: Access granted

The journey in plain steps

People join, change roles and leave. A healthy org mirrors that story automatically, so access always matches reality.

Where user data comes from

In most companies the real truth about a person lives in a human resources system or an on-premises directory. The org imports or receives those records and stores them in the Universal Directory. A profile mapping says how fields travel, for example that the HR field “department” becomes the Okta field “department”. These mappings can run both ways, so the org can also write values back to other systems.

The life of a user account

Every user in an org has a status. Understanding the statuses explains most support questions.

flowchart LR
  S["Staged"] --> P["Provisioned"]
  P --> A["Active"]
  S --> A
  A --> L["Locked out"]
  L --> A
  A --> R["Password reset"]
  R --> A
  A --> X["Suspended"]
  X --> A
  A --> D["Deprovisioned"]
  X --> D
  D --> Z["Deleted"]

A staged user is created but has not been activated, which is useful for people who start next month. Provisioned means an activation message is waiting for the user. Active is the normal working state. Locked out happens after too many failed attempts. Suspended temporarily blocks sign-in without removing the account, for example during an investigation or leave. Deprovisioned ends access, and the user can then be deleted.

Provisioning to apps

When a user becomes active and belongs to a group assigned to an app, the org can automatically create an account in that app using SCIM or an app-specific connector. When the user changes department, attributes update. When the user leaves, the account is disabled or removed. This is often called the joiner, mover, leaver flow, and automating it is one of the biggest security wins an org gives you.

Signing people in is only half of the story. The other half is letting apps and APIs ask “what may this caller do?” That is the work of authorization servers.

What a token is

A token is a small, signed piece of data that proves something. An ID token says who the user is. An access token says what an app may do on the user’s behalf. A refresh token lets an app get a new access token without asking the user to sign in again. Because tokens are signed, an API can check them without calling the org every time.

Two kinds of authorization servers

On a custom server you define scopes, which are named permissions like “read invoices”, and claims, which are extra facts placed inside the token, such as the user’s department. You then write access policies and rules that say which apps may request which scopes, and how long tokens live.

Policies decide how hard it is to get in. Good policy design is the difference between a safe org and an annoying one.

How rules are picked

A policy contains one or more rules, each with a priority number. The org reads rules in order and uses the first one whose conditions match. A final catch-all rule handles everyone else. This means the order of rules matters a great deal, and a broad rule placed too high can hide a more careful rule beneath it.

Whoever can change an org can change who gets in. Careful sharing of that power is one of the most important design decisions.

Standard roles

Custom roles and resource sets

The standard roles are broad. When a team needs only a slice of power, a custom role bundles exactly the permissions needed, and a resource set limits those permissions to specific groups, apps or other objects. This supports least privilege, the rule that every person should hold the smallest amount of power needed for their job.

Should a company have one org or many? The answer shapes safety, cost and complexity for years.

Separate test and production

Because a change in production affects every user at once, teams keep at least one preview org for testing. The preview org has its own users, apps and settings. It is not an automatic copy of production, so teams must bring configuration across on purpose. Many do this with infrastructure-as-code tools such as the Okta provider for Terraform, with scripts that use the management API, or with careful manual checklists.

flowchart LR
  DEV["Developer org for experiments"] --> PRE["Preview org for testing"]
  PRE --> PROD["Production org for real users"]
  GIT["Configuration in version control"] --> PRE
  GIT --> PROD
  PROD -.->|"Lessons and incidents"| GIT

In this picture, the configuration lives in version control. Changes are first applied to the preview org, tested, reviewed by a second person and then applied to production. Problems found in production flow back into the repository so the same mistake is not repeated.

One org or many orgs?

When several orgs are needed, a feature often called Org2Org lets one org act as a hub that signs users in to apps and to other orgs, so people still get a single place to start. This adds convenience but also adds moving parts, so use it only when the separation is truly required.

An identity org is a high-value target. If an attacker controls it, they control access to everything behind it. These measures protect the heart of the system.

Habits that help

• Protect admins most. Require the strongest factors for administrators and review admin lists often.
• Prefer scoped access over static keys. Static API tokens act like the user who made them and can be hard to track. OAuth-based access with named scopes is easier to limit and audit.
• Restrict where admins sign in from. Network zones can limit admin access to known networks.
• Control embedding. Trusted origins and redirect addresses should list only the sites that really need them.
• Review the log. Many incidents leave early hints that nobody read.

You cannot protect what you cannot see. The org writes a detailed diary of everything that happens, and it is your best friend during an incident.

The System Log

The System Log records events such as sign-ins, failed attempts, password resets, policy changes, app assignments and admin actions. Each event says who did what, to which object, from where and with what result. It can be searched in the Admin Console and read through an API. Okta typically keeps it for around ninety days, which is shorter than many audit rules require, so most companies export it.

Getting logs out

What to watch

A shared service protects itself and its other customers with limits. Knowing them early prevents mysterious failures later.

Rate limits

Okta limits how many requests your org may send to each API endpoint in a given period. The limits apply per org and are grouped by type of endpoint, so heavy use of one endpoint does not necessarily block another. Each response includes headers that say what the limit is, how many calls remain and when the count resets. When you go over, the org answers with a “too many requests” error.

The limits depend on your plan and on the endpoint, and they change over time, so always read the current documentation instead of memorizing numbers.

Living politely within limits

No design is perfect. An honest look at the strengths and costs of the org model helps you decide where to lean.

Teams that run orgs for years end up repeating a few good arrangements and avoiding a few painful ones.

Patterns that work

Anti-patterns to avoid

If you remember only a short checklist, make it this one.

Best practices

• Plan the org structure first. Decide how many orgs you need and why before creating apps and policies.
• Use a custom domain so users see your own name and phishing pages are easier to spot.
• Automate joiners, movers and leavers from the HR source, and test the leaver path regularly.
• Make strong, phishing-resistant sign-in the default for admins and for sensitive apps.
• Name things clearly. Use consistent names for groups, apps and policies so anyone can understand them.
• Document every policy with who owns it and why it exists.
• Back up knowledge, not just data. Keep exported configuration and runbooks outside the org.
• Review access quarterly. Check admins, API tokens, app assignments and unused apps.
• Prepare for outages. Know how a critical app signs in if the org is unreachable, and keep break-glass access ready.

Common mistakes beginners make

The ideas above become clearer when you see them in everyday company situations.

A sensible rollout path

An org can ask people to prove who they are in many different ways. Choosing the right mix decides how safe and how pleasant sign-in will feel.

The three kinds of proof

Security people group proof into three families. Something you know, like a password. Something you have, like a phone or a hardware key. Something you are, like a fingerprint or a face scan on your device. Multi-factor authentication, often shortened to MFA, means asking for proof from at least two different families. Two passwords are not MFA, because both are things you know.

The common authenticators

Why phishing resistance matters so much

Most attackers do not break the maths. They trick people. They build a copy of the sign-in page and wait for a user to type the password and the one-time code. A phishing-resistant authenticator checks the real web address as part of the proof, so on a copy-cat page it simply does not work. Moving administrators and sensitive apps to such authenticators removes the most common path of attack.

Recovery: the forgotten back door

Every strong sign-in method needs a way back in when a user loses a phone or a key. If recovery is weak, attackers simply use recovery instead of the strong method. Good practice is to let users enroll more than one authenticator, require strong proof for resetting factors, involve a verified identity check for help-desk resets, and log every recovery event for review.

Assurance levels

A helpful way to think is in levels of assurance. Low-risk apps may accept a password plus one extra factor. Medium-risk apps may need a device that the company manages. High-risk apps and admin tools may need a phishing-resistant authenticator on a healthy device, with a recent sign-in. Authentication policies per app let you express these levels in plain rules instead of one setting for everything.

An org is only useful once apps trust it. Here is how that connection is chosen and built.

The integration network

Okta keeps a large catalog of ready-made app integrations, called the Okta Integration Network. For thousands of popular apps, an administrator picks the app, fills in a few settings and assigns users or groups. The catalog entry already knows which protocol the app speaks and which attributes it needs. For anything not in the catalog, an administrator can create a custom integration using SAML, OIDC or another method.

flowchart TD
  Q["New application to connect"] --> A{"Does it support OIDC or SAML?"}
  A -->|"Yes"| B{"Is it a modern web or mobile app?"}
  A -->|"No"| C["Use password vaulting or a gateway"]
  B -->|"Yes"| D["Choose OIDC"]
  B -->|"No, business app"| E["Choose SAML"]
  D --> F{"Does it support SCIM?"}
  E --> F
  C --> F
  F -->|"Yes"| G["Enable automatic provisioning"]
  F -->|"No"| H["Manage accounts by import or by hand"]
  G --> I["Assign groups and set an app sign in policy"]
  H --> I

The diagram starts with one question: does the app understand a modern sign-in language? If yes, choose OIDC for newer web and mobile apps and SAML for classic business apps. If the app is old and understands neither, the org can store the user’s password securely and fill it in on the sign-in page, a method often called secure web authentication, or it can place a gateway in front of the app. Next, ask whether the app supports SCIM. If so, turn on automatic provisioning. Finally, assign groups and choose the sign-in policy.

Mapping attributes

Apps often need facts about the user, such as email, department or a role name. The org sends these as attributes or claims. You decide which attributes each app receives, and you can build new ones from expressions. Sending only what the app truly needs is a privacy habit and a security habit, because less data in a message means less data to leak.

Trust and certificates

For SAML, the org signs each message with a private key. The app holds the matching public certificate and uses it to check the signature. Certificates expire, so someone must own their renewal. A forgotten expiry date is a classic cause of sudden sign-in failure for one app. Put certificate dates in a shared calendar and review them each quarter.

The org is rarely the first place where user records exist. It must get along with the systems that came before it.

Common sources of users

Who owns each attribute?

A frequent source of bugs is two systems that both believe they own the same field. For each attribute, decide on exactly one owner. If HR owns “department”, then nobody should edit it by hand in the org, or the next sync will overwrite the change and confuse everyone. Profile mappings make these ownership rules visible, by showing which direction each field flows and when.

Matching and duplicates

When users come from several sources, the org needs a rule to decide whether two records are the same person. It may match on email or on an employee number. Weak matching rules cause duplicates, or worse, merge two different people into one account. Pick a stable, unique value that never changes, and avoid using names, which can repeat or change.

Passwords and the move to passwordless

Some firms start by letting the org check passwords against their old directory, then slowly move users to modern authenticators so that passwords matter less. The aim is to reach a state where most sign-ins use device-bound proof and the password is only a backup or is removed altogether.

Sometimes the built-in settings do not fit the exact business rule. Orgs offer several ways to add your own logic without breaking the service.

Four ways to extend

Inline versus event

The difference between inline and event hooks is timing. An event hook is like a doorbell camera that sends you a notification after the visitor has already rung. An inline hook is like a doorman who must phone you before letting a visitor in, so the visitor waits for your answer. Because inline hooks sit in the path of a user action, they must answer fast and reliably. A slow or broken inline hook can make sign-in slow or fail.

Automation that pays for itself

• Access reviews. Regularly ask managers to confirm who still needs which app.
• Offboarding. When HR marks someone as leaving, suspend the account, revoke sessions, remove access and open tickets for devices.
• Admin alerts. When an admin role is granted, post to a security channel.
• Onboarding. When a new hire joins a team, add the right groups and send a welcome message.

Keep extensions healthy

Every custom piece is something your team must maintain. Document why it exists, who owns it, how to test it in the preview org and what to do if it fails. Remove extensions that are no longer used. The best org is one in which built-in features do most of the work, and custom code handles only the real exceptions.

Because so many apps depend on the org for sign-in, you should plan for the day something goes wrong, whether the cause is on the vendor side or your own.

Two kinds of trouble

Problems fall into two groups. The first is a service problem, where the shared cloud service is slow or unreachable in your region. You cannot fix it yourself, but you can prepare for it. The second is a configuration problem, where someone on your own team changes a rule or a certificate and many people are suddenly locked out. Surveys of identity incidents often find that configuration mistakes are more frequent than service failures, so most of your protection should aim at safe changes.

Preparing for service problems

• Subscribe to status updates so your team hears of an incident from the vendor before users complain.
• Know what keeps working. Users who already hold an app session may continue until it expires, while new sign-ins may fail. Learn which of your apps behave which way.
• Keep emergency access. Critical systems such as the cloud console and the network should have a break-glass path that does not depend on the org.
• Prepare a message. Have a template ready that tells staff what is happening, what still works and where to find updates.

Preparing for configuration problems

Short answers to the questions people ask most about orgs.

You began with a building full of apartments. You now know what lives inside one apartment and how to run it well.