OAuth for Google and Apple on all platforms

[mdmohsin7]

This would get rid of the google_sign_in and apple_sign_in hard dependencies and also closes #2648
Apple auth will now work on windows and as well as macos notarised distribution (dmg)

• Use OAuth for Google
• Use OAuth for Apple
• Support Apple Auth on all platforms (android, ios, macos, windows)
• Test with existing apple and google account auth on mobile and desktop
• Test with new apple and google account auth on mobile and desktop
• remove google_sign_in, google_sign_in_all_platforms and sign_in_with_apple deps

---

Deployment Plan:
Add the following env vars for backend

GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
APPLE_CLIENT_ID=
APPLE_TEAM_ID=
APPLE_KEY_ID=
APPLE_PRIVATE_KEY=
API_BASE_URL=

• Deploy Backend
• Deploy App

[beastoin]

1/ basically we still use firebase auth, right ? do we need the additional config on the google / apple portal ?

2/ i wonder how apple login would work by these changes ? UX related. so please drop the demo video

@mdmohsin7

[beastoin]

3/ is it compatible with the current system, likes what happen with my current account(data) if i sign-in by the new mechanism ?

@mdmohsin7

[mdmohsin7]

1/ yes we still use firebase auth. I already configured on google and apple side, we don't have to do it anymore

2/ Not much changes in terms of UX, just one additional click for ios. On mac/windows/android the same auth in a webview window flow

ScreenRecording_07-16-2025.10-38-07_1.MP4

3/ Yes it is compatible with the existing system. Previously we were doing everything on the client side directly through firebase, now what we do is we auth the user (from backend) through google or apple and then exchange the credential with firebase. At the end it still is firebase that is handling the auth

@beastoin

[beastoin]

1/ ok
2/ could you deploy it to the dev env and use the api: api.omiapi.com then demo again haha.
3/ ok
4/ so basically we can remove the firebase config file in the app ?

@mdmohsin7

[mdmohsin7]

2/ will do and report back
4/ not yet, we still use the firebase package to check for auth status, request token change (if expired) etc, but we can get rid of it by moving all of this to the backend. This will also help in making it easy to use any backend url in our app as the complete auth will be in the backend

@beastoin

[mdmohsin7]

2/ on dev env with api.omiapi.com

ScreenRecording_07-16-2025.17.MP4

@beastoin

[beastoin]

2/ cool, the UX looks good.
5/ lets talk abit about the DX, do i need to enable the apple, google login on firebase whenever setting up the backend/app. i saw you add more steps to the dev docs ?

@mdmohsin7

[mdmohsin7]

5/ yes you'll have to enable google/apple sign in in firebase when setting up backend. We had the google client id and secret envs on the frontend side when we added desktop support (

omi/app/.env.template

Line 4 in f5286ce

GOOGLE_CLIENT_ID=

), now that is moved to backend and to support apple oauth we had to introduce new env vars. These add additional steps for dx but decouples app from firebase a bit. Next we could slowly move the remaining auth stuff from app completely to backend and get rid of firebase deps (like the google service json file) from the app

@beastoin

[beastoin]

5/ that’s the main reason holding me back from merging this PR. basically, it would x2 the complexity on auth: firebase + duplicated google/apple setup, it's easy to meet the inconsistency on the auth.

e.g. could we use the same client id for google/apple with the firebase auth setup? i guess yes. login with the new oauth, but let the backend still use firebase admin (backend/utils/other/endpoint.py) to authorize the user's privileges.

the objective: remove friction in setting up the omi repo for devs - make it customizable, but simple, and consistent.

my suggestion: if you want to support sign-in with apple on the desktop app, make the minimal changes needed to achieve it. then think long term and ensure the new auth setup is actually simpler than the current one.

man, no rush. do it carefully.

@mdmohsin7

[mdmohsin7]

5/

e.g. could we use the same client id for google/apple with the firebase auth setup? i guess yes. login with the new oauth, but let the backend still use firebase admin (backend/utils/other/endpoint.py) to authorize the user's privileges.

It still uses the same method to authorize privileges. Previously, we signed in the user on the frontend using Google/Apple IDs and then exchanged the credential with Firebase. We’re still doing the same, except now the credential is created on the backend instead of on the frontend.

The old flow was: create the credential with sign_in_with_apple / google_sign_in and pass it to firebaseAuth.signInWithCredential. The new flow is effectively the same — the only difference is that credential creation happens through a backend OAuth flow instead of relying on frontend dependencies.

my suggestion: if you want to support sign-in with apple on the desktop app, make the minimal changes needed to achieve it. then think long term and ensure the new auth setup is actually simpler than the current one.

Getting Apple Sign-In to work without the native Sign in with Apple capability requires using OAuth, which is why we have to set up these things ourselves. The minimal change would be to keep using the "Sign in with Apple" capability, but that unfortunately won’t work on DMG builds or on Windows. Previously, the"Sign in with Apple" capability handled everything for us, but since we’re moving away from it, we need to implement that part ourselves.

Please let me know if there’s an alternative approach I might have missed

@beastoin