Before details, let us see the problem the catalog solves and the simple idea behind the solution.

The problem: every app speaks a slightly different dialect

A modern company uses dozens or hundreds of apps. Each app has its own way to accept sign-ins and its own way to create or remove user accounts. One app wants a particular web address for its sign-in callback. Another wants the user’s email in a special field. A third needs a secret token. If an administrator had to learn every dialect from scratch, connecting a single app could take days of reading and testing, and mistakes would be common.

The solution: build it once, share it with everyone

Okta and the software makers who sell the apps do the hard work one time. They write down the correct settings, test them, and publish the result as a catalog entry. After that, every Okta customer can add the same app in a few clicks. The catalog is therefore a shared library of tested connection recipes.

A few simple words are used again and again when people talk about the catalog. Learn them here once.

Catalog entry versus app instance

This pair of ideas is the most important one in the whole guide. A catalog entry is like a cake recipe printed in a book. An app instance is the cake you bake in your own kitchen. Many kitchens can bake from the same recipe. Each cake can have its own decorations, and eating one cake does not touch another. In the same way, thousands of organizations can add the same catalog entry, and each gets its own independent instance with its own settings.

You can even add the same catalog entry more than once in your own org. A company that has two separate accounts with the same vendor, for example one for each region, would create two instances.

An entry is more than a logo. It tells you exactly what the app and the org can do together.

The capabilities an entry may offer

Different entries support different abilities. A good entry page shows badges or labels that tell you which abilities are included, so you can check before you start.

The provisioning abilities in more detail

When an entry supports provisioning, its page lists which lifecycle actions work. Common ones include creating users, updating user attributes, deactivating users, importing new users and profile updates, importing groups, pushing groups, and syncing passwords. Not every app supports every action, so read the list carefully. An app that can create users but cannot deactivate them will leave old accounts behind, and you need to know that before you rely on it.

The catalog involves several players. Seeing how they fit together makes later chapters much easier.

flowchart LR
  subgraph VENDOR["Software vendor side"]
    ISV["Software vendor builds integration"]
    WIZ["Submission tool for OIN"]
  end
  subgraph OKTA["Okta side"]
    REV["Okta review and testing"]
    CAT["Shared OIN catalog"]
  end
  subgraph CUST["Your Okta org"]
    ADM["Administrator browses App Catalog"]
    INST["App instance with your settings"]
    POL["Policies and assignments"]
    DASH["End user dashboard tiles"]
  end
  APP["The application itself"]
  USERS["Employees"]
  ISV --> WIZ
  WIZ --> REV
  REV -->|"Approved"| CAT
  CAT --> ADM
  ADM --> INST
  INST --> POL
  POL --> DASH
  DASH --> USERS
  INST |"SAML or OIDC or SCIM"| APP
  USERS --> APP

Read the picture from the left. A software vendor builds and tests an integration and submits it through Okta’s tool for publishing. Okta reviews it. Once approved, it appears in the shared catalog. An administrator in a customer org browses the catalog and adds the entry, which creates an app instance inside that org. The administrator then sets policies and assigns users or groups. Assigned users see a tile on their dashboard, and clicking it signs them in to the real app. Behind the scenes, the instance and the app exchange sign-in messages and, if enabled, account changes.

The main parts

Knowing where to look and what to compare saves hours of confusion.

Where you can browse

There are two places. The first is the public integrations page on Okta’s website. Anyone can read it, even before becoming a customer, which is handy when you are comparing vendors. The second is the App Catalog inside the Admin Console, where an administrator can search, filter and add an app directly into the org. Menu names change from time to time, but the entry point is found under the applications section of the console, with a button to browse the catalog.

Filtering and comparing

You can search by app name or filter by the ability you need, such as a particular sign-in method or provisioning support. This is useful when you need more than a logo. If your security rule says that every app must support automatic account removal, filter for apps that offer deactivation. If your policy bans password vaulting, filter for federated sign-in only.

Behind every catalog entry is one of a few integration types. Understanding them tells you how strong, flexible and safe each one is.

SAML

SAML is a long-standing standard in which the org sends the app a digitally signed message that says “this person is who they claim to be”. The app checks the signature using a certificate it already trusts. Nothing secret travels in the message, and the app never sees a password. SAML is common in business software.

OpenID Connect

OIDC is a newer standard built on OAuth 2.0. It uses lightweight tokens and fits web apps, single-page apps and mobile apps well. If an app supports both SAML and OIDC, many teams choose OIDC for new work because tokens are easier for developers to handle and the standard is friendlier to modern clients.

Secure web authentication

Some older apps understand neither standard. For these, the org can store a username and password in encrypted form and use a browser add-on to fill them into the sign-in page. This is called secure web authentication, or SWA. It helps users avoid typing, but the app still holds its own password, and the sign-in does not get the benefits of federation. Treat it as a last resort.

API service integrations

This type is different. It is not about people signing in. It lets a vendor’s product, such as a security monitoring tool, act as a service and call Okta’s own APIs with permissions that the administrator approves. The administrator grants specific named scopes, so the tool gets only the access it needs.

Clicking “Add” looks simple. Let us open the lid and see what the org does behind the screen.

sequenceDiagram
  participant Admin as Administrator
  participant Org as Okta org
  participant Cat as OIN catalog
  participant App as Application admin page
  Admin->>Org: Browse App Catalog and select an app
  Org->>Cat: Fetch the catalog entry
  Cat-->>Org: Template with defaults and settings
  Org->>Org: Create app instance in the org
  Admin->>Org: Fill in label and app specific values
  Org-->>Admin: Show sign on details and metadata
  Admin->>App: Paste org details into the app settings
  App-->>Admin: Save and enable single sign on
  Admin->>Org: Assign groups and set policy
  Org-->>Admin: Tiles appear for assigned users

The story in plain steps

After setup, the catalog entry does its everyday job each time an employee opens the app. There are two ways the journey can begin.

Starting from Okta: the dashboard tile

The employee signs in to the Okta dashboard, which shows a tile for each assigned app. Clicking a tile makes the org build a signed message for that specific app and send the browser to the app with that message. The app checks the signature, finds the matching user account and lets the person in. This flow is called identity-provider-initiated, because the identity provider, Okta, starts it.

Starting from the app: the direct address

Many people never visit the dashboard. They type the app’s own address or follow an email link. The app sees an unknown visitor and redirects the browser to Okta with a request that says which app is asking. Okta signs the person in, then sends them back with the signed message. This flow is called service-provider-initiated, because the app, the service provider, starts it. Most apps support this one, and many prefer it.

The dashboard and the browser add-on

The end-user dashboard is the home page of all tiles. Employees can also install a browser add-on that fills in credentials for password-vaulted apps and gives quick access to tiles. For federated apps, the add-on is not needed, because the signed message does the work.

Sign-in is only half of the story. The other half is making sure the right accounts exist in the app at the right time.

Why provisioning matters

Without automation, an administrator in each app must create accounts by hand when someone joins and remove them when someone leaves. Hand work is slow and easy to forget. Forgotten removals are dangerous, because a former employee may keep access for months. With provisioning enabled, the org creates the account when a user is assigned and removes or disables it when the assignment ends.

sequenceDiagram
  participant HR as HR system or directory
  participant Org as Okta org
  participant Inst as App instance
  participant App as Application SCIM service
  HR->>Org: New employee record
  Org->>Org: Create user and add to groups
  Org->>Inst: User assigned through group rule
  Inst->>App: Create user request
  App-->>Inst: Account created with identifier
  Inst-->>Org: Store link between user and account
  HR->>Org: Employee leaves
  Org->>Inst: Assignment removed
  Inst->>App: Deactivate or delete request
  App-->>Inst: Account disabled

The picture shows the whole life of an account. The HR system announces a new person. The org creates the user, and group rules assign the person to the app. The app instance then calls the app’s SCIM service and asks it to create an account. The app replies with its own identifier, and the org remembers the link between the two. Months later, when the person leaves, the same chain runs in the other direction and the account is disabled.

Useful provisioning abilities

A sign-in message is not just “this is Maria”. It also carries facts about Maria. The mapping rules decide which facts travel.

Two profiles, one person

Every user in the org has an Okta profile with fields such as email, first name, last name and department. Every app has its own profile with its own field names. A mapping says which Okta field fills which app field. Catalog entries come with sensible default mappings. You can change them when your company stores data in unusual ways.

The application username

Each app needs a name by which it recognizes the user. Some apps use the email address. Others use a short login name or an employee number. The org lets you choose how the app username is built, for example from the email, or from a custom expression. If the app’s idea of the username does not match what the org sends, the app says the user does not exist, even though the account is there.

Extra attributes and roles

Apps often need to know a user’s role, team or country. You can send these as extra attributes in the sign-in message. Some apps even create roles automatically from a group name sent in the message, a feature often called just-in-time provisioning. Use it with care, because a wrong value can silently grant too much power.

The catalog is only as good as the entries inside it. Here is how software makers put theirs in.

Why vendors bother

Customers who use Okta expect to find their apps in the catalog. A vendor that is listed becomes easier to buy, since the buyer’s identity team can set it up quickly and safely. For that reason many vendors treat the listing as part of their product, in the same way that they treat a mobile app store listing.

The steps a vendor follows

What a customer should take from this

A review by Okta is a useful quality check on the integration itself, meaning that the sign-in works as documented. It is not a guarantee that the vendor’s whole product is safe, well run or right for your business. Your own vendor risk review still matters. Treat the catalog as a way to connect faster, not as an endorsement of every vendor.

Sometimes the app you need is not in the catalog, or it exists but does not fit. Then you have a second route.

Custom integrations

The Admin Console includes a guided builder, often called the App Integration Wizard, where an administrator can create an integration for any app that speaks a supported standard. You choose SAML, OIDC, password vaulting or a simple bookmark, and you type in the settings that a catalog entry would normally have pre-filled. The result is a private integration. It lives only in your org and does not appear in the shared catalog unless you choose to publish it.

flowchart TD
  S["Need to connect an app"] --> Q1{"Is it in the catalog?"}
  Q1 -->|"Yes"| Q2{"Does it offer the features you need?"}
  Q1 -->|"No"| C["Create a custom integration"]
  Q2 -->|"Yes"| U["Use the catalog entry"]
  Q2 -->|"Partly"| V{"Can you live without the missing feature?"}
  V -->|"Yes"| U
  V -->|"No"| C
  C --> Q3{"Does the app support SAML or OIDC?"}
  Q3 -->|"Yes"| F["Build federated custom app"]
  Q3 -->|"No"| W["Use password vaulting or a bookmark"]

Follow the diagram from the top. Start by checking for a catalog entry. If one exists and gives you the features you need, use it. If it exists but lacks something, ask whether you can live without it. If you cannot, or if no entry exists, build a custom integration. For a custom build, prefer SAML or OIDC. Fall back to password vaulting or a bookmark only when the app supports neither.

Adding an app is not the end. A well-run org manages each app through a full life, from request to retirement.

flowchart LR
  R["Request from a team"] --> RV["Risk and licence review"]
  RV --> T["Add to preview org and test"]
  T --> P["Pilot with a small group"]
  P --> G["Go live in production"]
  G --> M["Monitor and maintain"]
  M --> AR["Periodic access review"]
  AR --> M
  AR --> RT["Retire and remove"]

Why a life cycle helps

Without a process, apps pile up. Nobody remembers who asked for them, whether anyone still uses them, or what data they hold. Each leftover app is a possible entry point for an attacker, and each unused tile adds confusion for users. A life cycle gives every app a clear path and an owner.

Step by step

• Request. A team explains what the app is for and who will use it.
• Review. Security and legal check the vendor, the data involved and the licence. The review also decides which sign-in strength is needed.
• Test. The integration is built in a preview org and tested with sample users, including the leaver case.
• Pilot. A small, friendly group uses it in production and reports problems.
• Go live. Assignments are widened, with a clear message to staff.
• Maintain. Certificates, tokens and mappings are checked on a calendar.
• Review. Owners confirm every quarter or half-year that the app and its assignments are still needed.
• Retire. When an app is no longer used, provisioning is turned off, accounts are removed, and the instance is deactivated and later deleted.

Every connected app is a door into your company’s identity system. A few careful habits keep those doors safe.

Protect the strongest doors the most

Not every app deserves the same treatment. A cafeteria menu is low risk. A payroll system or a code repository is high risk. Use the app sign-in policy on each instance to ask for stronger proof, such as a phishing-resistant authenticator, for the sensitive ones. You can also limit access to managed devices or known networks.

Be careful with API service integrations

These integrations act as machines, not people. When you approve one, you grant it named scopes that let it read or change data in your org. A monitoring tool may only need to read logs. A tool that can also change users or policies is much more powerful. Read each requested scope, ask the vendor why it is needed, and keep the list as short as possible.

An integration that works today may break next month. Good watching turns surprises into small, early warnings.

The System Log as your diary

The org writes an event to its System Log whenever something important happens with an app. Examples include an app instance being created, settings being changed, a user being assigned, a user signing in through single sign-on, and a provisioning action succeeding or failing. Each event shows who did it, which app it concerned, when it happened and whether it worked. You can search the log by app name, by user or by event type.

The default retention is limited, commonly around ninety days. If your audit rules require longer, send the logs to your own storage or security tool as they are written.

What to watch for each app

Simple metrics worth tracking

Almost every integration problem falls into a small set of families. Learning them gives you a head start.

A calm method

The catalog is a great helper, but it is not magic. Seeing both sides helps you set the right expectations.

Teams that manage many integrations discover arrangements that work well and arrangements that cause pain.

Patterns that work

Anti-patterns to avoid

When time is short, work through this checklist.

Best practices

• Read the entry before you start. Check the protocol, the provisioning abilities and the licence needs on both sides.
• Prefer federation. Choose SAML or OIDC over password vaulting whenever the app allows it.
• Automate account creation and removal for apps that hold important data, and test the removal path.
• Name clearly. Use a naming scheme for instances, such as the app name plus the environment, so that nobody mixes up test and live copies.
• Track certificates. Put expiry dates in a shared calendar and renew with plenty of time.
• Send only needed attributes. Fewer fields mean less risk and simpler mappings.
• Keep a register. Every app has an owner, a purpose, a protocol and a review date.
• Review scopes and assignments on a fixed schedule.
• Document custom work. Anything you built yourself needs notes that another person can follow.

Common mistakes beginners make

Here are everyday situations that show the catalog at work.

A sensible rollout plan

The catalog is not only a list of business apps. It also holds connections that automate work, share security information and affect what your company spends.

Automation connectors

Okta offers a no-code automation tool called Workflows. Its building blocks are connectors, and many of them are listed in the same catalog. A connector for an app lets a flow read from it or act inside it. For example, a flow can wait for HR to mark a person as leaving, then disable the Okta account, post a message to the security team, and open a ticket to collect the person’s laptop. Each step uses a connector, and the catalog tells you which apps have one.

The advantage is that your team writes the logic once, in a visual builder, instead of maintaining a pile of scripts. The risk is that a flow acts with real power, so treat each flow like code. Give it an owner, review it and test it in a preview org.

Security partner integrations

Many security products are listed too, such as tools that watch devices, networks or suspicious behavior. They connect to the org in two common ways. Some read the System Log through an approved API service integration, so that they can spot attacks. Others exchange risk signals with the org, so that a device flagged as unhealthy can cause a sign-in policy to ask for stronger proof or to block access. This turns the org into part of a wider security picture instead of a lone gatekeeper.

Keeping partner connections healthy

Partner tools change over time. A vendor may rename a permission, retire an old connection method or ask for a new approval. Subscribe to the vendor’s release notes, assign a named contact for each partner tool, and test the connection after every major update. When a partner is dropped from your toolset, remove its integration, revoke its permissions and delete its stored secrets, so that no forgotten connection keeps reading your logs.

Thinking about cost

Every app in the catalog may add cost in three places. The first is the licence of the app itself. The second is any higher plan the vendor needs for single sign-on or provisioning. The third is the cost of your own time to set it up, watch it and review it. A tidy catalog of apps keeps all three under control.

Documenting why you chose each integration

Months after an app goes live, nobody remembers why a certain sign-in type, attribute list or provisioning option was picked. Keep a short decision note beside each integration in your register. Record the alternatives considered, the licence limits discovered, the scopes granted and the person who approved the choice. When a new teammate or an auditor asks questions, the note answers them quickly, and when the app is replaced the note shows exactly which settings must be rebuilt.

Choosing between similar apps

Teams often ask which of two similar products to buy. The catalog gives you an extra way to compare. Look at which one supports federated sign-in without a special plan, which one supports automatic removal, which one lets you send roles and groups cleanly, and which one has clear, current setup guides. A product that is hard to connect will also be hard to secure, and that hidden cost often outweighs a small difference in price.

Short answers to questions that come up again and again.

You started with a wall of sockets. You now know how each one is made, how to plug into it, and how to keep the whole wall safe.