Quick answer: When an AI learning platform’s students started hitting GitHub’s “Too Many Requests” error at login, the cause wasn’t a broken integration. Automated bot traffic was hammering the GitHub OAuth endpoint and exhausting GitHub’s secondary rate limits before real students could get in. We fixed it by adding a Cloudflare Managed Challenge to the OAuth redirect, which filtered out the bots while letting genuine users through. Student access was restored the same day, with no changes needed to the client’s app or their GitHub setup.
The client runs an AI education platform. Students log in with their GitHub accounts to reach their course content and software, using GitHub OAuth for authentication. It’s a clean, secure setup that thousands of platforms rely on.
Then, over a sustained period, every student trying to log in started seeing the same thing: a “Too Many Requests” error and no way into their materials.
From the student’s point of view, the platform was simply down.
What was actually going wrong
The thing is, GitHub wasn’t broken and neither was the client’s integration. GitHub’s protection was doing exactly what it’s meant to do.
A wave of automated traffic was repeatedly hitting the GitHub OAuth login endpoint from the hosting server’s IP address. GitHub responded by applying secondary rate limits to that IP. Once those limits were tripped, every request from the server got knocked back, legitimate students included.
In other words, the real users were caught in the crossfire of a defensive response aimed at the bots.
What our investigation found
Our first read of it, like most people’s, pointed at the OAuth integration itself. But once we got into the authentication logs and request patterns, a clearer picture emerged.
The server’s IP address had effectively become associated with excessive automated login activity. The endpoint was being battered by non-human traffic, burning through GitHub’s secondary rate limit before any genuine student could finish authenticating.
Our security monitoring picked up thousands of malicious requests during the incident, coming from IP addresses across multiple countries. More than 3,600 originated in China and almost 900 in Iran.
A word of caution on that, because it matters. Geolocation tells you where traffic appears to come from. It does not tell you who is behind it, and it certainly doesn’t attribute anything to a specific actor or government. What the data does show is how global and automated this kind of activity has become.
How we fixed it
We had a choice. We could have disabled GitHub login or bolted friction onto the whole platform. Neither was acceptable, because both punish your real users to deal with a problem they didn’t cause.
Instead we went targeted, using Cloudflare’s security platform.
We built a custom security rule that spots requests heading to the GitHub OAuth redirect endpoint and presents a Cloudflare Managed Challenge before the authentication flow can continue. Real users pass the quick verification step and get redirected to GitHub as normal. Automated traffic gets filtered out before it ever reaches the authentication process.
The whole point was to verify that a request came from a person, not a script, right at the pinch point and nowhere else.
The outcome
Student access to course materials was restored immediately.
The GitHub secondary rate limit errors stopped.
Automated authentication abuse was cut dramatically.
No changes were needed to the client’s application or their GitHub integration.
The fix was deployed fast, with minimal disruption to users.
A tidy result, and one that protected both the students and the trusted third party (GitHub) sitting behind the login.
Why this matters if you run an AI or tech platform
AI is now a high-value target. As the value of these platforms climbs, so does the volume of automated activity aimed at their authentication systems, developer tooling and supply chains. Login endpoints are an obvious target, because they’re the front door to everything behind them.
The wider lesson is that modern web security isn’t just about protecting a website. It’s about keeping your critical services available to legitimate users while stopping automated systems from exploiting the trusted platforms you depend on, like GitHub.
The most effective fixes often stop the bad traffic before it ever reaches those third-party services. Get the right rule in the right place, and you protect your users and your dependencies in one move, without re-architecting anything.
What to do if your login is throwing “Too Many Requests”
If your users are seeing rate limit errors at a third-party login, here’s the order we’d work through it:
Don’t assume the integration is broken. Check whether your server’s IP has tripped the provider’s rate limits first.
Read the authentication logs. Look for volume and patterns that don’t match human behaviour.
Find the pinch point. Usually it’s a single endpoint (here, the OAuth redirect) doing all the damage.
Filter at that point, not everywhere. A targeted challenge beats blanket friction every time.
Verify humans, block scripts. A managed challenge or WAF rule lets real users through and keeps the bots out.
Why does GitHub return a “Too Many Requests” error during login?
Usually because GitHub’s secondary rate limits have been triggered for your server’s IP address. If automated traffic floods the OAuth endpoint, GitHub throttles requests from that IP, which can block your genuine users along with the bots.
Was the OAuth integration the problem?
No. In this case the GitHub integration and GitHub’s protections were both working correctly. The issue was automated traffic exhausting the rate limit before real users could authenticate.
What is a Cloudflare Managed Challenge?
It’s a verification step Cloudflare presents to confirm a request is coming from a real person rather than an automated system. Genuine users pass it quickly, while bot traffic is filtered out.
Does adding a challenge hurt the user experience?
Barely. We placed it only on the OAuth redirect endpoint, so real students complete a quick check and carry on. The rest of the platform stays friction-free.
How quickly can this be fixed?
Fast. We deployed the targeted rule with minimal disruption and access was restored the same day, with no changes to the client’s app or GitHub setup.
Does this block every bot?
It won’t claim to. It dramatically reduces automated abuse at the point that matters, which was enough to clear the rate limit errors and keep students learning. — *Miles Gripton is Operations Director at Devstars, where he’s spent more than two decades running delivery and infrastructure for clients including the Ministry of Defence, Heathrow Airport and Cushman & Wakefield. Devstars builds and protects bespoke web software and digital platforms from offices in Jersey and London.*
