A Comprehensive Formal Security Analysis of OAuth 2.0. OAuth is examined here across its grant types. This 2016 work by Daniel Fett, Ralf Küsters, and Guido Schmitz appeared at ACM CCS. They built a detailed mathematical model, defined what successful authorization, authentication, and session integrity should mean, and analyzed the grant types together. The security problem is how browser behavior and confusion between providers can break those intended guarantees, why the proposed repairs help, and where the proof stops.

The model includes relying parties and identity providers, each of which can be honest or malicious. It formalizes authorization, authentication, session integrity for authorization, and session integrity for authentication. The identity-provider mix-up attack demonstrates how a client can become confused about which authorization server it is using. Another attack demonstrates what can happen when a relying party fails to track the user's intended identity provider and login purpose. The analysis considers both network attackers and web attackers under specified corruption cases.

Can the OAuth grant types be represented together in a sufficiently detailed web model? Can meaningful authorization and authentication properties be stated precisely? And do repaired flows satisfy those properties against the modeled attackers? The examined failures cross component boundaries: redirects can preserve sensitive request bodies, third-party content can receive sensitive state, and a client can become confused about which provider it is using. The question is therefore not simply whether each endpoint behaves correctly, but whether the complete interaction preserves the user's intent.

The researchers used the Web Infrastructure Model to represent browsers and their windows, documents, iframes, and scripts. The model also captured cookies, network communication, redirects, and other web behavior. Relying parties and identity providers could be modeled as either honest or malicious. Within that environment, the researchers formalized authorization and authentication. They also formalized whether sessions remained tied to the user's intended login and authorization choices. They evaluated those properties against network and web attackers under specified corruption cases. After modeling repairs for the discovered problems, they proved the stated properties for the repaired model, conditional on the paper's full security recommendations and best practices.

One attack depended on an HTTP 307 redirect. Because that redirect preserves the submitted request body, it could forward an identity-provider credential submission to a relying party. The repair was to use a redirect such as 303, which does not preserve that body. In the identity-provider mix-up attack, a client supporting multiple providers became confused about which authorization server it was using. The proposed defenses were to identify and verify the issuer—the server that produced the response—or to use separate redirect addresses for different providers. Another attack let state and authorization data escape through the browser's Referer header when a page loaded third-party content, defeating the intended session binding. Suggested mitigations included single-use state, a restrictive referrer policy, and avoiding external resources. Finally, a naïve client could log a victim into an attacker's resource if it failed to remember the victim's intended provider and login purpose. That repair required explicit tracking of user intent.

The authors also checked whether variants appeared outside the mathematical model. They validated variants in Apache mod_auth_openidc, pyoidc, the Facebook PHP SDK, and the nytimes.com site. They reported the cases and documented confirmation, fixes, or discussions from the relevant groups and projects. That implementation evidence showed that variants of the modeled attacks occurred in deployed software. Separately, the theorem established the specified properties for the repaired model only when all of the paper's recommendations and best practices held; it did not establish that every OAuth deployment was secure.

The proof is conditional. It treats honest parties as free from untrusted third-party scripts and cross-site scripting. It also excludes open redirects and relevant corruption of those parties. The analysis assumes passwords are not reused or entered outside the identity provider. The repaired setting depends on protected connections and cookies. It also requires fresh state values and explicit checks at the relevant endpoints and for user intent. Expiration, logout, and access-token revocation remain outside the model. So do detailed refresh-token behavior and fine-grained authorization scopes. Identity-provider errors are also omitted. Scripts and implementation details are abstracted, so the analysis does not prove that any particular codebase is correct. The result supports the modeled protocol properties under its assumptions, not a blanket conclusion about OAuth deployments.

An operational reading of these findings gives identity engineers and security architects a focused review list. Multi-provider clients should bind each response to the expected issuer or use distinct redirect addresses. Credential submissions should not be followed by an HTTP 307 redirect when preserving the request body would expose credentials; a redirect such as 303 avoids that behavior. Teams should protect state with single-use values, restrictive referrer handling, and careful control of external resources. Clients should also record which provider and login purpose the user selected. These are design checks supported by the modeled attacks, but the proof should remain a design-review aid. Code-level testing and separate assessment of excluded threats are still necessary.

Fett, Küsters, and Schmitz combined formal web analysis and concrete repairs with checks of attack variants in existing software. Identity teams and security architects can use the proposed checks to verify provider identity and ensure redirects and session state preserve the user's intended provider and login purpose. They should not infer that an integration is safe merely because it follows the modeled flow: the theorem depends on its assumptions and does not cover code-level flaws, excluded web threats, or token-lifecycle behavior outside the model.