# What is single sign-on (SSO)?

Single sign-on (SSO) lets you sign in once and open all the apps you may use. It works only with apps that connect to your identity provider.

Updated: October 16, 2026

Single sign-on (SSO) is a way of signing in once and then opening every app you're allowed to use without signing in again.

## What is single sign-on?

Microsoft's documentation describes single sign-on as signing in once with one set of work login details and then opening every assigned app. The check is done by an identity provider, the service that holds your staff's accounts in one place, such as Okta or Microsoft Entra ID. It verifies the person and confirms who they are to the app. So people don't need a separate password for that app. [What is an identity provider (IdP)?](/guides/access-basics/what-is-idp) explains what that service does.

## Why does it work only with some apps?

With single sign-on, the app doesn't check a password. It accepts a message from the identity provider saying who the person is. Microsoft lays out the flow in four steps. The user opens the app, and the app sends them to Entra ID. Entra ID checks them and confirms who they are, and the app lets them in.

That message follows a standard. The common ones are SAML 2.0 and OpenID Connect, a newer standard for the same job. Microsoft calls this federation-based SSO. If the app wasn't built to accept one of them, it can't read the message, and single sign-on can't work.

## What about apps that don't support it?

Identity providers offer a different feature for those apps. Microsoft's password-based SSO is for apps that sign in with a username and password. Entra ID stores the login, encrypted, and sends it to the app. It works with any cloud app that has an HTML sign-in page, and an admin can set the username and password for a user or a group. Okta's Secure Web Authentication (SWA) gives single sign-on to web apps that don't support those standards. Okta fills in the username and password and submits them to the app's sign-in page. In both cases, the app's own password check stays in place.

| Method | What happens in the app | When you can use it |
| --- | --- | --- |
| SSO through SAML or OpenID Connect | The app accepts the identity provider's check | The app supports the standard |
| Filling in a stored password (Microsoft password-based SSO, Okta SWA) | The app gets its usual username and password | The app has a sign-in page |
| Link only (Microsoft Linked SSO, Okta Bookmark-only) | The app's sign-in page opens, and no sign-in is done for you | You only want the app listed in the portal |

## Can shared accounts use single sign-on?

Sign-in through SAML or OpenID Connect assumes each person has their own account in the identity provider. A shared account, one login that several people use, doesn't fit that. Okta lists five ways to set up the login for an SWA app. In one of them, users share a single username and password that an admin sets. So when an identity provider handles a shared account, it fills in the password rather than using single sign-on through a standard. [Managing shared accounts](/guides/shared-accounts) covers the wider set of options.


## Frequently asked questions

**Does single sign-on work with every app?**

No. Microsoft and Okta build it on standards such as SAML, and the app has to support them. For other apps, both offer a separate feature that fills in a stored password.

**Does single sign-on get rid of passwords?**

For connected apps, people stop keeping a separate password for each one. The sign-in to the identity provider stays, and so do the passwords for apps that don't connect.

**Can a shared account use single sign-on?**

Not through SAML, which assumes each person has their own account. Okta's SWA has a setting where users share one username and password an admin sets, so shared logins use the fill-in route.

**Is a feature that fills in the password a kind of single sign-on?**

Microsoft calls it password-based SSO and Okta calls it SWA, and both list it as an SSO option. But the app still checks its own password; nothing replaces that check.

## Sources

- [Microsoft Learn: What is single sign-on in Microsoft Entra ID?](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/what-is-single-sign-on)
- [Microsoft Learn: Add password-based single sign-on to an application - Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-password-single-sign-on-non-gallery-applications)
- [Okta Help Center: Configure Single Sign-On options](https://help.okta.com/oie/en-us/content/topics/apps/apps_overview_of_managing_apps_and_sso.htm)
- [Okta Help Center: SWA app integrations](https://help.okta.com/oie/en-us/content/topics/apps/apps-about-swa.htm)

## How Junify handles this

**Doing this by hand** Single sign-on and multi-factor authentication don't reach apps that can't connect to your identity provider, or accounts that stay shared. Those are left to manual work, and you have to track for yourself which accounts the tools cover.

**With Junify** Junify doesn't replace single sign-on. For apps without it and for shared accounts, Junify fills in the username and password an admin added, and the person never sees the password. They confirm who they are on their own phone and click the account, so each use is recorded by person. Signing in to Junify can also go through your identity provider.

Junify is an access management service for handing work in your web accounts to employees, contractors and outside teams without giving them the password. Each person verifies on their own phone and clicks a card to sign in. The password is never shown, and Junify records who used which account and when.

- [Try the demo](https://www.junify.com/bpo/try?lang=en&from=guide&cluster=access-basics&slug=what-is-sso)
- [Book a 30-minute demo](https://www.junify.com/bpo/demo)

## More on this topic

- [What's the difference between an audit log and audit evidence?](/guides/access-basics/audit-log-vs-evidence): An audit log is what a system records. Audit evidence is a log you can rely on: tied to a person, protected from change, kept for a set period, and reviewed.
- [What a browser extension can and can't control in access management](/guides/access-basics/browser-extension-access-control-scope): An extension works inside the browser it's installed in, on the sites it's allowed to run on. Other apps, other browsers and other devices are out of its reach.
- [What work data stays on a personal computer, and how to keep it off](/guides/access-basics/byod-leave-no-business-data): History, cookies, saved passwords, password manager copies and downloads. Pair company browser settings with logins that don't show people the password.