SOAP: A Social Authentication Protocol

TL;DR

SOAP formalizes social authentication as a remote, automated binding between a messaging app's public key $PK$ and multiple external identities $ID$ via an OpenID Connect-based flow, and proves a strong security property called sender correspondence using the Tamarin prover. By hashing and salting the session safety number, SOAP preserves privacy while enabling multi-provider verification, markedly increasing the security bar over traditional in-app key verification. The authors implement web-based and Signal-based prototypes to demonstrate practicality and provide formal proofs of security and privacy, showing that an attacker would need to compromise both the messaging platform and all IdPs to impersonate a user. The work offers a feasible path to adoption across messaging apps and suggests broad applicability of social authentication beyond messaging, with potential for use as a second factor or native digital authentication. Overall, SOAP advances usable, remotely applicable, multi-provider authentication that reduces reliance on device-local key material and enhances resilience against impersonation and provider-compromise scenarios.

Abstract

Social authentication has been suggested as a usable authentication ceremony to replace manual key authentication in messaging applications. Using social authentication, chat partners authenticate their peers using digital identities managed by identity providers. In this paper, we formally define social authentication, present a protocol called SOAP that largely automates social authentication, formally prove SOAP's security, and demonstrate SOAP's practicality in two prototypes. One prototype is web-based, and the other is implemented in the open-source Signal messaging application. Using SOAP, users can significantly raise the bar for compromising their messaging accounts. In contrast to the default security provided by messaging applications such as Signal and WhatsApp, attackers must compromise both the messaging account and all identity provider-managed identities to attack a victim. In addition to its security and automation, SOAP is straightforward to adopt as it is built on top of the well-established OpenID Connect protocol.

Figures (9)

• Figure 1: SOAP implements a social authentication ceremony. A user initiates the ceremony in their messaging application, which requests an identity token for each of the user's identities and forwards the tokens. The verifier's application verifies the token's sender. The verifier uses the identities to authenticate the user.
• Figure 2: Steps of the prover to register at the messaging application and share their public key with other users. Our proposal is to additionally authenticate using multiple , here Microsoft and GitLab.
• Figure 3: Social authentication establishes for a verifier that the digital identity $ID$ and messaging application public key $PK$ are controlled by the same person.
• Figure 4: OpenID Connect authorization code flow with pkce. $h(v)$ is the commitment to a random value $v$ as specified by pkce and $s$ is the state parameter.
• Figure 5: SOAP running between the prover, the , and the verifier. Here, $h_s$ is a password hashing algorithm using a salt $s$ and $h$ is SHA-256 as specified by . The application randomly samples a code verifier $v$, a salt $s$, and nonce $n$. Finally, $\sigma$ is the OpenID Connect token, which is forwarded to the verifier and includes a signature on $h_s(k,s)$ and $n$.