Single Sign On (SSO) allows users to use a single login for multiple applications, simplifying the lives of both IT and your team on Drift. Our SAML 2.0 Implementation will allow team members to sign in securely through any identity provider. Here's a guide for configuring your IDP if you're not using Okta, OneLogin, or Entra.

This documentation is intended to help your organization's IT admin set up SSO. It might not be as reader-friendly to those outside of the IT department, so don't worry and forward it over to them if it's confusing!

Plan availability: 

Single Sign On is available on any paid Drift plan, starting with Premium.

 

Settings to Include

Drift will look for the following elements in the SAML Assertion:

Drift SSO post-back URL

This is also known as the Assertion Consumer Service URL. It handles the SAML Assertion returned from the Identity Provider after the user has been logged in.

https://api.drift.com/auth/sso/saml/acs

Note: If you're an EU-based customer, your URL will be:

https://api.eu.drift.com/auth/sso/saml/acs

Drift Entity ID

The ID that can be used to uniquely identify requests coming from the Drift Service Provider.

https://www.drift.com

Drift Default RelayState

The URL to which users will be redirected in the IdP-initiated flow.

https://app.drift.com

 

Email (Required)
 

<saml:Subject>
  <saml:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">
    user@email.com
  </saml:NameID>
</saml:Subject>

Name (Optional)
 

<saml:AttributeStatement>
  <saml:Attribute
    Name="Name"
    NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
    <saml:AttributeValue
      xmlns:xs="http://www.w3.org/2001/XMLSchema""
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"" xsi:type="xs:string">
        Drift User
    </saml:AttributeValue>
  </saml:Attribute>
</saml:AttributeStatement>

Considerations

Drift supports Service Provider Initiated and Identity Provider Initiated flows, as well as Just In Time user account provisioning. Drift only supports HTTP POST binding, not HTTP REDIRECT binding. Your Identity Provider must ensure a user is both authenticated and authorized before sending back an assertion.