I have a Google Marketplace app that is currently using OpenID for federated login.
When an admin installs the application to the domain users are able to login via a site.com/login/domain.com link.
Currently when a user uses this link they are being asked to consent once again for "Know who you are on Google" scope. I understand that this is something to do with my OpenID realm not matching. The problem is I cannot find where to edit that realm in the new console. My research shows that OpenID has been abandoned for OAuth2 authentication. Please correct me if I am wrong.
Is there a good example anywhere that shows how to authenticate a user that an admin has already granted scopes for on the domain so that they do not get asked to consent again? I've looked up and seen documentation to make a call to https://accounts.google.com/o/oauth2/auth but I'm unaware of how to actually skip the user consent since the admin already authorized the scopes domain-wide.
Using C# but I'm open to any example as I'm sure I can figure out how to get it back into C#.
If you read this post on the google groups, then it seems it is intentionally :
This is an intentional change to more precisely communicate to users
the set of permissions that is being granted. Through knowledge of the
user's email address it is possible, via indirect means, to locate the
user's profile address. In the interest of more accurate disclosure,
thus, we are prompting users to approve such disclosure.
The new tokens issued include permissions to obtain public profile
information, in accordance with the modified text. You can use
https://developers.google.com/accounts/docs/OAuth2Login#userinfocall
to obtain the subset of user's profile information that is publicly
linked from the user's profile. The user's profile Id, which is always
public in that endpoint, is also a more reliable identifier for the
user (as email addresses can be changed on accounts). We recommend
that you store the user's profile id to ensure that email changes
don't cause account confusion.
Related
TLDR: I've been struggling with the new Sign in with Google functionality and especially the part how I can let the user stay signed in. What I understand from the docs is that Google only tells "this is a user who would like to sign in" but basically I would still need to create my own backend to track that user.
Note this question is about the new Sign in with Google functionality, all the guides/questions I can seem to find are about legacy sign-in and this is quite well described here:
https://developers.google.com/identity/sign-in/web/server-side-flow
What confuses me most is basically already stated in the beginning of the guide:
https://developers.google.com/identity/gsi/web/guides/overview?hl=en#user_sign-in_to_your_site
You'll manage per user session state for sign-in to your site.
User sign-in status to their Google Account and your app are independent of each other, except during the sign-in moment itself when you know that the user has successfully authenticated and is signed into their Google Account. Users may remain signed-in, sign-out, or switch to a different Google Account while maintaining an active, signed-in session on your website.
I understand the basic principle behind OAuth and the part where you have to exchange the authorization code for an access token and you can verify this access token (which is perfectly described in the legacy guide), but this is now only required for OAuth2 in order to access personal data. If I understand correctly this access token can be used as an identifier for a specific session (as alternative to a password or session cookie).
With the new sign in policy you will only get a JWT which identifies the user. Also apparently the only way to get a JWT is as a response when the user clicks the Sign in with Google button and selects the account in the consent screen (which ideally should only occur once).
What I actually want to achieve is that when a user enters the site I want to send a request "Hey Google this user is visiting my site, do you recognize this session and is it still valid".
Maybe I'm thinking way too difficult, but what I just don't understand is how can the new Google Login actually help me remember and validate users?
After some more digging around I found a lead on this page: https://developers.google.com/identity/gsi/web/guides/migration#object_migration_reference_for_user_sign-in
Basically what I am looking for was provided by the depreciated GoogleAuth.isSignedIn.get() function, but the notes clearly show:
Remove. A user's current sign-in status on Google is unavailable. Users must be signed-in to Google for consent and sign-in moments.
Combined with the prior statement:
You'll manage per user session state for sign-in to your site.
To validate the assumption I did some testing with other web services where I logged in using Google, revoked the log-in access for that website from the Google console and when revisiting that website I was still logged in to the website.
My conclusion:
Google login only verifies the initial login
Google basically responds with "Yes this is a valid user"
I have to keep track of the user session using cookies/databases myself
I'm building an app that shows users people they might be interested in talking to. If a user says he's interested in a person I show them, I want my app to create this person as a contact in my user's SalesforceIQ.
How do I do this? I see from the API documentation https://api.salesforceiq.com/#/ruby#documentation_contacts_create-a-contact that I can create a contact if I know my user's username and password, but of course I don't want my users to give me this information. Is there some way for the user to OAuth or whatnot by clicking a button that authorizes me to add things to their SalesforceIQ?
The SalesforceIQ API uses HTTP Basic authentication and does not currently support OAuth according to their documentation.
For a SalesforceIQ user to grant API access to your app to create contacts and for other privileges, the SalesforceIQ admin creates an API Key and API Secret for your app which is then used for the HTTP Basic authentication username and password. This way no user needs to provide your app with their credentials. This is configured in the SalesforceIQ admin UI under Settings > Integrations > Create New Custom Integration.
For the admin to provide these credentials to your app, you can have a UI where the SalesforceIQ admin enters this for your app to store and use with the API for their account.
This is described in the following places, briefly in the API Reference and in detail in a Help Desk article with screenshots of what the SalesforceIQ admin needs to do:
API Reference: Requesting Access
API Reference: Security and Authentication
Help Article: Set up API access
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.
I'm building an app with Google Sign Up button. Google suggested for me to use Google+ instead, which I did.
I'm asking for users profiles and email address in two different scopes (https://www.googleapis.com/auth/userinfo.email and https://www.googleapis.com/auth/userinfo.profile). However, I noticed that the scope https://www.googleapis.com/auth/plus.login is added automatically in the token request response.
Is there a way to remove it? I'd like only to ask users for the two I've mentioned in order not to have additional permission requests in the dialog box, and this one also causes a confirmation popup for access to users' circles (which I don't need). I've Googled about it a lot, but couldn't find anything related to this problem.
Previously you could not remove the plus.login scope from the Google+ Sign-In button, as profile information for users who had not upgraded to Google+ was not available from the Google+ APIs. Now you can choose whether you want to require a Google+ upgraded user and get access to the users' circles and the ability to write app activites, or just request basic profile information.
For full Google+ Sign-In include email and https://www.googleapis.com/auth/plus.login scopes.
For basic profile information include email and profile scopes. Note that these are just the bare strings profile and email - they are not in URL form.
The user's email address and profile information will be available from the Google+ profile endpoint. You can always allow users to upgrade to https://www.googleapis.com/auth/plus.login later using incremental auth so they can take advantage of access to circles users and writing app activities.
To use the Google+ Sign-In button you must request https://www.googleapis.com/auth/plus.login
plus.login includes a basic set of permissions that a generally useful including a request to read a users circles. Users can easily choose not to grant access to their circles for your app by simply selecting the 'Only you' option that is presented prominently on the consent dialog. However, it is not possible to reduce that set of permissions included in plus.login.
Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process.
Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.
Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.
My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??
What are the best practices in such a scenario?
Thanks for any info you can provide.
Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.
You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.