How To Authenticate A Firebase User To An IFTTT Service?

I'm trying to build an IFTTT service and connect it to my Firebase backend.

I need to authenticate user as indicated in the IFTTT docs:

IFTTT’s protocol supports OAuth2 authentication, including support for refresh tokens if so desired.

Your service API should use access tokens for authentication and as a source of identity. A single access token should correspond to a single user account or resource owner on your service.

If refresh tokens are used, they must be non-expiring. If refresh tokens are not used, access tokens must be non-expiring.

But I can only get short-lived access tokens from Firebase it seems. Where can I get or how can I generate such tokens from the Firebase auth SDK?

Update in response to @FrankvanPuffelen:

I'll create an IFTTT service running on a Node server (possibly simply Cloud Functions) that will use the Firebase RTDB to send formatted HTTP request back to IFTTT. IFTTT requires me to authorize user accounts. Their required UX is something like this:

  • If an IFTTT user tries to use my service on the IFTTT website,
  • an auth dialog for my service pops up.
  • The user logs in and confirms IFTTT's access to their data on my service.
  • Some OAuth 2.0 tokens are exchanged.
  • IFTTT servers will periodically send requests (authentified with those tokens) on behalf of the user to my server.

Part of the question is: Can I use the Firebase Auth API to get those tokens, etc. or do I need to create a new OAuth 2.0 "layer" with my own generated tokens for IFTTT?

PS: I'm very new to OAuth, so it's all a bit confusing to me, sorry if the question isn't very clear.



I'm posting my solution here, this is a rough draft of what I did at at the time.

I'm using this auth method: My API has users with non-expiring OAuth2 access tokens and have an Express server responding at a Firebase HTTPS Cloud Function endpoint. Currently, at the prototyping stage, it generates fake tokens from the UID that are successfully accepted by IFTTT.

It's a redirect-heavy authentification flow based on this old IFTTT api example:

Here's the gist of it:

  • Tokens and Auth Codes are just randomized and encrypted UIDs for now.
  • /oauth/authorize redirects to my app.
  • The app asks the user if they want to authorize IFTTT
  • The app redirects to /oauth/authorize_user
  • /oauth/authorize_user generates a user-specific code and redirects the user to IFTTT with this code
  • IFTTT asks /oauth/token to exchange the code for a Bearer tokens.
  • IFTTT can now make requests on behalf of this user with this bearer token.

Sample code here: