Rate this page:

Single Sign On

Single Sign On (SSO) mitigates compliance and security risks for organizations by giving businesses control over user authentication and user revocation via corporate mandated tools.

Please Note: This feature is offered under the Twilio Enterprise Plan. If you have any questions or feedback, please contact

The purpose of this document is to describe the SSO capabilities Twilio supports and steps necessary to integrate your Identity Provider (IdP) with Twilio. The document is created for System Administrators or staff knowledgeable about SSO administration.

Twilio SSO Capabilities

Once configured, Twilio acts as a Service Provider (SP) and allows users to login either via IdP Initiated flows or Service Provider initiated flows.

In order to integrate with Twilio, your IdP must support the following features:

  • SAML 2.0
  • Either IdP initiated login or Service Provider Initiated Login.

The initial Twilio SSO integration will not support the following capabilities.

  • User Authorization via SAML. (User permissions may be managed via the Twilio Console’s User Management system only).
  • Twilio will not support Single Logout

Twilio will continue to enhance its offerings and may support these, and other features, in the future.

SSO Integration Steps

Customers work with Twilio’s Support in order to setup and configure Single Sign On. The integration steps are as follows:

SSO Configuration

In order to configure SSO, you will need to provide the following details (your IdP may provide this as a combined XML file):

  • Entity ID, Connection ID, or External Key
  • SSO Service URL: IdP url where login requests will be directed (GET or POST)*
  • Redirect URL (optional): where to send users after logout from Twilio (POST)
  • Public x509 Certificate

* Please ensure that the SSO Service URL is publicly accessible.

Twilio will provide its Entity ID, Security Token Consumer URL, and Public x509 Certificate so that you may properly configure your IdP.

Assertions & Shared Identity

In order to login a User, Twilio needs to match the email address of the user we have in our systems with the email address found in the SAML packet.

By default Twilio will match the email address found in SAML Subject / NameID field. However, Twilio requires that the NameID format is set to


Alternatively, you may provide the email via an Assertion element in the SAML Response. If you’re doing this, then you must provide twilio with the name of the SAML Assertion attribute that contains the email address, eg “email”, or "urn:oid:0.9.2342.19200300.100.1.3". Twilio will then look for that attribute and use it to match the user’s email address we have on file.

Security & Signing

By default, SAML responses must be signed, we do not need the assertions to be signed. If you need additional security capabilities please let us know.

Testing & Validation

In order to deploy the SSO integration, your staff and Twilio Support must validate that Twilio successfully integrates with your IdP, and that your users are able to log into Twilio.

The integration testing involves the following steps:

  1. Provide Twilio with the requested information, so that Twilio can configure its systems to recognize your IdP.
  2. Configure your IdP with the information provided by Twilio.
  3. Nominate one or more users that you’d like to enable SSO login for (via the user’s login email addresses)
  4. Twilio will then enable SSO for these users, and you should ensure that your IdP is appropriately configured to allow users to log into Twilio.
    • For example, this may require you to configure a Twilio application in your IdP and assign the specified users to it.
  5. Customer and Twilio will then concurrently validate that the users are able to log in via the SSO.

Migrating Users

The next step is to identify the full set of users that you want to enable for SSO. This can be done in one of several ways:

  1. Specify an email domain that Twilio Support can use to search our internal user database. We will identify all users which are using the email domain to log in.
  2. You may specify a specific list of users via user SIDs.
  3. You may specify a list of accounts and Twilio Support will pull all users associated with those accounts.

Based on the preferred method, Twilio will provide a list of users that it will enable SSO for. You must review the list and ensure that these users exist within your Identity Provider.

Please note, if an employee is using an alias that does not exist within your IdP, we may not be able to enable SSO for that user’s account.

Once you have reviewed the final list of users, we can enable SSO for those users in Twilio’s console. You must ensure that your IdP is also appropriately configured to allow access to the Twilio application.

Before Twilio enforces SSO we recommend that you inform these employees that they will be logging into Twilio via their IdP. Once you give us the go ahead Twilio will start enforcing SSO for the specified users.

Rate this page:

Need some help?

We all do sometimes; code is hard. Get help now from our support team, or lean on the wisdom of the crowd browsing the Twilio tag on Stack Overflow.


        Thank you for your feedback!

        We are always striving to improve our documentation quality, and your feedback is valuable to us. How could this documentation serve you better?

        Sending your feedback...
        🎉 Thank you for your feedback!
        Something went wrong. Please try again.

        Thanks for your feedback!

        Refer us and get $10 in 3 simple steps!

        Step 1

        Get link

        Get a free personal referral link here

        Step 2

        Give $10

        Your user signs up and upgrade using link

        Step 3

        Get $10

        1,250 free SMSes
        OR 1,000 free voice mins
        OR 12,000 chats
        OR more