[FR] auth: Allow expiry to be specified in .createCustomToken

[rhodgkins]

Is your feature request related to a problem? Please describe.

It would be good if you could specify the duration of time you would like the login token to be valid for. For our use at least, the result of .createCustomToken is mostly used immediately after being provided to the client, so we'd like to have a very short expiry time.

Describe the solution you'd like

Update .createCustomToken or a new method .createCustomTokenWithOptions that takes an expiry.

Describe alternatives you've considered

Using the details from create custom tokens using a third-party JWT library, but this seems a bit redundant when the SDK is so close to providing what is needed.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[rhodgkins]

I realise this API change will probably need to go through the API council or something like firebase-tools does, but going to start a PR off for this anyway, going with the .createCustomTokenWithOptions for now...

[felansu]

+1 Good and needed idea

[hiranya911]

@bojeil-google this is really a product decision. WDYT? Should we expose an option to make the expiry time configurable?

[bojeil-google]

Ok, I checked with some folks. I think we can allow a range from [5min, 1hour] with 1 hour being the default. 1 hour is the maximum allowed on our backend token verifier. I suggest setting 5min as the lower limit to take into account clock skew issues, but in theory we can go down lower.

[hiranya911]

@bojeil-google do you want to start an API proposal or something for this?

[bojeil-google]

@lsirac has some bandwidth to work on the API proposal this quarter. Hey @lsirac, basically we need to update these APIs to accept an additional optional duration. We can allow a range from [5min, 1hour] with 1 hour being the default. Anything beyond 1 hour will be rejected by our backend anyway and anything less than 5mins could be subject to clock skews.

[rhodgkins]

@bojeil-google if it helps I've rebased by original PR #1017 to fix any conflicts (its almost been a year, but luckily there weren't many!) and also set the minimum expiry to 5 mins as per your comment.

Hopefully it might be of some eventual use...!

[alexcastillo]

No chance we can have the 1 hour max increased?

[bojeil-google]

No chance we can have the 1 hour max increased?

Yeah, the internal service we use only allows 1 hour max and they are unlikely to change it. I would also agree with that from a security perspective.

[alexcastillo]

Understood. Do you have any advice on implementing apiKey-like auth since custom tokens don't seem to be a good fit for this use case?

[davinchia]

@alexcastillo did you ever figure out how to implement apiKey-like auth with FIrebase? This is something I'm curious about as well.

[alexcastillo]

I ended up implementing a custom OAuth workflow with the help of this library:

https://github.com/chrisvxd/oauth2-firebase-auth

Plus additional work, which you can find in this pull request:

https://github.com/chrisvxd/oauth2-firebase-auth/pull/4

Good luck.

[IchordeDionysos]

@bojeil-google any updates on the internal review?

[jeremyrajan]

any updates on this, would be really useful :) thanks!

[lahirumaramba]

FIY: @prameshj @renkelvin

[georgeportillo]

Come on, someone check the buganizer (or whatever y'all are using now) and tell the community. We need the ability to extend the custom tokens beyond an hour.

[Stradivario]

Having the same issue

I am trying to implement CI/CD workflow based on my login credentials with firebase.

The feature actually is not simple to implement from google side.

• When we generate token without expire we should invalidate somewhere in some moment so there should be a list of created custom tokens without expire date.
  • We should be able to revoke these tokens probably from a user interface in firebase cli

In addition to these things firebase team need to introduce a scope to these tokens in order to have only access to a specific parts of the system like IAM roles in AWS for example. Accept everything else we need to do a little changes to our auth layer in the backend in order to understand the scope of the generated token since if it is coming from the same account and this custom token leaks the intruder will be able to interact and mimic like the issue account in our applications.

So i am probably assuming that these feature will not be introduced unless firebase create OAuth like service where we could define our Scope and custom tokens.

The same problem appears to be happening if we want to create a Single Sign On button from our website

For example "Login with MyWebsite" in order to do that we need to be able to create OAuth redirect to a particular website and create token which will then be used in third party app for signing in with "Login with MyWebsite" button.

I am thinking that this will not land even in 5+ years in firebase so we need to find different solution to our usecase.

If you have any recommendations i would love to read them!

Cheers guys !

[IchordeDionysos]

I am trying to implement CI/CD workflow based on my login credentials with firebase. I'm not sure if you are correct in this issue.

This is about end-user authentication, if you want to automate your deployments, e.g. with Cloud Build or CircleCI, look into service account credentials, which are exactly for that use-case to authenticate against Google servers. You can assign IAM roles to your service accounts.

More on service accounts

If you want to build your own CI tool and your customers use your own CI tool, the way they'd need to authenticate against your server would be with the ID and refresh tokens. If the ID token expires they can get a new ID token using the refresh token.

More on ID & Refresh tokens

When we generate token without expire we should invalidate somewhere in some moment so there should be a list of created custom tokens without expire date.

You can create your own JWT token where you specify your own expiry, and then have an API that checks your own JWT token for validity and whether it's expired/revoked. More on JWT token revocation

When your own JWT token is valid, you can create a custom token for using it immediately!

In addition to these things firebase team need to introduce a scope to these tokens in order to have only access to a specific parts of the system like IAM roles in AWS for example.

You can add custom claims to your token which will then be part of the Firebase ID token. This allows you to verify access to resources based on those claims. More on this here

[IchordeDionysos]

@lahirumaramba @prameshj @renkelvin any updates here? :)

[ponez]

This issue been on-going for the last 3 years, not to mention people were asking for this since 2018 ? I doubt that this feature would be added

[felansu]

maybe next week @ponez

[jordanebelanger]

+1 lmao

In the end I just made my own token which is used as an intermediary token to generate a custom token afterwards, but it would've been nice to not have to do this.

[ponez]

It's been over 6months 💀

[lsirac]

@pragatimodi mind taking a look?

[arnotixe]

ok so it's not closed either

I don't like long lived tokens. And for my use case 3600 secs is waaay too much -- would be great to reduce it in a simple way.

Use case is -feel free to yell if there are much better way to do this- Logging on to a "sister" app using the same Firebase auth.

Specifically, use case is going from a web or mobile-native app to a support web site hosted on a different domain, in 1 click:

• Logged in users can click Support button to call a callable Cloud Function that will generate a custom token for their uid
• The app then opens a web browser at https://support.myapp.com/login?token=xxx
• Support app consumes that token and user is in✓

Longevity for this use case while maximizing eavesdropping/valid tokens floating around for long periods in time would in my mind be something like 5 to 10 seconds tops.

Not opposed to minting custom tokens for this - totally doable, but maybe it's easier to do the reduce expirytime portion of this issue?