To see why integrations matter, first look at life without them.

Many apps, many logins

A modern company runs on dozens of applications. There is email, chat, a customer system, a finance tool, a code hosting service, a learning platform, and more. Left alone, each of these apps keeps its own list of users and its own login rules. Every person ends up with a separate username and password for each one.

The cost of isolation

Isolation creates real problems. People forget passwords and call the help desk. Administrators must create accounts in every app one at a time when someone joins. When someone leaves, a forgotten account in an obscure tool may stay active for months. Security teams cannot see who has access to what, because the information is scattered across many separate systems.

The simplest honest answer, then the details.

The one-sentence definition

An app integration in Okta is the configured connection between Okta and one specific application, which lets Okta handle sign-in for that app and, optionally, manage the accounts inside it.

What the connection includes

An integration is not a single switch. It is a bundle of settings that together describe how Okta and the app will work together. These settings usually include how people will sign in, which people are allowed to use the app, what information about each person is shared, and whether Okta should create and remove accounts in the app automatically.

flowchart LR
  P[Person] --> O[Okta]
  O --> I1[Integration: Email]
  O --> I2[Integration: Chat]
  O --> I3[Integration: CRM]
  O --> I4[Integration: Finance]
  I1 --> A1[Email App]
  I2 --> A2[Chat App]
  I3 --> A3[CRM App]
  I4 --> A4[Finance App]
        

A short glossary makes the rest of this guide easier to follow.

For many apps, the connection is already prepared for you.

A catalog of ready-made connections

The Okta Integration Network is a large catalog of pre-built integrations for popular business applications. Each entry has been prepared so that the technical details of connecting that app to Okta are already filled in. An administrator searches for the app by name, adds it to their Okta setup, and follows a guided set of steps.

Why a catalog is so helpful

Without a catalog, every connection would be built from scratch, requiring careful reading of each app’s documentation. With the catalog, most of the hard parts are done in advance. The administrator mainly supplies details that are unique to their organization, such as the app’s web address for their company or a few settings.

What if the app is not in the catalog?

Many organizations also run their own custom-built applications, or smaller tools that are not listed. For these, Okta provides a way to create a custom app integration. The administrator chooses a sign-on method, enters the technical details, and builds the connection manually. The result works in the same way as a catalog integration, once it is configured correctly.

Different apps speak different languages, so Okta supports several.

Why there is more than one method

Applications were built in different eras. Older enterprise tools often speak one language, while newer web and mobile apps speak another. A good identity provider must be able to talk to both. Okta therefore offers several sign-on methods, and each integration is set up to use one that the app understands.

Preferred methods and fallbacks

Where possible, administrators prefer the standards-based methods, because the app never sees the person’s password. The password-filling method exists for apps that offer nothing else. It works, but it is a fallback, since the password still passes through a login form, and it depends on the app’s page layout staying stable.

Let us follow one person through one ordinary login.

Suppose Priya wants to open her company’s project board, which has been connected to Okta through a standards-based integration.

sequenceDiagram
  participant P as Priya
  participant A as Project Board
  participant O as Okta
  P->>A: Open the app
  A->>P: Redirect to Okta
  P->>O: Sign in and prove identity
  O->>O: Apply the app access policy
  O->>P: Signed confirmation with profile details
  P->>A: Present the confirmation
  A->>P: Access granted
        

Connecting an app does not automatically let everyone in.

People and groups

After an integration is created, an administrator decides who may use it. This is called assignment. An app can be assigned to individual people, but the far more common and scalable approach is to assign it to groups. Everyone who belongs to the group receives the app, and when someone leaves the group, the app is taken away.

The powerful chain

Assignments connect nicely with ideas we have already met. A profile attribute, such as department, can place a person in a group through a group rule. The group is assigned to the app. The result is a smooth chain: a fact about a person leads to a group, and the group leads to the app on their dashboard.

flowchart LR
  A[Profile: Department = Finance] --> R[Group Rule]
  R --> G[Finance Group]
  G --> S[Assigned to Finance App]
  S --> D[Tile appears on the dashboard]
        

Apps often need more than a name, and Okta decides what to share.

What apps ask for

Besides knowing who someone is, an app may want their email, display name, team, or location. Okta can include these details when it confirms identity, or send them when it creates an account. The administrator chooses exactly which details are shared.

Different apps, different names

The same fact is often called different things by different apps. One app expects a field named surname, another expects family name, and a third expects last name. Okta’s mapping feature translates between the central profile and the app’s expectations, so each app receives data in the shape it understands.

Share only what is needed

A guiding rule is to send each app only the information it truly needs. An email tool does not need a cost center. A finance tool does not need a home address. Sharing less reduces risk if an app is ever compromised.

Signing in is only half the story. Accounts must exist in the app first.

The account question

Many apps need a user account to exist before someone can sign in. Without automation, an administrator must create each account by hand. Provisioning is Okta’s way of doing this automatically. When a person is assigned to an app, Okta can create their account in that app using details from their profile.

Updates and removals

Provisioning does not stop at creation. When a person’s details change, such as a new title or team, Okta can push the update to the app. When the person leaves or loses the assignment, Okta can disable or remove the account. This last step, often called deprovisioning, is one of the most valuable features, because it closes doors that would otherwise stay open.

How apps accept these instructions

For this to work, the app must offer a way for Okta to manage accounts. Many apps support a common standard for this purpose, often called SCIM. Others provide their own programming interface that Okta’s catalog entry already knows how to use. Apps that offer neither cannot be provisioned automatically, and accounts may need to be created by other means.

Not every app deserves the same level of protection.

Rules per app

Okta lets administrators set sign-in rules for each app separately. A low-risk tool, such as a company news page, might allow a quick sign-in from a known device. A high-risk tool, such as payroll, might always require a strong second proof, regardless of where the person is.

What a policy can consider

Policies can take into account who the person is, which groups they belong to, what device they are using, where they are connecting from, and how strong their sign-in method is. This lets organizations match the strictness of the check to the sensitivity of the app.

Apps come in different shapes, and the shape affects the setup.

An honest look at both sides helps you plan wisely.

Thinking about the single front door

Putting many apps behind one front door is both a strength and a risk. It lets you protect that door with great care, but if it ever jams, many apps are affected at once. Wise organizations prepare emergency access for administrators and write down recovery steps in advance.

Stories make the benefits easier to see.

Most integration trouble comes from a few familiar habits.

A short plan for success, followed by quick answers to common questions.

No. The app stays as it is. The integration only connects it to Okta so Okta can handle sign-in and, optionally, account management.

You can usually create a custom app integration, as long as the app supports a standard sign-on method or can be bridged with a password-filling method.

Prefer a modern standard that the app supports, such as SAML or OpenID Connect. Use password filling only when nothing else is available.

No. Only people or groups you assign can use the app. Connecting it and assigning it are separate steps.

Provisioning is the automatic creation, updating, and removal of accounts inside an app. It is optional, and it only works if the app supports it.

If provisioning and deactivation are set up, Okta disables or removes the account automatically. Without it, someone must close the account by other means.

Yes. Each app can have its own sign-in policy, so sensitive apps can require stronger checks than low-risk ones.

Yes. Developers add a standard sign-in method to the app and register it in Okta, after which it behaves like any other integrated app.

With standards-based methods, no. The app only receives a signed confirmation. With password-filling methods, the login form does receive it, which is why those methods are a fallback.

For catalog apps, setup is usually guided and fairly simple. The harder part is planning groups, mappings, and policies, so spend your effort there.

We began with a mall of separate shops and ended with a central front door that all of them trust. An app integration is the configured connection between Okta and one application. It defines how identity is proven, who may enter, what details are shared, whether accounts are managed automatically, and how strictly each sign-in is checked. Catalog integrations make the common cases easy, custom integrations cover the rest, and group-based assignment keeps access aligned with real roles. Done thoughtfully, app integration turns a scattered collection of logins into one calm, consistent, and auditable system.