DEV Community

Discussion on: How to share Firebase Authentication across subdomains

Collapse
 
johncarroll profile image
John Carroll • Edited

Hi Mohammad,

You seem to be conflating authentication, which this article discusses, with authorization, which this article does not discuss.

Authentication is the process of determining who someone is. This article helps you do this across subdomains in a secure way.

Authorization is the process of determining if a known or unknown client has access to something. This article does not help you with this. Just because you've authenticated someone and know who they are on every subdomain, does not mean you need to give them access to all (or any) data on each subdomain. You said, "Imagine you have an admin panel and a simple game in your organization such as admin.domain.com and funnygame.domain.com. In this scenario you are giving the admin access to the funny game team because they can use that token to access admin portal." But this is only true if you don't implement authorization. For example, you can (and probably should!) have different Firestore security rules for admin.domain.com and funnygame.domain.com.

If you're not sure how to authorize users within Firebase, you'll need to learn how to do that by reading the Firebase documentation or other articles on the internet. That's out of scope for this article.

Also FYI, this is incorrect:

It sounds that this approach uses a single access token for all subdomains which is not secure

The approach discussed here results in the user having a different Firebase auth token for each subdomain. This is necessary because Firebase Authentication (again, authentication not authorization) doesn't support single sign-in across subdomains. From the article:

When someone navigates to one of the other apps, say app1.domain.com, the app first checks to see if the person is already signed in via Firebase Auth. If not, it calls the /users-checkAuthStatus cloud function which looks for the signed __session cookie and returns a custom auth token to the client if appropriate. The client then signs the user in using the custom auth token (if present).

I'll also point out that having a single authentication token shared between subdomains is not inherently insecure (but obviously it could be depending on the authorization strategy).

PS: I'll reiterate the very first sentence of this article

This post is intended for people who are already familiar with Firebase, Firebase Authentication, and who are using Firebase in their web apps.

Collapse
 
madnik7 profile image
Mohammad Nikravan

Dear John,
Thank you for your complete answer.

You seem to be conflating authentication, which this article discusses, with authorization, which this article does not discuss.

I completely understand the difference between authorization and authentication. Still, it is impossible to authorize an authenticated user if you don't have enough information in its id-token or access token.

The approach discussed here results in the user having a different Firebase auth token for each subdomain. This post is intended for people who are already familiar with Firebase, Firebase Authentication, and who are using Firebase in their web apps.

Yes, Anyone who needs to find the proper tools looks for some key points and possibilities before implementing the whole system. Indeed, Your article works if there is something in authentication tokens so the access-token function can distinguish the domain. However, it sounds like it needs a lot of customization to achieve this, especially when I compare it with AWS Cognito. It would be so helpful if you put a sample of authenticated tokens (JWT) in each step of your article.

To sign-in:

  1. Someone navigates to the accounts.domain.com app! (perhaps redirecting from the subdomain)
  2. They provide their authentication information
  3. That authentication information is sent to our /users-signin cloud function which verifies the information and, if valid, sets a signed __session cookie which contains the user's UID and returns a success indication to the client

Here there is no trace of the audience domain, and I couldn't understand how "/users-checkAuthStatus cloud function" can generate the token and validate the authenticity of the requested subdomain.
Perhaps I need to learn much more and implement it to understand.