In Okta, an app is a connection, not a download.

The plain-English definition

When most people hear the word app, they think of something installed on a phone. In Okta, the word means something different. An app in Okta is a saved connection between Okta and another piece of software, such as an email service, a customer database, a project tool, or an in-house website. That connection tells Okta how to sign people in to that software and who is allowed to use it.

You do not install the other software through Okta. Instead, you record how it should talk to Okta. Think of it as writing down the rules of a friendship: who the two parties are, how they will recognize each other, and which people are invited.

Why start with one app

Your first app teaches you the pattern that every later app follows: choose the app, pick the sign-in method, decide who gets it, test it, and then release it. Learning this pattern on a single, low-risk application builds confidence and reveals how your organization wants things done.

Because every extra password is an extra problem.

Without a central identity service, each application keeps its own list of users and passwords. People then juggle many logins, forget them, reuse them, and call the help desk. When someone leaves, administrators must remember to close each account separately. Connecting applications to Okta changes this picture by putting one trusted sign-in in front of many tools.

A few small words appear again and again. Learn them once and the rest is easy.

Every field has its own language, and identity is no exception. Do not worry if a word sounds technical. Each one has a simple meaning, and we pair each with a plain description. Keep this chapter nearby, because later chapters use these words often.

A few minutes of planning saves an afternoon of confusion.

The excitement of adding your first app can tempt you to dive straight into the Admin Console. A little preparation makes the process smoother. Gather the facts below before you start, and write them down so teammates can follow later.

You can pick a ready-made connection, or build your own.

In the Admin Console, the applications area offers two main ways to add an app. The first is browsing the catalog of ready-made connections. The second is creating a connection yourself for software that is not in the catalog. Knowing which road to take is your first real decision.

Road one: the catalog

The Okta Integration Network contains thousands of popular applications that have already been prepared to work with Okta. Choosing one from the catalog gives you a head start, because many of the technical details are pre-filled. You mostly confirm a few choices and follow the setup guidance.

Road two: create your own

If your software is built in-house or is not in the catalog, you can create an app integration yourself. You choose the sign-in method and fill in the technical details that the catalog would otherwise provide. This takes more care but gives complete flexibility.

This is the most important choice you will make for the app.

A sign-on method decides how Okta proves a person’s identity to the app. The right choice depends on what the app supports. In many catalog entries, the method is already suggested, but understanding the options helps you make sense of the screens and avoid surprises.

flowchart TD
    A[Does the app support modern sign-in standards?] -->|Yes, SAML| B[Use SAML 2.0]
    A -->|Yes, OIDC| C[Use OpenID Connect]
    A -->|No, only passwords| D[Use SWA password-based sign-in]
    B --> E[Assign people and test]
    C --> E
    D --> E
        

A friendly rule of thumb

If the app supports SAML or OpenID Connect, prefer one of those, because the app never sees the user’s password and security is stronger. Use password-based sign-in only when nothing better is available. It works, but it depends on stored credentials and a browser plug-in, and it gives you less control.

Let us follow one administrator, Meera, as she adds her first app.

Meera works in IT and wants to connect a team collaboration tool to Okta. She has chosen a catalog application and a small test group. Here is the story of what she does, in everyday language. The exact buttons may differ slightly in your Admin Console, but the order of thinking is the same.

Behind a single click, Okta and the app hold a short, polite conversation.

When a person clicks the app’s tile on the dashboard, a quiet exchange takes place in just a moment. Understanding this helps you troubleshoot later, because you will know which step might have gone wrong.

sequenceDiagram
    participant U as User
    participant O as Okta
    participant A as Application
    U->>O: Sign in to Okta dashboard
    O->>U: Show assigned app tiles
    U->>O: Click the app tile
    O->>O: Check assignment and policy
    O->>U: Send signed proof of identity
    U->>A: Present proof to the app
    A->>A: Verify proof
    A->>U: Open the app
        

Notice a few things. Okta first checks that the person is actually assigned to the app and that the rules allow access. Only then does it produce proof of identity. The app verifies that proof and opens a session. At no point does the app need to store a separate password for this person when a modern sign-on method is used.

Starting from the app instead

Some people will go straight to the app’s own website rather than the dashboard. If the connection is set up for it, the app will send them to Okta to sign in, and the rest of the conversation continues in the same way. Both starting points can work, and it is worth testing each one.

An app that is not assigned to anyone is invisible, like a locked cupboard with no key holders.

Assignment is the step that connects people to the app. You can assign the app to individual people, or to groups. Both work, but they suit different situations, and choosing well saves a lot of future effort.

Why groups are usually better

Imagine a new person joins the Finance team. If the Finance applications are assigned to the Finance group, simply placing the person in that group gives them everything they need. When they move to another team, changing their group changes their access. Nobody needs to remember a long list of individual assignments.

A good connection carries the facts the app needs, such as a name and an email.

When Okta tells an app who is signing in, it can also pass extra facts about the person, such as first name, last name, email address, or department. These are often called attributes or claims. The app uses them to recognize the person and sometimes to decide what to show them.

The most important attribute: a stable identifier

The app needs one reliable value that always points to the same person. Often this is the email address or a username. If this value ever changes, for example because of a name change, the app may think a new person has arrived and create a second account. Choosing a value that stays stable is one of the wisest decisions in the whole setup.

Not every app needs the same level of protection.

Okta lets you set rules, usually called authentication policies, that decide how a person must prove who they are before opening a particular app. For a low-risk app, a normal sign-in may be enough. For a sensitive one, you may require an extra step, such as a code or a push approval on a phone.

Choosing a sensible starting policy

For a first app, using your organization’s standard policy is usually the safest choice. It keeps the experience consistent for people and avoids the confusion of one-off rules. You can tighten the rules for sensitive apps later, once you understand how the policy options work.

Signing in is one thing. Having an account waiting inside the app is another.

Many apps need an account for each person. Provisioning means Okta creates that account automatically when someone is assigned the app, updates it when the person’s details change, and closes or disables it when access ends. This is optional and depends on whether the app supports it.

A quiet test now prevents a noisy complaint later.

Testing is where careful administrators earn their reputation. Before telling the whole company that a new app is ready, check that the connection really works from the point of view of an ordinary person. Do not test only as an administrator, because administrators sometimes have extra rights that hide problems.

When something goes wrong, a calm checklist beats guessing.

Even careful setups sometimes fail. The good news is that the same few causes explain most first-app problems. Okta also keeps a detailed activity record called the System Log, which notes sign-in attempts and what happened to each. Reading it is often the fastest path to the answer.

A friendly troubleshooting path

Each connected app is another door that Okta now guards, so guard it well.

Connecting an app is not only about convenience. It also becomes part of your company’s security picture. A few thoughtful habits keep that picture healthy, even when you are just beginning.

Connecting apps brings large benefits, and a fair view also shows the costs.

Experience teaches a few habits that make every later app easier.

Habits worth building

Mistakes to avoid

Quick answers to questions beginners ask most often.

Usually not. You add a connection record in the Admin Console. Some password-based connections need a small browser plug-in for end users, and some apps need settings changed on their own side.

You can create your own app integration and choose a sign-on method the app supports, such as SAML or OpenID Connect. This needs more technical detail, so confirm the app’s supported options first.

Prefer SAML or OpenID Connect when the app supports them, since the app never receives the user’s password. Use password-based sign-in only when nothing better is available.

The most common reason is that the app has not been assigned to those people or to a group they belong to. Check assignments first.

Groups are usually better for ongoing access, because membership follows job roles. Individual assignment suits testing or very small, one-off needs.

No. It is often wiser to get sign-in working first and add provisioning afterwards, changing one thing at a time.

Test with a normal user account, open the app from both the dashboard and the app’s own address, test an unassigned person, and review the System Log for your test sign-ins.

Common causes include an expired signing certificate or a change made on one side of the connection that no longer matches the other. Check certificate dates and compare settings.

No. Okta controls how people sign in, but the app still decides what each person can do inside it. Also remember to limit any old local password logins.

Yes. You can deactivate or remove the app connection when it is no longer needed. Review who depends on it first, and check whether local accounts in the app should also be closed.

Adding your first app in Okta means recording how one piece of software should sign people in and who is allowed to use it. You choose between a ready-made catalog entry and a custom connection, pick a sign-on method that the app supports, complete matching settings on both sides, assign a small pilot group, and test as an ordinary user. Along the way you decide which attributes to share, which sign-in rules to apply, and whether Okta should also manage accounts inside the app. Done carefully on a low-risk application, this first journey gives you a repeatable pattern you will use for every future connection.