Skip to main content

Single sign on (SSO)

Ease logging in and up security with SSO. An overview of what SSO is and how it works, as well as how to set it up and troubleshoot if anything is not working.

Updated over a week ago

Single Sign-On (SSO)

Single Sign-On (SSO) lets your team log in to Apsis One using the same credentials they already use for other company tools β€” like Microsoft 365 or Azure AD. Instead of managing a separate username and password for Apsis One, users authenticate once through your organisation's identity provider and get straight in.

πŸ’‘ Good to know

SSO is optional. If your organisation doesn't use it, every user simply logs in with their Apsis One email and password as described in First Time Logging In.


Why use SSO?

SSO brings three main benefits for organisations using Apsis One:

  • Stronger security β€” authentication is handled by your identity provider's policies, including multi-factor authentication, conditional access rules, and session management. You don't need to rely on individual users choosing strong Apsis One passwords.
    ​

  • Simpler access management β€” when you disable a user in Azure AD, they lose access to Apsis One automatically. No need to remember to deactivate them in a separate system.
    ​

  • Less friction for your team β€” users don't need to create or remember a separate password. They click "Log in", authenticate through your company's standard login, and land on the Apsis One Dashboard.


How SSO works in Apsis One

Here's what happens behind the scenes when a user logs in with SSO enabled:

  1. The user goes to app.apsis.one and enters their email address.
    ​

  2. Apsis One recognises the email domain (e.g. @yourcompany.com) and redirects the user to your identity provider (Azure AD).

  3. The user authenticates using their company credentials β€” including any multi-factor authentication your organisation requires.

  4. Azure AD confirms the user's identity to Apsis One.

  5. The user is logged in and lands on the Dashboard.


Important: SSO is based on the email domain, not the account

This is the most common source of confusion, so it's worth understanding clearly.

SSO is applied to the email domain used to log in (e.g. @yourcompany.com), not to the Apsis One account itself. This means:

  • All users with an email address on your company domain (e.g. anna@yourcompany.com) will be required to authenticate via SSO once it's enabled.
    ​

  • External users β€” such as freelance consultants or agency partners β€” who log in with email addresses from a different domain (e.g. consultant@agencyname.com) can still access the same Apsis One account using standard email-and-password login. SSO does not apply to them because their domain isn't enrolled.

πŸ’‘ Tip β€” Working with external consultants?

If you invite an external consultant to your account, they don't need to be part of your Azure AD. As long as their email domain is different from your SSO-enrolled domain, they'll log in normally with their Apsis One credentials. Just make sure you've added them as a user in Apsis One with the correct role.


Technical requirements

Before you start the setup process, make sure you have the following in place:

Requirement

Details

Identity provider

Microsoft Azure Active Directory (Azure AD). This is currently the only supported provider. If you use a different identity provider, contact your Account Manager β€” new providers are added based on demand.

Authentication method

Apsis One authenticates users by email address, not by User Principal Name (UPN) or user ID. The email address in Azure AD must exactly match the email address configured in Apsis One for each user.

Azure AD admin access

Someone from your IT department needs admin access to Azure AD to register the application and approve permissions.

Users exist in both systems

Each user must have an account in both Azure AD and Apsis One, with the same email address. SSO does not auto-create Apsis One users.

⚠️ Check your Azure AD email configuration

If your Azure AD is configured to use UPN as the primary identifier and the UPN doesn't match the user's email address, SSO authentication will fail. Consult your IT department to confirm that the email address attribute in Azure AD matches what's set in Apsis One for each user.


How to set up SSO

Setting up SSO is a collaborative process between your IT department and Apsis Customer Service. Here's what to expect:

Step 1 β€” Register the application in Azure AD

Your Azure AD administrator creates an application registration by following Microsoft's quickstart guide. Use the following configuration:

Step 2 β€” Gather your credentials

After registering the application, collect these credentials from Azure AD:

  • Application (Client) ID

  • Directory (Tenant) ID

  • Client Secret (value, not the secret ID)

⚠️ Security β€” Do not send credentials by email

Contact Apsis Customer Service at customerservice.apsis@efficy.com first. They will provide a secure method for transferring your credentials. Never send Client Secrets in plain email.

Step 3 β€” Contact Apsis Customer Service

Email customerservice.apsis@efficy.com and let them know you want to enable SSO. Include:

  • The email addresses of 1–3 test users (who exist in both Azure AD and Apsis One)

  • Confirmation that you've registered the application in Azure AD

Apsis will create the SSO integration on their side, enable it for your test users, and send you an approval link.

Step 4 β€” Approve the application

Your Azure AD admin uses the approval link from Apsis to grant the application permission to "Sign in and read user profile". This is a standard Azure consent step.

Step 5 β€” Test with your test users

Have your test users log in to Apsis One. They should be redirected to Azure AD, authenticate there, and land on the Apsis One Dashboard without needing a separate Apsis One password.

πŸ’‘ Tip β€” What to verify during testing

Confirm that: (1) test users land on the correct Apsis One account, (2) users without Azure AD access are blocked, and (3) users on other email domains can still log in with standard credentials.

Step 6 β€” Go live

Once testing is complete, let Apsis Customer Service know and they'll enable SSO for all users on your domain. From that point, every user logging in with your company email domain will be routed through Azure AD.


About the activation email for SSO users

When you add a new user to Apsis One, they receive a standard activation email that prompts them to create a password. If SSO is enabled for their email domain, they won't actually need this password β€” they'll log in through Azure AD instead.

The activation email is currently the same for all new users regardless of SSO status. SSO users can safely ignore the password creation step. Their account becomes active when they log in via SSO for the first time.

πŸ’‘ Good to know - If you're onboarding multiple SSO users at once, consider sending them a brief internal note explaining that they should use SSO to log in and can disregard the password setup prompt in the activation email.


Ongoing management

Once SSO is live, there are a few things to keep in mind:

Adding new users

  1. When a new colleague needs access to Apsis One:

  2. Make sure the user exists in your Azure AD with the correct email address.

  3. Add the user in Apsis One with the same email address and assign the appropriate role.

  4. The user can now log in via SSO. Remember: SSO does not automatically create users in Apsis One β€” you need to add them in both systems.

Removing users

When someone leaves the organisation:

  1. Disable or delete the user in Azure AD. This immediately prevents them from authenticating.

  2. Deactivate the user in Apsis One as well. This is a safety measure β€” if SSO is ever disabled in the future, the user won't be able to fall back to password-based login.

Rotating credentials

Azure AD Client Secrets have an expiry date (set when you created the secret). You need to rotate the credentials before they expire, or SSO login will stop working.

When it's time to rotate:

  1. Generate a new Client Secret in Azure AD.

  2. Contact Apsis Customer Service to securely transfer the updated credentials.

  3. Apsis will update the integration on their side. There's no downtime if you rotate before expiry.

⚠️ Set a calendar reminder - We recommend adding a reminder in your calendar 2–4 weeks before your Client Secret expires. If the secret expires without being rotated, all SSO users on your domain will be unable to log in until the credentials are updated.


Troubleshooting

Problem

What to check

User is redirected to Azure AD but authentication fails

The user's email address in Azure AD may not match their Apsis One email address exactly. Check for typos, uppercase/lowercase differences, or a UPN that doesn't match the email attribute. The email addresses must be identical in both systems.

User is not redirected to Azure AD at all

SSO may not be enabled for their email domain yet (still in test phase), or they may be logging in with an email address on a different domain. Check with Apsis Customer Service to confirm which domain is SSO-enabled.

External consultant can't log in

If the consultant's email domain is different from your SSO domain, they should be using standard email-and-password login. Make sure they've been added as a user in Apsis One and have completed the account activation process (set a password).

SSO suddenly stopped working for all users

The most common cause is an expired Client Secret in Azure AD. Check the expiry date in your Azure portal and rotate the credentials if needed. Contact Apsis Customer Service to update the integration.

New user was added but can't log in via SSO

The user must exist in both Azure AD and Apsis One with the same email address. SSO does not auto-create users in Apsis One. Add the user in Apsis One first.

User receives activation email with password prompt

This is expected β€” the activation email is the same for all new users. SSO users can safely ignore the password creation step and log in via SSO directly.


What's next?

Now that you understand how SSO works, here are some useful next steps:

Did this answer your question?