Brave Analysis Exposes Design Weaknesses in zkLogin Authorization Protocol

Researchers at privacy-focused browser developer Brave say that a widely used zero-knowledge authentication model may carry serious security and privacy risks, despite being promoted as a next-generation solution for blockchain identity.

In a newly released research paper and accompanying blog post, Brave security researcher Sofía Celi and co-authors examined “zkLogin,” a zero-knowledge authorization system used across the Sui blockchain ecosystem. 

Their analysis concludes that the system’s security depends heavily on external assumptions that are not enforced by the protocol itself.

The team also said their findings highlight broader lessons for the growing class of zero-knowledge (ZK) identity and authorization tools being proposed for wallets, digital credentials, and decentralized applications.

Zero-Knowledge Proofs Meet Real-World Authentication

Zero-knowledge proofs allow a user to demonstrate that a statement is true without revealing the underlying data. In identity systems, this means a user can prove they hold a valid credential without disclosing the credential itself.

In the case of zkLogin, a user logs in through a traditional OpenID Connect (OIDC) provider such as Google or another web identity service. The provider issues a signed JSON Web Token (JWT), and the user then generates a zero-knowledge proof showing that the token contains specific claims and a valid signature. The verifier accepts the proof without seeing the full token.

At first glance, that architecture appears secure: if the zero-knowledge proof is correct and the issuer’s signature is valid, authorization should be trustworthy. But the Brave researchers argue that this logic ignores critical assumptions about how real-world authentication systems behave.

According to the paper, zkLogin relies on external documents and services whose correctness and trustworthiness are not guaranteed by the protocol itself. That creates risks that cannot be solved by cryptography alone.

Three Classes of Vulnerabilities

The researchers identified three broad categories of issues in zkLogin’s current architecture.

The first involves how the system parses JWTs. Instead of using a standards-compliant JSON parser, the zero-knowledge circuit searches for specific claim substrings such as issuer, audience, subject, and nonce. It does not enforce canonical JSON formatting, unique keys, or correct typing, according to the researchers.

That approach can allow ambiguous or malformed tokens to be interpreted differently by various components. For example, a token could contain duplicate or conflicting claims, with one value extracted by the proof system and another interpreted by wallets or backend services. Because the verifier never sees the full payload, such inconsistencies could go undetected.

The second class of vulnerabilities stems from missing bindings between authentication and authorization. The researchers said zkLogin transforms short-lived login tokens into long-lived authorization credentials without strong ties to the original session or application context.

In some deployments, attackers could exploit weak issuer controls, extract API keys from browser-based applications, and request proofs for arbitrary identities or applications. The team described an end-to-end impersonation scenario that does not break any cryptography but relies on gaps in how the system binds issuers, users, and relying parties together.

The third set of concerns relates to centralization and privacy. Despite being marketed as decentralized, zkLogin depends on a small set of identity providers, as well as external proving and salt services that may process sensitive user tokens.

Because these services can receive JWTs containing personal data, the researchers said users may unknowingly expose identity attributes to third parties outside the original consent flow.

Security Depends on More Than Cryptography

A key takeaway from the research is that zero-knowledge proofs only guarantee the correctness of the statement being proven. If the underlying data or semantics are ambiguous, the proof will faithfully reflect those ambiguities.

In the case of zkLogin, the system effectively proves statements about how a byte string was parsed, rather than about a well-defined identity or authentication event. This distinction, the researchers said, can have serious security implications.

The team concluded that zkLogin’s weaknesses are not isolated implementation bugs but stem from architectural design choices. These include repurposing short-lived web authentication tokens into long-lived blockchain authorization credentials without a unified threat model.

Responsible Disclosure and Recommendations

Brave said it disclosed its findings to zkLogin’s designers and the Sui ecosystem in November 2025, with follow-up communication in early 2026. 

The researchers recommended stricter JWT validation, explicit issuer allow-lists, stronger bindings between users and applications, and the removal of long-lived credentials from browser storage.

They also called for clearer user consent mechanisms when tokens are forwarded to external proving services.

The broader lesson, according to the paper, is that zero-knowledge authorization systems must treat canonical parsing, issuer governance, credential lifecycle, and deployment assumptions as core security properties.