Skip to main content

Understanding Domain Claims, SSO, and OAuth

Written by Brady Price

Login methods

Secureframe supports multiple ways for users to sign in. This article explains email-based sign-in, social login (OAuth), and Single Sign-On (SSO), including how domain claims fit into setup.

Choose the sign-in method that matches how your organization manages identity. Each option below covers what it is and how to set it up.

Email-Based Sign-In

What it is: Basic login using your work email with either:

  • A password

  • A magic link sent to your inbox

How to set it up
No setup required. This method is enabled by default unless restricted by an admin.

Social Login (OAuth)

What it is: OAuth allows users to log in using Google or Microsoft credentials. This is often shown as “Sign in with Google” or “Sign in with Microsoft.”

How to set it up:

  1. Go to the Integration tab on Secureframe as a Secureframe admin

  2. Connect your Google or Microsoft integration

    1. You must have appropriate permissions in the Google or Microsoft environment.

There is no additional cost to enable OAuth.

Single Sign-On (SSO)

What it is: SSO allows users to log in through a company-wide identity provider (IdP) like Okta, Azure AD, or Google Workspace using SAML. Users enter their email and are redirected to authenticate with your IdP.

How to set it up

  1. Go to Company Settings

  2. Select the Single-Sign On tab

  3. Claim your domain(s) (required for SSO setup)

  4. Follow the guided configuration flow for your IdP

There is an additional cost to enabling SSO.

Interactive Walkthrough

Interactive Walkthrough: Launch the interactive walkthrough to practice configuring SSO integration. Click the highlighted areas on each screen to move to the next step. This is not a play/pause video.


Claiming a Domain

Why it matters: Claiming your domain is required to set up SSO and control how users with company emails log in to Secureframe.

How to do it:

  1. Go to Company Settings

  2. Select the Single Sign-On tab

  3. Follow the instructions to claim and verify your domain(s)


What is SCIM, and How Does It Relate to SSO and OAuth?

SCIM (System for Cross-domain Identity Management) is a protocol that simplifies user lifecycle management by automating the creation, updating, and deactivation of user accounts across systems. When combined with SSO and OAuth, SCIM ensures that user access and permissions stay in sync with organizational changes, reducing manual effort and improving security.

Click here to learn more about SCIM and how to provision in your Secureframe instance.

If you have further questions or need assistance with domain claims, OAuth, SCIM or SSO setup, please contact our support team for guidance at [email protected]


Common Error Responses

If a user sees "Account not found" when signing in with Sign in with Microsoft (or Google), Secureframe cannot match their identity provider sign-in to an active personnel record. Common causes include: the user is Uncategorized in Personnel, the Office 365 integration is not connected, or the user's Microsoft account is linked to a different profile (such as a non-personnel record or a duplicate with a different email address). See the FAQ below for troubleshooting steps.

If you are currently seeing the “Needs admin approval” or "Approval required" message, please ask your admin to complete the reauthorization process and consent. This process may need to be carried out at either the global tenant level or the user level, depending on your tenant settings.

Screenshot 2025-06-11 at 11.00.26 AM.png

Below are Microsoft articles that provide detailed guidance on configuring consent settings:


Frequently Asked Questions (FAQ)

For cases where I truly need SSO to have more full control over login method, SAML, and centralized auth, why does SSO cost extra?

  • This is a pass through cost from our vendor on a per-connection basis.

  • You can use our free OAuth login options (Microsoft o365 and Google Workspace) if you just need basic login functionality. Consider purchasing SSO only if you need: Full control over login methods, SAML-based SSO setup, and or Centralized authentication management.

Important: Purchasing SSO is a single cost and will support multiple connections/integrations.

What happens to non-domain users when a customer enables SSO, would they get locked out?

  • No, they will not get locked out. Those non-domain users could still login with any other non-SSO method (google, password, magic link).

  • Any auth restrictions set by the admin like not allowing google/password login, etc. apply only to domain users.

Is there a way to restrict users from signing in with a password, so they can only use OAuth or SSO?

  • Yes, if you want to enforce sign-in exclusively via OAuth or SSO, you’ll need to claim your domain first. Once the domain is claimed, you can disable all other sign-in methods from the Company Settings. SSO Settings page.

What could be the reason for a user's status appearing active but Single Sign-On (SSO) not being enabled?
If a user’s status shows as active, but they are unable to log in using SSO (e.g., Microsoft) or OAuth, it’s likely due to one of the following reasons:

  • The user is uncategorized, meaning they have not been assigned an employment type (e.g., Employee, Contractor).

  • Without an employment type, users will not be placed into the appropriate access group, and therefore cannot log in via Microsoft SSO or email/password.

  • This can occur even if the user is marked as "active" in the system.

Head to the Personnel tab and make sure the user has an employment type assigned. Once categorized, their login method will be enabled based on your organization’s SSO configuration.

Why does a user see "Account not found" when signing in with Microsoft, even though they accepted the invitation and are using the correct Microsoft account?

  • This error means Secureframe cannot match the user's Microsoft sign-in to an active personnel record. Check the following in order:

  • 1. Confirm the user is categorized in Personnel. The user must be Active, Invited, and assigned an employment type (Employee or Contractor). Users marked Uncategorized cannot sign in via Microsoft OAuth, even if they appear active.

  • 2. Confirm the Office 365 integration is connected. Microsoft sign-in requires the Office 365 integration to be set up in Integrations. See Microsoft Office 365 (O365) for setup steps.

  • 3. Check for email mismatches or duplicate profiles. If the user was invited with one email (for example, [email protected]) but their Microsoft account uses a different email (for example, [email protected]), the O365 account may be linked to the wrong profile. This often happens when:

  • The Office 365 integration synced the user under a different email domain than the one they were invited with.

  • A non-personnel profile exists with the Microsoft email, while the invited personnel record uses a different email.

  • Duplicate profiles exist for the same person with different email addresses.

  • Search Personnel for the user's name and check whether multiple records exist. Verify the invited email on the personnel profile matches the email the user signs in with via Microsoft.

  • 4. If all of the above look correct, contact support. O365 account linking between profiles may need to be corrected on the backend. Contact [email protected] and include the affected user's name, invited email, and the Microsoft email they use to sign in.

Who can configure SSO?

  • Only customers with subscription plans that include SSO (or legacy plans with this feature) can configure SSO in Company Settings > Authentication Settings.

  • If you wish to add SSO, head to Settings, then Authentication settings, then scroll down to Single Sign-on, then click Explore SSO to discuss upgrade options.

  • Alternatively, email [email protected] for assistance.

What if my plan doesn’t include SSO?

  • Customers without this feature will see an upsell message, even if SSO had been set up before without a plan.

Did this answer your question?