Authenticate same users in multiple projects

[Kevin Adams]

Hi friends, 

Is it possible to somehow use the same authentication for users across multiple projects?  We're wanting to make it so there's only one place to authenticate a user for multiple projects.  The example would be that we have an app that is like an admin console that determines which of several sub-apps the clients want to subscribe to.  For example, logging into Google to access apps like Gmail, Drive, Calendar, etc.

I can use custom auth claims to just have the same user duplicated in other projects and log them in programmatically, but it seems like that could get messy.  I was reading some on multi tenancy (https://cloud.google.com/identity-platform/docs/multi-tenancy-authentication), but I don't know if that would help with what I'm asking about.

Thanks.

Kevin 

[Kato Richardson]

Hi Kevin,

The scenario you've described is whitelabeled authentication (using the same credentials across multiple apps). Multi-tenancy is a different paradigm and probably not useful here.

Some initial thoughts: Google apps like Gmail, Drive, etc all ask for credentials separately when installed. They launch Google OAuth sign in and assuming you have a single account already authenticated, it's a fairly transparent process; you still have to review access permissions and approve. I don't really know if Google apps do any magic behind the scenes (if so you wouldn't be able to duplicate that), but I suspect the shared part of the authentication is the OAuth provider, not the per-app token (for example, deleting the local cache for an app which will re-launch OAuth consent when the app is reopened, which suggests this is the model).

If you are using multiple apps, consider using a similar model. OAuth is only done once, but the consent is raised on each app so they can pick the appropriate OAuth account (assuming multiples) and review access permissions (which may differ between apps).

If you're using something other than OAuth (e.g. email/password or similar) then this is a bit harder. It might be possible to figure something out with custom auth tokens, but I'm not really sure what sort of credentials you can securely share between the apps to send to the server for verification (it still needs to authenticate the user somehow to assign the custom JWT token). For example, storing the email/password or the auth token in shared storage seems problematic.

☼, Kato

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/a8f01c73-8fc6-49c5-8a26-bf7295afac07n%40googlegroups.com.

--

Kato Richardson |

Developer Programs Eng |

kato...@google.com |

775-235-8398

[Stephen Cagle]

Hello to both of you,

Thank you for the well written response Kato. It is completely ridiculous that I even spend energy thinking about it, but it would be interesting to allow "migration" of users from one app to another for scaling demands that exceed a single application. For instance, if I have a application that is at some scaling limit, I could then copy that user to some other application that hasn't yet reached that limit. In this case I mean that all "copies" of the application are running the same codebase; the N applications exist solely to allow for horizontal scaling beyond the hard limits per application.

Like I said, completely ridiculous to even spend energy thinking about it, but it would be nice I I knew that there is *some* way to handle throughputs beyond the scaling limits if I absolutely need it.

[Kevin Adams]

Thanks for the info Kato 👏  We will need to do email/pass auth most likely.  One idea I had wouldn't require storing any shared credentials.  At least I don't think it would. Here's an example of what I was thinking:

- When Bob signs in the "Main" App, he subscribes to "App A", so we duplicate his Main user in App A (using some random long ugly password that he would never need to know)

- Bob clicks a button to access "App A", which would make an HTTP call to a cloud function like /sign-in-to-app-a

- In cloud function, Main app verifies Bob is signed in, and if signed in, makes HTTP call to App A, like /get-temp-sign-in-token

- App A creates a JWT and sends that token back to Main App

- Main App returns that JWT to the UI, and Bob is redirected to App A and the JWT will auto log him in to App A

It seems like it could work ok, but if he accesses 3 sub apps, and wants to logout, signing out of all of them at once seems a little weird.  I was just hoping there would be a way I could just have one auth user to share across all apps, but it sounds like it's probably not so simple. I hope I explained that scenario clearly.  Thanks so much for taking the time to respond. 

Kevin

You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/dlYEx7YLu68/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/CADypTEY7SQPp%2BDbnqj%2BG8zx8V5u80bB%2ByyPVnhAUjUJuv1U7BQ%40mail.gmail.com.

[Kato Richardson]

Firebase Authentication does have import/export functionality in the CLI (https://firebase.google.com/docs/cli/auth) which you could use for migrating between servers. So that use case is straightforward.

To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/cb84d865-33cb-4b4a-b408-a5785803130cn%40googlegroups.com.

[Stephen Cagle]

Oh, very cool. Didn't ever notice authentication import & export. Thank you.