I'm building a full-stack application with Next-JS. I'm building an API that works with Firebase. I was wondering if there is a way to make this API secure.
Let me elaborate. There is an option to your account called Premium. This variable is stored in the Firestore and will determine if you have purchased a Premium membership. This will determine whether or not you have access to certain features. I will use an API to change this variable.
I had the following in mind:
Have a button on the page to upgrade account.
Button pressed? Call to the API with the following params: email, upgrade to. This is because the same function can also be used to downgrade an account, for example when the user doesn't pay for the upgrade.
That API function changes the variable in the Firestore. It returns a status and a message.
I want to make option 2 more secure because otherwise, it would allow anyone to change the premium variable. That is obviously not what I want. Is there anything I can do about that? For example, a token system, the thing with that is that I have been thinking about that and I don't really know how to implement that and how it would work exactly.
For anyone wondering why I am using an API: I will also be creating an app, probably with react-native. The user will also be able to change their account status and interact with the API to do other stuff in that app.
Thanks for reading and responding! I hope this is at least a bit clear. If you have any questions, please comment them.
I do similar things in my app. I use Cloud Functions (which operate in a secure environment) to both save settings in Security-Rules -protected tables, as well as setting Custom Claims in the users Auth profile. All authorizations are then verified in the Cloud Functions before any changes are made - You may need to "seed" some values in a protected collection/document from the Console to get the process started.
Related
I'm creating a Google Workspace Add-On and need to make some requests using OAuth. They provide a guide here explaining how to do so. In the sample code, it's suggested that the OAuth client secret be inline:
function getOAuthService() {
return OAuth2.createService('SERVICE_NAME')
.setAuthorizationBaseUrl('SERVICE_AUTH_URL')
.setTokenUrl('SERVICE_AUTH_TOKEN_URL')
.setClientId('CLIENT_ID')
.setClientSecret('CLIENT_SECRET')
.setScope('SERVICE_SCOPE_REQUESTS')
.setCallbackFunction('authCallback')
.setCache(CacheService.getUserCache())
.setPropertyStore(PropertiesService.getUserProperties());
}
Is this safe for me to do?
I don't know how Google App Script is architected so I don't have details on where and how the code is being run.
Most likely it is safe since the script is only accessible to the script owner and Workspace Admins if it is for Google workspace (which may or may not be an issue).
Well, you can add some security/safety by making use of a container, by using Container-bound script which makes use of Google Spreadsheet, Google Doc or any other that allows user interaction. Or a standalone script but also makes use of other way to connect to UI for interaction. Refer to this link for more detailed explanation on that: What is the appropriate way to manage API secrets within a Google Apps script?
Otherwise, the only way I see that you can do is store the keys and secrets in User Properties. Here's how you can do it: Storing API Keys and secrets in Google AppScript user property
Also you can refer to this link below for more general information on how you can manage or add some security: https://softwareengineering.stackexchange.com/questions/205606/strategy-for-keeping-secret-info-such-as-api-keys-out-of-source-control
I am working on a project which needs User Authentication. The "Clients" are iOS (Swift) or Android (Kotlin) native applications. The original form of the API (NodeJS) used Facebook and Account Kit for OAuth and Phone authentication respectively. Since Account Kit shutdown, we moved to Firebase Phone Authentication for Phone but left Facebook in its original form. Now, we're wanting to consolidate our Authentication providers (to Firebase) but I can't seem to find a way to "convert" or "import" Facebook users to Firebase-based Facebook users.
So far, I've read through the Documentation, including the category about importing users, but it doesn't seem to indicate an ability to maintain backwards compatibility, while also moving forward to Firebase. What I mean is, it has an ability to set information, but it doesn't indicate that the same information will be used to authenticate that user as the same unique visitor.
What I am looking for is either transitory logic, which will handle this during login, or preferably, a "bulk-insert" type migration. Essentially, I want to have it setup so that the API only needs to keep a single authentication UID, and use only a single third party (even if they then use another subsequent third party) while maintaining user uniqueness (so that it doesn't create a new user for the same Facebook account).
Part of my problem in creating a temporary patch (not necessary if the main question is answered) is that I don't know of a way to differentiate between a Facebook UID and a Firebase UID to fork the logic. Again, this is only relevant if there isn't a solution for migration.
Feel free to request any more details that would be useful.
Update #1
I realized my question was open ended in what I was asking. I've been digging further and can better define my question:
I need a way to bulk insert users into Firebase's Authentication with a provider of Facebook. I know I can import them, via admin.auth().importUsers([...]) and that I can create accounts via admin.auth().createUser({...}) but when I do the former I can't seem to get back the user's UID, and the latter doesn't seem to allow specifying a provider. Am I missing something?
I'm trying to develop a Webapp that would allow users authenticate with their Google Account and store some information and files on their Google Drive.
It would be a static html/js page with no backend.
There is a quickstart example here:
https://developers.google.com/drive/api/v3/quickstart/js
It works fine but I am wondering if exposing my Client ID and API Key to everybody like in this example could not be a security problem. Anyone could use these id and key in their own app.
What do you think?
As per Changes to the Google APIs Terms of Service, you are asked to keep your private keys private.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
The author of that post was contacted and the exchange was made available on DaImTo's blog. This is a part of the reply:
Yes, you are not making your personal data available to them. You are,
however, allowing them to “impersonate” you in Google’s eyes. If our
abuse systems detect abuse (say, should someone try to DoS one of our
services using your key), you run the risk that they would terminate
your account because of it (and please note — they wouldn’t just cut
access to the key, they would shut down your console account).
I'm building a Windows 8.1 store app and need to incorporate authentication. This is an enterprise app used in house. We load the app onto a tablet and a team may check that tablet out for weeks at a time, go out to the field to collect data and then we put in on a shelf until another team needs to use it. Now different teams may work for difference clients so when we authenticate users not only do they get access to the app but we also check what groups they are in to determine what clients they can work on or what previous records they can search for.
I've followed various ADAL tutorials and am able to setup everything in Azure and in my app I am able to authenticate a user successfully and get their groups. This relies on ADAL handling the username/password. What happens when the app shuts down and the user in a place where there is no internet (or even a reliable cell connection)? Specifically how can I have the user type a username/password to re-authenticate and get the same groups they were in when they can't access Azure services?
It appears they isn't available as the guidance always points to that is a risky proposition to have the app handle username/passwords. I understand that stance and can appreciate the caution behind it. However, in all of the ADAL documentation that I find that says this, none of them tell me how to handle an offline authentication scenario.
I have found links such as ADAL v3: How to authenticate using UserPasswordCredential? that tell me how to bypass the ADAL login page. I may have to move to that route and handle all of the username/passwords securely within the app, but first I would like to reach out and see how others tackle this scenario. Is it really as simple as avoiding best practices and just handle the username/password within the app?
If anyone has some guidance, ADAL (or other oauth providers) documentation, or other articles/advice I can follow up on to help achieve offline authentication I would greatly appreciate it!
Additional Information:
My scenario that I'm trying to cover is what happens when I have 1 device, 1 app, and many different users? These users will be in different groups that will determine how data fields get populated (filter data in combo boxes) and what previously submitted forms they can query for. All users would need to login when online to cache their information (say on Day 0) before they can ever use the app. On Day 1 user 1 uses the app and doesn't log out. I would expect the app to have a timeout timer to log that user out after 2 hours of no activity. On Day 2, user 2 just grabs the device off the shelf and takes it out into the field. He has no internet and needs to log in to determine who they are and what group they are in. I would expect since he has logged in once and verified his credentials already that we can enable this sort of scenario.
What I'm looking for is guidance if ADAL as a library can handle this or is it truly up to me the app developer to handle this sort of scenario. As I see it currently I need to store all user credentials, but at the same time it seems like everyone advises against that. I feel like I'm in a situation where I need to create a custom login screen and store the user data, SECURELY of course, even though its not recommended. It seems like all articles on how to use ADAL are written from a consumer app standpoint (or a BYOD) and don't take into account how a mobile app would be written for the enterprise.
That depends on your app design, if the first time(app online) , user login and app store all groups ,user information .After that user doesn't need to use token to get related information again(send request to server to acquire groups/user info). If app is offline , user doesn't need to re-authenticate(app controls the user session) , just get group/user information from cache . When using resource owner flow , you still need to send authenticate request to Azure AD server which need internet.
I have just an idea for now to develop an application based on foursquare API.
I checked in the website that a creation of an application inside the foursquare is needed to access the api functions.
There some form fields in the application creation that cannot be filled by me as I don't have an application yet, like web address home page, privacy police page, etc.
I want to perform some tests for a certain time and then choose if I'll proceed with the application development or not.
For now I just need access for the venue stats function. Do you know if it's possible to have access to this function without have an official application?
Regards,
Rodrigo Lima
You need to create an application in order to get an OAuth token, which you need to call venues/stats. In practice, during testing, the only real field that needs to be accurate is the redirect URI, which you'll need for OAuth. The others can take dummy values for now, so long as you go and change them before you publish.