Understanding Single Sign-On (SSO) at MobileAction

Single Sign-On (SSO) at MobileAction is built around one core principle: data security. Instead of managing logins inside the platform, MobileAction relies on your organization’s Identity Provider (IdP) to confirm who can sign in and what level of access they should have.

When SSO is in place, MobileAction and the SearchAds.com platform act as connected services that trust your Identity Provider for authentication. This keeps access rules consistent across platforms and lets your security policies live in the system your team already uses.

This article explains the fundamentals behind SSO, the role of the Identity Provider, and the key terms you’ll see when reviewing or planning an SSO setup.

What is Single Sign-On (SSO)?

Single Sign-On (SSO) is an authentication model where users access multiple platforms through a single, centrally managed login. Rather than creating separate usernames and passwords for each tool, users authenticate through their organization’s Identity Provider and reuse that verified session across connected services.

From a user’s perspective, SSO removes repeated login prompts. From an organization’s perspective, it centralizes authentication, password rules, and access policies.

SSO does not mean a shared password across tools. Instead, it means each platform relies on the Identity Provider’s confirmation that the user is already authenticated and approved.

Key concepts, explained clearly

Identity Provider (IdP)
The system your company uses to manage user identities and authentication, such as Okta or OneLogin. This is where users prove who they are.

Redirect URI
A secure return address where the Identity Provider sends users after successful authentication. For MobileAction, this address is:
https://insights.mobileaction.co/auth/sso/callback

OIDC with PKCE
OpenID Connect (OIDC) with PKCE protocol is a security mechanism used by MobileAction to confirm that the login process was completed by the same application that started it. This prevents intercepted or reused authentication attempts. 

Why teams use SSO

SSO is often adopted by teams that want clearer access control and less operational overhead.

From a security standpoint, authentication policies live in one place. Password rules, multi-factor authentication, and login restrictions are managed through the Identity Provider rather than across multiple tools.

From a workflow standpoint, team members sign in using the same company account they already use every day, whether they’re accessing the MobileAction platform or the SearchAds.com platform.

From an admin standpoint, access changes happen centrally. When a user joins, changes teams, or leaves the company, their access is updated through the Identity Provider without needing manual changes inside the platform.

How SSO works at MobileAction

When SSO is enabled, authentication starts and ends with your Identity Provider (IdP). MobileAction and the SearchAds.com platform do not validate passwords themselves. Instead, they rely on your IdP to confirm that a user is who they claim to be.

As stated earlier in this article, MobileAction uses OpenID Connect (OIDC) with PKCE, which is a modern authentication standard designed for secure, token-based login flows. In simple terms, this works as a secure exchange where the IdP confirms a user’s identity and sends MobileAction a verified response without sharing any sensitive credentials.

This structure allows MobileAction to trust the authentication result while keeping all credential handling inside your organization’s identity system.

Information involved in an SSO connection

An SSO connection works because a few shared details allow MobileAction and your Identity Provider to communicate securely.

Client ID
A public identifier created in your Identity Provider that represents MobileAction as a trusted application. This tells the IdP which service is requesting authentication.

Well-known configuration URL
An OpenID Connect discovery URL provided by your Identity Provider. MobileAction uses this URL to automatically retrieve the correct login, token, and verification endpoints.

Force SSO setting
An account-level option that requires all users to sign in exclusively through SSO. When this is active, password-based and social logins are disabled to keep access aligned with company policies.

SSO configuration requires Account Admin permissions.

If you’d like to continue, you can follow our platform-specific setup guides:

• How to set up SSO with Okta

• How to set up SSO with OneLogin

If you’re reviewing SSO as part of a broader security decision or want help choosing the right approach for your team, reach out to your Customer Success Manager or start a conversation through live chat. We’re happy to help you take the next step with confidence.