One proof of identity, many doors. That is the whole idea.

Let us define the words first. A SaaS app is software-as-a-service, which means an application you use through a web browser that is run and hosted by another company, such as a chat tool or a customer database. Authentication is the act of proving who you are. Single sign-on (SSO) is a setup where you authenticate once with a trusted service, and that service then vouches for you to many apps, so you are not asked to log in again at each one.

Okta is an identity provider. That means it is the trusted service in the middle. It keeps track of who your people are, checks their identity, applies your security rules, and then tells each app, “Yes, this person is who they say they are, and you can let them in.” The apps do not need to see the password at all.

A day without SSO and a day with it

Picture Dana, who starts work at nine. Without SSO, she opens email and types one password, opens the chat tool and types another, opens the project tracker and types a third, and repeats this for the customer database and the document editor. By ten o’clock she has typed five passwords, forgotten one, and asked the help desk for a reset. She also keeps a sticky note under her keyboard, which nobody in security knows about.

With SSO, Dana signs in to Okta once, confirms a prompt on her phone, and lands on a dashboard of tiles. She clicks the chat tile and she is in. She clicks the tracker and she is in again. She never types an app password, never calls the help desk, and has nothing to hide under her keyboard. The company gains the same improvement in the background, because every one of those sign-ins now passes through one place where rules are applied and records are kept.

A short vocabulary makes everything after this chapter easier to read.

SSO has its own small language. You will meet these words again and again, so it is worth learning them now.

The benefits show up in daily life, in security, and in the work of the IT team.

Without SSO, every SaaS app keeps its own list of users and its own passwords. When someone joins the company, an administrator must create an account in every app. When someone leaves, the same administrator must remember to remove each account. Sooner or later one is forgotten, and a former employee keeps access for weeks or months.

Several moving parts work together every time someone clicks an app tile.

The big picture is simple. The user sits at a browser. Okta sits in the middle as the trusted service. The apps sit on the other side. When the user needs an app, the browser carries a proof from Okta to the app, and the app decides whether to trust it.

flowchart LR
  U["User"] --> D["Okta Dashboard or App Link"]
  D --> O["Okta: Sign-In, Policies, Sessions"]
  DIR[("Directory or Okta Users")] --> O
  O -->|"SAML or OIDC"| A1["SaaS App A"]
  O -->|"SAML or OIDC"| A2["SaaS App B"]
  O -->|"Browser plugin"| A3["SaaS App C"]
  O --> L["System Log"]

Notice that the apps never talk to your directory. They only talk to Okta, and only through the trust you set up for each app. This is why your internal network stays closed while dozens of cloud apps can still rely on the same people list.

Most popular apps are already prepared for Okta, so you rarely start from scratch.

The Okta Integration Network (OIN) is a large catalog of ready-made app connections. Thousands of well-known apps have been built and tested to work with Okta. When you pick one from the catalog, much of the setup is already filled in for you. You still need to enter a few details, such as your company’s account name at the app, but the hard parts are done.

Questions to ask a vendor before you commit

Not every SaaS app is equally ready for SSO. Before you sign a contract or roll an app out company-wide, a few direct questions to the vendor can save weeks of effort later.

• Which protocols do you support? Ask specifically about SAML 2.0 and OpenID Connect, and whether both flows can start at the app and at the identity provider.
• Which plan includes SSO? Confirm the price in writing, so there are no surprises at renewal time.
• Can we enforce SSO and turn off local passwords? Ask whether this applies to every user or leaves some exceptions.
• Do you support SCIM provisioning? This decides whether offboarding can be automatic.
• How do you handle certificate changes? Ask whether you can load more than one certificate at a time, which makes rotation smoother.
• Do you keep audit logs we can read? You will want them during investigations.

Why catalog apps are better

A catalog integration has been checked by Okta and the app’s vendor. The right fields are pre-filled, and the instructions match the real screens in the app. A custom integration is perfectly valid, but you take on the work of getting every setting exactly right, and you must keep the instructions up to date yourself.

Okta can connect to an app in three main ways. The right choice depends on what the app supports.

A protocol is an agreed set of steps two systems follow to talk to each other. Okta supports several for SSO. For most SaaS apps, the choice is among three.

flowchart TD
  S["Start with a new SaaS app"] --> Q1{"Does the app support SAML or OIDC?"}
  Q1 -- "Yes" --> Q2{"Is it in the Okta Integration Network?"}
  Q2 -- "Yes" --> C1["Add it from the catalog and follow the guide"]
  Q2 -- "No" --> C2["Create a custom SAML or OIDC app"]
  Q1 -- "No" --> Q3{"Does it have a normal web login form?"}
  Q3 -- "Yes" --> C3["Use SWA with the browser plugin"]
  Q3 -- "No" --> C4["Ask the vendor about SAML support or review alternatives"]

As a rule of thumb, choose the strongest method the app supports. SAML and OIDC are called federated methods because the app trusts Okta’s signed proof and never sees the user’s password. SWA is not federated. It still helps users, but the password does travel to the app, so it is the weakest of the three and is best kept as a fallback.

SAML is the most common SSO method for business apps, so it deserves a careful look.

SAML stands for Security Assertion Markup Language. In a SAML setup, Okta and the app first exchange a few pieces of information once, when you create the connection. After that, each sign-in is just a short, signed message passing through the user’s browser.

What you exchange during setup

Okta publishes these details as metadata, which is a small file or web address that describes the connection. Many apps can read the metadata directly, which saves you from typing each value by hand.

Why signing matters

Every assertion Okta sends is digitally signed. A digital signature is a mathematical stamp that proves two things: who sent the message, and that nobody changed it on the way. The app holds Okta’s public certificate and uses it to check each stamp. If the stamp is missing or wrong, the app refuses the sign-in.

There are two ways a sign-in can start. Both end with the same signed message.

An SSO sign-in can begin at the app or at Okta. When it begins at the app, it is called SP-initiated, because the service provider starts it. When it begins at the Okta dashboard, it is called IdP-initiated, because the identity provider starts it.

sequenceDiagram
  autonumber
  participant U as User
  participant A as SaaS App
  participant O as Okta
  U->>A: Open the app login page
  A-->>U: Redirect to Okta with a sign-in request
  U->>O: Arrive at Okta
  O->>O: Check session and sign-in policy
  O-->>U: Ask for password and extra proof if needed
  U->>O: Complete sign-in
  O-->>U: Send a signed assertion to the app
  U->>A: Deliver the assertion
  A->>A: Verify signature, audience, and time
  A-->>U: Create the app session and show the app

Reading the flow

In an SP-initiated flow, the user types the app’s address or opens a bookmark. The app notices that the user is not signed in and sends them to Okta with a request. Okta checks for an existing session. If the user already signed in earlier, they pass straight through, and this is the moment that feels like magic. If not, Okta asks for a password and any extra proof the policy requires. Then Okta sends the signed assertion back through the browser to the app, which checks three things: the signature, the audience, and the time. If all three are correct, the app signs the user in.

In an IdP-initiated flow, the user clicks an app tile on the Okta dashboard. Okta already knows who they are, so it creates the signed assertion right away and sends it to the app. There is no request from the app first. This is quick and easy, which is why dashboards are popular.

Both flows rely on the user’s browser to carry the message. The browser is only a messenger. It cannot change the signed assertion without breaking the signature, which is why the design is safe even though the message travels through a device you do not control.

OIDC is the modern cousin of SAML. It uses tokens instead of XML messages.

OpenID Connect (OIDC) is built on top of OAuth 2.0, which is a standard for letting one system act on behalf of another. OIDC adds a layer that tells the app who the user is. Instead of a signed assertion, Okta gives the app an ID token, a small signed package of facts about the user. The package format is often called a JWT, short for JSON Web Token.

The main pieces

The most common modern flow is called the authorization code flow. The user is sent to Okta, signs in, and is sent back to the app with a short-lived code. The app’s server then swaps that code for tokens by speaking directly to Okta, using its client secret. This way the tokens never travel through the browser where they might be seen, which is safer.

When OIDC is the better choice

OIDC is a natural fit for modern web apps, mobile apps, and anything that also needs to call APIs. If an app supports both SAML and OIDC, your team may choose based on what your developers know best and what the app’s vendor documents most clearly. For many standard business apps, SAML remains the default, and that is perfectly fine.

SWA is the fallback for apps that do not speak a standard SSO language.

Some apps, especially older ones, offer only a normal login page with a username box and a password box. They have no SAML and no OIDC. For these, Okta offers Secure Web Authentication (SWA). Okta stores the user’s login for that app in an encrypted form. When the user clicks the app tile, a small browser plugin fills the username and password into the login form and submits it, much like a password manager.

Limits of SWA

SWA is helpful, but it has honest limits. The app still holds its own password for each user, so those passwords can still be weak, reused, or leaked. The app is not told about your multi-factor rules, so Okta’s policies protect the tile but not the app’s own login page. And because it relies on the browser plugin, it works best on laptops and desktops and can be less smooth on phones.

The exact screens change over time, but the order of work stays the same.

Connecting an app is half the work. Deciding who gets it is the other half.

An app connection does nothing until people are assigned to it. An assignment tells Okta, “These users may use this app.” Okta then shows the tile on their dashboard and agrees to send signed proof for them. You can assign individual users, but the better habit is to assign groups, which are collections of users such as “Sales” or “Finance.”

The application username

Each app needs to recognize the person who arrives. The application username is the name Okta tells the app. Most often it is the user’s email address. This value must match exactly what the app has on file for that person. If Okta says “maria@company.com” and the app has “maria.lopez@company.com,” the app will say it cannot find the user, even though the sign-in itself worked.

Group hygiene

Assignments are only as clean as the groups behind them. Use clear names, such as “App-Chat-Users,” so anyone reading the list knows what a group is for. Remove old groups when projects end. Review each app’s assignments at least once or twice a year, so people who changed roles do not keep access they no longer need.

SSO makes access easy. Policies make sure the easy path is also a safe one.

One sign-in opens many apps, which is wonderful for users and also means that sign-in must be strong. If an attacker steals one password and SSO has no second check, they now reach every app at once. This is why SSO and multi-factor authentication belong together.

Multi-factor authentication (MFA) asks for two or more different kinds of proof, such as a password and a prompt on a phone. In Okta, rules called sign-in policies decide when to ask. Depending on your Okta version, they are called sign-on policies or authentication policies, and they can be set for the whole org or for each app.

Why users should not be asked too often

It may seem that more prompts always mean more safety, but that is not true. If people are asked for a second proof every few minutes, they grow tired of it and start approving requests without reading them. Attackers count on this habit. A good policy asks at the right moments, such as the first sign-in of the day, a sign-in from a new device, or a visit to a very sensitive app, and stays quiet the rest of the time.

The goal is a policy that people barely notice on a normal day and that stands firm on an unusual one. Review your prompt rates from time to time. If your users complain about constant interruptions, the policy likely needs tuning, not more strictness.

The layered approach

A strong setup works in layers. A general policy applies to everyone, and tighter rules apply to specific apps. A person may sign in once in the morning with MFA, then open ordinary apps all day with no further prompts. When they open the finance app, Okta may ask for a fresh proof, because that app’s policy demands it. The user feels a smooth day, and the company still gets a firm gate where it counts.

Getting in is only half the story. Knowing how access ends is just as important.

When a user signs in to Okta, Okta creates a session, which is a period of time during which Okta remembers them. When they open an app, that app creates its own, separate session. These two sessions have their own timers. This is the root of a surprise that catches many teams: ending someone’s Okta access does not always end their app sessions at the same instant.

flowchart TD
  H["New hire added to directory"] --> G["Added to groups"]
  G --> AS["Apps assigned by group"]
  AS --> T["App tiles appear on the dashboard"]
  T --> SSO["User signs in once and opens apps"]
  SSO --> M{"Role changes or leaves?"}
  M -- "Role changes" --> G2["Groups change and apps change"]
  G2 --> AS
  M -- "Leaves" --> D["Account deactivated"]
  D --> R["Okta access ends and app accounts are removed or disabled"]

What happens at offboarding

When an employee leaves, an administrator deactivates their Okta account, or the directory change does it automatically. The user can no longer sign in to Okta, and the app tiles disappear. They also cannot start new SSO sessions to any app. However, an app session that was already open may stay valid until the app’s own timer ends, which could be hours or days. If the app also has a separate local password, the user might still sign in directly, unless SSO is enforced.

To close these gaps, teams use three habits. First, they connect automatic provisioning, so that deactivating a user in Okta also disables or deletes their account in the app. Second, they enforce SSO in the app, so local passwords no longer work. Third, they set sensible session lengths for sensitive apps, so old sessions expire quickly.

Single logout

People often ask whether signing out of Okta signs them out of every app. This idea is called single logout. Support for it varies a lot between apps, and many apps do not fully support it. Plan on the assumption that users may need to sign out of sensitive apps separately, and tell them so clearly.

SSO answers “who is this person.” Provisioning answers “does this person have an account.”

SSO proves identity, but the app must also have an account for the person. There are two common ways accounts get created. With just-in-time (JIT) provisioning, the app creates an account the first time a user arrives through SSO, using the details in the signed message. With SCIM provisioning, Okta actively creates, updates, and disables accounts in the app ahead of time, using a standard interface called SCIM, short for System for Cross-domain Identity Management.

This guide focuses on the SSO side, which is the foundation. But if an app supports SCIM, turning it on is one of the best things you can do for security and for the IT team’s time. It turns “remember to remove access” into “access is removed automatically.”

SSO concentrates trust in one place, so that place must be protected carefully.

The strength of SSO is also its main risk. Because one sign-in opens many doors, an attacker who defeats that sign-in gets a lot. The answer is not to avoid SSO, since weak separate passwords are usually worse. The answer is to protect the single front door very well.

Threats to keep in mind

Phishing is a trick where a fake website copies a real sign-in page to steal passwords and codes. Session theft means stealing the small file that keeps a person signed in. Over-permissioned apps are apps that give people more rights than they need. Shadow IT means apps that employees sign up for on their own, outside your list, so Okta does not protect them. Each of these can be reduced with the habits above plus regular reviews.

Because so many apps depend on one sign-in, it is wise to plan for the day something breaks.

Okta is a cloud service run across many data centers, and it is built to stay available. Even so, any system can have problems, and so can the apps and networks around it. Good planning means you know what breaks, what keeps working, and what to do about it.

The emergency plan

Write a short runbook that answers four questions: who is told first, where to check the status of Okta and the app, how to turn SSO off temporarily for an app if truly needed, and how to reach an emergency account. Practice it once or twice a year. In an incident, a calm checklist is worth more than any clever idea.

What you cannot see, you cannot fix. Okta records a lot about every sign-in.

The System Log is Okta’s searchable record of events in your org. It shows who signed in, to which app, from where, and whether it worked. Event names and wording can vary between releases, so if a name does not match what you see, search by user, time, and app name. One event that often appears when a user opens an app through SSO is named user.authentication.sso.

Useful alerts

• An app’s success rate falls sharply within a short window.
• A signing certificate is within thirty days of expiry.
• A user is assigned to a highly sensitive app outside the normal process.
• Many failed sign-ins for one user, or one failed sign-in each across many users.
• A change to an app’s SSO settings, such as new URLs or a new certificate.

Send these logs to your security monitoring tool, if you have one, using Okta’s log streaming or event hooks. Combine Okta’s view with each app’s own audit log, since each side sees something the other does not.

SSO is a clear win for most companies, but it comes with honest costs.

Comparing the methods

The main trade-off is concentration. SSO puts your eggs in one very well-guarded basket. For nearly every company, that is much safer than keeping eggs in many poorly guarded baskets, as long as the single basket gets strong MFA, careful admin control, and a recovery plan.

A pattern is a habit that works. An anti-pattern is a habit that looks fine until it hurts.

Patterns that work

Anti-patterns to avoid

These habits separate a smooth rollout from a stressful one.

A short checklist before assigning an app to everyone

• Owner: Does a named person own this app’s integration?
• Method: Is it using SAML or OIDC, and if not, why?
• Usernames: Have you tested people whose names or emails are unusual?
• Policy: Does the sign-in policy match the app’s sensitivity?
• Enforcement: Do you know how to turn on SSO-only mode, and how to get back in if it fails?
• Offboarding: Have you tested what happens when a user is deactivated?
• Communication: Do users know what to expect and where to get help?

Mistakes seen again and again

These stories are illustrative, built from common patterns, to show the ideas at work.

Most SSO problems come from a short list of causes. Check these first.

A repeatable troubleshooting routine