Anatomy of Mobile SSO: How Facebook’s Login Solution Fails and How to Fix It

Executive Summary

TL;DR: While Facebook’s "Login with Facebook" is ubiquitous, its native implementation on mobile devices historically drifted from security best practices. This paper deconstructs the Facebook Android SDK’s SSO flow, exposes vulnerabilities to phishing and impersonation, and proposes a new architectural model—now validated in e-health applications—that treats the mobile device as a first-class security citizen.

Background Positioning: This is a critical security audit and architectural redesign. It moves beyond "What is OAuth?" to "How do we implement OAuth safely in an environment where the client secret cannot be kept hidden?"

The Hidden Complexity of Mobile SSO

In the web world, Single Sign-On (SSO) is stabilized by the browser’s "Same-Origin Policy" and the ability of servers to keep secrets. On mobile, native apps run in a shared environment where malicious applications can intercept "Intents" or spoof UI components.

The authors argue that the lack of a proper reference model for native SSO has forced vendors like Facebook to create proprietary, poorly documented flows that prioritize convenience over rigorous security isolation.

The Facebook Anatomy: A Rational Reconstruction

Through reverse-engineering the FB Android SDK and intercepting HTTPS traffic via Fiddler, the authors mapped out the Facebook SSO logic.

The Original Flow

1. The Request: A Client App (C) triggers the FB_client via an Android startActivityForResult.
2. Authentication: If not logged in, the user types credentials directly into a UI provided by the FB app.
3. The Token: The FB_client fetches a token_FB (long-lived) and then requests a token_C specifically for the calling app.
4. Validation: The FB_server checks the app's key_hash (certificate fingerprint) before issuing the token.

Why it Fails

The researchers identified three "Break Points":

• Phishing: A malicious app can mimic the FB login UI perfectly. The user has no way to verify they are typing their password into the real Facebook app.
• Client Impersonation: Because the FB_client itself relies on the same credential flow, an attacker who steals user credentials can impersonate the Facebook app itself, gaining a powerful, non-expiring master token.
• User Impersonation: Since token_C is a simple "bearer token" (opaque), a malicious app can swap its own token for a victim’s token during the data exchange, tricking a benign app into logging in as the victim.

Methodology: The Secure Abstract Model

The authors propose a generalized model that fixes these gaps by introducing stricter Identity and Channel Assumptions.

Key Improvements

1. The Activation Phase: Users never enter credentials into a native app. Instead, they authenticate via a system browser (Trusted Agent) to generate a unique Activation Code for the device.
2. Cryptographic Binding: The signature calculation (sig) for requests uses this unique activation code, preventing an attacker from simply replaying stolen credentials from a different device.
3. Signed JWTs: Instead of opaque bearer tokens, the system uses JSON Web Tokens (JWT). These contain a signature to ensure integrity and an "Audience" (aud) field to ensure the token cannot be reused by a different app.

Comparative Results

The authors compared their proposal against Facebook, OAuth with Custom URIs, and the newer OAuth HTTPS URI redirection.

Key Finding: While the latest "OAuth 2.0 for Native Apps" (using HTTPS URIs) is a major improvement, the authors’ solution is the only one that effectively mitigates Phishing (CA2) by ensuring the primary authentication happens away from the potentially malicious app's environment through a verified activation phase.

Critical Insight & Conclusion

The most significant takeaway is that Bearer Tokens are dangerous in mobile environments. Without an identity assertion (like an OIDC id_token) that the client can verify locally (checking the signature and intended audience), native SSO remains a "trust-by-proxy" system that is easily exploited.

While the authors’ "Activation Phase" adds a slight hurdle to usability, it provides the only robust defense against credential harvesting in a native environment. For high-stakes applications—like the TreC e-health platform where this was tested—this trade-off is not just beneficial, but mandatory.

Future Outlook

As mobile OS providers (Apple and Google) further restrict inter-app communication, the shift toward "In-App Browser Tabs" (like Chrome Custom Tabs) aligns with the authors' vision: moving authentication out of the app’s control and back into a secure, system-managed context.