One-Click Account Takeover: When an Open Redirect Exposed an Authentication Token

An open redirect is often triaged as a limited phishing issue. In this case, following the complete authentication flow showed that the redirect destination also received an authentication token. That changed the impact from navigation control to account takeover.

This revised edition uses synthetic hosts and tokens. It documents an authorized security test and omits the affected organization.

#Initial observation

I registered a test account and watched the login flow rather than stopping at the first successful response. The authorization request included a redirect_uri parameter:

https://example.com/authorize
  ?client_type=loginCloud
  &view_type=web
  &redirect_uri=https%3A%2F%2Fexample.com%2Fsystems
  &client_id=cloud_portal
  &response_type=code
  &grant_type=password

Changing the redirect destination from the expected application path to a controlled test domain caused the post-login flow to navigate to that domain. That confirmed an open redirect, but it did not yet prove account compromise.

#Following the authentication data

Several days later, I revisited the behavior after discussing the finding with fellow security researcher Abdelrhman Amin. The important question was not only where the browser went, but what the application placed in the URL before it redirected.

The application appended an authentication token to the redirect URL. I used a Burp Collaborator endpoint as a controlled receiver and repeated the login flow. The collaborator received a request containing the token, demonstrating that an attacker-controlled redirect destination could capture it.

The vulnerability chain was therefore:

1. The application accepted an arbitrary redirect destination.
2. The authentication flow placed a reusable token in the redirected URL.
3. The browser sent that URL to the attacker-controlled destination.
4. The captured token could be replayed against the account endpoint.

My first replay attempt used the same /systems path seen during the normal flow and did not establish a session. After another review with Abdelrhman, we removed that application-specific path and tested the account endpoint directly:

https://example.com/account?code=REDACTED_AUTH_TOKEN

The replay established the victim session in the authorized test environment. The open redirect was the entry point, but token placement and replayability created the account-takeover impact.

#Root causes

This was not one isolated input-validation bug. It was a chain of trust failures:

• The authorization server did not enforce an exact allow-list of redirect URIs registered for the client.
• Sensitive authentication material was placed in a browser-visible URL and forwarded across origins.
• The token was usable outside the original browser flow and was not adequately bound to the initiating client or transaction.
• The authentication design treated redirect completion as a navigation detail instead of part of the security boundary.

#Defensive engineering lessons

• Register exact redirect URIs and compare the complete normalized URI. Do not accept arbitrary hosts, suffix matches, or user-controlled forwarders.
• Do not expose access tokens in redirect URLs. Prefer a short-lived, single-use authorization code with PKCE and strict client binding.
• Bind the authorization response to the initiating browser transaction using state, and use OpenID Connect nonce where applicable.
• Invalidate authorization codes immediately after redemption and reject replay from a different client or redirect context.
• Treat open redirects inside authentication paths as potentially high impact until token, code, referrer, and callback behavior have been traced end to end.

#Validation mindset

The practical lesson was to keep following data after proving the first bug. An open redirect alone did not explain the real risk. Mapping the authentication sequence, observing token movement, testing replay boundaries, and collaborating on a failed hypothesis exposed the complete vulnerability chain.

Further reading

• OWASP: Unvalidated Redirects and Forwards
• OWASP: OAuth 2.0 Security