Single sign-on (SSO)
Updated over a week ago

What is Single Sign-On?

Single sign-on or SSO at its simplest is a technology that allows someone to log in to multiple applications with one single login. Many people are already familiar with this technology, having used or seen tools like “Sign in with Google” or “Login with Facebook”.

Anywhere that the user has leveraged Google, Facebook, Twitter, LinkedIn, etc. to log into an application or software that is not Google/Facebook/Twitter/etc. they’ve been using SSO.

Within the context of a business, employees can also utilize SSO. Typically this looks like one of two things:

1. Social SSO

The employee has an email address that is provided by Google (Google Workspace) / Microsoft (Office 365) and they're able to leverage “Sign up / Sign in with Google / Microsoft” buttons to sign in or authenticate.

2. Enterprise SSO

The employee is directed to use a specific system to authenticate across multiple business applications. This is commonly done via tools like Okta, Azure Active Directory, or OneLogin.

One confusing (but often not all that important) thing that can sometimes happen, occurs when an organization is utilizing an enterprise SSO system BUT that same provider also has a social SSO option. Google is the most common use case.

If an organization is using Google Enterprise SSO but the application has a “Sign in with Google” button, it can commonly occur that an employee authenticates across two separate methods, depending on the day. Normally Google is smart enough to authenticate the user and pass them along regardless of the method used.

Why would a business want to use Enterprise SSO?

Simplicity. There are a lot of things that a business needs to watch out for internally. With SSO a business can control & manage all of the following in one single place:

  • Granting access to only users that should have access to the application

  • Verifying users have the correct role & permissions within the application

  • Enabling updates that are made by the user to their name, email address, etc. are automatically updated within the application.

  • Verifying password strength requirements are being met (it doesn’t matter what Tactic uses for password requirements if password entry occurs with the SSO provider)

  • Ensuring two-factor authentication (2FA) is being used

It’s much, much easier to verify the right people can log in & have the right permissions when it’s all controlled and stored in one place. Instead of logging into 40 different applications and removing users every time someone leaves a company, with SSO they can merely update the user’s access in one place.

🚧 Single sign-on user attribute updates are not real-time updates. Real-time updates are only possible with Directory Sync. SSO updates a user’s information within Tactic only when they log in. If they haven’t logged into the system for a while, their information will be out of date. This can be problematic if an admin is relying on the updated information for things like inviting attendees to a meeting or creating desk restrictions.

How do we use SSO at Tactic?

At Tactic, we allow any organization to purchase SSO as an add-on to allow them the benefits described above. A lot of organizations won’t allow a company to purchase SSO separately – so many that it’s become known as the SSO tax. There’s even a website that’s been created to name and shame the companies that do this. We charge a nominal fee since ultimately we have built in costs with each new SSO connection we add.

How to set up SSO at Tactic?


To set up SSO, an organization will need three things:

  1. They will need to know which email URL (or URLs, it can be multiple) that they will want to have forwarded to their authentication provider.

  2. They will need admin access to their SSO provider’s admin portal

  3. They will need admin access to their Tactic account


  1. Log in to your Tactic account (account must have admin role)

  2. Navigate to Settings > Organization Settings

  3. Click on the Authentication tab

  4. Enter all of the email URLs that need to forward to the enterprise authentication system in the Authorized Domains section, separating each URL with a comma eg:,

  5. Once the email URL or URLs (most organizations only have one) have been saved, scroll down to view the list of available SSO providers

  6. If you see your provider on the list, click on the Get Started button

  7. Once you’ve clicked Get Started this will open a new tab to the self-service portal. The portal will ask you to confirm your SSO provider to get started

  8. The self-service portal will walk you through each step in the process, providing you with screenshots. Any information that needs to be entered can be input directly in the portal wizard.

🚧 Common email addresses like,,, etc. will not work. These URLs must be URLs within your organization’s control.

💡 Note: If you do not see your provider, don’t worry. You may still be able to set up SSO via the generic “SAML” or “OpenId” options. You will need to check if your provider allows for generic SAML or OpenId connections. If so, you can use those options.

Post Setup

If you’ve gone through all of the portal setup steps and you’ve successfully tested the implementation, congratulations 🎉 You’re all finished.

If you ran into any issues, please reach out to our support team at “[email protected]” or by clicking on “Create Ticket” on the top right of the Tactic Help Center.

Now that SSO is all set up, any user that attempts to log in to Tactic with the email URLs provided will be redirected to authenticate on your enterprise authentication provider. Once successfully authenticated, they will be redirected to your organization’s Tactic dashboard.

SSO JIT Account Creation

The software industry really loves acronyms. Single sign-on just-in-time (JIT) account creation is a fancy way of saying that we support creating user accounts on their first login i.e. just in time.

We’re able to do this since theoretically a user authenticating within your enterprise provider account would mean the user in question should have access to Tactic– at least as long as your enterprise provider has been configured correctly.

This behavior is enabled by default. If you would like to turn this behavior off, please send an email to [email protected].


What SSO systems does Tactic integrate with?

We're always adding to the list but currently the list includes:

  • AD FS SAML (Active Directory Federated Services)


  • Auth0 SAML

  • Azure SAML


  • ClassLink SAML

  • Cloudflare SAML

  • CyberArk SAML

  • Duo SAML

  • SAML (Generic)

  • Google OAuth

  • Google SAML

  • JumpCloud SAML

  • Keycloak SAML

  • Microsoft OAuth

  • miniOrange SAML

  • NetIQ SAML

  • Okta SAML

  • OneLogin SAML

  • Oracle SAML

  • PingFederate SAML

  • PingOne SAML

  • SimpleSAML.php

  • Salesforce SAML

  • VMWare SAML

What if my SSO provider is not on the list?

First and foremost, send an email to [email protected] so we can get it added to our product roadmap! Also, that's why the "SAML (Generic)" option is on the list. If your provider has a SAML option, you can use the generic setup and it still should work. If you're seeing any funny business, again please reach out and someone on our team will try to help.

What if a user’s Tactic account has not been created yet and they try to log in?

As long as SSO JIT is enabled and the user is configured within your SSO provider to have access to Tactic, an account will be created during the process of their first login. All of the data that your SSO provider gives to Tactic during this login process will be used to populate their account i.e. name, email address, etc.

Can I use SSO instead of or without Directory Sync?

Single Sign-On and Directory Sync are different features that can be purchased and used separately, but we always recommend using them together. SSO used separately means that users will be redirected to your enterprise identity provider to authenticate.

The downside is that many data attributes will not be passed automatically to Tactic AND any data attributes that may be passed will only be updated each time that a user is forced to manually log in i.e. if they check the “Remember me” box when logging in, that could be quite some time.

Directory sync is especially important if you are relying upon Tactic for features like desk, meeting room, or zone assignments being made to specific teams or users. Without having user accounts pre-created and team assignments being accurate, assignment to specific resources within Tactic will be impossible to achieve accurately.

Can I use Directory Sync without or instead of SSO?

Yes, though we typically discourage it. The onboarding process especially can be a little tricky for users since they'll need to receive an invite email, allowing them to create a password and essentially "claim" their pre-created account.

What if I don’t want SSO JIT enabled?

Not a problem. Send an email to [email protected] and we will manually deactivate the feature for your account.

Did this answer your question?