Summary: I had a rough time adding Google login to my app, Kenning. It took me a while to figure out four issues that were causing problems. These issues were not related to each other and were not covered in any tutorial I read.

My second post about building Kenning, this phase is about OAuth2 login. I thought it would be easy. It was not. I had to deal with four confusing bugs.

Bug 1: the client ID with a hidden character

Google did not accept my login. It gave me an error message saying "Error 401: invalid_client". I checked my client ID in the .env file. It looked correct. I had copied it from the Cloud Console.

When I looked at the actual request that was being sent, I saw the problem. The client ID had a hidden character at the end. This character was a carriage return, represented by %0D in URL encoding. My .env file had Windows line endings (CRLF), and that extra character was being included in the value.

The fix was switching my editor's line ending setting from CRLF to LF and re-saving the file. (You can also strip it from an existing file with sed -i 's/\r$//' .env, but the actual cause was the editor's line-ending mode, not a one-off corrupted file.)

What I learned from this is that just because something looks correct does not mean it is correct. I should have checked the actual value instead of just looking at it.

Bug 2: the user service Spring never called

After I fixed that bug I was able to complete the login process. But I noticed that no user was being added to my database. I had written a custom user-loading service, and it was not being called.

I looked into the auth object that Spring had built after login and saw that it had an authority called OIDC_USER. This told me that Spring was routing the login through the OidcUserService interface. My custom service was extending the wrong base class — DefaultOAuth2UserService instead of OidcUserService — so it was simply never invoked, even though it was wired in correctly.

To fix this I changed my custom service to extend OidcUserService instead. This fixed the problem.

Bug 3: the CSRF cookie that needs to be asked for

After fixing that, login worked end to end. When I tried to upload a file, I got a 403 Forbidden error. I had set up CSRF protection on purpose, so this made sense in principle — except the cookie it depends on, XSRF-TOKEN, was never being written in the first place.

It turns out Spring Security 6+ defers writing that cookie until something in the request actually reads the token. A GET request that never touches it never triggers the write.

To fix this I wrote a filter that forces the token to be read on every request, which triggers the cookie write.

Bug 4: two cookies, same name, different values

I spent a lot of time on this one. I kept copying the X-XSRF-TOKEN value into a manual request and it kept getting rejected, even right after confirming in DevTools that the cookie existed.

Looking closer, DevTools was showing two separate XSRF-TOKEN entries with the same name but different values — one with an empty partition key, and one partitioned under resource://devtools. I had been copying the DevTools-partitioned one, which isn't the value the browser actually sends on a real request. Once I copied the other one — the unpartitioned cookie — it worked immediately.

A thing I haven't solved yet

Before any of this, I tried using the spring-dotenv library to load my .env file automatically instead of exporting variables by hand every time. After adding it, login stopped working, and I genuinely don't know why — I never confirmed whether it was even loading the file, or something else entirely. I removed the dependency and went back to exporting variables manually. If anyone's gotten this working alongside Spring Security + OAuth2, I'd like to hear how.

What actually mattered

None of these bugs were caused by Spring or OAuth2 being badly designed. Each one had a clear explanation once I found it. What would have saved me time is checking the actual outgoing request the moment something failed for a reason that didn't make sense, instead of trusting echo output or DevTools at face value.

And the frontend?

Comparatively quiet, which I'm counting as a win. I used Angular and PrimeNG to build the document list and chat screen. Once I had the right cookie and header names configured, the whole CSRF back-and-forth from Bug 3 just worked automatically on every request, because the frontend handles this pattern natively.

Next up: a reader on the last post called the chunk-dilution theory exactly right and suggested keeping chunks to one topic each. So up next is testing that properly — comparing chat models, embedding models, and chunking strategies head to head, local and cloud, on quality, speed, and cost.

---

Building Kenning in public. Corrections welcome — especially on the spring-dotenv mystery above.