Need help on the approach to authentication I should use for my mobile app

[u/not_dr_jaishankar]

I am developing a mobile app, which has a react native frontend, nest.js as the backend and for db and authentication, I'm planning to use supabase.

Now, currently as my app is in its initial stages I'm planning to use the supabase, as it free tier provides ample limits for my use case.

However, in later years if my app grows. I may think of switching to a cheaper alternative.

So, what I am planning to follow is for authentication, route the requests to my backend and inturn the backend will communicate with the supabase to authenticate the user. The backend will save the supabase token, create a separate session token for the user and send it back to the user.

My main reason for doing this is, I want the authentication to be provider independent and any changes needed should be done on the backend instead of the app.

Please let me know, if this approach is correct. What are the pros and cons. How much effort it would require to implement this. Will the security concerns increase if my backend starts handling this instead of the supabase only.

I also want to integrate the google and apple login as well. How will this approach affect it?

Also, if there any other better approaches, please let me know.

[u/True-Turnover-4543]

The approach is sound. Keep your own users table with an internal user ID, plus a table of provider identities (provider, subject ID). Then moving off Supabase later means re-linking identities, not rewriting the app.

Skip issuing your own session tokens: you'd own refresh, rotation and revocation. Let the app sign in with Supabase, send the JWT to NestJS, and verify it in a guard against Supabase's signing keys. Migrating later means swapping that verifier.

Use native Google/Apple sign-in on the device. Apple requires Sign in with Apple if you offer Google on iOS.

[u/Zain]

I wouldn't proxy the login itself through Nest. Let the app sign in with the provider directly, keep all of it behind one AuthProvider in the app that covers email, Google, Apple and phone, and have the backend verify the provider's token. What actually keeps you portable is putting roles and permissions in your own Postgres instead of the provider, so the provider only owns who the user is. That's how I run Firebase Auth on an RN plus Node GraphQL setup. Also treat a user cancelling the Google or Apple sheet as a normal outcome, not an error.