Social Login and Federation

Federation is outsourcing authentication to someone else’s infrastructure. Social login (Google, GitHub, Microsoft) is the consumer version. Enterprise federation (SAML, OIDC with corporate IdPs) is the B2B version. Both share the same architectural challenge: mapping an external identity to an internal user.

The SaaS platform supports three federation scenarios:

1. Social login for individual users. A developer signs up via GitHub OAuth. The platform creates an account linked to their GitHub identity. Fast onboarding, no password to manage.

2. Enterprise OIDC for B2B tenants. Acme Corp runs Okta. Their employees sign in via Acme’s Okta instance. The platform trusts Okta’s authentication and maps Okta users to the acme-corp tenant.

3. SAML 2.0 for legacy enterprise. Globex Corp runs on-premise ADFS. They require SAML integration. The platform acts as a SAML Service Provider.

Each scenario introduces unique security risks:

• Social login: email-based account linking allows account takeover if the email is not verified.
• Enterprise OIDC: a misconfigured provider could issue tokens for users who should not have access.
• SAML: XML signature wrapping attacks bypass authentication entirely.

The Identity Mapping Problem

External providers authenticate the user. They tell you: “This person proved they control [email protected] via Okta.” But your system needs more:

• Which internal user corresponds to this identity?
• Which tenant do they belong to?
• What roles and permissions should they have?
• Is this the first time they are signing in (provisioning) or a returning user (lookup)?

The mapping is the attack surface. A provider that allows unverified email addresses can be exploited: an attacker registers [email protected] at a permissive provider, signs in to the SaaS platform via that provider, and gets mapped to Alice’s account.

Spring Security OAuth2 Login Configuration

@Configuration
@EnableWebSecurity
public class FederationSecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        return http
            .oauth2Login(oauth2 -> oauth2
                .userInfoEndpoint(userInfo -> userInfo
                    .oidcUserService(customOidcUserService())
                )
                .successHandler(federatedAuthenticationSuccessHandler())
                .failureHandler(federatedAuthenticationFailureHandler())
            )
            .build();
    }
}

# application.yml - Multiple provider configuration
spring:
  security:
    oauth2:
      client:
        registration:
          github:
            client-id: ${GITHUB_CLIENT_ID}
            client-secret: ${GITHUB_CLIENT_SECRET}
            scope: read:user,user:email
          google:
            client-id: ${GOOGLE_CLIENT_ID}
            client-secret: ${GOOGLE_CLIENT_SECRET}
            scope: openid,email,profile
          okta-acme:
            provider: okta-acme
            client-id: ${OKTA_ACME_CLIENT_ID}
            client-secret: ${OKTA_ACME_CLIENT_SECRET}
            scope: openid,email,profile
            authorization-grant-type: authorization_code
        provider:
          okta-acme:
            issuer-uri: https://acme-corp.okta.com/oauth2/default

What This Chapter Covers

Section 1 covers OIDC federation and account linking: how to safely map external identities to internal users, prevent email-based account takeover, and handle multi-provider account linking.

Section 2 covers SAML 2.0: the XML signature wrapping attack, Spring Security SAML2 configuration, and why SAML assertions require careful validation beyond what most libraries provide by default.