Fixing [authorization_request_not_found] by Thinking Outside the Backend

For weeks, my logs were flooded with [authorization_request_not_found] exceptions coming from the backend where I’d set up Google OAuth2 authentication. At first, I thought it was just noise — maybe a bad redirect or a user doing something weird. But the errors kept piling up.

It’s a Spring Security OAuth2 error that usually means:

“You tried to complete the OAuth2 login flow, but I don’t remember any request being made in the first place.”

That typically happens when:

The login session expired
The state parameter isinvalid or missing
The authorization request was never created in the first place

I started with the obvious: I googled the error. Read through every GitHub issue I could find. Double-checked my entire Spring Security OAuth2 setup. I even revisited the Google OAuth documentation (yes, the whole thing). Still nothing.

What made this especially frustrating was that I couldn’t reproduce the issue. Every time I tried to log in with Google — it worked perfectly. No errors. Same thing for my teammates and most users. Everything was configured correctly, and everything seemed fine… yet the logs told a very different story.

Then, on a random Monday morning — coffee in hand, cup filled to the brim — I decided to look through the logs again.

And there they were — those same [authorization_request_not_found] errors, mixed with some other strange ones. Some looked like they were caused by search engine bots crawling the site.

At first, I didn’t think much of it. But then I had a thought:

“Wait, what if those bots are somehow trying to open the Google OAuth link from my frontend?”

That would explain everything. It’s why I couldn’t reproduce the issue myself. Maybe the problem wasn’t in the backend at all.

I remembered that my Google login button was just a regular <a href="..."> link, pointing to something like:

  
/oauth2/authorize/google?redirect_uri=...

So if a bot is crawling the site and just clicking every link it sees — including that one — it could absolutely trigger an authorization flow with no user behind it. And when that flow reaches the backend, Spring Security throws an exception because the session (or authorization request) isn’t valid or doesn’t exist.

The Fix: Block or Deter Bots from Hitting the OAuth2 Entry Point

Once I realized what was happening, the fix was simple:

1. Add a Header to Discourage Crawlers

In Spring Boot, I added a filter that adds an X-Robots-Tag header to that URL:

@Component
public class OAuth2HeaderFilter extends OncePerRequestFilter {

    @Override
    protected void doFilterInternal(HttpServletRequest request,
                                    HttpServletResponse response,
                                    FilterChain filterChain)
            throws ServletException, IOException {

        String path = request.getRequestURI();
        if (path != null && path.startsWith("/oauth2/authorize")) {
            response.setHeader("X-Robots-Tag", "noindex, nofollow");

            // Optional: log suspicious requests
            String ua = request.getHeader("User-Agent");
            String ip = request.getRemoteAddr();
            log.info("OAuth2 authorize hit: IP={}, UA={}", ip, ua);
        }

        filterChain.doFilter(request, response);
    }
}

2. Convert the Link to a JavaScript-Initiated Button

Instead of an <a> tag, use a <button> with an onClick that redirects. This prevents crawlers from directly following the link:

<button onclick="window.location.href='/oauth2/authorize/google?redirect_uri=...'">
  Continue with Google
</button>

Bots generally don’t execute JavaScript or click buttons.

Lessons Learned

Not every exception in your logs is caused by your users — bots can trigger errors silently.
OAuth2 flows are stateful — if someone tries to “resume” an auth flow that never started, it fails.
It’s easy to forget that frontend code, like a simple <a> tag, can be the root of backend errors.

Final Thought

This wasn’t a breaking bug, but it was noisy, strange, and potentially scary if you didn’t know what was going on. And as I learned, there aren’t many good resources online that explain it.

So if this helped you — or you’ve seen this error and weren’t sure why — feel free to share or drop me a comment!

Summary

In this post, I share how a persistent [authorization_request_not_found] error in my Spring Security Google OAuth2 setup turned out to be caused by search engine bots triggering the login flow. Although everything worked fine for real users, bots were accessing the OAuth link directly, leading to backend errors due to missing session state. I walk through the debugging process, what the error actually means, and how switching from a raw <a> tag to a JS-triggered <button> solved the issue. This is a reminder that sometimes, bugs come from unexpected “users.”