I have 20 enpoints that HTTP POST to my realtime database using the query parameter "auth":"<db secret>" and this works but I need to restrict access based on group. There are 2 groups of 10 endpoints.
These (particle.io) endpoints can be hardcoded with the URL to POST to, query parameters, custom headers, etc, but I don't believe they can handle an HTTP response (get the token to use) without some additional firmware level coding.
Is it possible for me to manually mint a persistent (lifetime:0) token using the Firebase Admin SDK that I can then configure in my endpoint?
You can mint a custom token using Admin SDKs, but they are meant to be exchanged for an ID token, which is what you must present when accessing the Firebase database. Plus, both custom tokens and ID tokens are short-lived (1 hour TTL).
If possible, you can run the Admin SDK directly on your devices with its privileges restricted via database auth overrides. But this is not usually recommended, since the users on the device can simply disable that.
I think you will have to make some HTTP calls from your devices, if you're to make this work with access tokens.
Related
I've used Firebase Auth to manage user logins on my app, and custom claims for their roles and permissions for each organization they belong to.
The problem is that when a user belongs to several organizations, the custom claims exceed the 1,000 characters length limit set by Firebase Authentication.
For the client, I can make an API call with the ID token, and respond with his/her claims. But for my gateway, it means I now need to query my database at each user request. It defeats the point of JWT at all.
How can I embed custom claims in a safe way?
Desktop Client: ReactJS + Firebase SDK
API Gateway: Express on NodeJS
Backend: Firestore for user metadata
Usually the keys and values of custom claims are very short, and you should not run into this limit. Short keys and values are important, since the claims are encoded in the JWT, which is sent with each request/connection.
You are likely storing readable, meaningful values in your token now. I'd recommend using shorter "codes" as the keys/values of your claims, similar to the three letter default properties of a JWT. That will keep your token size under control, and should bring you back under the limit unless really have a lot of claims.
firebase claims are used to control user permissions across firbase services like firestore rtdb storage .
I have 2 options
create-custom-tokens and firebase auth custom claims
is the claims in the custom-tokens are also limited to the same 1000 bytes size as the built-in option ??
can I just have an http trigger to the cloud function to create a custom token when needed from the frontend and use that token(that includes the custom claims) in any transaction that require user permission like upload a photo on a specific route. As the latest sdk allows to call the function without any boilerplate for HTTP client libraries is that feasible??
Claims on custom tokens are not size limited. But you can't exactly use custom tokens the way you've proposed. Only thing you can do with a custom token is to sign in with it on a client app: https://firebase.google.com/docs/auth/admin/create-custom-tokens#sign_in_using_custom_tokens_on_clients
However, once you perform the sign in, you can use the resulting ID token to perform any operation you need. That is the ID token will have the custom claims set on it.
I have following use cases:
I have cloud functions which are accessible with HTTP endpoint and they use authorization using custom token because the app is only accessible with certain IPs stored in RTDB so I have created one cloud function with will generate a custom token after signing in user using firebase client SDK and then it will create a custom token using admin SDK after checking IPs which are stored in RTDB.
Now with every subsequent call client will send token and functions will serve the request.
I have event listeners bound with the RTDB on a client and use file upload using client SDK which client initialize with firebaseApp.auth().signInWithCustomToken(custom token).
On the function side I use the same sign in the method that also utilizes my firebase SDK and then I serve that request. The problem here is this sign in the method is very slow like it is taking generally more than 1 second only in sign in.
Alternative
Now alternative is I can use id token which can be created using currentUser.getIdToken() on the client side itself and it takes barely few ms to decode that token but I cannot initialize SDK with that token. so I have to use admin SDK but my IP node in RTDB is not accessed by the normal user and can only be accessed with admin SDK, so if I use ADMIN SDK with Control Access with Custom Claims and Security Rules to give admin SDK similar access that the authorized user has then IP node will not be accessible.
Issues with id token
Id token can be refreshed on the client side so once a client has a custom token, It can generate as many tokens it wants and that is not desirable. Apart from that validating IP everytime is not the operation that I wanted to do so with custom token I only use that in generating a custom token and then for a refreshing token but with id token, this would not be possible as the client can generate it with SDK.
Basically, I have to use firebase SDK on the client side which will need custom token(for additional authorization check) to initialize and at the same time I call the clound function from the similar app so what is the best way to implement this use case.
Sometimes I want to send a message through Firebase notifications to one unique user, then I want access the token from that user, so I like to know what is the best practice for get that token at any time?
On initial startup of my app, the FCM SDK generates a registration token for the client app instance.
I can get that token, but if I save that token in Firebase realtime database, I think other people can access that data because it is "set persistent mode on" to access offline data.
My questions is:
Is it possible to get tokens of all users without save that in a database?
Can I get these tokens direct from Firebase Authentication? If not, what is the best practice for access these tokens?
I think other people can access that data because it is "set persistent mode on" to access offline data.
Simply save the registration token details to a secure node. Making sure that only you (or even including the user itself) to be the only ones that can access it. Read more on Understand Firebase Realtime Database Rules.
I can get that token, but if I save that token in Firebase realtime database, I think other people can access that data because it is "set persistent mode on" to access offline data.
Users won't be able to get the data they're not allowed to/wasn't designed to have on their device if you choose to restrict them.
Is it possible to get tokens of all users without save that in a database?
There is no API to get all the registration tokens related to your app. As mentioned in the documentation (emphasis mine):
After you've obtained the token, you can send it to your app server and store it using your preferred method. See the Instance ID API reference for full detail on the API.
It's the developer's (you) responsibility to send and store the registration token to a secure location.
Can I get these tokens direct from Firebase Authentication?
I'm not entirely sure what you mean by this. FCM Registration tokens are different from auth tokens. So, no.
If not, what is the best practice for access these tokens?
So long as you store the tokens in a secure location and make sure that you're always using the most recent/valid token, it should be good.
How can I create a firebase user from the node.js client? I see that there is a simple-login but that looks to be used from the web browser. I would like to authenticate with my firebase secret and then call the createuser api somehow.
The way my system is built the clients only send requests to the backend for processing. This way I have a log of every action taken by every user and I can guarantee that each alteration is applied to my other databases as well before it makes it into firebase. Also I do not want users to be able to create other users. Firebase is just a workqueue for me mostly but I am also using the simple login to verify the user then swapping them over to a login token afterwards to get the ability to check custom permissions in the auth on security rules.