Multiple Redirect URIs, Token Refresh, and MCP Security: What Developers Need to Know in 2025

If you've ever shipped an OAuth integration only to watch it break the moment a user switched environments — or quietly worried about unmonitored AI agent traffic slipping through your network — you're not alone. Two recent platform updates from GitHub and Cloudflare address exactly these friction points, and together they paint a clear picture of where secure, developer-friendly infrastructure is heading.

This article breaks down what each update actually does, why it matters for app developers and security teams, and how you can act on both announcements today. Whether you're maintaining a GitHub OAuth app for thousands of users or locking down an enterprise network against rogue Model Context Protocol (MCP) traffic, the practical takeaways here are worth your time.

Let's start with the fundamentals before connecting the dots.

GitHub's OAuth App Upgrades: Multiple Redirect URIs and Token Refresh Explained

For years, OAuth app developers on GitHub had to live with a frustrating constraint: a single registered redirect URI per app. If your application served multiple environments — staging, production, regional subdomains — you were forced to either create separate apps for each or hack around the limitation with fragile middleware. GitHub's August 2025 update changes that.

According to GitHub's official changelog, OAuth apps can now register multiple redirect URIs in a single app configuration. This is a significant quality-of-life improvement that also closes a common security anti-pattern: developers registering overly broad or wildcard redirect URIs just to make their app work across environments. Wildcard URIs are a well-known attack surface for open redirect vulnerabilities, and tightening them to explicit, enumerated values is universally considered best practice.

Why Multiple Redirect URIs Matter for Security

The security implications go deeper than convenience. Open redirect attacks exploit OAuth flows by substituting a malicious redirect_uri parameter in an authorization request. When developers are forced to use a single, broad URI to cover multiple use cases, they inadvertently widen the target. With explicit multi-URI support, you can now enumerate every legitimate callback endpoint your app needs — and GitHub will reject any authorization request that doesn't match one of them exactly.

This brings GitHub's OAuth app platform closer in line with the strictness that RFC 6749 recommends and that many enterprise security audits now require as a checkbox item. If your app has been flagged in a pen test for loose redirect URI registration, this update gives you a clean path to remediation without architectural surgery.

Token Expiration and Refresh: The Shift Away from Long-Lived Tokens

The second major change in GitHub's update is arguably more impactful from a security posture standpoint: OAuth apps can now opt in to expiring access tokens and refresh tokens.

Historically, GitHub OAuth app access tokens never expired. That meant a token minted two years ago — potentially from a device that had since been lost or compromised — was still perfectly valid today unless the user manually revoked it. This is a textbook example of excessive privilege persistence, and it's the kind of thing that makes security engineers lose sleep.

The new model allows app developers to opt in to token expiration. Here's what that flow looks like in practice:

User authorizes your app → GitHub issues a short-lived access token and a refresh token.
Access token expires after a defined period.
Your app uses the refresh token to obtain a new access token without requiring the user to re-authorize.
The refresh token itself is rotated on each use, limiting the blast radius if one is ever intercepted.

This is the same pattern that modern identity providers like Auth0, Okta, and Google have used for years. GitHub bringing it to OAuth apps means developers building on the platform now have a credible, standards-compliant path to least-privilege token management — without having to bolt on an external identity layer.

What Developers Should Do Right Now

If you maintain a GitHub OAuth app, here's a practical checklist based on these changes:

Audit your current redirect URI configuration. Replace any wildcard or overly broad URIs with explicit, environment-specific values now that multi-URI registration is available.
Evaluate the token expiration opt-in. For apps handling sensitive repository data or organizational resources, enabling expiring tokens is a low-friction way to significantly reduce your exposure window.
Update your token refresh logic. If you opt in to expiring tokens, make sure your app handles 401 Unauthorized responses gracefully by attempting a token refresh before failing the user-facing request.
Test across all registered redirect URIs. With multiple URIs now in play, add automated tests that verify each environment's callback still resolves correctly after the configuration change.

The GitHub changelog notes that these are opt-in changes for existing apps, so nothing breaks automatically — but the longer you delay, the longer your app carries unnecessary risk.

How Cloudflare Detects MCP Traffic and What That Means for Enterprise Security

Shift gears to a very different but equally timely problem: the rise of Model Context Protocol (MCP) traffic on enterprise networks, and the challenge of securing it.

MCP has emerged as the de facto communication protocol for AI agents interacting with external tools and APIs. As organizations deploy more AI-powered workflows, MCP servers are proliferating — sometimes with explicit IT approval, and sometimes very much without it. The latter category, often called shadow MCP traffic, is what keeps security teams up at night.

Cloudflare has published a detailed breakdown of how its Gateway product addresses this problem, and the technical approach is worth understanding even if you're not a Cloudflare customer today.

Protocol-Level Heuristics: How Cloudflare Identifies MCP Requests

According to Cloudflare's security blog, Cloudflare Gateway identifies MCP requests using protocol-level heuristics. Rather than relying solely on destination IP addresses or domain blocklists — both of which are easy to evade and slow to update — Cloudflare inspects the behavioral and structural characteristics of network traffic to fingerprint MCP communication patterns.

This is a meaningful technical distinction. Domain-based blocking is reactive: you block a known bad actor after the fact. Protocol-level detection is proactive: you can identify any traffic that looks like MCP, whether it's going to an approved server, an unknown server, or a potentially malicious one. That gives security teams a much broader signal to work with.

The practical output of this detection capability is threefold, as Cloudflare describes:

Shadow MCP traffic discovery — Security teams can use the Gateway signal to surface MCP connections they didn't know were happening. In large organizations with distributed developer teams, it's entirely plausible that engineers are spinning up or connecting to MCP servers without formal approval. Visibility is the prerequisite for governance.
Portal-only access enforcement — Once shadow traffic is visible, teams can enforce a policy that only MCP connections routed through an approved portal (Cloudflare's managed pathway) are permitted. Direct connections to arbitrary MCP servers on managed network paths can be blocked.
Direct connection blocking — For the strictest posture, security teams can outright block direct MCP connections on managed network segments, forcing all AI agent traffic through inspected, logged, and policy-controlled pathways.

Why Shadow MCP Traffic Is a Real Risk

To understand why this matters, consider the threat model. An AI agent operating via MCP can read files, call APIs, execute code, and interact with services — all based on instructions from a language model. If that agent is connecting to an MCP server outside your security perimeter, it may be:

Exfiltrating data by passing sensitive context to an untrusted server.
Receiving malicious instructions from a compromised or adversarially controlled MCP endpoint.
Bypassing DLP controls because the traffic looks like routine HTTPS rather than a recognized data transfer pattern.

None of these scenarios require malicious intent from the developer who set up the agent. The risk can arise from a misconfigured open-source MCP server, a third-party integration with poor security practices, or a supply chain compromise. The common thread is that you can't defend against what you can't see.

MCP Security as an Emerging Governance Discipline

What Cloudflare's update signals is that MCP security is graduating from a theoretical concern to an operational discipline. The same governance frameworks that enterprises apply to SaaS applications — approved vendor lists, data classification policies, access controls, audit logging — are now being extended to AI agent communication channels.

This has implications beyond just Cloudflare customers. Any organization deploying AI agents at scale should be asking:

Do we know every MCP server our agents are connecting to?
Are those connections logged and auditable?
Do we have a policy for approving new MCP integrations?
Is sensitive data context being passed to MCP servers outside our trust boundary?

These aren't Cloudflare-specific questions. They're the foundational questions of any mature AI security program, and they apply whether you're using Cloudflare Gateway, a competing secure web gateway, or building your own inspection layer.

Connecting the Dots: A Common Security Philosophy

At first glance, GitHub's OAuth updates and Cloudflare's MCP detection capabilities look like unrelated announcements from different corners of the developer infrastructure world. Look closer, and they share a clear architectural philosophy: make the secure path the easy path, and make dangerous configurations visible or impossible.

GitHub is making it easy to register explicit redirect URIs and opt into short-lived tokens — directly reducing the most common OAuth attack surfaces without requiring developers to become security experts. Cloudflare is making it easy to see AI agent traffic that would otherwise be invisible, and then apply standard enterprise controls to it.

Both approaches recognize a practical truth about security at scale: you cannot rely on every developer making perfect decisions under time pressure. Platform-level guardrails and visibility tooling are what actually move the needle on organizational risk posture.

What This Means for Multi-System Architectures

If you're building or maintaining a system that combines GitHub-hosted code, OAuth-authenticated integrations, and AI agent workflows — which describes a growing number of modern developer tools — these two updates are directly complementary:

Use GitHub's multi-URI support and token expiration to harden the authentication layer of any OAuth-connected tool.
Use network-level MCP detection (whether via Cloudflare or another gateway) to ensure that AI agents built on top of those tools aren't creating unmonitored data pathways.
Treat both as part of a unified security review process, not isolated configurations in separate systems.

Practical Takeaways and Next Steps

The velocity of change in developer infrastructure security is high right now, and it's easy to let important platform updates slip through without acting on them. Here's a condensed action list based on everything covered above:

For OAuth app developers on GitHub:

Register explicit redirect URIs for every environment your app serves.
Enable token expiration and implement refresh token rotation in your auth flow.
Review your token storage and handling logic to ensure refresh tokens are stored securely.

For security and platform teams:

Inventory your organization's MCP usage — both approved and potential shadow deployments.
Evaluate gateway-level MCP detection as part of your AI security architecture.
Establish a formal approval process for MCP server integrations before your agent footprint grows further.

For architects and engineering leads:

Treat OAuth token hygiene and MCP traffic governance as first-class security requirements in system design, not afterthoughts.
Build refresh token handling into your standard OAuth integration template so developers don't have to think about it from scratch each time.

The underlying message from both GitHub's changelog and Cloudflare's security update is the same: the tools are getting better, but only teams that actually implement them will see the benefit. Security improvements that live in a changelog don't protect anyone.

Conclusion

GitHub's OAuth app updates — multiple redirect URIs and opt-in token expiration with refresh — represent meaningful, standards-aligned improvements to one of the most commonly misimplemented parts of web application security. Cloudflare's MCP traffic detection capability addresses a genuinely new and fast-growing risk category that most organizations don't yet have a formal answer for.

Together, they illustrate a broader shift: the developer infrastructure layer is absorbing more security responsibility, giving teams who pay attention a real advantage over those who don't. The features are there. The question is whether your team has a process to evaluate, adopt, and operationalize them.

Start with your OAuth redirect URI configuration this week. Then ask your security team when your last MCP traffic audit was. If the answer to either is unsatisfying, you now know exactly where to begin.

Meta Description: GitHub now supports multiple redirect URIs and expiring tokens for OAuth apps. Cloudflare detects MCP traffic to stop shadow AI agent connections. Here's what to do.