I'm trying to write extension which will not allow to use chrome window where google user already authetificated.
The reason for this is that computer might be used by other person, and I don't want anyone else to use my google account, and I don't want to sign out each time.
But anyway. I was thinking to use chrome.identity.getAuthToken but this will ask current user to approve to use token for my app. Not logon (remember, chrome user already logged in!). So how can I ask user to enter using password, then send it to google, so password is checked?
Related
I'm working on my first MERN fullstack project (an e-commerce demo). I have almost finished the authentication part, but I am having doubts about how to manage the users who have the same registration email both through custom sign-in and google login on the MongoDB database.
While doing various researches, I noticed that one of the methods used is the following:
1- If the email of the user who logs in via google login is already saved in the database as the same user had already registered via traditional sign-up, a new user will not be created in the database, but with both methods of signing -in we will point to the same user already saved with that email.
2- If there are no users saved in the database with that email (as the user logged in for the first time with google login and did not first register traditionally), once the user logged in with google login, it will be saved to the database for the first time.
However, this method presents problems with regard to the second type of users mentioned above.
In fact, if we merge the accounts with the same email on the database, if the user logs in for the first time with google, no password will be saved on the database. Therefore, if the same user decides in the future to log in in the traditional way, he will not be able to do so because he will not be able to fill in the password field.
How to solve this problem?
Usually sites with the "first Google login immediately creates an account" have 2 solutions to this problem:
As part of the "immediately create an account", they directly ask the user to choose a password.
Alternatively, their "Change password" section allows creating a password should there be none yet. Therefore the account is indeed passworld-less at the beginning, but the user can opt to add a password.
For the 2nd solution, there's the small problem that if the user loses access to their Google account and didn't set a password, they're locked out. Rare case which might not be worth looking out for. And perhaps your Customer Service can still help them out.
I am trying to login firebase google sign in using selenium web driver. But I am getting the following error when enter email and click next button:
**Couldn't sign you in**
This browser or app may not be secure.
Try using a different browser. If you’re already using a supported browser, you can refresh your screen and try again to sign in.
// Redirected to reject url
https://accounts.google.com/signin/oauth/deniedsigninrejected?
I used chrome browser and chrome driver version 79.0.3945.79.
Any help would be appreciated.
The problem is you provide email to sign in which didn't access this firebase.
May be not the best solution.But it works best for me.
Provide email to sign in should be the owner email, which is used to specify who can full acess firebase. So, it works property when you use owner email.
Is there any way to logout Or switch the account in actions on google? I am using account linking with Google (OAuth and Google SignIn) I want to do something like this that if the user says "Logout me from this account OR switch to another account", the action should logout him and open the google authentication.
I saw some of the Helpers intent in the documentation but not found any Helper for signout/logout.
Could you please help me that how can I logout the user by saying "logout from account or switch to another account"
Keep in mind that "Account Linking" isn't really logging in. It is connecting the Google Assistant account they're using to the account you use on your system. If you're using just Google Sign In for Assistant, then you just want access to the information about the account they're using.
So "logging out" isn't quite what you're asking to do. In the first case, you want to "unlink" their Assistant account from the account on your system. In the second case, you want to forget who they are.
To do the "unlinking", you can return HTTP code 401 "Unauthorized". This will force the Assistant to discard any tokens they have for the user. Users can also do the unlinking through your directory listing.
Forgetting who they are is more difficult. There is nothing in AoG that does this directly, although you can direct them to a page that calls the sign out method for Google Sign In. They can also do the unlinking through the directory listing or through Google's account management page.
Account linking can be turned off by clicking at that account logo below in case you want to test the intent again and redirected to sign in automatically every time.
Problem assumptions/conditions:
There exists a user with email foo#bar.com (unverified) in the system.
Visitor is not signed into the system (no current session, e.g. new browser).
Visitor signup/login using Google Account, through OAuth (user authorizes).
The system receives callback with uid and the email foo#bar.com [verified by Google].
I see three options here:
A. Sign in the visitor to the existing account with email foo#bar.com. This have some security implications.
B. Ask for a password [assuming there is a password in the system, this may not be the case with multiple OAuth providers] and sign them into existing account if it's valid.
C. Reject the login/signup, say email is already used, encourage user to login before connecting with Google.
What are the security risks with option #A?
What I've come up with myself:
'Anticipation attacks' could be performed, where an attacker anticipates a signup and creates an account on the system before the target does. After the target has signed up using OAuth he will have an active session on that account. Would be defeated by clearing all sessions on the account before doing #A.
When the user logged in through OAuth in Google, you can be sure that the email address you get back from Google really belongs to that user. So the thing you seem to worry about is that the user already known on your system by that email address does not own that email address. That should have been caught by the time he signed up, with an email conversation. But if it isn't, you might want to reset the password and send an email to the genuine user that you did so, and for what reasons. You may also want to log the user out if he is currently logged in. The user can still access his data, but only through his OAuth login session, or by responding to the email. The email should state that it is a precaution, as there is no way to find out if it really is the same person.
An "accidental attack" can happen too:
In step 1, the user who signed up with address foo#bar.com, in fact intended to type fuu#bar.com, but typed a typo: foo instead of fuu.
Now, the Google user signs up with Oauth and foo#bar.com, and in this way hijacks the account of the step-1 user. Accidentally :-) because of a typo made by the step-1 user.
So, either the step-1 user can anticipate-attack the Google user, or the Google user can accidentally-attack the step-1 user. (I cannot think of any other attacks at least not right now.)
I've seen sites that you login with your facebook account, give a donation and it will save your CC information for future use.
The scary part is if your FB login is saved and say you walk away from your computer, someone can go to that with your login, donate to another organization with your credit card because it's saved.
An unlikely scenario, but still possible. Is there a way to allow users to browse the website with the saved FB login, but require them to re-enter their password as the last step to complete their transaction?
Yes, there is such functionality. It's called by docs Re-Authentication and designed for cases exactly like this.
Citing documentation:
In some applications, you may want to double-check the user's identity - perhaps before they make a purchase, or change some personal data. Re-authentication allows you to force the user to re-enter their Facebook password before they're passed back to your app.