I'm currently thinking about using Firebase Auth system with my custom rest api service.
For example:
My custom api would authorise requests coming from angular app, but auth system begins in that
Angular app, so there I would get authenticated.
Later on, I would pass a token received from firebase to communicate with my service.
That service would check if token is ok and then let me in to resources.
Is it possible to do ?
Related
I have my FastAPI secured with Firebase Auth.
My app sings in using Firebase Phone Auth, requests a Custom Firebase Token from my FastAPI server to gain extra custom claims, and signs in using the Custom Token in de App automatically. This last token is then used to authenticate further with my API.
Now my problem is; how can I load test my API with this, for example with 1k/10k/20k concurrent users?
Kind regards.
I am new to Firebase. I have linked Firebase to my React Native app, the Auth part is working and in the SCOPES array I am passing necessary scopes for sending emails https://www.googleapis.com/auth/gmail.send.
The Problem: On backend I am using Node.js and a Google Cloud project for sending emails, the way I wan this to work is that I will be sending a POST request to backend with the access token of user's account and then using that access token to send emails.
Is this something possible? I am basically using 2 different projects, one Firebase project for Authentication and giving Gmail permission and then another Google Cloud project for sending emails. I have whitelisted the Email sending project in Firebase Auth project.
Is this something possible? Is there any better way to achieve this?
I have a mobile app (Android/iOS) that uses the Firebase SDK for several Firebase services (including Authentication and Storage).
Now there's a subsystem within the app that can't directly access the Firebase SDK, but I need to upload files to Storage from this subsystem. HTTP(S) requests are possible, so I tried to use the Storage JSON API for uploading.
However, an OAuth 2.0 token is required for authorizing requests via the JSON API. Is there a simple way to receive such a token, when there's already a signed-in user in the Firebase SDK? It seems the only thing I get from the Firebase SDK is the "Firebase ID token" (JWT token), but I don't know how to convert it (or if this is even possible) to an accepted OAuth token for the JSON API.
I think you're trying to do the petition from the plugin itself and it might not have the permissions.
Did you pass it to sign In With Custom Token to the SDK when your users sing-in?
I read that after that, a Custom Token and credentials are attached to the user's profile.
Why don't you try to do the petition from the user's profile instead of doing it from the plugin?
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:
https://platform.ifttt.com/docs/api_reference#service-authentication
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.
So IFTTT calls Cloud Functions, which then calls Realtime Database, and you want to authentication the IFTT user with Realtime Database. Is that correct? If so, you can either use an OAuth2 token or create a Firebase Authentication session cookie.
Use an OAuth2 token
I did this not too long ago for accessing the Realtime Database from Google Apps Script. The requirements are relatively simple (once you know them):
The OAuth2 tokens must be requested with the correct scopes: https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/firebase.database.
The OAuth2 access token must be present in the request to Realtime Database.
The authenticated user must be at least an editor on the Firebase project. Note that this is not a Firebase Authentication user, but a Google user account.
Also see:
How to integrate Firebase into Google Apps Script without using (deprecated) database secret
Use a Firebase Authentication session cookie
You can also use a Firebase Authentication session cookie, which can be longer-lived (up to 2 weeks) than a regular Firebase Authentication ID token (up to an hour). You'll want to set up a Cloud Function for creating the session cookie, call that from IFTTT, and then pass the session cookie with the IFTTT request and along to the Realtime Database.
For more on this, see:
the Firebase documentation on managing session cookies.
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: https://github.com/IFTTT/connect_with_ifttt_auth_sample
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: https://gist.github.com/nathanvogel/15ed311258b91d7ec3d25f44047780e2
Firebase Rest API mentions that we can pass CREDENTIAL to provide access to authenticated nodes. However I was not able to find documentation on where I can find these credential or generate these credential. Custom tokens generated using NodeJS firebase-admin client also don't work.
https://firebase.google.com/docs/database/rest/save-data
https://docs-examples.firebaseio.com/rest/saving-data/auth-example.json?auth=CREDENTIAL
If you scrolled down a little on the same page, you would find the answer:
In the following example we send a POST request with an auth parameter, where CREDENTIAL is either our Firebase app secret or an authentication token...
Firebase secrets are legacy credentials you can find/create under Project settings - Service Accounts in the Console. Using one as the auth parameter gives the caller administrative access.
Or you can use a service account to generate admin level access tokens instead of relying on the legacy secrets. See here for the Java implementation.
Or if you have an authenticated user – for example you're implementing an API a client apps call via HTTP, passing along their current access token –, you can use that token directly to impersonate the user.
The custom authentication tokens serve a completely different purpose and are part of a different sign in flow. Therefore they do nothing via the REST API.