Four OAuth2 Bugs Blocking Google Login: CRLF Characters, Wrong Spring Classes, and Cookie Confusion

Four Bugs Stood Between Me and “Sign in with Google”

Developer Dogukan Karademir encountered four distinct bugs while integrating Google sign-in into his app, Kenning. The issues included a hidden carriage return in a client ID and a custom service extending the wrong base class in Spring Security.

Why This Matters

OAuth2 and OpenID Connect are foundational protocols for modern authentication, yet their implementation in Spring Security contains nuanced pitfalls that can cost developers hours or days of debugging. The author encountered four unrelated bugs — from hidden CRLF characters corrupting client IDs to Spring routing user services to the wrong base class — none of which were covered in tutorials. The cumulative effort highlights the gap between documented ideal flows and the reality of integrating third-party identity providers.

Key Insights

• Invisible characters in config files cause silent failures: A carriage return (CRLF line ending) in a .env file was appended to the Google OAuth client ID, resulting in Error 401: invalid_client despite the ID appearing correct. Fix: switching editor line endings to LF and re-saving.
• Spring Security routing logic depends on authentication type: A custom user-loading service extending DefaultOAuth2UserService was never called because the login flow produced an OIDC_USER authority, which routes through OidcUserService instead. Fix: changing the base class to OidcUserService.
• Lazy cookie writing in Spring Security 6+ breaks CSRF protection: The XSRF-TOKEN cookie was never written because a GET request never reads the token, so no write is triggered. Fix: forcing the token to be read via a custom filter that writes the cookie on every request.
• Browser DevTools can misrepresent cookie values: The author wasted hours copying a partitioned XSRF-TOKEN cookie (with resource://devtools key) from DevTools, but the actual request uses the unpartitioned cookie with a different value. Cross-check with real outgoing requests, not DevTools display.

Practical Applications

• Use LF line endings for all configuration files (.env, .yml) to prevent hidden carriage returns from corrupting sensitive values like API keys or client IDs. Pitfall: Editors with CRLF defaults (e.g., Windows Notepad, older VS Code settings) silently inject extra characters that break network requests.
• Always verify OAuth2 service inheritance against the authentication type (OIDC vs. OAuth2). Pitfall: Extending DefaultOAuth2UserService for Google login never fires because Google uses OpenID Connect, requiring OidcUserService instead — wasted debugging hours.
• Explicitly force CSRF token initialization to ensure cookie is written before any state-changing request. Pitfall: Relying on Spring Security’s lazy cookie write can cause unexpected 403 Forbidden errors on file uploads or POST requests after login completes.

References:

• https://dev.to/mido-dev/four-bugs-stood-between-me-sign-in-with-google-2ajn