Skip to content
Connect2id
OAuth 2.0

Protecting OAuth code flows against browser-swap attacks

The browser swap attack is not a new attack. It was first theorised in 2022 by a team of researchers commissioned by the OpenID Foundation to perform a formal security analysis of the FAPI profile of OpenID Connect. More recently, the attack resurfaced in concrete, practical forms, through work by Jonas Primbs, which he presented at an OAuth WG meeting (PDF link).

To carry out a browser-swap attack the following is required:

  • The attacker must cause the victim to click a crafted link that triggers an authorisation request to the victim’s IdP.

  • After the authorisation is completed, the callback to the client must be prevented, and the attacker being able to obtaining the unconsumed authorisation code.

In essence, the attack is an OAuth code (or implicit) flow, initiated and completed by the attacker on the attacker’s own device, while the victim is tricked into authenticating in their own browser to the IdP.

At present, OAuth 2.0 and OpenID Connect do not have a universally applicable and reliable protocol-level defence against browser-swap attacks. That said, there are practical measures you can take today to reduce the risk:

  • For web-based clients, consider using the form_post response mode (HTTP POST), to receive the authorisation response from the IdP. This reduces the exposure of the authorisation code, compared to the default OAuth 2.0 response mode that passes the code inside the redirection URI.

  • Reduce the lifetime of the issued authorisation codes. We recommend a value of 1 minute. A forthcoming Connect2id server release is going to support code lifetime setting down to 1 second.

  • Review logging at the redirect_uri. Take steps to minimise disclosure of the codes. Logging may occur behind scenes on multiple layers - in the web server, reverse proxies, CDNs, WAFs, APMs and analytics.

  • Avoid third-party scripts and resources (such as analytics) on HTML pages served at client redirect_uris.

  • Educate users, in the UI and otherwise, about phishing risks and how to recognise suspicious login flows.

Upcoming Connect2id server releases we are going to include changes and features to harden the security against browser-swap attacks, while remaining compliant with the OAuth 2.0 and its extensions.

To secure native applications (mobile, desktop), which are considered public clients in OAuth 2.0, against browser swap attacks we are having active discussions with experts in the OAuth community. The form_post response mode is not applicable to native apps, so the discussed mitigations may require adjustments to the flows and instance-based authentication of clients.