[Android] Recommended approaches to token expiration handling.

[Klymentiy Haykov]

I have been playing with Firebase for a couple of days, and have a couple of questions regarding token expiration on android.

What is recommended approach to handling token expiration?

Documentation says to listen to onAuthStateChanged. It does not says where you are supposed to listen to it, but I assume in Service. This is an easiest solution, but leaves us with a problem - what happens to the requests made during token refreshing? Looks like the data could be easily be lost.

Second approach is to listen to onAuthStateChanged  AND have a scheduled task of some sort to check token expiration time and preemptively refresh it. This is probably the safest option, but it puts additional strain on token minting server (and increases chance of going over authentication provider api limits).

Another approach is to check a user's authentication status with each request, and in case of expired token issue a new one, and repeat request. This requires some sort of wrapper around firebase client, and I can't really think of a way to approach it.

So, I wanted to ask, how do you guys handle token expiration? Is there anything I'm missing?

[Klymentiy Haykov]

There is another issue I discovered.

Documentation on Offline capabilities says following:

If the auth token expires while our app is offline, the client will pause our write operations until we re-authenticate, else our writes might fail due to security rules.

This is great. (What about read operations, btw?) But, in case of custom authentication this might not work. Let's say we have a setup where client and our own token minting server communicate only through firebase. To make it secure we use anonymous authentication, place request for token with our anonymous UID, server read's it, mint's token and put's it back, where client reads it, and then authenticates with it. For firebase the brief time where we are anonymous is still considered "authenticated" and we will get permission errors. 

Is there a way to specify a "primary" authentication provider, or set a flag manually? Or any other way to avoid this problem?

[Klymentiy Haykov]

I'm answering my own questions, but whatever. Maybe someone will find it helpful.

My way of thinking was not really compatible with Firebase way of doing things.

The way I made it work, with Twitter Digits is like this, after user authenticated through usual flow:

In onCreate we check for Digits auth data and firebase token. If either one is missing - tough shit, return to start. Like monopoly. But If we already authenticated with digits, we smoothly get firebase token and go to application entry point.

If the token expiration set to reasonably long time (say couple of days) this will almost never be needed, because if user won't come back to your app for this long (pressed home button and doing something else), it will probably be scrapped by android, and when user do come back, it will be through normal entry point, because the activity he was at would be recycled. Either way result will be same.

To keep token fresh, I check for token expiration date preemptively and attach/detach AuthStateListener to some lifecycle events (onResume/onPause) just to be safe. This way if user uses app normally token will always be fresh.

This leaves us with a negligible chance of data being lost or permission errors.

On Tuesday, November 10, 2015 at 10:34:10 AM UTC+9, Klymentiy Haykov wrote: