I am having a strange situation in my app where Unauthorised users can send me the messages. whereas It will be only one user who can have the read access to those messages.
I am using the $bindto to write on the database (with my google logged in and google authentication enabled) and reading it through email password authentication method .
I want that user could send the message without any authentication process.
Is this possible?
There is no way we can stop unautheticated user to get the data from firebase database. For this situation that I faced I was worried about that if a user download the JS file he can get the access of all my database. But there is a catch :
Since you whitelist your IP/domain name no one other than that domain can take the access.So, even if they download your file they will no be able to get the access as request will not be from authenticated IP/domain name.
The other way is using the anonymous authentication method so that u can anyhow authenticate user and by that you can atleast have the trail of who are working or modifying your data (IP tracking access log is also useful).
Related
I am trying to figure out how OAuth2.0 (or something else entirely) can be used to handle a situation where a user who is calling a backend api, can only retrieve data relevant to that user.
For example:
Lets say I have a bank application, and the customer account information is located at "bank.com/account/{customerId}". How do I restrict access to this, so that other customers cannot see each-others bank account information? As anyone with an access token could get anyone's account info and Roles can't solve this.
I have come up with a potential solution to this problem using Firebase JWTs which is to access the header of the incoming request and compare the User ID in the body of the token to that of the data being accessed.
My gut tells me I am missing the bigger picture, as this problem must be a common phenomena, and I could not find the answer elsewhere.
My Environment is a Spring Boot backend utilizing the Oauth2.0 resource server pointing to the firebase project. Backend is connected to a Postgres database. Frontend is an Angular Application.
To ensure users can access only their own resources, you must write it in your Spring Boot application. OAuth2 only provides you an access token which you can use to find out who is calling you and what scopes he has granted.
But the security logic is up to you to implement. If you have a userId in URLs, you should check that it matches the userId from access token. If user data is stored in a database, you will probably need to add conditions to your SQL queries such as WHERE user_id = :userId.
You can also use scopes from an access token to grant only partial access to user's resources. It's useful if another application can access user's resources on his behalf. Such as reading person's name and email when logging in somewhere using Google/Facebook/Github.
I'm currently developing a web app using firebase authentication to make sure only authorized users can access the backend (e.g. firestore).
However, I don't really care about differentiating users but just want a single password based login/authentication. Meaning users come to the site, enter the password they know and then they get access to the protected data (e.g. from firestore). No need to create a own account.
However, I don't think firebase auth supports something like that.
What would likely work is just using .htaccess to protect the page and then provide users with anonymous accounts once they can access the app/page.
However, the browser popup caused by this is not nice enough for my purpose, I would prefer a nicely styled password form in the actual browser window.
What I could try is creating one account and sharing the password for that with all users (and set the email in the background). However, I'm not sure whether this works fine (e.g. multiple users being logged in at the same time on the same account).
Am I missing a simple option to implement such a single password based login shared between users?
Or is it e.g. possible to send a password to cloud functions, check it there and return an access token for an anonymous account from there to the user?
You can just create a single Firebase Auth email/password account and share the credentials with everyone. As long as you trust that each user will not share them with anyone else, and you trust that they will not maliciously overwrite each others' data, it should be fine.
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
I know there is a way to log in anonymously with Google Firebase, but I haven't gotten it working. The issue I am having is that my app needs to be accessible on any device without logging into any account with the app.
It needs to have full control of the app's database, both reading and writing. This app isn't really meant for public use, so I am OK with anonymous authentication. I also should not have to click a button in order for it to authenticate, it should do it automatically. I tried adding the code that Google provides, but it still wont authenticate. It does work with a Google account.
Thanks!
It was an issue related to the database rules. The default rules are set so that only authenticated users are able to read and write to the database. I set both so that anyone can read or write to the database from any device without logging in.
I would like to track anonymous user actions as if the user would be authenticated. The goal is to let users perform actions(normally reserved to authenticated users), save it in Database with a special status (not visible until user will log into the application).
For example,
an anonymous user reply to a comment.
The system detect that the user is not logged in, save the comment with special status 'waiting for authentication'.
The system ask user to log in, in order to complete the registration of the comment.
User log into the application.
The system check for 'waiting for authentication' status and update/associate entries to the user authenticated.
Have you any suggestions / experiences to implement this type of functionality? Maybe Symfony has already in feature/bundle for that?
What you are trying to do is simillar to Lazy Registration, which is a proven concept. It is well implemented here at stackoverflow. It allows you to post messages after providing an email address. It works similar to this one:
http://www.90percentofeverything.com/2009/03/16/signup-forms-must-die-heres-how-we-killed-ours/
However, if you really want to go your way, without asking user for an email address, I would recommend storing data at browser local storage. It would save you a lot of work on backend side. Data would be transferred to the backend only when user registers. This way you will also prevent database pollution with users who never registered. http://blog.teamtreehouse.com/storing-data-on-the-client-with-localstorage
You could use ip address but it won't be very effective because one user can access your website from many ip addresses (wifi, 3g/4g connection ...).
You can rely on cookies but once he logs in from another device you can't do anything about it.
IMO, you should save actions and link them to a uniq token that you send to the anonymous user, once he's authenticated he can provide the generated token and then you save actions for that user. Becareful to not forget removing saved anonymous-actions once they are "identified".