Migration to Firebase authentication from Google Identity Toolkit

[harry_sb]

I'm trying to migrate my application's authentication from Google Identity Toolkit to Firebase authentication. I went through the migration guide posted here: 

https://developers.google.com/identity/toolkit/migrate-firebase

Currently my application is using Identity Toolkit's gtoken cookie for authentication in the backend APIs (hosted on Google App Engine for Java) with additional checks for Origin header. When the server receives the cookie, it verifies the Origin header and the validate the cookie. I can replace the gtoken cookie and do similar authentication using Firebase ID Token. I did a quick prototype by installing Firebase Admin SDK for Java on the backend and verified the ID token using the instructions posted here:

https://firebase.google.com/docs/auth/admin/verify-id-tokens

It seems to work well. But I'm unclear about the following statement from the migration guide: 

"If your server relies on the Identity Toolkit token (valid for two weeks) to manage web user sessions, you need to convert the server to use its own session cookie."

Is there a need to manage my own session cookie if the Firebase ID Token is working fine for me? I'll appreciate if someone can explain this to me.

[Bassam]

You can just rely on the Firebase ID token, but keep in mind, this is short lived and refreshes every hour compared to the 2 weeks gtoken. In addition the gtoken was stored directly in a cookie whereas Firebase ID token is stored in web storage and accessible typically via getToken API (you have to manually get it and send it to your backend unlike gtoken which was already sent along the request due to the nature if it being stored in a cookie). You are not forced to manage your own session cookie as long as you are aware of these changes. 

Bassam

[harry_sb]

Thank you, Bassam.

Yes, I understand that the cookie is sent automatically to the server provided both server and client share the same domain. In my case, that isn't true (client and server are running on different domains, so cookie is not sent to the server automatically). So, I had to get the cookie on the client and send it to the server explicitly. I'll do the same for the ID token using getToken to get the token. 

I also understand that the ID token is refreshed every hour. I'm not going to persist it anywhere. I'll simply use getToken API to fetch a valid token (though it changes every hour) before I need to send it to the server. The only downside I see is with an edge case. Say I call getToken at 59 mins and 59 secs after the token was generated, and get the Id token. But 1 sec later the token is invalid. Now I make an asynchronous call to the backend API. Assume that by the time the server tries to validate the token, 1 sec has already lapsed. In this case, the token becomes invalid and the validation fails on the server. How should I handle this case?

Can I check the expiration time and if the token is expiring in say 1 min or less, I force refresh it? 

Thanks again.

[Bassam]

Yeah, you can always check a couple of minutes earlier and force refresh via getToken(true);

As you were already manually sending the gtoken cookie and now doing so with getToken, I think you are in good shape to migrate from Google Identity Toolkit to Firebase Auth.

Please feel free to ping us if you have any other problems.

Best regards,

Bassa,

[harry_sb]

Thank you! I'm good for now.

[harry_sb]

Hi Bassam,

About checking token expiry, I came across this post from Sep 2016 that describes the exact problem I referred to: https://groups.google.com/d/msg/firebase-talk/rjR0zYiiEhM/jPAWNLKXAwAJ

Quoting that post here:

Does the client SDK refresh the [ID] token some time before expiration?
Unfortunately, this is not the case :( We will only refresh the ID token after a call using the previous token fails. We consider this a bug though and are actively working to fix this in an upcoming release. In the future, we will optimistically refresh the ID token as you are suggesting. I don't have a release date for when that will happen though.

I'm wondering whether this "optimistic refresh" has already been implemented. Do you have any update on this? I do not want to implement it if it's already in the SDK now.

Thanks.

On Tuesday, May 9, 2017 at 11:31:09 AM UTC+8, Bassam wrote:

[Bassam]

Hey Harry,

Proactive refresh is only available when you include the real time database service in your app, as it is required for that service. As proactive token refresh is an expensive operation and not required for many applications, we do not force it. You will need to implement that logic.

Bassam

[harry_sb]

Hi Bassam,

Thanks for your response. 

I'm surprised that it isn't seen as a big issue. My use case - calling a backend API - is pretty common. Since the token expires every hour, there's a high chance that the token verification would fail on the backend if the API call is made seconds or milliseconds before the hourly expiry. This means anybody with this use case would need to implement their own mechanism to proactively refresh the token. With Google Identity Toolkit, the token expiry was every 14 days and the chances of this issue occurring were far less. 

I would request your team to consider this proactive token refresh as an option and "not" enabled by default so that it doesn't affect the applications that do not want to use the feature. 

Thanks again.

[Bassam]

Hey Harry, I will relay your request to the relevant folks.

Best regards,

Bassam

[harry_sb]

Hi Bassam,

Thanks for considering the suggestion.

I have one more comment on one of your statements earlier, and an observation to share.

As proactive token refresh is an expensive operation ...

The token is going to refresh every 60 mins anyways. What I'm asking is that if the request is made between 59:30 to 60:00 mins, simply force refresh the token. I don't see a big overhead in advancing the refresh by 30 secs and that too only if the request is actually made in that 30 sec window, which may not always be the case.

One interesting observation during my testing - the token is indeed refreshed after 59:30 mins and not actually after 60 mins. It makes me wonder whether my requested feature is already in place. Can you check on this and confirm?

In that case, let's say the client makes a request at 59:29 mins, and by the time the server receives and attempts to validate the token, 59:31 mins have elapsed. If the client hasn't requested a (new) token between 59:29 and 59:31 mins yet, would the original token still validate on the server until 60:00 mins? 

Thanks,

Harry

[Bassam]

Hey Harry, you are mistaken, there is currently no "automatic" token refresh. Tokens are not refreshed unless you call an operation that requires a fresh token when the token is expired, the token will be refreshed underneath or if you are using a service like Firebase Database which requires a fresh token at all times.

Bassam

[harry_sb]

Hi Bassam,

Thanks for the clarification. Can you specifically comment on my observation of the token getting refreshed at 59:30? I want to understand the associated behavior as mentioned in my previous message. 

Harry

[Bassam]

I am not sure I understand the question. You can force refresh of a token any time, even when the token is not expiring. 

The server should honor an unexpired token as long as the token is validated before it expires. The token itself contains its UTC expiration.

If you are building your own proactive token refresh, you can force refresh ahead of time. 

The current behavior is as follows:

When a token is issued, we save it along with its expiration. The next time getToken is called, we check if it is expired. If not, we return the cached on, otherwise, we send a request to the secure token server backend for a new one and return that.

[harry_sb]

Hi Bassam,

I understand the behavior that you explained. Let me explain my question again.

Based on the documentation, token lifetime is 60 mins, but in my testing, the lifetime is 59 mins and 30 secs. I called getToken every few secs starting 2 mins before the previous token's expiry. In my testing, I observed that 30 secs before the 60 min interval if I call getToken, it would return a new token and not the cached token. Why does getToken return a new token after 59:30 mins and not after 60mins?

I want to build a proactive refresh functionality, but there's no API to get expirationTime. I have to use an undocumented approach to read the local storage and get the expirationTime. The way I get the expirationTime is this:

var expirationTime = user.toJSON().stsTokenManager.expirationTime;

Is there a guarantee that the contents of the object in the local storage won't change in future?

Hope the issues are more clear now.

Harry

[Bassam]

Hey Harry, we add a 30 second offset on the client side. This is needed for slow network connections. Gives us enough room for error.

I think the method you are using for checking the expiration time is Ok, though I can't guarantee it wouldn't change in the future.

The ideal way to do so is to parse the ID token and get the expiration from there. It is in the expiration field: 'exp' which contains the UTC expiration.

Bassam