If you need to sign in SSO, you usually start from the application’s login page and select an option such as “Sign in with SSO” or “Single Sign-On.” You are then redirected to your organization’s identity provider, where you authenticate with your work or organization credentials. After successful verification, you are sent back to the application and granted access. The exact buttons vary by service, but the basic process is remarkably similar across business platforms.
Quick Answer: To sign in with SSO, open the application’s login page, choose Sign in with SSO, enter your company or organization information if requested, authenticate through your identity provider, complete MFA if prompted, and wait for the application to redirect you back.
What Does “Sign in With SSO” Mean?
SSO stands for Single Sign-On. It is an authentication method that lets one account and its authentication session provide access to multiple connected applications.
Instead of creating and remembering a separate password for every work application, you authenticate through a central identity provider. The application then trusts that authentication and allows you to continue.
For example, imagine that your company uses Microsoft Entra ID, Google Workspace, Okta, or another identity provider. You may already be signed in to that service when you open a business application. If SSO is configured correctly, the application can recognize your existing authenticated session and let you in without asking for another application-specific password.
This is why an SSO login can sometimes feel almost invisible: you click the SSO option, authenticate once, and are redirected into the application.
How to Sign in SSO Step by Step
The following process works as a general guide. Individual applications may use slightly different wording or require an organization-specific login URL.
1. Open the Correct Login Page
Start by visiting the official website or application you are trying to access.
Avoid clicking login links from unfamiliar emails or messages. If you already know the official address, enter it directly into your browser or use a trusted bookmark.
Look for a button labeled something similar to:
- Sign in with SSO
- Single Sign-On
- Continue with SSO
- Company Login
- Organization Login
- Sign in with your organization
- Continue with Microsoft, Google, Okta, or another provider
The wording depends on the software.
2. Select the SSO Login Option
Click the application’s SSO button rather than entering credentials into a separate local-password field.
Some services display SSO alongside traditional email-and-password authentication. Others automatically redirect you to an identity provider when you use your organization’s dedicated login URL.
For example, Zoom’s documented SSO process asks users to select Sign In with SSO, enter their company domain, and then continue to their organization’s identity provider.
3. Enter Your Company or Organization Information
Some SSO systems need additional information to identify your organization.
You may be asked for:
- Company domain
- Organization name
- Work email address
- Company-specific login URL
- Organization ID
If you do not know this information, check your organization’s onboarding documentation or contact your IT administrator.
Do not guess sensitive organizational information repeatedly. A wrong domain can send you to the wrong authentication environment or simply cause the login process to fail.
4. Authenticate With Your Identity Provider
After selecting SSO, you may be redirected to an identity provider (IdP).
The identity provider is the system responsible for verifying who you are. Depending on your organization, this could be a service such as Microsoft Entra ID, Google Workspace, Okta, or another enterprise identity system.
You may see a familiar company-branded login screen.
Enter your normal organization credentials when requested.
If you are already authenticated with the identity provider, you might not need to enter your password again.
5. Complete Multi-Factor Authentication if Required
Your organization may require MFA as part of the SSO authentication process.
For example, you might need to approve a notification on your phone, enter a one-time verification code, use a security key, or complete another authentication step.
SSO and MFA are not the same thing.
SSO reduces repeated authentication across connected applications, while MFA adds additional verification to establish that the person signing in is really the authorized user.
Using both can provide a convenient login experience while adding stronger protection.
6. Wait for the Redirect
After authentication succeeds, the identity provider normally redirects you back to the application.
You may briefly see a loading screen, a message saying authentication is being completed, or a browser redirect.
Do not repeatedly click the login button during this stage.
If everything is configured correctly, you should arrive at the application’s dashboard or the page you originally attempted to access.
7. Confirm That You Have the Correct Access
Successfully authenticating does not necessarily mean you have permission to use every feature.
For example, you might be able to enter an application but receive an “Access denied” message when opening a particular workspace, project, or administrative section.
That usually indicates an authorization or account-assignment issue rather than a basic authentication failure.
If this happens, contact your administrator and explain which application and resource you are trying to access.
What Happens Behind the Scenes During SSO Login?
The visible process may take only a few seconds, but several systems can communicate in the background.
A simplified SSO flow looks like this:
You → Application → Identity Provider → Authentication → Application Access
The application acts as the service you want to use. It relies on an identity provider to verify your identity.
Depending on the environment, SSO may use technologies such as SAML or OpenID Connect (OIDC). SAML is commonly used for enterprise web SSO, while OIDC provides an authentication layer built on OAuth 2.0.
The important point for an everyday user is that the application does not necessarily need to maintain a separate password for you. Instead, it can rely on an established trust relationship with the identity provider.
SSO Login vs. Traditional Login
Understanding the difference can make SSO less confusing.
| Feature | Traditional Login | SSO Login |
|---|---|---|
| Credentials | Often managed separately by each application | Usually managed through an identity provider |
| Passwords | Potentially many | Often one organizational credential |
| Authentication | Repeated across services | Centralized authentication |
| MFA | Depends on each application | Can be enforced centrally |
| User experience | More individual login screens | Fewer repeated prompts |
| Access management | Often distributed | Can be centrally managed |
SSO does not mean that you never authenticate again. Your organization can require reauthentication, MFA, device verification, or other security checks depending on its policies.
Common Reasons SSO Sign-In Fails
If you cannot sign in with SSO, don’t immediately assume your password is wrong. Several different problems can interrupt the authentication process.
Wrong Organization or Company Domain
Some platforms require a company-specific domain before they know which identity provider to use.
A typo in the domain can prevent the SSO flow from starting correctly.
Double-check the information provided by your employer or administrator.
Your Account Is Not Assigned to the Application
An organization may have SSO configured but still restrict individual applications to specific users or groups.
In that situation, authentication can succeed while application access fails.
Ask your administrator to confirm that your account has been assigned to the application.
Your SSO Session Has Expired
An existing identity-provider session may expire because of security policies, browser changes, inactivity, or administrative settings.
Try signing in again through the organization’s normal login process.
If you are repeatedly redirected between pages, completely closing the browser and starting a fresh session can sometimes help identify whether a stale session is involved.
MFA Is Blocking the Login
Check whether your organization requires an MFA approval, verification code, security key, or another authentication factor.
If you changed phones or lost access to your authenticator, you may need your administrator to reset your MFA enrollment.
Browser Cookies or Extensions Are Interfering
SSO often relies on browser sessions and redirects.
Privacy extensions, aggressive cookie restrictions, outdated browser sessions, or blocked redirects can interfere with the process.
Try these basic checks:
- Update your browser.
- Open a private/incognito window.
- Temporarily disable problematic browser extensions.
- Clear relevant site data if appropriate.
- Make sure cookies and redirects required by the service are not being blocked.
- Try the organization’s recommended browser.
Do not disable security software permanently just to make an SSO login work.
What to Do When You See an “SSO Configuration Error”
An SSO configuration error is different from simply entering the wrong password.
For employees, common causes include:
- Incorrect identity-provider configuration
- Missing application assignment
- Incorrect email or username attribute
- Expired or incorrect certificates
- Incorrect SSO or redirect URLs
- Misconfigured SAML settings
- Problems with OIDC configuration
- An account that has been suspended or deactivated
These issues usually require administrator access.
If you are an end user, take a screenshot of the error, note the exact time it occurred, and send that information to your IT or application administrator. Avoid changing technical SSO settings yourself unless you are responsible for administering the system.
Is SSO Safe?
SSO can provide strong security when it is correctly implemented and combined with appropriate access controls.
One important advantage is centralized authentication. Instead of every application independently handling your credentials, an organization can centralize identity management and security policies.
However, SSO is not a magic security shield.
If an attacker gains control of a user’s primary identity-provider account, that access can potentially affect multiple connected applications. This is why organizations commonly combine SSO with MFA, access policies, monitoring, device controls, and timely account deprovisioning.
NIST defines SSO as an authentication process in which one account and its authenticators can be used to access multiple applications, generally through federation.
SSO, SAML, and OIDC: What’s the Difference?
These terms often appear together, but they are not interchangeable.
SSO describes the overall sign-in experience or authentication approach.
SAML is a standard commonly used to exchange authentication information between an identity provider and a service provider.
OIDC, or OpenID Connect, is an authentication layer built on OAuth 2.0 and is widely used by modern applications.
You do not normally need to understand these protocols to sign in.
They become more important when you are configuring an application, troubleshooting an enterprise integration, or working as an identity administrator.
Quick Security Checklist for SSO Users
Before signing in, use this simple checklist:
- Confirm that you are on the legitimate application website.
- Use your organization’s normal SSO login route.
- Never share your password or MFA approval with another person.
- Be suspicious of unexpected login links.
- Check the domain before entering credentials.
- Use MFA whenever your organization supports or requires it.
- Report repeated or suspicious authentication prompts to IT.
- Sign out of shared or public devices.
- Keep your browser and operating system updated.
A genuine SSO workflow should not require you to send your password to another person through email, chat, or a support message.
Frequently Asked Questions
What does sign in with SSO mean?
“Sign in with SSO” means that an application uses a separate trusted identity provider to authenticate you. Instead of maintaining a separate login for every connected application, you use your organization’s established identity.
How do I sign in using SSO?
Open the application’s official login page, choose the SSO option, enter your company or organization information if requested, authenticate through your identity provider, complete MFA if necessary, and wait for the application to redirect you back.
Why is my SSO login not working?
Common causes include an incorrect company domain, an account that has not been assigned to the application, expired sessions, MFA problems, browser issues, or an SSO configuration problem. If authentication succeeds but access is denied, your administrator may need to adjust your permissions.
Do I need a password to sign in with SSO?
Usually, you still have credentials associated with your identity provider. However, you may not need to enter them every time you open an application if you already have an active authenticated session.
Is SSO safer than a normal login?
SSO can improve security by centralizing identity management and allowing organizations to apply consistent authentication policies. Its security depends on implementation, access controls, MFA, monitoring, and protection of the primary identity-provider account.
Final Thoughts
Knowing how to sign in SSO makes workplace applications much easier to navigate. In most cases, the process is straightforward: open the correct login page, select SSO, identify your organization, authenticate through the identity provider, complete MFA if required, and return to the application.
When the process fails, focus on identifying where the failure occurs. A wrong organization domain, missing application assignment, expired session, browser problem, or administrator-side configuration issue can all produce different symptoms.
