I have doubts on the calling of firebase functions (gcp functions).
According to here: https://firebase.google.com/docs/functions/callable,
when HTTPS callable functions are being called, the functions.https.onCall trigger automatically deserializes the request body and validates auth tokens. Then in this case, if an unauthenticated end user called this function, is this function being triggered or not? In other words, will I be charged on this calling?
Its true that it does validate the auth tokens for you, but what your function does with those auth tokens is up the the function. By validating them, the framework ensures that invalid auth tokens won't look like an authenticated user.
Notably, the documentation states:
With callables, Firebase Authentication and FCM tokens, when available, are automatically included in requests.
The key to your question is when available.
If validating that the request was authenticated is important to you, then you need to check the variables that firebase provides in the context parameter. (See the API definition of the CallableContext object that is passed in. You are able to pull things off such as the uid (as auth.uid on the second parameter to the function), etc.
In short, the function certainly is executed, and if it does anything or not for an unauthenticated user depends on how it is written.
You can safely expect that the invocation itself is still is accounted for in your free tier quota or as a billable invocation -- there isn't anything at all that says that callable functions have to be authenticated, and there are many possible uses for non-authenticated callable functions (e.g. you want to protect a certain part of the database to only be accessed by server-side code, even if unauthenticated users run it).
Related
I have a callable function that gets users auth data and validates it (inside the function), if user is not authenticated or allowed to do a certain action I throw respective error.
However nothing stops malicious actors to run a loop that constantly pings such function and rack up cost in terms of invocations / little bit of time those functions run.
Cloud providers like AWS have systems in place where this auth check is set up on an api gateway / loadbalancer level and users are not billed if someone calls functions with unexpected headers / payload or without authentication.
Does something like this exist for firebase, perhaps via google cloud?
No, it's not possible. The callable function must execute in order for the firebase-functions SDK to verify the user's ID token via the Firebase Admin SDK. It's not a "free" operation in any way. No matter how you write or deploy it, something is going to have to invoke the Firebase Admin SDK to verify the token - it's not part of any unbilled cloud infrastructure.
Firebase callable cloud functions can be accessed via client sdks, which requires a valid auth context for authentication and authorization. But and at the same time it is exposed as an HTTP endpoint, thus can be called but will receive an unauthorized response.
My questions is, is there a way to completely restrict public access for a callable cloud functions? since firebase will charge cloud functions based on function executions. Even to return an unauthorized response, the request has already gone through to the function, thus during a DDoS attack this could be problematic.
There is no built-in support for rejecting a request to a Cloud Function before it reaches your code. If you want such functionality consider setting up Cloud Endpoints in front of your Cloud Functions.
The best you can with just Cloud Functions do is check whether the caller is authorized as the first thing in your function code, so that you reduce the amount of time the function is active. You'll still be charged for the invocation in that case, but you'll minimize the GB-seconds and CPU-seconds.
I tried out as #Frank suggested using google cloud run to deploy and ESP container which can by used to invoke private cloud functions. A detailed overview is described in the documentations itself.
https://cloud.google.com/endpoints/docs/openapi/get-started-cloud-functions#deploy_endpoints_proxy
Above given answer by #Frank van Puffelen is perfect but you can utilize a trik to restrict the access by securing that route. Here is the example,
const functions = require('firebase-functions');
exports.scheduleSampleJob = functions.https.onRequest((req , res) => {
let auth = req.header('Authorization');
if(auth == 'YOUR_API_AUTHORIZATION_KEY'){
// valid Authorization key, process the call
}else{
//send forbidden if Authorization key not valid
return res.status(403).send('Access is Forbidden');
}
});
Now, if you want to call the endpoint, It will require a Authorization header in request having value your secret key.
As firebase cloud function can also be used with firebase-auth, you can create custom logic to allow access to users having auth only and restrict the access for public excluding your app's authentic users.
My project is creating a website using firebase, but it is using the internal authen micro service instead of Firebase authen.
Every time the user logs in, the internal authen service will generate a token (I call it client_id), and send it to the client.
This token is also stored in the user collection.
Please help me how to write rule for the user via this client_id.
If it is write role, I can send the client_id via mothod update, delete, create and get it out by
request.resource.data.cliend_id and check it.
But if it is read role, I don't have any way to send to the client_id via the get method to authenticate users
I even thought of replacing all the get methods with the update methods to pass the client_id
But the response of the update method is just the update_time, not the object I updated
Firebase RTDB & Firestore Rules uses their own auth only. In every request that firebase client library sends uid along with jwt token and other security parameters. These are fundamental to firebase's working and thus can't be replaced.
As Aleksey mentioned, you can try custom auth. It is specifically tailored for such use cases only.
There is no way to provide extra data to security rules for the purpose of limiting read operations. That would not be secure at all, because a client could simply fake whatever they want in the query.
You can only use information provided by Firebase Auth available in request.auth, the data in the document itself in resource.data, or the contents of other documents using get(). If you want to attach additional data to the user account, consider using custom claims.
I've been following a tutorial to build a full stack website using firebase, react and redux. Log in sends a call to a back end function which uses
firebase.auth().signInWithEmailAndPassword for logging in. The IdToken is passed back to the client and stored in localstorage. Authentication and state persistence then relies on the client checking if the current date is past the expiry of the JWT token. API calls to the back end cloud functions also require an Authorization header using 'Bearer {IdToken}'.
This structure is causing me lots of headaches. I've done lots of reading and my current understanding is that firebase has it's own authorization persistence (?) that I can implement directly on my front end. Then using a listener I can automatically get new Id tokens on auth state change. This would solve my problem of the tokens expiring every hour. From what I've read local storage of the tokens is also a security risk.
I'm unsure as to how that affects authorization of my function calls. Should I still use the authorization header or is there a more elegant firebase way of doing that?
If you use Firebase Authentication's built-in providers, they indeed automatically persist the sign-in information information on most clients, restore it upon restart, and refresh the ID token just before it expires.
So if you use one of the standard providers, you can just get the user's ID token and then pass that to your Cloud Function.
You can even skip that step by using Callable Cloud Functions. For those, the Firebase Functions SDK passes the ID token along automatically, and the server automatically decodes and verifies it, and passes it to your code as context.auth.
So now that we can call HTTPS functions directly from client side, I'm wondering if I can use it for sensitive transactional requests and if it's safe. Before I was using forms with POST method but this could make things much simpler.
Is the call from the beginning to the end encrypted?
It may not be obvious at first, but you're asking a lot of questions here. It may take some time to unwind your concerns
First of all, both Cloud Functions HTTPS functions and callable functions are encrypted. In fact, all traffic in and out of Google is encrypted. That is the norm, and you can't even disable that if you wanted to. However, encrypted traffic doesn't necessarily mean that it's "safe". Encryption just guarantees that there can be no man-in-the-middle attacks that are eavesdropping or changing the content on the way in or out.
Encryption doesn't prevent someone from simply invoking the function directly from their own code. For HTTPS and callable functions, it's very much possible for anyone to invoke your function directly. There are no requirements that the call must be coming from your app or your web site. If this is a requirement for you, you need to perform some checks in your function itself to ensure that the call is valid.
With HTTP type functions, you can require that the caller send an authentication token with the request. Then, you can validate the token in your function, and proceed only if everything looks OK to you. There is an example of this in the official samples.
With callable type functions, an authentication token is automatically added if the user is logged in with Firebase Auth. The token is automatically validated as well. All you have to do is check to see if the user is allowed to do whatever it is the call wants to do.
"Safety" is not just about encryption. It includes both authentication and authorization as well.
The documentation you refer to explicitly mentions that Callable Functions are HTTPS ones, so yes the call is encrypted from end-to-end.
The Cloud Functions for Firebase client SDKs let you call functions
directly from a Firebase app. To call a function from your app in this
way, write and deploy an HTTPS Callable function in Cloud Functions,
and then add client logic to call the function from your app.