Some organizations may require an additional layer of security to comply with their processes. Text supports SSO via the SAML 2.0 standard. With it, you can configure a custom single sign-on (SSO) login for your team to help align your Text products with your company's security protocols.
You can integrate with any provider that supports SAML 2.0. This tutorial walks you through the Okta provider setup.
What do you need?
An Enterprise Text subscription plan
Text account with admin organization permissions
Okta account with admin permissions
Configuring the custom SSO
Set up your Okta application
First, you need to create a new application in Okta that will handle the authentication for your Text team. This is where you configure the SAML connection.
Log in to your Okta Admin Console (for example, https://example.okta.com/admin/dashboard)
Go to the Applications section and select Create App Integration. This will open a wizard to help you set up the connection.
When prompted to choose a sign-in method, select SAML 2.0. This is the authentication standard that Text uses.
Fill in the General settings for your application. You can name it something recognizable, like "Text," to make it easy to identify later.
Now comes the important part — configuring the SAML settings. This is where you'll tell Okta how to communicate with Text. Enter the following values exactly as shown:
Field name | Input value | Additional notes |
Single sign-on URL | The location where the SAML assertion is sent with a HTTP POST. This is often referred to as the SAML Assertion Consumer Service (ACS) URL for your application. | |
Audience URI (SP Entity ID) | The application-defined unique identifier that is the intended audience of the SAML assertion. This is most often the SP Entity ID of your application. | |
Name ID format | Persistent | Identifies the SAML processing rules and constraints for the assertion's subject statement. Text requires the Persistent option. |
Click through to finish creating the app. Once you're done, you'll see the application details page. Don't close this window — you'll need to copy some information from here in the next section.
There's one more thing to configure in Okta. You need to tell the application which user information to send to Text. Find the Attribute statements section and click Show legacy configuration. Under Profile attribute statements, add the subject_email attribute as shown in the table below. This tells Okta to send the user's email address to Text so it can identify who's logging in:
Name | Name format | Value |
|---|---|---|
subject_email | Unspecified | user.email |
Save your changes before moving on.
Connect Okta to your Text account
Now that Okta is set up, you need to give Text the information it needs to verify login requests from Okta.
You'll need to copy three pieces of information from your Okta application. You can find these in your Okta application details at Okta Application > Sign on > Settings > Sign on methods > SAML 2.0, or you can click View SAML setup instructions for a simplified view.
The three things you need are:
Identity Provider SSO URL (called "Sign on URL" in Okta)
X.509 certificate (called "Signing Certificate" in Okta)
Identity Provider Entity ID (called "Issuer" in Okta)
Once you have these ready:
Open the Security settings in Text at: https://www.text.com/app/settings/security/login
Look for the Custom SSO option and click Set up custom SSO. This will open a form where you'll paste the information from Okta.
Fill in each field with the corresponding value from your Okta application:
Text field | Okta field | Example value |
Identity Provider SSO URL | Sign on URL or Identity Provider Single Sign-On URL | |
X.509 certificate | Signing Certificate or X.509 Certificate | -----BEGIN CERTIFICATE----- AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD -----END CERTIFICATE----- |
Identity Provider Entity ID | Issuer or Identity Provider Issuer | |
Service Provider Entity ID | Audience Restriction or Audience URI (SP Entity ID) |
The Service Provider Entity ID field is already pre-filled with the default value and can stay unchanged in most cases. You'll only need to edit this if your organization or Identity Provider specifically requires a custom ID from the Service Provider.
Once you've filled in all the fields, click Set up SSO. This saves your SSO configuration, but it doesn't activate it yet.
Now for the final step: click Save changes at the bottom of the page. This enforces the SSO login method for your organization. From this point forward, SSO will be the only way for your agents to log in, and password login will no longer be available.
How do agents log in with SSO?
Once you turn on custom SSO login, your agents will receive an email notifying them of the change. They won't be able to log in with their regular Text password anymore — that option is now disabled.
From now on, when agents go to the Text login page, they'll click Log in with custom SSO and authenticate through Okta. Authentication occurs entirely through your Identity Provider, which means you maintain full control over security policies, password requirements, and access management.
Frequently asked questions
Register new agents with your Identity Provider first. Once they're set up in Okta, you can add them to your Text organization, and they'll be able to log in using SSO.
When you turn on SSO, your Identity Provider handles all authentication. This means security features like two-step verification or logging in with Google will no longer be available in Text. However, if your Identity Provider has two-factor authentication turned on, your agents will still need to complete that step.
When you turn on SSO, Text doesn't handle authentication. Your agents' passwords are stored in your SSO provider, not in Text. If agents forget their passwords, they'll need to reset them through your Identity Provider's panel (in this case, Okta).
No. To authenticate with custom SSO, none of your agents can be added to more than one organization. This is a technical limitation — each agent account needs to be associated with a single organization's SSO configuration.