Our application is using gapi.auth.signin for authentication. The problem is that the account selection drop down list is not presented when user is logged into multiple accounts. Currently, to overcome this the app sets approvalprompt = force, cookiepolicy = url/single_host_origin. Obviously, this is not very efficient.
Is it possible to display multi-user selection drop down list when using gapi.auth.signin?
Shall gapi.auth.authorize be used instead? (Related question)
Thank you.
Google+ Sign-In uses a mechanism that detects when a user has already authorized a Google account. In order to prompt the user to sign in and not automatically sign the user in, you can call gapi.auth.signout from the JavaScript client as demonstrated here:
http://wheresgus.com/signindemo
However, on Sign in, the currently active Google account will be automatically signed in. Please comment on the Google+ issue tracker, this might be a bug.
Related
I set up an account creation page with a remember me and a jwt token verification via WorkOS. There is no password creation and just this verification (plan to add in password later if needed as the country uses OTP more than passwords)
A new user creates an account and selects remember me (using JavaScript).
The next time I sign in, I have my account populated like a*****#gmail.com.
A lot of websites I have seen have it so that when you click on this email, it goes to the full list of all gmails and you have to select that email again.
I’ve seen this remember me automatically sign in only if the user saves a password (like Facebook - see other profile accounts in sign in and you click and go in directly). But above mentioned this country doesn’t prefer passwords as much as OTP. I don’t have a password yet and really looking to avoid adding it in unless it is absolutely necessary to do this.
My goal: I don’t want to see this full screen of all gmail accounts in Google OAuth also referred to in documentation as the Account picker. I just want it to automatically sign in to the specific remembered account selected, assuming I have that gmail password saved.if the user doesn’t have the gmail password saved then, they will be directed to that specific emails sign in screen
How do I bypass this full list of gmail accounts and manual selection and just automatically sign in to my remembered email account?
I’ve looked at older answers on here but nothing seems to fully handle this. I’m wondering if this will help me achieve this.
https://developers.google.com/identity/gsi/web/guides/automatic-sign-in-sign-out
I’ve tried just having the email remembered and then they click on it and it asks do you want to sign in via gmail or magic link? That works and is better than not providing the remember me at all, but it’s only half way.
Our website allows users to create a new account using a registration page where we collect username, email, passwords, avatar, etc. The users activate their account and then login and browse, buy, comment, etc like normal.
We recently added the Login with Google button to our site as an additional option. Currently the system does the following:
Get a post request from Google
Verify the signature on the JWT and prepare the credentials
Do some security checks on the request
Check if the email exists with an existing user in our system - if it does, authorize them and login
If the email and sub don't exist, create a new account and load the data from Googles credential POST to make a new account
The conflict here is whether or not we should be doing step 4 on existing accounts that were not created using Google or if those accounts should be converted to Google only accounts when they login.
For example,
I register with john#gmail.com as my account name with a password created on the register page. One day, I accidentally, or on purpose, click Sign in with Google. The system sees my email from the oauth login and finds my account already in the system.
Should it:
Log me into the account without checking password, since its already my Google account, and keep everything else the same.
Give me an error that my email is already in use on another account and abort the login process.
Convert the account to a Google only sign-in and remove the password to prevent me from logging in without using Google in the future.
Update the account with the Google sub id but keep the password option and allow them to reset their website password independently from Google should they wish to "unlink" their Google account in the future.
I believe step 4 would be the most logical, but as we have not implemented this before we want to follow the standard that most other developers would use - or maybe there's an even better way.
I am implementing a functionality of removing a user account (the user will have the possibility to delete its account).
I am using Auth0 as authentication provider. If I log in the app using a Gmail account, Auth0 will create the account with user ID value of XXXXX. After I delete the user (through API or from users management section), if I try to access the app again with the same Gmail account then the user ID will still be XXXXX.
This is a problem in my case because I need to anonynimize the data and the other details should never be visible.
I can solve the problem by changing the the ID in my database but for the moment I would like to keep it.
Is this the normal behavior of auth0?
Good morning tzortzik! I work with the Auth0 Community team and after confirming with one of our senior engineer, some connections the user ID is built based on details originating from the external IDP (Google in this case). That being said, if you remove a user in Auth0 for this instance, the very next time the user logs in/signs up they will receive the same ID that originated from the external IDP. I hope this helps clear some things up. Thanks!
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
I'm a person with a non-programming background working on a web application that must store user-generated content and always associate that content with the user who created it. I just had the developer tell me since the application must do this, using Facebook as an alternate login method is pointless because Facebook only let's a third-party web application hang on to Facebook profile information for a certain amount of time, and therefore users who login via Facebook cannot actually contribute content that would remain in the web application's databases.
I'm having trouble swallowing this. I just signed up and logged in to stackoverflow using my Facebook account, and it appears to have generated a site-specific user ID that was automatically associated with my Facebook account - thereby allowing me to save/store content on the site without having to actually create a site-specific profile.
My questions:
Where is the misunderstanding here? To what extent do alternative login options affect the ability of my application, which will consist largely of user-generated content, to store user-generated data and consistently associate it with that user? Appreciate the help!
Alternative login allows users to use an existing account to sign in to multiple websites, without needing to create new passwords. Alternate login using facebook, OpenID, gmail or any other provider doesn't affect the ability of your application to store user generated content.
When a user logs in using a login option for e.g. facebook, user enters the facebook login credential(if he isn't already logged in), facebook generates a authenticated token which is utilised by your application for future use.
In case of alternative logins only the login information (User ID/Password) isn't stored in your application, it totally depends on how you are implementing it in your application. But in any case it doesn't affect your application in saving storing and using the user generated content in your website.
Please refer to this link for more info -
http://openid.net/get-an-openid/what-is-openid/
http://oauth.net/
Hope this helps!