Inbound SSO
An SSO configuration where an external Identity Provider authenticates users and the local application accepts the authentication assertion for access.
What is Inbound SSO?
Inbound SSO (also called external SSO or SP-initiated SSO) is an SSO configuration where a Service Provider (SP) trusts an external Identity Provider (IdP) to authenticate users. The user authenticates at the external IdP, and the IdP sends an assertion/token to the SP, which grants access.
Inbound SSO typically uses:
- SAML 2.0: SP receives SAML assertions from external IdP
- OpenID Connect: SP validates ID tokens issued by external IdP
- Social Login: SP uses Google/Facebook as external IdP
Inbound SSO allows organizations to leverage existing identity infrastructure (Okta, Azure AD) for application access.
Analogy
Think of inbound SSO like using your Google account to sign into a third-party website. Instead of creating a new username and password for that site, you click 'Sign in with Google' and Google (the external IdP) confirms your identity to the website (the SP).
Types and Use Cases
- Enterprise Applications: Companies configure inbound SSO so employees use their corporate Okta/Azure AD credentials to access SaaS apps like Salesforce, Slack, Workday
- Partner Portals: Configure inbound SSO so partner employees use their own corporate credentials to access your portal
- Customer SSO: Allow customers to use their existing social login (Google, Facebook) or enterprise IdP to access your application
- Government Systems: Citizens use their government-issued digital identity to access services
How it Works
Inbound SSO vs Outbound SSO
Inbound SSO
Outbound SSO
Inbound SSO is when external IdP authenticates to your SP
Outbound SSO is when your IdP authenticates to external SPs ; Inbound SSO = you are the SP; Outbound SSO = you are the IdP ; Inbound SSO: external identity source (Okta) → your app; Outbound SSO: your identity source → external apps (Salesforce)
Inbound SSO is SP-initiated
Outbound SSO is IdP-initiated
Best Practices for Inbound SSO
- Validate signatures: Always verify SAML assertion or OIDC token signatures using the external IdP's certificate
- Set appropriate session lifetime: Balance security and user experience with configurable session timeouts
- Map attributes correctly: Configure attribute mapping between IdP and SP for user profile data
- Implement Just-in-Time provisioning: Auto-create user accounts based on inbound SSO assertions
- Plan for IdP outages: Have fallback authentication mechanisms if the external IdP is unavailable
How LoginRadius Powers Inbound SSO
LoginRadius CIAM platform supports inbound SSO as a Service Provider, accepting authentication from external IdPs including social login providers (Google, Facebook, Apple), enterprise IdPs (Okta, Azure AD via SAML/OIDC), and custom SAML/OIDC providers. LoginRadius handles assertion validation, attribute mapping, and just-in-time provisioning.
FAQs
Inbound SSO: Your application (SP) accepts authentication from an external Identity Provider. For example, your app lets users sign in with Google. Outbound SSO: Your Identity Provider authenticates users to external applications. For example, you log into Okta and access Salesforce, Slack, and Workday without re-authenticating.
Social login is a form of inbound SSO (Google/Facebook are external IdPs). However, inbound SSO typically refers to enterprise federation (SAML/OIDC with corporate IdPs like Okta or Azure AD). If you only need consumer social login, social login is sufficient. If you need to support enterprise customers using their corporate IdPs, you need SAML/OIDC inbound SSO.
LoginRadius supports inbound SSO by acting as a Service Provider that accepts authentication from external IdPs. We support: (1) Social IdPs - Google, Facebook, Apple, 40+ providers, (2) Enterprise IdPs - Okta, Azure AD, Ping via SAML/OIDC, (3) Custom IdPs - any SAML 2.0 or OIDC compliant IdP with metadata configuration.