Quickstart-android: Why the expiry time of Firebase custom auth token is limited to max 1Hr(3600sec) ?

[Karthi-R]

exp The time, in seconds, at which the token expires. It can be at a maximum 3600 seconds later than iat.

I'm doing a chat application using Firebase. where I need to listen for incoming messages most of the time. If auth token expires every hour, its difficult for me to maintain the valid session all the time :(

In Legacy Firebase system, token expiry time was too flexiable; where we can adjust TTL value from 1Hr to as many years!! Never expire option was also there!

Why the current Firebase API, is forcing the client to refresh the Auth token every hour?

Also, I couldn't verify the Auth session length at client side,
In Firebase 9.0.0 API, how to check the user has valid Auth session or not?

Kindly help me on this.Thanks in advance!

[samtstern]

@Karthi-R if you are using the Android SDK you should not have to worry about token expiration. The auth and database SDKs talk to each other and the token is automatically refreshed every hour. This should all be invisible to your application.

Are you having some problem where this is not the case?

[Karthi-R]

@samtstern; thanks for your reply!

After the token expired, internally SDK itself trying to refresh the token. but its always failing with below error. As I'm using custom Authentication, SDK won't know my server endpoint to fetch new token (I guess).

D/ConnectionRetryHelper: Scheduling retry in 398ms
D/PersistentConnection: pc_0 - Trying to fetch auth token
D/PersistentConnection: pc_0 - Error fetching token: An internal error has occured. [ Internal error. ]
D/PersistentConnection: pc_0 - Scheduling connection attempt

In Firebase SDK, I couldn't find any API to check the token validity. If I know that token is expired, I can do the token refresh manually.

I'm planning to maintain _"last-token-fetch-time"_ info at local, so that I can refresh the token manually after one hour.

Kindly let me know, if there is any better way to handle this.

[samtstern]

@Karthi-R this is a known issue in Firebase Authentication that a small number of developers are seeing, sorry about that! I will get back to you with a workaround as soon as I have one.

Also as you can see on the status page Authentication currently has one other known issue that makes the SDK not production ready. You can continue to develop your Android app with Firebase but we recommend not releasing with Authentication until that issue is resolved.

[Karthi-R]

@samtstern Thanks for your update!
Hope this issue will get resolved soon!

[sowdri]

Hi,

I've migrated from the legacy firebase to google-firebase. I've semi-private information the access to which was being controlled using tokens with a large expiry time. This has become impossible with the current limitation.

Is there any plans of making the expiry time flexible. I'm using custom authentication as well.

Ideally the validity of the token has to be left to the token provider in case of custom authentication. Security needs are different for different applications. That's the whole point of having a custom authentication. I can't understand the rationale behind limiting the expiry for one hour.

Please help me comprehend it.

Thanks,

[iammert]

Same issue here. Hope it will get fixed soon.

[iammert]

@Karthi-R @sowdri Finally made it work. It is all about configuration problem. You have to add you SHA-1 to firebase database. You can follow this documenatation. Easy way to get SHA-1 key here

It should supposed to be documented.

[Karthi-R]

@iammert Are you doing custom Authentication ?

[iammert]

I am using Facebook and MailPassword authentication. @Karthi-R

[Karthi-R]

@iammert
If we use default Auth providers like (Google, Facebook, Email..), updating "SHA-1 key" in firebase console would enable Automatic token refresh. (Its working fine as you said)

But in custom authentication, Firebase SDK need to contact 3rd party server to fetch new token.
Here only SDK is failing to refresh the token!

[myuseringithub]

Oh seriously, why did you add this limitation ! I have a PHP server which produces tokens for other server users (for serverside & frontend admin dashboard control) to use for at least several months. Now I should build a service to create tokens every hour ?
Please remove this limitation, every developer has his own solutions and ways to get things to work. nonesense

[psigen]

@samtstern I'm running head on into this problem. This timeout restriction is really terrible for IOT use cases.

I have a few hundred mobile (i.e. frequently offline) IOT devices that I am trying to safely upload data from. An ideal way to do this is to generate tokens for each device that last about a year: using their owner's uid, but signed with "claims" containing the device serial numbers. My secure server checks the ownership on each device before issuing these tokens.

In Firebase, this makes it easy to secure each device's database access: any individual device that misbehaves can be restricted to write-access in its own /$userid/$auth.deviceid path using the claims in the token.

However, with this 1-hour limit, there is absolutely _no way_ that I can find to make this work, other than:

• having each user either store their password on each device
• using a second authentication system and querying an entirely separate database to generate the tokens (at which point why even use firebase?)
• having each user create dozens of accounts for each of their IOT devices.

I'm really at a loss on how to handle this when transitioning from the v2 API. Anyone over there have any ideas?

[samtstern]

While the token expires in one hour, that's just how long you have to use that token to authenticate. Once you've called authWithCustomToken successfully, you stay logged in forever (until you sign out explicitly) so you should be able to get devices to have a long-lived authentication session without minting long-lived custom tokens.

[psigen]

Thanks very much for the suggestion @samtstern!

I tried this, but unfortunately, it seems like the session is not cached if the device reboots or the app gets force-stopped/restarted. Is this supposed to be the case? Alternatively, is there a way to force the authentication to be preserved across hard resets?

[samtstern]

@psigen on an Android device the session is cached in the SharedPreferences of your application. It should have the same lifecycle as that does, which should definitely persist across device reboots. Unfortunately you can't persist across hard resets.

[psigen]

Ok, I might be accidentally clearing your entry in SharedPreferences as part of an autoupdate process.

Thanks for the info, I think I should be able to make this work now!

[samtstern]

Ok for the following reasons I am going to close this issue:

• Original poster has not been involved in 21 days
• @psigen has a potential workaround to go try
• This issue tracker is really meant to deal with issues with the quickstarts and not general product feedback
• I have shown the team this thread and they are taking all of your feedback under consideration

If anyone here experiences further issues trying to use code in this repo, please open a new issue so we can discuss those in isolation. Thanks to all of you for your great feedback and patience!

[skela]

I'm seeing this issue too, is this really not going to be fixed?

[everhusk]

Yeah this is kind of crazy, why not just allow custom expiration?

[MariCarmenBaenaSopra]

Hi!!

I have a questions.
I am making an app and in ionic3 and angular 4 and I need that my apikey never to expire because when my app is uploaded so people can download it, it will fail because my apiKey expires.

How can I do that? It is possible?

Thanks for all

[katowulf]

@MariCarmenBaenaSopra that's a usage question outside the scope of this quickstart and you've appended it to a closed issue. It's unlikely to get any attention here. Try our community channels instead.

[katowulf]

Locking this conversation as it's unrelated to the quickstart. Please file feature requests here.