Skip to main content
Contact support Service status Platform login
Deutsch Español Français
Sign in

SSO (Single sign-on)

Updated

This article explains what SSO (Single sign-on) is, how it works and what configuration is needed to get it setup on your Sinch Engage account.   

Single Sign-on (SSO) is an authentication method that allows users to log in to multiple applications or services with a single set of credentials. Instead of signing in separately to different platforms, SSO streamlines access by authenticating the user once and granting access across all connected systems. 

Note - This page will soon be decommissioned and customers using this functionality will be migrated to our new Sinch ID Single-Sign On system - you can read about it in this article.

How SSO Works 

User logs in once – The user enters their credentials on an identity provider (IdP) platform.  
Authentication token issued – The IdP verifies the credentials and generates a secure authentication token.
Access granted – The token is shared with connected applications, allowing the user to access them without logging in again. 

Benefits of SSO 

Convenience – Users don’t need to remember multiple passwords. 

Security – Reduces the risk of phishing and password reuse. 

Efficiency – Speeds up login times and minimizes IT support requests for password resets. 

Pre-configuration information

At present, SSO is a request-only feature, so if you would like to have it enabled on your account, please submit a request with our support team. If you already have the feature enabled, let's walk through how to get it set up. You need to meet certain criteria before you can proceed to configure SSO:

  1. An identity provider that supports the SAML 2.0 standard. We offer support for the following providers: Microsoft Azure AD (Active Directory)
    Okta

  2. User permissions that allow you to configure applications within your identity provider.

  3. Administrator user credentials for the Sinch Engage parent account.

Validating SSO Domain Verification

When setting up Single Sign-On (SSO), you’ll need to prove that you own the domain by adding a DNS TXT record. This is a common security practice across the industry.

Steps to validate your domain

  1. Get your TXT record details - In the SSO configuration screen, you’ll see the TXT record value generated for your domain.
  2. Add the TXT record to your DNS
    - Log in to your domain provider’s DNS settings.
    - Add a TXT record with the details provided.
  3. Wait for DNS to update - DNS changes may take a few minutes to propagate.
  4. Save your SSO configuration
    - Go back to the SSO setup page and click Save.
    - If the TXT record is not yet in place, the system will prevent you from saving and show clear guidance on what to fix.

Note: If you need to use a single domain for multiple accounts and have the need to verify domain ownership for them, you can put multiple values in the TXT record, separated by space, and each value is surrounded by double quote. For example:

_sso_domain_verify.dub.ams.stg.mmd.zone. 60 IN TXT "559d63e31092f630ecc07ef84b58a643b64dfd7d0612fc3125ab1c825deb53cd" "4c54ce3fe8553f75282c75f6be30d8d087c4dc82f6cd038d56fb8a3ec6415096"

If you can’t add a TXT record yourself, please contact your IT team or domain provider for assistance. Should they advise that they are also unable to assist, please reach out to our support team.

Step 1 | Configuring your SSO Identity Provider

Important - This setup guide is intended for IT system administrators. While we can help you set up SSO to work with our platform, we can't provide support for the configuration of your SAML identity provider.

To ensure security and compatibility, for now our system only supports well-known Identity Providers (IdPs) such as Microsoft Entra ID (Azure AD) and Okta. Unfortunately, we do not support custom domains or self-hosted IdPs for SSO setup at this time.

The supported trusted locations are:
- okta.com
- Microsoft Azure AD (Active Directory)

The IDP domains used must be subdomains of the Trusted domain.

We’ve also noticed that some customers attempt to configure one-tap SSO login (such as Okta ISPM SSO app) with Sinch Engage. At this time, we do not support this feature. To access your account via SSO, you must log in through the Sinch Engage web portal SSO login page.

We use SAML 2.0 (Security Assertion Markup Language), a standard that permits Identity Providers (IdP) to safely pass authorisation credentials, such as your username and password, to service providers like the Sinch Engage.

  1. The first step is to create a new SAML application with your IdP:
     - For Microsoft Azure AD, navigate to the Microsoft Entra Gallery and select Create your own application, then follow this guide 
Entra's 'Create your own application' button

- For Okta, follow this guide

  1. Configure the application using the following settings:

For Microsoft Azure AD

MICROSOFT AZURE AD
Audience URI (SP Entity ID) https://app.sinch.com/
Single Sign-On URL https://app.sinch.com/login
Assertion Consumer Service URL (Reply URL) https://eu.app.api.sinch.com/v2/iam/sso/acs

 

MICROSOFT AZURE AD | Claim
NAME TYPE VALUE
Unique User Identifier (Name ID) SAML user.userprincipalname

 

MICROSOFT AZURE AD | Additional Claim
NAME TYPE VALUE
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress SAML user.mail
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname SAML user.givenname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name SAML user.userprincipalname
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname SAML user.surname

 

For Okta

OKTA
Audience URI (SP Entity ID) https://app.sinch.com/
Single Sign-On URL (Assertion Consumer Service URL (Reply URL)) https://app.api.sinch.com/v2/iam/sso/acs

 

OKTA | Attributes
NAME NAME FORMAT VALUE
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress URI Reference user.email
http://schemas.microsoft.com/claims/authnmethodsreferences URI Reference session.amr
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname URI Reference user.firstName
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname URI Reference user.lastName
  1. Configure a logo - this is optional.
  2. Assign users or groups to the application.
  3. Copy or download the IdP XML metadata - put this somewhere safe as you'll need this for Step 5 of Configuring the Sinch Engage Platform.

 

Step 2 | Configuring the Sinch Engage platform

  1. Log into the parent account in the Sinch Engage platform - remember, you will need admin-level user credentials to proceed from here.
sub account levels screenshot
  1. Once you're logged into the Sinch Engage platform, go to the menu and click on Settings > Account:
Settings navigation screenshots

Note: If you can't see the Single Sign-on (SSO) option it just means that the feature isn't enabled on your account. You can contact support to request for it to be enabled.

  1. Configure the email domains that you want to enable for SSO - email domains can only be used once per account hierarchy so if you set an email domain at a sub-account level, you can't set the same email domain on another sub-account. To save the entered information simply press Enter on your keyboard or click anywhere outside of the field. 
  2. Use the dropdown arrow to select your Identity Provider (IdP) - either Okta or Azure AD. If your IdP is not listed, you can contact support to chat more about extending SSO support to your IdP.

  3. Enter the XML provided by your IdP in the field provided.

  4. When someone logs into the Sinch MessageMedia platform using SSO but they don't already have a user profile, you can allow the Sinch MessageMedia platform to automatically create a new user with the credentials provided by the IdP. Just toggle this switch to On to enable.
  5. Use the dropdown arrow to set the default user role to be assigned to these newly created profiles.
  6. Select the accounts and sub accounts you want to allow these new users to have access to.
  7. Toggling this switch to On means that any users logging in with credentials matching your nominated email domains will be forced to log into the Sinch MessageMedia platform using SSO only.

  8. You can choose to enforce SAML authentication by toggling it on and off - this will apply to all users.

Note on 2FA (Two-Factor Authentication) 

When SSO is enforced, the user cannot log in using a password, so 2FA is not triggered.
When SSO is not enforced, the user can log in using a password, which will trigger 2FA. However, they can also choose to log in via SSO, which then bypasses 2FA.

FAQs

  • My organization uses an identity service provider (IdP) that's not in the list. Will it be supported?
    Please contact the support team with the details of which identity provider you would like to use.
  • Do you support on-premises Microsoft Active Directory?
    No, we only support Azure Active Directory.
  • Do you support IdP initiated SSO?
    Unfortunately not at this stage. Users will need to re-enter their email address in the Login with Single Sign On page.
  • Does enforcing SAML SSO log out users?
    No, active user sessions stay logged in until they expire. The next time a user needs to log in, they will need to log in with SAML SSO.
  • What version of SAML does Sinch Engage support?
    We currently support SAML v2.0.
  • Can I still log into the Sinch Engage platform if my identity provider is experiencing an outage?
    If you have Enforce SAML authentication turned on and your IDP is down, you should contact the support team and we can turn off “Enforce SAML” to allow administrators and users that existed beforehand to login with email again.
  • Why am I receiving the error "SSO auth failed"?
    There are several reasons you may see this error message, you will find the two most common examples below, however if neither of these apply please contact support.
     a. It is most likely due to a disparity in your relative Active Directory (AD), where the records may be misaligned, in which case you would need to check with your AD admin to ensure the right details are there.
     b. Sometimes when a user logs in with Single Sign-On (SSO), they start by entering their email. After going through the login steps, the system confirms their identity and sends back their details, including their verified email. Sometimes, the returned email is different from the one they entered. This usually happens because the system was set up to pull the wrong email field. Many platforms store multiple email-like fields (e.g. yourorganisation.com vs. on.yourorganisation.com). If the wrong one is being used, the admin can simply update the settings to select the correct field.

Related to

Related articles