Sign in with your company account using SSO instead of a password

TL;DR — To sign in with your company account instead of a separate password, connect your company identity provider (IdP, the service that manages employee logins) to our app using either SAML or OIDC. The most common fix is entering the app's callback/ACS URL and Entity ID exactly as shown in our app, then pasting the IdP metadata, issuer, client ID, or certificate back into the app without extra spaces. Reading time: ~5 min

Goal

When you finish, people in your company can click "Sign in with company account" in our app, get redirected to your company login page, and return signed in without using a separate password for our app.

Prerequisites

• An admin account in our app with permission to change authentication or single sign-on settings
• An admin account in your company identity provider, such as Microsoft Entra ID, Okta, Google Workspace, or another SAML/OIDC provider
• Your company email domain, for example example.com
• A test user account in your company directory that is not your only admin account
• A private/incognito browser window for testing, so old login cookies do not interfere
• The values from our app's SSO setup screen: either ACS URL and Entity ID for SAML, or Redirect URI for OIDC
• If your provider asks for a sign-in URL format, have your app sign-in URL ready, for example https://app.yourservice.com/login

Steps

Step 1: Open the SSO setup page in our app

In our app, go to:

Settings → Security → Single Sign-On (SSO)

If your workspace uses a different label, look for Authentication, Identity, or Login Methods under settings.

What you should see: a page that shows either SAML and/or OpenID Connect (OIDC) setup options, plus values you can copy such as ACS URL, Entity ID, or Redirect URI.

Step 2: Choose SAML or OIDC and copy the app values

Use the protocol your company identity provider already supports for business apps. If both are available, use the one your IT team prefers. Copy the values exactly as shown on the SSO setup page.

Use one of these sets:

What you should see: you have the exact values copied from our app into a note, with no missing https:// and no extra spaces.

Step 3: Create the app in your company identity provider

In your identity provider's dashboard, create a new application for our app.

Use your provider's menu path. Common examples:

• Microsoft Entra ID: Applications → Enterprise applications → New application → Create your own application
• Okta: Applications → Applications → Create App Integration
• Google Workspace: Apps → Web and mobile apps → Add app → Add custom SAML app or OIDC app if available

Enter the values from Step 2 exactly:

• For SAML: paste the app's ACS URL into the provider's Reply URL or ACS URL, and paste the app's Entity ID into Identifier or Audience URI
• For OIDC: paste the app's Redirect URI into Redirect URI

If the provider asks for a sign-on URL for SAML and our app shows one, paste that exact value. If our app does not show one, leave the provider's optional sign-on URL blank.

What you should see: the new app is created in your identity provider and shows a setup page with metadata, issuer URL, client ID, or certificate details.

Step 4: Copy the identity provider details back into our app

Return to our app's SSO setup page and paste the values from your identity provider.

Use the matching fields:

If your provider gives you a metadata URL for SAML, use that instead of pasting certificate text when our app offers both options.

What you should see: our app accepts the values and enables a Test connection, Save, or Verify action.

Step 5: Assign a test user in your identity provider

Before turning SSO on for everyone, assign only a test user or test group to the new app in your identity provider.

Common menu paths:

• Microsoft Entra ID: Enterprise applications → <your app> → Users and groups → Add user/group
• Okta: Applications → Applications → <your app> → Assignments → Assign
• Google Workspace: assign access according to the app's access controls in the app settings

Use a test user account that is not your only admin account.

What you should see: the test user is listed as assigned to the app.

⚠️ If you enable required SSO for all users before testing, you can lock people out, including admins. Keep password login or a break-glass admin account available until verification succeeds.

Step 6: Test the sign-in flow from a private browser window

Open a private/incognito window and go to your app's sign-in page. Click the company sign-in option, or if your app supports domain discovery, enter your work email address.

Expected flow:

[User Browser] ---- 1. open sign-in ----> [Our App]
[Our App] ---- 2. redirect to SSO ----> [Company IdP]
[Company IdP] ---- 3. sign in ----> [User Browser]
[Company IdP] ---- 4. assertion/token ----> [Our App]
[Our App] ---- 5. signed in ----> [User Browser]

What you should see: after signing in on your company login page, you return to our app already signed in as the test user.

Step 7: Turn on SSO for your company domain

After the test succeeds, enable SSO for your company domain in our app.

In our app, go to:

Settings → Security → Single Sign-On (SSO) → Enable SSO

If there is a domain field, enter your company domain exactly, for example:

example.com

If there is an option for login behavior, choose the literal option closest to Allow SSO and password during rollout first. After rollout is complete, you can switch to Require SSO.

What you should see: SSO shows as enabled for your domain, and the app displays your company login option on the sign-in page.

Verify it works

Run these checks end to end:

1. Open a private/incognito browser window.
2. Go to your app sign-in page.
3. Enter a company email address such as:

alex@example.com

1. Click the company sign-in button if shown.
2. Sign in on your company login page.

Expected result:

• You are redirected to your company identity provider
• After successful company login, you return to our app signed in
• You do not need to enter a separate password for our app
• If SSO is enabled by domain, another user with the same company domain sees the same redirect behavior

If your app has an audit log, also check:

Settings → Security → Audit Log

Expected result: a successful SSO login, SAML login, or OIDC login event for the test user.

Common pitfalls

The callback URL or ACS URL was pasted incorrectly

Mistake: the ACS URL or Redirect URI was entered with a typo, missing path, or wrong https://.

Symptom: after company login, you see an error like redirect_uri_mismatch, Reply URL does not match, or a generic sign-in failure.

Fix: copy the exact ACS URL or Redirect URI from our app again and replace the value in your identity provider.

The wrong identifier or audience was used for SAML

Mistake: the provider's Identifier/Audience URI does not exactly match the app's Entity ID.

Symptom: the identity provider login succeeds, but our app rejects the SAML response with an audience or issuer error.

Fix: paste the exact Entity ID from our app into the provider's Identifier or Audience URI field.

The certificate or metadata is old

Mistake: an expired certificate or outdated metadata URL/XML is still configured.

Symptom: users get a signature, certificate, or invalid SAML response error even though the URLs look correct.

Fix: in your identity provider, copy the current metadata URL or current X.509 certificate and replace the old value in our app.

The test user was never assigned to the app

Mistake: SSO is configured, but no user or group assignment was added in the identity provider.

Symptom: the user can reach the company login page but gets user not assigned, access denied, or returns to the app without access.

Fix: assign the test user or the correct group to the app in your identity provider, then test again.

Browser cookies are hiding the real result

Mistake: you test in a normal browser tab that already has an old app session or company login session.

Symptom: the login appears to skip steps, logs into the wrong account, or keeps showing the old password flow.

Fix: repeat the test in a private/incognito window, or sign out of both the app and your identity provider first.

SSO was required too early

Mistake: Require SSO was enabled for the whole company before a successful test.

Symptom: users or admins cannot sign in with their old password, and SSO is not working yet.

Fix: sign in with a break-glass admin account if available, switch the login mode back to Allow SSO and password, correct the SSO settings, and test again.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.