How is Quora able to show me an invite page with all my Gmail contacts without even me logging into Gmail? Is there a way to pull email addresses without a password? Or is it that they are storing my address book, when I initially logged in?
IMHO, you don't have to be logged in into Gmail for OAuth to work (which Quora is most probably using).
You need to be logged in at the moment of authorizing Quora via Oauth, afterwards you don't need to be logged in, since Quora keeps Oauth authorization internally, tied with your account. So until your OAuth gets invalidated, Quora most probably has access to Gmail contacts and entire Google shebang.
You are likely already logged into Gmail, and when you click "Find Contacts", what Quora does is communicate with Gmail via OAuth. Google then asks you if you are sure you want to grant Quora access to your account data, which they will then send to Quora if you click allow.
If you weren't already logged into Gmail (or had a cookie saved) then Google would have to ask you to authenticate yourself first.
Related
I'm using the identity API in my Chrome extension to authenticate users and prove to my backend who they are. This works fine for the most part, I use getAuthToken to get an OAuth access token that I send over to the server, which it uses to confirm the user's identity.
The only problem is this: the first time getAuthToken is called, the user is asked to choose a Google account from the list of accounts they're currently logged into. Any calls to getAuthToken after that though just keep reusing that same Google account without prompting the user. I'd like to give users the ability to choose a different Google account later. Seems like clearAllCachedAuthTokens would be exactly what I need - and it works - but only when the chosen Google account isn't the account that's logged into Chrome. In that situation, clearAllCachedAuthTokens doesn't do anything.
The only way I've found to reset the locked in Google account of getAuthToken that works even when the user chose the Google account that's logged into Chrome is to get the user to log out of Chrome, which is annoying and awkward. Is there a better way?
When performing authorization code grant authentication, Docusign asks for consent. Far as I understand documentation, it's user's consent implied. When first asked for consent, the user is required to enter his credentials. When asked next time, the same user is implied.
However consider this: I have 3 users listed in my demo account wowproj.dev#gmail.com: the wowproj.dev#gmail.com himself, and Mary#inbox.ru, and Mike#inbox.ru.
I need to know two things:
1) whether I can statically specify the user when doing code authorization (say, by his "api username"), so that the user only has to press some "OK" button (maybe enter his password as well, but not username) - is that possible? Otherwise it may be possible that I have users "Mike" and "Mary" in my app, and I have those users in my Docusign account as well; then "Mike" user of my application starts some action, but when asked for consent, "Mary" enters her Docusign credentials and gives her consent. I want the consent to be Mike's! For example, I could store Mike's api username in his account in my app, and use it in grant authorization. But, far as I can see, neither user's login nor his api username are sent to Docusign in authorization code request, so I don't see how to achieve what I want.
2) When asked next time, the same user is implied - that may be a problem. What if my "Mike" from former paragraph, when asked by Docusign, enters his credentials and gives his consent, then he logs out from MY application and Mary logs in instead and starts some action involving Docusign; will Docusign assume it's still Mike's session? How do I make sure this does not happen?
I don't understand your question's use of "implied." Here's how it works. If you have further questions, please update (edit) your original question.
When using authorization code grant, the user first authenticates himself to DocuSign.
Then, if he hasn't previously done so, he is asked to grant consent to the integration. The permissions requested by the integration are the integration's scopes. The usual scope is signature, there can be others.
After he grants consent, the DocuSign authorization service will redirect the user's browser back to the integration, and and an authorization code will be included as a query parameter.
Your integration then makes an oauth call to DocuSign to exchange the authorization code for an access token.
Next (typically), your integration uses the OAuth::getUserInfo method to obtain the user's name, email, authorized DocuSign accounts, and more from DocuSign.
Ensuring that your app's user is the DocuSign user
You can't force who will be authenticating with DocuSign. But you can check that the right person authenticated. For example:
Mike logs into your app. You know Mike's email.
Your app wants its user to authenticate with DocuSign. Your app initiates the OAuth Authorization Code Grant flow with DocuSign.
Your app's user now sees the DocuSign login screen.
(The problem) is that Mike asks Mary to authenticate with DocuSign for him. Mary does so.
But when your app learns the email address of the DocuSign authenticated user, it will be Mary's email address, not Mike's. So your app can reject the DocuSign authentication by posting a message to the user saying that Mike must re-authenticate with DocuSign.
By implementing the above, your app can guarantee that when Mike is logged into your app, the matching authentication with DocuSign will be Mike's DocuSign user account, never someone else's.
Instead of comparing email addresses, you can also use the DocuSign user id. But doing so requires that you go through a step of loading your app with a table that associates Mike's account and his DocuSign User ID. Email addresses are probably easier.
Re: other people logging in after a prior session
There are two cases:
Same browser on the same machine
This is the "public computer problem."
Mike uses browser "G" to login into your app and also into DocuSign. Later Mary slides into his seat and uses the same browser and same application.
By default, DocuSign's OAuth Auth Code Grant enables Silent Authentication. This means that the DocuSign auth flow will silently enable Mary to use Mike's DocuSign session (if it is still active). For a public machine scenario, this is obviously not good. Solutions:
Always require DocuSign to actively authenticate the person (no Silent Authentication allowed). To do so, include prompt=login in the initial URL sent to DocuSign. See docs.
Clear the browser's cookies between users. The standard methods for handling public computers will include this.
Different users on the same app
Your app should use sessions. Each user of the app (in parallel or sequentially) will get their own session. Each session should maintain its own authentication information for DocuSign including the current user's access token, account id, and base url.
All of that information is determined as part of the authentication-with-DocuSign process.
These days, all modern web app frameworks provide easy to use session interfaces.
We also have code examples you can use. See this repository list. (With more on the way.)
I am trying to implement Google's
One tap sign-up and automatic sign-in.
I can successfully prompt the user for sign-on, get an ID token from Google, and validate it on the server. Where I am lost is what do I do with the ID token once I have it? Google's documentation is vague.
I get the impression that I send something back to the browser to store in Session Storage, but what do I send and how I use it to verify that the user is authenticated on future requests.
If you're all the way up to "Create an account or session" in that Guide, you're pretty much done with the problem of integrating with Google Identity.
There is nothing to return to the browser from Google's perspective. The client-side API has retrieved the token, you've sent it to your server, your server has used it to successfully verify and extract the user's Google account information, authentication is complete.
What happens next is your decision. It depends what your website does with the user's details (e.g. create a user in your database, do stuff to remember them for the rest of their visit).
Google Identity is not authorisation, only authentication. It provides identity ("who is this user?"), not permissions ("what is the user allowed to do?", "How long should I trust this session for?"). User permissions is a separate problem.
To remember a user for future requests, you would typically create a unique, one-time unpredictable session token on the server, and store that in a HTTP-only, secure session cookie. As already explained, this is unrelated to Google Identity.
Scenario: I have been developing a web application for management of small and medium-sized enterprises. Some time ago we used login and password authentication that were stored in our database. Nowadays when "everyone uses facebook" we moved to Facebook/Google OAuth2 authentication as well.
The problem is, there are some key operations that have to be especially secured (e.g. changing addresses, accessing clients' details). The best way to do this is I guess to ask users for retyping them credentials just before these risky operations are executed. But, since I use social authentication I can not confirm credentials anymore :(
Is there any way that I can force Facebook or other OAuth2 provider to re-ask users for credentials even they are already logged in?
I think this may be useful for someone.
I have found such a credentials confirmation implemented on https://www.airbnb.com but only for facebook.
AirBNB uses
https://www.facebook.com/login/reauth.php as an authentication url
Facebook re-authentication mechanism is described widely here:
https://developers.facebook.com/docs/facebook-login/reauthentication
For Google it is possible to force re-authentication by setting max_auth_age parameter to 0
No prompt for re-authentication with OAUth2. Why and how to force it?
I use the https://www.googleapis.com/auth/userinfo.email scope to get an email address of the authenticated user. But while authenticating, Google prompts the user:
The app would like to:
Know who you are on Google+ (for which the help icon says: This app is requesting permission to associate you with your public Google profile)
View your email address
I don't want the user's Google+ related information. I am using the OAuth2 authentication method. For Authsub request authentication it requires only email address access. How can I get access to the user's email address alone?
If you are using Google+ Sign-In, the https://www.googleapis.com/auth/plus.login scope is automatically included, which would be why you were seeing that portion of the permission dialog.
If you do not need the enhanced features that come along with the Google+ Sign-In feature, then you'd probably want to do a standard OAuth flow. See the Google OAuth scenarios for a solution that might fit your needs where you can ask for only the email scope.
If anyone is still searching for this, I think this might help. In the gapi.auth2.init method in the Google Sign In JS client reference, set fetch_basic_profile to false (it's true by default). Now using the scope param for the same method specify "email", "profile" permissions