How to get SSO-like sign-in for SaaS apps without SAML

Some SaaS apps don’t support SAML, the standard that lets an app accept sign-in from an identity provider. Those apps can’t use single sign-on (SSO), one sign-in that opens many apps, in the usual sense. You can still get close: one-click sign-in, control over who may use the account, and a record of who used it. There are four ways to do it. They differ on whether people learn the password, what the record shows, and what each method assumes.

What “SSO-like” sign-in aims for

An identity provider, such as Okta or Microsoft Entra ID, holds each employee’s account and checks who they are. In SSO, it then tells the app that the person is verified. That only works if the app is built to accept the message. Microsoft’s documentation names two cases for its password-based alternative: the app doesn’t support SAML, or it signs people in with a username and password.

The goal has three parts. People don’t have to remember or pass around each app’s username and password. An admin decides who may use the account and can take that away when the work ends. And there’s a record of who used it and when. Microsoft’s page on shared accounts lists what goes wrong with the usual way of sharing: you can’t tell who has access or who used it. To remove someone, you change the password and send it to everyone again.

The four methods

1. Entra ID’s password-based SSO.
2. Okta’s Secure Web Authentication (SWA).
3. A shared vault in a password manager.
4. A tool that verifies the person and signs in for them without showing the password, often called an access management tool.

The first two have your identity provider fill in the login. Entra ID’s password-based SSO works with cloud apps that have a regular web sign-in page. Entra ID stores the app’s username and password encrypted and sends them to the app’s sign-in page. An admin can set the login for a person or a group; if they don’t, each person enters their own. For a shared account, the admin creates a group of the people who use it and sets the password for the group. Microsoft says those people don’t see the shared password. They only get permission to use it. For some apps, Entra ID can change the password on a schedule.

Okta describes SWA as a technology that gives single sign-on to outside web apps that don’t support SAML or similar standards. It has five ways to set the username and password. People can set their own, an admin can set them, or an admin can set one pair that everyone assigned shares, among others. When an admin sets the login, Okta turns off password reveal for that person. With the shared option, people can’t reveal the shared password, and only super admins and app admins can see or change it. The Okta Browser Plugin enters the login automatically when the person reaches the app’s sign-in page.

A password manager such as 1Password lets you share a vault with people or groups. In 1Password Teams, view access includes showing concealed passwords and copying them. 1Password Business treats View and Copy Passwords as a separate setting. The browser extension fills saved logins in on sign-in pages. What is a password manager? covers how they work and where they stop.

An access management tool verifies the person, then enters the password for them without showing it. Unlike an identity provider’s fill-in, a tool of this type doesn’t have to require an account in your identity provider. Which apps and devices they support varies by product. The only official page we checked for this type was Junify’s, so the fourth column covers Junify only.

The comparison

The record of who used the account comes from the method you sign in through, not from the app. Seeing Entra ID’s sign-in data in the Usage and insights report takes an Entra ID P1 or P2 license. The Okta pages we read don’t state which plan SWA needs.

Which one to choose

The first or second method does the job if everyone who uses the account is in your identity provider. A record of “who opened the app, and when” also has to be enough. If you already run Okta or Entra ID, you don’t need another tool for this. Shared admin logins that remain when you use Okta or Microsoft Entra ID covers what’s left over in that case.

If only people who may see the password use the account, a password manager tidies up how it’s stored and handed out. But people who saw the password still know it. So when someone’s work ends, you still change the password on the app.

If the account is used by people you won’t add to your identity provider, such as contractors or short-term staff, look at an access management tool. The same goes when you want a record by person and the first two methods aren’t available. Comparing ways for several people to use one shared account goes deeper into each method.

What stays the same with all four

With every method, the app still has a password, and the app’s own records show only the shared account’s name. What is passwordless sign-in? covers methods that drop the password itself. If the app requires two-step verification, the method also has to handle the code. Microsoft’s and Okta’s pages for these features don’t say how they handle the app’s own two-step codes. Sharing two-step verification across a team covers the options.