Single sign-on (SSO) FAQs

Frequently asked questions about using SSO with Mindful Callback

This article provides answers to frequently asked questions about Mindful Callback SSO.

Which SSO providers do you support?

We support:

SAML
OIDC

and we have validated integrations with:

Okta
Auth0
Azure AD

Note: For complete instructions on configuring SSO with your chosen identity provider, see the Single Sign-On (SSO) Configuration Guides. To investigate authentication failures, see How to troubleshoot SSO integrations.

Can I have multiple Mindful Callback organizations using SSO?

You can have multiple organizations on the Mindful Callback platform with the same SSO provider, but any users who utilize SSO can only be associated with one organization.

The short answer is "Not if they are using the same email address."

The same SSO integration can be used across multiple Mindful Callback organizations, but each organization's users must have a different email domain. This means SSO user accounts cannot be shared unless the users log in using a different email address for each Mindful Callback organization.

Can I have multiple Mindful Callback organizations with the same SSO provider but different users?

Yes, the same SSO integration can be used across multiple organizations with different users assigned to each organization. Remember that those users must have different email domains, as they will each correspond to a specific Mindful Callback organization.

How do I set up Business Units with Mindful Callback SSO?

Business Units in Mindful Callback Callback do not change when using SSO.

Note: Users must log in to Mindful Callback at least once before they can be assigned to a Business Unit.

For more information, see the Business Units reference article.

How do I grant users access and permissions on the Mindful Callback platform?

An SSO user will first have to be assigned to a group within the SSO provider that has been designated to grant them access to the Mindful Callback platform. This group will then be mapped to roles within the Mindful Callback platform. A user that is not assigned to a group that has been mapped to roles and access within the Mindful Callback platform will have no access when attempting to log in.

Can users still log in with their current credentials?

After the initial migration to Mindful Callback Platform Management, users can log in for the first time with their existing credentials. After their first login, they will be prompted to create a new password. For organizations with an SSO integration, those users will need to enter the email they use to log in to their SSO provider. They will be redirected to log in using their SSO credentials and redirected back after successful login.

Can I prevent users from logging in with their current credentials?

User accounts can be removed in two ways:

In Mindful Callback — Navigate to Organization > User Management to manage user accounts. For more information, see User Management.
Through the SSO identity provider — Remove the user from any SSO group mapped to Mindful Callback platform permissions.

What happens to my existing user setup?

All non-SSO user accounts will be migrated to the new Mindful Callback platform just as they are. These users will receive an invitation to the new platform via email. They can then log in for the first time using their existing credentials.

Can an organization use both SSO and default email/password users at once?

Yes, if you use SSO, you can still optionally add users via the User Management page. Those users will log in to Mindful Callback directly with their email and password.

However, when SSO is enabled, any users trying to log in to Mindful Callback directly with an email address on the SSO domain will be forwarded to the SSO provider. For example, if getmindful.com were configured as the forwarding domain and a user tried to log in with JDoe@getmindful.com, that user would be forwarded to the SSO provider.

What is the difference between SP-initiated and IdP-initiated SSO?

An SSO login can start in one of two places:

SP-initiated — The login starts at the Mindful Callback UI (the service provider). The user enters their email address in Mindful Callback and is sent to your organization's identity provider to sign in. After a successful sign-in, they are sent back to Mindful Callback.
IdP-initiated — The login starts at your organization's identity provider. The user signs in to the identity provider first, usually from an app dashboard or portal. The identity provider then sends them straight to Mindful Callback , even though Mindful Callback never asked for a login.

Does Mindful Callback support IdP-initiated SSO?

No. Mindful Callback supports SP-initiated SSO only. With SP-initiated SSO, Mindful Callback sends a login request to your identity provider and checks that the response it gets back matches that request. This check protects users from forged or replayed login attempts. With IdP-initiated SSO there is no request to match, so Mindful Callback rejects those responses.

Note: Many identity providers add a dashboard tile for each SAML application automatically. That tile uses IdP-initiated SSO, so it won't work with Mindful Callback. Hide it from users and use a deep link instead (see below).

Can users still launch Mindful Callback from my identity provider's app dashboard?

Yes, with a deep link. Most identity providers let you add a bookmark or link tile that points to any URL. If that tile points to the Mindful Callback SSO login URL below, here is what happens when a user clicks it:

Mindful Callback starts an SP-initiated login and sends the user to your identity provider.
If the user is already signed in to your identity provider, they are sent back and logged in to Mindful Callback without entering their credentials again.

To the user, this looks like a login from the identity provider. But Mindful Callback still starts the login, so it is fully supported.

Use this URL for the deep link, replacing the values in braces:

https://auth.getmindful.com/authorize?response_type=code&identity_provider={ORGANIZATION_ID}&client_id={CLIENT_ID}&scope=aws.cognito.signin.user.admin+email+openid+profile&redirect_uri=https://app.getmindful.com/

{ORGANIZATION_ID} — your Mindful Callback Organization ID with the dashes removed. For example, 1a2b3c4d-5e6f-... becomes 1a2b3c4d5e6f....
{CLIENT_ID} — contact Mindful Callback Support for this value.

Note: The redirect_uri must match the Mindful Callback application URL exactly. If the deep link returns an error about the redirect URL, check that the URL is entered exactly as shown above, including the slash at the end.

Should I use a metadata URL or a metadata XML file for my SAML integration?

We recommend a metadata URL whenever your identity provider supports one.

Your SAML metadata tells Mindful Callback how to trust your identity provider, including which signing certificate to expect. The two options behave differently when that information changes:

Metadata URL — Mindful Callback checks the URL for changes on its own. When you change your identity provider (by adding a new signing certificate, for example), Mindful Callback picks up the change automatically but not instantly. Mindful Callback caches your metadata and can take up to six hours to see an update.
Metadata XML file — Mindful Callback uses a saved copy of the file you provided. It never checks your identity provider for changes, so a change on your side has no effect until a new XML file is applied to your Mindful Callback SSO configuration. The new file takes effect as soon as it is applied.

Note: In both cases, users cannot log in if your identity provider starts signing with a certificate that Mindful Callback does not recognize yet. Follow the steps below whenever you change your signing certificate.

If I use a metadata URL, will a new signing certificate take effect automatically?

Yes, but it can take up to six hours. If you switch to the new certificate right away, logins may fail until Mindful Callback detects the change.

To avoid this, keep the old certificate in your metadata while the change rolls out. When your metadata contains more than one signing certificate, Mindful Callback accepts a login signed by any of them, so both certificates work during the changeover.

How do I change my SAML signing certificate without interrupting logins?

Note: The following are general steps. The exact screens and wording depend on your identity provider.

If you use a metadata URL:

In your identity provider, add the new signing certificate to the Mindful Callback application.
Keep the current certificate active for signing.
Open the metadata URL in a web browser and confirm that it lists both the old and new certificates.
Wait at least six hours.
This gives Mindful Callback time to detect and apply the updated metadata.
In your identity provider, make the new certificate the active signing certificate.
Test an SSO login to Mindful Callback.
After the login succeeds, remove the old certificate from your identity provider.

If you use a metadata XML file:

Because a new XML file takes effect as soon as it is applied, you do not need to keep the old certificate or wait.

Contact the Mindful Callback Support team to schedule the change.
At the scheduled time, make the new certificate the active signing certificate in your identity provider.
Download the updated metadata XML file and send it to Support to apply.
After the file is applied, test an SSO login to Mindful Callback.

Note: Logins fail from the moment your identity provider switches certificates until the new XML file is applied. Keep that gap as short as possible and plan the change for a low-traffic time. To avoid managing this yourself in the future, consider switching to a metadata URL during the update.