Firebase-js-sdk: FR: Single Sign On - firebase.auth().signInWithToken(token)

[nik-lus]

• Operating System version: MacOS
• Browser version: Chrome
• Firebase SDK version: 7.2.0
• Firebase Product: auth

If I have 2 apps that the same user can use (apps share same firebase project) then that user must log in to both apps to be authenticated in both.

If I mint my own custom token I can authenticate the same user in both apps (with only one login) using:

firebase.auth().signInWithCustomToken(token)

...but to do so requires jumping through some hoops.

However, firebase already provides a valid JWT (token) once a user logs in so would it be possible to provide this token from app A to app B to authenticate the same user on app B automatically. Something like:

firebase.auth().signInWithToken(token)

I've searched up and down the internet and there doesn't seem to be a clean solution for something like this at the moment, unless I've missed something.

[rommelpe]

Thanks for sending this feature request, @nik-lus. AFAIK, custom token would be appropriate solution for this use case. I have created an internal FR (b/146031338) looping Auth team to get some inputs as well.

[rommelpe]

I got feedback from Auth folks that another choice is to pass the Firebase JWT token from app A to app B and verify the token in app B with Admin SDK.

[nik-lus]

Thanks for looking into in @rommelpe

The admin SDK has that feature but we don't use admin SDK. Both apps are client apps (w/o a backend)

It would be nice to have the same feature that verifies the token in the admin-sdk in the js-sdk

[nes123]

@nik-lus did you find a clean solution for that. I am looking how can I do single sign on between react web app and react native app, both using the same firebase backend including admin SDK in the google cloud functions environment.

[Qamar4P]

Hi @nik-lus, My use case is the same. We have two Android apps (signed with signature) that uses same Firebase. So we want to share the token b/w these two apps so that login in one app auto logged in another app. Any clean solution will be appreciated. Thanks

[nik-lus]

@nes123 @Qamar4P

I haven't found a solution that works easily, however I've found a workaround that (somewhat) works for me. What I'm building is a prototype so the following explanation is good enough for me. However, if I ever roll this out I'm either looking at a different backend, or an Auth service that would sit on top of Firebase.

Current workaround/solution:

• On App "A" I'm using FirebaseUI to log in. Currently only login provider is google.
• Once user is logged in FirebaseUI sends back a result with a "credential" object
• I take the credential object that was returned and send it to app "B"

• On app B I do the following:
  1) I mint a new credential object from the original "credential" object:

  const newCredential = firebase.auth.GoogleAuthProvider.credential(null, credential.oauthAccessToken);

  2) Then I try to sign into firebase with the new credential object:

  const oAuthCredential: firebase.auth.UserCredential = await firebaseAuth.signInWithCredential(newCredential);

  3) Then I return the user:

  return oAuthCredential.user;

Hope this helps. It would be nice to hear back from the firebase team if there's a SSO solution ever coming.

[NicholasLYang]

Agreed that this would be a very useful feature. I'm trying to implement auth for an electron app, which doesn't really allow me to use pop-up windows. I'd love to authenticate in the browser, then transfer that auth state to the electron app.

[dbanisimov]

Another use case for signInWithToken would be using the firebase-js-sdk on the server to execute firebase requests on behalf of the user.

A particular application for that is a server-rendered web app where using an existing idToken passed with the request is beneficial for a couple of reasons:

1. Faster execution - no need to use Admin SDK methods to verify the token
2. Smaller function archive size - faster cold starts. This should work even better with the new exp/lite versions of the client-side SDKs.
3. Reuse of the security rules - no need to re-implement the same checks in the server code.

Right now this seems achievable by using REST APIs, but having that implemented in the SDK would be nice.

[samhorlbeck]

Hi folks, one thing to consider: an ID token is (relatively) short-lived. It has an expiration time after which it is no longer usable. When signing in with Firebase, the server actually returns both an ID token and a refresh token (see the REST docs).

For this feature request, would you expect the lifetime of the second signed-in device (i.e. using this signInWithToken()) to be a short-lived sign in, or would you expect it to be the same as the first account (i.e. it is signed in potentially long-term using occasional refreshes)

[nik-lus]

@samhorlbeck if you're giving me the choice of short term vs long term my preference is long term. I'm treating my two apps as a single app. So if the same token works across all apps the same way (and I don't have to juggle refreshes often) then I'm all in for long term.

Nice to see that there's follow up on this issue and that you are considering it. Awesome!

[samhorlbeck]

Thanks for explaining your use case a bit more. In this case, we'd need to expose the refresh token which introduces some security concerns. This is something we've discussed with the team previously but we've not come to any conclusions yet unfortunately.

[nik-lus]

I hear you, auth ain't easy.

Even if it's a short term token, with a refresh token that's fairly trivial to use, that's an improvement over the existing method.

I'll take anything at this point :)

[dbanisimov]

For this feature request, would you expect the lifetime of the second signed-in device (i.e. using this signInWithToken()) to be a short-lived sign in, or would you expect it to be the same as the first account (i.e. it is signed in potentially long-term using occasional refreshes)

@samhorlbeck for my particular use case (server-rendering, not a single sign-on) short-lived idToken is enough. I expect it to be always fresh, e.g. by implementing the client-side refresh in the service-worker. If a request to a Firebase resource is rejected due to the expired idToken I expect it to fail and don't attempt to re-authenticate, so refresh token is not needed.

[tomlarkworthy]

The following should work out of the box.

    firebase.auth().signInWithCustomToken(user.getIdToken());

We can organize our own refresh tokens if we want.