Getting Google Auth Working in a Chromium Fork Is More Painful Than It Should Be

I want to write about something I have not solved yet. That feels important to say upfront. Most build notes are retrospectives. This one is not. This is an honest account of a problem I am still working through.

Google authentication in Kinka is not working the way I want it to. And the reason is not simple.

Why this is harder than it sounds

If you have ever implemented Google OAuth in a web app or a standard Electron app, you might assume it is the same problem in a Chromium fork. It is not. Not even close.

Google's OAuth flow involves a redirect back to a registered URI after authentication. In a web app that URI is a domain you control. In a standard app it might be a localhost callback or a custom protocol handler. Both of those are well-documented, well-supported paths.

In a custom Chromium fork you are in different territory. The browser itself is the client. You are not just implementing OAuth inside a browser, you are implementing it as a browser. The way Chromium handles OAuth internally for Google services like Chrome Sync involves APIs and credential flows that are not part of the public Chromium source in a clean, drop-in way. They are tied to Google's internal infrastructure and the keys that ship with the official Chrome binary.

The key problem

When you build Chromium from source, you can apply for API keys from Google to enable certain services. The process is documented, but the approval and scope of what those keys give you access to is limited compared to what ships in the official Chrome build.

For basic OAuth flows where a user is logging into a website through Kinka, this is not the issue. That works fine because the browser is just a container for a standard web OAuth flow. The problem is when I want Kinka itself to have a deeper integration, where the browser has its own authenticated identity, where features inside Kinka can interact with Google services on behalf of the user at a browser level rather than a page level.

That is the thing I am trying to build and that is where it gets complicated.

Where I am right now

I have been working through a few different approaches. The first was trying to use the standard OAuth flow with a custom URI scheme registered for Kinka. That gets partway there but the callback handling inside a Chromium fork requires more plumbing than I initially expected, particularly around how the browser processes the redirect and surfaces the token to the right internal component.

The second approach has been looking at how other Chromium-based browsers have handled this. Brave, Vivaldi, Arc. They have all had to solve versions of this problem. The solutions are not always documented publicly but reading through their open source repositories and issue trackers gives you a clearer picture of what is involved.

I am still in that phase. Reading, experimenting, hitting walls, trying something different.

Why I am writing about this now

Because I think there is value in being honest about the parts of building that are not going well yet. Everything I write here about Kinka could be polished into a neat narrative of progress and forward momentum. But that would not be fully accurate.

Kinka is a real project with real technical challenges. Some of those challenges are taking longer than I would like. Google auth is one of them. I am not shelving it, I am not giving up on it, but I am also not pretending it is solved.

When I do get it working I will write about that too. The full picture of what the problem actually was and what the solution turned out to be. That post will be more useful to anyone else building in this space than a vague success story would be.

For now, it is still in progress. And that is fine.