SSO Integration: What It Means When You Sign In

SSO integration is the work of connecting an application to a central sign-in system, so that people use one organizational account to reach it instead of a separate username and password. SSO stands for single sign-on.

For you as a user, the visible result is that an app stops asking for its own password and instead sends you to your employer's or school's sign-in page. Your password lives there, and that app never sees it.

What are the two sides of an SSO integration?

Two terms come up constantly and are worth defining once.

The identity provider is the system that holds your account and verifies who you are. In most organizations that is the company or school directory sign-in you already use for email.

The service provider is the application you are trying to reach — the payroll tool, the learning platform, the ticketing system. It trusts the identity provider's answer instead of checking a password itself.

The integration is the trust relationship an administrator sets up between the two. Once it exists, the application will accept anyone the identity provider vouches for, and it will accept nobody else.

What actually happens when I click "sign in with SSO"?

1. You open the application and choose the single sign-on option.
2. The application sends you to your organization's sign-in page. The address in your browser changes to the organization's.
3. You sign in there with your organizational account and complete any additional verification.
4. The identity provider sends a signed statement back to the application saying who you are.
5. The application matches that identity to a user record it already holds, and lets you in.
6. For a while afterwards, opening other connected applications skips straight past the sign-in page, because your session at the identity provider is still valid.

Step five is where most failures happen, and understanding it explains error messages that otherwise look random.

Why does it say my account is not recognized after I signed in?

Because signing in succeeded and matching failed. You proved who you are; the application does not have a record for that person.

Common causes:

• You have no account in that application yet. Somebody has to create it, or the integration has to be configured to create accounts automatically on first sign-in.
• Your identity is arriving under a different address than the record uses. This happens after a name change, a marriage, or a department move, when the application still holds the old address.
• You are not in the group that the integration grants access to. Access is usually driven by group membership, and being in the directory is not the same as being in the group.
• You have both a personal account and an organizational account with similar addresses, and the browser used the wrong one.

None of these are fixed by resetting a password. The fix is a change to the record or the group, made by an administrator.

What should I do before contacting the help desk?

1. Read the error exactly and write it down. Errors from the identity provider and errors from the application look different, and which one appeared tells the help desk where to look.
2. Note whether the browser address bar showed your organization's domain when the error appeared. That places the failure on one side or the other.
3. Try a private browsing window. Old sessions and cached identities cause a large share of mismatch errors.
4. Sign out of every other account in that browser, including personal accounts.
5. Try a different browser or device. If it works there, the problem is local state, not the integration.
6. Confirm you are starting from the correct entry point. Many organizations have a portal page, and starting there rather than at the application avoids a whole class of errors.

Why do I keep getting sent back to the sign-in page?

A loop between the application and the sign-in page usually means the session cannot be stored or the two sides disagree about the request.

Check that your browser accepts cookies for both sites, including third-party cookies if the application requires them. Privacy extensions and strict tracking protection break single sign-on regularly.

Check the clock on your device. Signed sign-in statements are time-limited, and a device whose clock is significantly wrong will have every one rejected. Set the time to update automatically.

Check whether you followed a bookmark saved from inside the application. Deep bookmarks often skip the step that starts the process properly. Start from the portal or the application's front page instead.

What changes when I leave the organization?

Access ends when the identity provider stops vouching for you, usually within a short time of your account being disabled. That is one of the main reasons organizations adopt single sign-on — one action closes many doors at once.

Practical consequence: anything you will want after you leave has to be moved before your last day, and personal accounts should never have been linked to the organizational sign-in in the first place. If you have work in a connected tool that matters to you, export it while you can still sign in.

What does an administrator have to set up?

Useful to know even as a user, because it tells you what to ask for.

• A trust relationship between the identity provider and the application, exchanging certificates and addresses.
• A decision about which piece of information identifies a person — usually an email address or an internal identifier. Choosing the email address is convenient and breaks whenever someone's name changes.
• A rule for who may sign in, normally based on group membership.
• A choice about whether accounts are created automatically on first sign-in.
• A tested emergency route in, so an administrator is not locked out if the identity provider is unavailable.

If you are reporting a problem, mentioning which of these you suspect — "I think I'm not in the group" — gets you to the right person faster than "SSO is broken".