Real-Time Token Relay

What Real-Time Token Relay Means in Practice

Real-time token relay is a phishing method that depends on speed, not just theft. The attacker intercepts a one-time code or similar authentication factor and forwards it immediately so the legitimate service still accepts it before expiry.

That timing window is what makes the technique effective. The victim may believe the code was “used up,” while the attacker is racing the session, challenge timeout, or one-time token validity to complete login first.

Although the term is often discussed with one-time passcodes, the same basic pattern can apply to any short-lived authentication artifact that is accepted once and then invalidated. The security issue is that the relay preserves the factor’s apparent legitimacy while moving it into an attacker-controlled flow.

Unlike simple credential theft, real-time relay does not require the attacker to know the password or permanently possess the factor. It abuses a live authentication sequence, which is why short validity alone is not enough if the service does not bind the factor to the original client or channel.

How the Relay Attack Succeeds

The attack usually starts with a convincing phishing page, proxy, or social-engineering prompt that captures the user’s current authentication response. The adversary then forwards that value to the real service fast enough that the login completes in the attacker’s session rather than the user’s.

This works best when authentication only checks that the factor is valid, not whether it is tied to the same device, browser, origin, or cryptographic proof. RFC 9449: OAuth 2.0 Demonstrating Proof of Possession (DPoP) is relevant because sender-constraining tokens is one of the clearest ways to make stolen artifacts harder to replay.

Token relay also becomes easier when user journeys contain multiple handoffs, redirects, or federation steps that create a delay between factor capture and verification. RFC 9700: Best Current Practice for OAuth 2.0 Security addresses exactly this class of token theft and replay risk in modern OAuth deployments.

When the underlying flow is a delegated or federated sign-in, the weakness is often not the presence of a token but the absence of meaningful binding to the party presenting it. OpenID Connect Core 1.0 is part of that trust chain, but it only helps when the implementation preserves the intended authentication semantics end to end.

Security Implications of Short-Lived Factors

Short-lived factors reduce exposure, but they do not eliminate relay risk if an attacker can capture and forward them within the acceptance window. The attacker still gains the same authenticated session the user would have received, which can lead to account takeover, data access, or follow-on MFA enrollment abuse.

For bearer-style access artifacts, the problem is broader than any single code. RFC 8707: Resource Indicators for OAuth 2.0 helps limit token usefulness by binding it to a specific resource, which narrows the value of a relayed token if it is stolen in transit.

Some environments still rely on tokens that can be replayed wherever the service accepts them, which makes the relay path especially attractive. RFC 8693: OAuth 2.0 Token Exchange is relevant where delegation is intentional, because confused or overly broad token exchange can make relay and impersonation harder to distinguish operationally.

At a control level, the subject sits at the intersection of identification, authentication, and token handling. Strong authentication helps, but the decisive question is whether the service can tell that the presented factor is being replayed in a different place, session, or client context.

Why Organizations Still Get Caught

Real-time relay succeeds because it is fast, human-facing, and often looks like a normal login failure or help prompt rather than obvious malware. The user sees a familiar challenge, while the attacker uses the captured response immediately enough to inherit trust.

Practical defenses therefore need to treat the login channel as part of the security boundary, not just the code itself. RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens is one example of binding authorization material to a client certificate so a relayed token is less useful off-channel.

This is also why phishing-resistant authentication matters. NIST SP 800-63 Digital Identity Guidelines is relevant because it distinguishes stronger authenticators and helps frame why replay-resistant methods are materially better than short codes alone.

Where services expose authentication or API flows, misuse of a relayed token can behave like a broken authentication failure rather than a classic password compromise. The operational lesson is that the control objective is not merely “make the code expire,” but “make the code unusable outside the intended context.”

Risk and Threat Considerations

Real-time token relay is high-risk because it compresses the attacker’s work into the few seconds or minutes that the factor remains valid. That makes the technique attractive for session hijacking, MFA bypass, and rapid account takeover even when the original factor is short-lived.

Failure mechanism: The service accepts a valid factor without cryptographic or contextual binding to the original client, so a phished code can be forwarded and redeemed before expiry.

Impact: An attacker can complete authentication as the victim, inherit the user’s session, and pivot into data theft, fraudulent actions, or persistent access if the session is not quickly contained.

Practitioner Guidance

Why practitioners should care: The main question is whether the authentication flow is replay-resistant, not whether the code is technically one-time. Real-time relay exposes weak assumptions in MFA, federation, and token handling that can survive even when passwords are never stolen.

What to watch for: Repeated login challenges, suspiciously fast successful sign-ins after a challenge, and sessions created from different devices or origins than the one that initiated the factor are all strong indicators of relay-style abuse.

Practitioner takeaway: Favor phishing-resistant, sender-bound authentication where possible, and treat short-lived codes as only one layer of defense rather than a complete answer to replay.

Related resources from NHI Mgmt Group

• How should blockchain teams implement real-time threat monitoring for smart contracts and token flows at scale?
• What breaks when AI access control is still bound to token expiry instead of real-time signals?
• What is the difference between OAuth token refresh and real privilege control?
• How should organisations reduce MFA compromise from real-time phishing?