If you only read one chapter, read this one.

An app sign-on method in Okta is the technical way Okta proves a person’s identity to one particular application. Okta knows who the person is. The application does not. The sign-on method is the agreed language that Okta uses to tell the application, “This is Priya, and I have checked her.”

Okta supports several such languages. The most important are:

• SAML 2.0: a long-established standard used by thousands of business applications.
• OpenID Connect (OIDC): a newer, lighter standard that suits modern web apps, mobile apps and single-page apps.
• Secure Web Authentication (SWA): a fallback for older apps that only know usernames and passwords. Okta stores the credentials and fills in the sign-in form.
• WS-Federation: an older Microsoft-flavored standard still found in some Microsoft-centered setups.
• API Services: not for people at all, but for software talking to software, using OAuth 2.0.

The golden rule: choose the most modern method the app supports. OpenID Connect or SAML where possible, SWA only when nothing better exists.

Three ideas get mixed up all the time. Let us separate them early.

Sign-on method: how identity is delivered

The sign-on method decides the format and path by which proof of identity travels from Okta to the app. It answers the question, “In what language does Okta speak to this app?”

Authentication policy: how strongly the person must prove themselves

Each app is also linked to a rule set, often called an authentication policy (older Okta setups call it a sign-on policy). The policy decides whether a person needs one proof or two, whether a managed device is required, whether certain networks are blocked, and how often the person must prove themselves again. The policy works the same way no matter which sign-on method the app uses.

Provisioning: whether the account exists in the app

Provisioning is about creating, updating and removing the user’s account inside the app. It is a separate switch from sign-on. An app can have fabulous single sign-on and no automatic account removal at all.

A short glossary makes every later chapter easier.

Identity provider and service provider

The identity provider (IdP) is the system that checks who the person is. In this guide, that is Okta. The service provider (SP) is the app that relies on the identity provider’s answer. In the OpenID Connect world, the same app is often called the relying party or the client.

Token, assertion and claim

A token is a small signed message that carries facts about the person. In SAML, this message is usually called an assertion. The facts inside, such as name, email and group, are called claims or attributes. Because the message is signed, the app can tell if anyone tampered with it.

Signing certificate and keys

Okta signs messages with a private key that only Okta holds. The app checks the signature using a matching public key, often shared as a certificate. If the app does not have the right certificate, it will refuse Okta’s messages, which is a classic cause of failed sign-ins.

Metadata

Metadata is a tidy file or web address that describes how one side wants to talk: its web addresses, its certificate and its supported features. Instead of typing a dozen settings by hand, you can often give the app Okta’s metadata, or give Okta the app’s metadata, and most settings fill themselves.

Redirect address

When Okta finishes checking a person, it sends their browser back to the app at a specific web address. Okta only sends people to addresses that were registered in advance. This protects against attackers who might trick Okta into delivering a message to the wrong place.

SP-initiated and IdP-initiated sign-in

In SP-initiated sign-in, the person starts at the app, and the app sends them to Okta. In IdP-initiated sign-in, the person starts at Okta, clicks the app’s tile, and Okta sends them to the app. Both are common. SP-initiated is generally considered safer because the app can tie the response to its own request.

Client ID and client secret

In OpenID Connect, an app is identified by a client ID, which is like its public name. Some apps also have a client secret, which is like a private password that proves it is really that app. Secrets must be guarded carefully.

Scope

A scope is a named permission the app asks for, such as “read the user’s basic profile” or “read the user’s email.” The person or the administrator approves what the app may receive.

Each method is a layer of history. Knowing the story explains the menu.

No one sat down and decided to confuse administrators. The different methods appeared because the web kept changing and because every app was built at a different time, by different people, with different needs. Okta supports all of them because real companies use apps from every era.

The practical result

Today a typical company has a mix: a few brand-new apps built on OpenID Connect, many established business tools that use SAML, a small crowd of old tools that need SWA, and a handful of internal services that speak to each other through OAuth 2.0 without any person involved. The sign-on method list lets one Okta organization serve them all.

Before diving deep, here is the whole menu on one page.

Methods that sit beside the main five

A few other app types appear in the console and are worth recognizing.

flowchart TD
    START["New app to connect"] --> Q1{"Is the app in the Okta catalog?"}
    Q1 -->|"Yes"| CAT["Use the catalog entry and follow its guide"]
    Q1 -->|"No"| Q2{"Does it support OpenID Connect?"}
    Q2 -->|"Yes"| OIDC["Choose OpenID Connect"]
    Q2 -->|"No"| Q3{"Does it support SAML 2.0?"}
    Q3 -->|"Yes"| SAML["Choose SAML 2.0"]
    Q3 -->|"No"| Q4{"Is it software calling software?"}
    Q4 -->|"Yes"| API["Choose API Services"]
    Q4 -->|"No"| Q5{"Does it only have a password form?"}
    Q5 -->|"Yes"| SWA["Choose SWA as a last resort"]
    Q5 -->|"No"| OTHER["Check for a gateway or ask the vendor"]
    

Even when an app appears in the catalog, the catalog entry has already chosen a method for you. Read its short setup guide so you know which one you are configuring.

Why the paid-plan question matters

One surprise catches many administrators: a vendor may support single sign-on only on its more expensive plans. The app may technically speak SAML, yet the setting stays hidden until the company upgrades. Before you plan a project, check the vendor’s pricing page or ask the account manager whether SAML or OpenID Connect is included. If it is not, you face a business decision: pay for the upgrade, accept SWA as a temporary bridge, or look for a different product. Writing the cost of staying with passwords, including the time spent on resets and the risk of forgotten accounts, helps leaders see why the upgrade may be worth it.

The workhorse of business single sign-on.

What it is

SAML stands for Security Assertion Markup Language. In a SAML setup, Okta is the identity provider and the app is the service provider. After checking the person, Okta creates a signed assertion: a statement written in XML saying who the person is and a few facts about them. The browser carries the assertion from Okta to the app, and the app trusts it because of the signature.

How a SAML sign-in travels

sequenceDiagram
    participant P as Priya in Browser
    participant A as App - Service Provider
    participant O as Okta - Identity Provider
    P->>A: 1. Open the app
    A-->>P: 2. Redirect to Okta with a sign-in request
    P->>O: 3. Arrive at Okta
    O->>O: 4. Check session, policy and second factor
    O-->>P: 5. Return a signed assertion
    P->>A: 6. Deliver the assertion to the app address
    A->>A: 7. Verify signature, audience and time
    A-->>P: 8. Sign Priya in
    

What you configure in Okta

When you create a SAML app integration, you meet a short list of settings. Each has a purpose, and learning them removes most of the mystery.

A worked example in words

Suppose the finance team buys an invoicing tool that supports SAML. The vendor’s help page says: the sign-in address is a certain web address, the audience value is a certain name, the username must be the person’s email, and the tool wants three attributes called first name, last name and role. Here is how an administrator turns that into Okta settings.

• Paste the tool’s sign-in address and audience value into the matching two boxes in Okta.
• Set the application username to the email address from the Okta profile.
• Add three attribute statements. Name them exactly as the tool expects, and map the first two to the profile’s first and last name.
• For the role attribute, create a group attribute statement that sends the person’s group names, so that members of “Finance Managers” arrive with a manager role in the tool.
• Download Okta’s metadata or certificate, and upload it to the invoicing tool.
• Assign the “Finance” group, and test with one manager and one regular user.

Notice how little is actually technical. Almost every step is copying a name from one side to the other. That is why a tidy checklist beats cleverness.

The two-way exchange

A SAML setup is a conversation in two directions. First you take values from the app and enter them into Okta (the sign-in address and the app’s name). Then you take values from Okta and enter them into the app (Okta’s sign-in address, Okta’s name, and Okta’s certificate). Both sides must agree on every value. A single typo, such as an extra slash at the end of an address, can break the whole thing.

Strengths of SAML

• Supported by a huge number of business applications, such as Salesforce, Box, GitHub Enterprise and Zoom.
• Well understood by security teams and auditors.
• No passwords reach the app.
• Group and attribute information can flow along with the sign-in.

Limits of SAML

• XML messages are heavier and harder to debug than the lighter JSON used by OpenID Connect.
• Not designed for mobile apps or modern single-page apps.
• Certificates expire, and an expired certificate causes sudden outages.
• Different apps interpret the standard slightly differently, so setup guides matter.

The modern choice for new apps.

What it is

OpenID Connect, usually shortened to OIDC, is a thin layer on top of OAuth 2.0. OAuth 2.0 handles permission (“this app may read the calendar”). OIDC adds identity (“and this is who signed in”). The app receives an ID token, a compact signed message in a format called a JSON Web Token, and often an access token that lets it call other services on the person’s behalf.

Four kinds of OIDC apps in Okta

The authorization code flow with PKCE

This is the modern recommended path for apps that sign people in. Rather than send real tokens through the browser where they might be seen, Okta first sends the app a short, one-time code. The app then goes straight to Okta behind the scenes and trades the code for the real tokens.

For apps that cannot hide a secret, such as mobile apps and single-page apps, a safeguard called PKCE (pronounced “pixie”) is added. The app invents a one-time secret for each sign-in and shows only a scrambled version at the start. At the end, it reveals the real one. If an attacker steals the code halfway, they cannot finish the trade.

sequenceDiagram
    participant U as User in Browser or App
    participant A as App - Client
    participant O as Okta Authorization Server
    U->>A: 1. Press Sign in
    A->>A: 2. Create one-time PKCE secret
    A-->>U: 3. Redirect to Okta with scrambled secret
    U->>O: 4. Sign in and complete second factor
    O-->>U: 5. Redirect back with a one-time code
    U->>A: 6. Deliver the code
    A->>O: 7. Trade code plus real PKCE secret
    O-->>A: 8. Return ID token and access token
    A->>A: 9. Verify the tokens
    A-->>U: 10. Signed in
    

What you configure in Okta

• Application type: web, single-page, native or service.
• Sign-in redirect URIs: the exact addresses where Okta may send people after sign-in. Keep this list short and exact.
• Sign-out redirect URIs: where to send people after they sign out.
• Grant types: which flows the app may use. Prefer authorization code, with PKCE where needed, and avoid older flows.
• Assignments: who may use the app.
• Client ID and secret: Okta creates them. Copy them carefully into the app and protect the secret.

Three tokens, three jobs

An OpenID Connect sign-in can produce more than one token, and each has its own purpose. Mixing them up is a very common beginner mistake.

• ID token: tells the app who just signed in. The app reads it once and uses it to create its own session. It is not meant to be passed on to other services.
• Access token: carries permission to call an API. It is sent along with each API request and expires quickly, often within minutes to an hour.
• Refresh token: lets the app quietly get a new access token without asking the person to sign in again. Because it lasts longer, the app must guard it carefully, and Okta can be set to rotate it so an old copy stops working.

Scopes and claims

The app asks for scopes such as “openid” (required for sign-in), “profile,” “email,” and sometimes “groups” or “offline access” for refresh tokens. Okta then fills the tokens with claims that match. If the app needs a custom fact, such as the person’s department or cost center, an administrator can add a custom claim.

Authorization servers

Every Okta organization has an org authorization server that supports basic sign-in. For protecting your own APIs, or for more control over claims and token lifetimes, Okta can offer custom authorization servers, which let you define your own scopes, claims and rules. Availability depends on the plan.

Strengths of OIDC

• Light, readable messages and friendly to developers.
• Designed from the start for web, mobile and single-page apps.
• Works well with APIs, because identity and permission travel together.
• Strong safeguards such as PKCE and short-lived tokens.

Limits of OIDC

• Many older business apps never added support.
• More moving parts to understand: scopes, claims, grant types and token lifetimes.
• Mistakes in redirect addresses or secrets cause confusing errors.

The helpful but old-fashioned fallback.

What it is

Some apps have no support for SAML or OpenID Connect. They only have a page where you type a username and a password. Secure Web Authentication solves this by storing the person’s credentials for that app in Okta, in encrypted form, and filling in the sign-in form automatically when the person clicks the tile. A small Okta browser extension does the typing.

Where the password comes from

Administrators can choose how the credentials are created for each SWA app. Common choices include letting users create and save their own, having the administrator set a shared or individual credential, or reusing the person’s Okta credentials for that app. Each choice has trade-offs. Individual credentials are better than shared ones, because shared credentials hide who did what.

When SWA makes sense

• The app is old, small or internal and offers no modern sign-in standard.
• You still want the person to enter through Okta, so MFA and session rules apply before the app opens.
• You need a temporary bridge while the vendor works on SAML or OIDC.

The weaknesses to understand

• Passwords still exist. The app keeps its own passwords, and an attacker who learns one can go directly to the app, bypassing Okta.
• Browser dependence. It needs the extension and supported browsers, so mobile and unusual setups can be awkward.
• Page changes break it. If the app changes its sign-in page layout, the form filler can fail.
• No attribute or group delivery. The app does not learn roles or groups from Okta.
• Weaker offboarding. Removing someone from Okta stops the form-filling, but the app’s own account may keep working if the password is known elsewhere.

Less common, but you will meet them.

WS-Federation

WS-Federation, often written WS-Fed, is an older federation standard associated with the Microsoft world. It does the same basic job as SAML: Okta, acting as the identity provider, sends a signed token to an app, which trusts it. You may see WS-Federation when connecting older Microsoft-centered services or applications built on older Microsoft identity technology. For some Microsoft integrations, administrators can pick WS-Federation or SAML. When both are available, follow the current guidance from Okta and Microsoft for that product, and test with a pilot group.

Bookmark apps

A bookmark app is simply a link tile. It opens a web address when clicked, and it does nothing about sign-in. It is useful for the company news page or an internal portal that has its own access control. Do not mistake it for single sign-on.

RADIUS

RADIUS is an old but still widely used network protocol. Devices such as VPN gateways and wireless controllers use it to ask a central server, “Should I let this user in?” Okta offers a RADIUS integration through a small agent installed on a company server. The agent receives the request, asks Okta to check the password and the second factor, and returns the answer.

Gateways for on-premises apps

Some older internal apps cannot speak SAML or OIDC at all, and they were built to trust special information added by a front-door server. A gateway product, such as Okta’s access gateway offering, sits in front of those apps, signs people in through Okta, and passes the identity to the app in the form it expects. This avoids rewriting old software.

Identity for custom-built company apps

If your own developers build a new internal tool, the best choice is almost always OpenID Connect, using an Okta-provided software kit for their programming language. They do not need to build a password system at all.

Not every sign-on involves a person.

Many tasks happen with nobody sitting at a keyboard. A reporting program pulls data at midnight. A billing service calls an inventory service. A script creates users in Okta every hour. These programs also need to prove who they are. For them, Okta offers the API Services app type, which uses the OAuth 2.0 client credentials flow.

How it works

The program holds a client identifier and a proof, such as a secret or a private key. It shows these to Okta’s token service. If everything is correct, Okta returns an access token that is valid for a short time and only for the scopes the program was granted. The program then shows this token to the API it wants to call.

Why it matters

• Programs get narrow permissions that can be listed and reviewed.
• Access tokens expire quickly, which limits the damage if one leaks.
• It is safer than long-lived API tokens that copy a person’s powers.
• It makes accounts for services clear in the logs, separate from human accounts.

The method delivers identity. The policy decides how hard it is to earn.

Every app in Okta is attached to a policy that works the same no matter which sign-on method is chosen. When a person clicks an app tile, or when the app redirects them to Okta, Okta consults the policy before issuing any assertion or token. Policy rules can look at who the person is, which groups they belong to, which device they use, which network they are on and how risky the sign-in appears.

Typical outcomes

Why this separation helps

Because policy and method are separate, you can upgrade security without touching the technical connection. If you decide that every finance app should require a security key, you change the policy once. You do not need to change any SAML or OIDC settings. Likewise, you can replace an app’s SWA connection with SAML, and the same strong rules keep protecting it.

Sessions and signing out

Two different sessions exist at once. The first is the person’s Okta session, which proves they signed in to Okta. The second is the app’s own session, which proves they are signed in to that app. They can last different lengths of time. If Okta keeps a person signed in for eight hours but the app ends its own session after fifteen minutes of inactivity, the person will bounce quickly through Okta again, usually without typing anything.

Signing out is harder than signing in. If a person signs out of Okta, are they also signed out of the apps? Not always. Some methods can send a “sign out” message to the app, and some apps ignore it. That is why short app sessions are valuable, because they protect people on shared computers even when a sign-out message is missed.

Rule order matters

Policies are read from top to bottom, and the first matching rule wins. A broad “allow” rule placed above a specific “deny” rule will defeat the deny. When you add a rule, always check where it sits in the list and test with a pilot account.

Turn the whole menu into a simple, repeatable decision.

Moving an app from SWA to a modern method

Many organizations start with SWA for speed and later want to improve. The move is usually safe if done in steps.

A complete app connection has more than one part.

When Priya joins the company, two things must happen for her to use the expense tool. She must be able to sign in (the sign-on method), and she must have an account inside the tool (provisioning). If only the first exists, her first sign-in may create an account on the fly in some apps, or may fail in others with an error such as “user not found.” If only the second exists, she has an account but no safe way to sign in.

Just-in-time accounts

Some apps support just-in-time creation. When a person arrives with a valid assertion for the first time, the app creates their account then and there, using the attributes in the assertion. It is simple, but it handles only creation. It does nothing about later updates or removal.

Provisioning for full lifecycle

For the full life of an account, Okta can create, update and deactivate accounts in the app, often through a standard called SCIM or through an app-specific connector. When Priya changes teams, her details in the app change. When she leaves, her app account is turned off.

The result is a clean pair: the sign-on method brings her in safely, and provisioning keeps her account tidy from her first day to her last.

Each method has its own typical weak spots.

SAML risks

The crown jewels of SAML are the signing keys. If an attacker steals them, they can forge assertions that look perfectly real, a technique known as Golden SAML. Security researchers described the idea in 2017, and public reports about the SolarWinds-related intrusions revealed in late 2020 described attackers using forged SAML tokens against on-premises federation servers. With a cloud identity provider, the vendor guards the keys, but you still protect certificates in apps, restrict who can edit SAML settings, and watch for unexpected certificate changes.

Another SAML risk is a weak check inside the app. The app must verify the signature, the intended audience, the expiry time and the issuer. An app that skips any of these can be fooled.

OIDC risks

The most common mistakes are sloppy redirect addresses, such as wildcards that let attackers redirect tokens to their own sites, and leaked client secrets stored in public code. Use exact redirect addresses, use PKCE for apps that cannot keep a secret, keep tokens short-lived, and avoid the older implicit flow that placed tokens directly into the browser address.

SWA risks

Because the app still has its own password, anyone who learns it can bypass Okta. Shared credentials remove accountability. A compromised browser extension or computer could expose filled-in credentials. Limit SWA to low-risk apps, require strong Okta sign-in first, and migrate when you can.

API Services risks

Secrets and keys for services tend to live in scripts and configuration files, where they can be copied, committed to public repositories or left in old backups. Store them in a secrets vault, rotate them, grant minimum scopes, and review which services still exist.

Risks that apply to all of them

• Over-broad assignments. Giving an app to “Everyone” when only Finance needs it.
• Local passwords left on. People or attackers can bypass Okta entirely.
• Weak policies. Even a perfect SAML setup is risky if the policy allows sign-in from anywhere with only a password.
• Unwatched changes. New apps, changed certificates and edited redirect addresses should raise alerts.

When sign-on breaks, a method-by-method checklist finds the cause fast.

Where to look

Okta’s System Log records sign-in events and many app-related messages. Start by searching for the person and the time. The entry often says what failed in plain words, such as a policy denial or a failed second factor. For SAML issues, administrators sometimes use a browser tool that shows the assertion that was sent, so they can compare it with what the app expects.

Numbers worth watching

• Number of apps by method. A growing SWA list is a warning.
• Days until certificate expiry for each SAML app.
• Sign-in failure rate per app, to spot broken connections early.
• Apps with local passwords still enabled.
• Service accounts and their last-used dates.
• Provisioning errors per app.

Habits that scale, and habits that hurt.

Helpful patterns

Anti-patterns to avoid

A checklist you can use for every new connection.

Best practices

• Pick the most modern method the app supports. OpenID Connect first, then SAML, then SWA only if necessary.
• Use the catalog entry when one exists. It saves time and avoids settings mistakes.
• Copy values exactly. Addresses, audience values and entity IDs must match character for character.
• Assign by group and keep an owner for every app.
• Attach a suitable policy and make the policy stricter for sensitive apps.
• Turn on provisioning whenever the app supports it, including automatic deactivation.
• Switch off local passwords inside the app wherever you can.
• Record certificate expiry dates and rotate certificates before they expire.
• Test in a preview organization first, or with a pilot group in production.
• Document each app: method, policy, owner, provisioning status and next review date.

A pre-flight checklist before you save

Pilots use a checklist before every flight, even though they have flown thousands of times. Administrators benefit from the same habit. Before you save and announce a new app connection, read through these questions slowly.

• Does the method match what the app vendor documents for this plan?
• Are the sign-in address, audience value and redirect addresses copied exactly, with no extra spaces or slashes?
• Which identifier will the app use to find the person, and is it stable over time?
• Which attributes and groups are being sent, and does the app really need every one?
• Which authentication policy protects this app, and is it strict enough for the data inside?
• Who owns the app, and who will review its access list?
• Is provisioning on, and does it also remove accounts?
• When does the certificate or secret expire, and where is that date written down?
• What is the way back if the pilot fails?

Answering these nine questions takes ten minutes. Skipping them can cost a whole morning of lost sign-ins for a department.

Common mistakes

• Mixing up the three questions. A policy problem gets blamed on the method, or a provisioning problem on sign-on.
• Choosing a method before reading the app’s guide. Vendors sometimes support a method only on certain plans.
• Typing values by hand. Use copy and paste or metadata files.
• Forgetting about sign-out. Test what happens when the person logs out of Okta or the app.
• Sending too many attributes. Share only what the app needs, because extra personal data increases risk.
• Treating a username as permanent. If the name format changes, accounts can mismatch. Prefer a stable identifier where the app allows it.
• Letting secrets live in public places. Never paste client secrets into chat or public code.
• Neglecting old SWA apps. They quietly pile up as the riskiest part of the estate.

Short stories to tie everything together.

You began with a screen full of unfamiliar acronyms. Now you can explain each one in a sentence: an app sign-on method is the language Okta uses to tell one application who a person is. The right choice makes sign-in smooth and safe, and the wrong choice leaves quiet risks behind. With a simple decision path, a few habits and a good checklist, you can connect apps confidently.