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
Related
I have a vuejs SPA. Users have their own accounts with a dashboard. On the dashboard, is a section for PDF signing. All users should have the same PDF displayed, but with their name pre-filled on the PDF, and then 4 spots to sign.
Right now I am stuck on the first part for using the API....which is the auth code.
Why does it seem that the tutorial I followed, requires the owner of the DocuSign account to login and grant rights? I had to do something similar to https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=5665656-3506-46fa-b46d-f6acf3b59268&redirect_uri=https://www.google.com and I got a code in return....but how am I even suppose to implement this for my web app?
How do I get the auth code in the background....meaning...I cant have all users go to this URL...am I supposed to do it via ajax GET? I was able to use a correctly formatted URL, but I got the response by visiting the URL in my browser...how can I do this programmatically?
I dont get the granting rights part....because there is no way this would be practical where all the users would have to know my private DocuSign account info?
Of the (3) oauth methods, which is best for my scenario? Authorization Code Grant, Implicit Grant, or JWT Grant
Auth Code Grant was meant for interactive scenarios. It requires UI and a web interface. It cannot be used without UI. Once you have the initial access token, there's a refresh token to be able to obtain a new one without UI, but the initial call requires UI.
The users don't have to know your account info, your account info may not be relevant. The user grant a right to your app/integration to make API calls. That is not your account, it is different. It's a clientId/integration key that you use your account to create, but it can be used with any DocuSign user/account.
JWT would allow for what you asked in #1 but only after a one-time consent was provided (What you asked in #2) by the end-user. You have to do that for users to enable DocuSign to make API calls on their behalf.
Final word, signers do not need an account in DocuSign. I don't know what you're building, but if your end-user just signs - they don't need an account and a lot of 1-3 is moot.
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.)
Here's my question. To access our app, the users must be invited.
This means, we use an admin web app to create the user account in Firebase and we send him an invite to download the app and use it.
Now the next phase, how can we send to the newly created user his credentials?
Our first idea was to use a temporary password. We could send the password by email to the user and ask him to redefine his password at his first logging.
His this a good idea? I guess it's not
Is there a better way?
Thanks for the help.
T
There is no way to prevent users from authenticating with Firebase Authentication. So instead of depending on pre-creating of the accounts, you should ensure that only authorized users have access to the data.
For example, when using the Firebase Database, you could keep a list of authorized users in the database:
/authorizedEmails
t4ncr3d3#hisdomain,com: true
puf#hisdomain,com: true
And then you'd check the auth.email variable against this list in the database's security rules.
Instead of pre-creating the account, you could then simply email the user an invite to the app. E.g. an email with a link like http://myapp.mydomain.com/signup.html?email=t4ncr3d3#hisdomain.com
Then when they click the link, pre-populate the sign-up form with the email address you sent the message to and call createUserWithEmailAndPassword().
You could use the new (as of Nov 2016) firebase-admin library (java or node) to programmatically create users from your server side - see this link for details.
After that, you could send the email and password to the user via email, and allow only email based password logins. Unfortunately, you can't force uninvited people to stop authenticating with your app, as they could manually invoke the APIs used to create a new account on their own, as you see on the same page. However, you are under no obligation to provide a login mechanism via your UI. They would have to use their browser to type and invoke the JS needed to create the account.
If you are OK with people forcibly creating accounts, but you would like to lock down their access, you could do something similar to what Frank mentions in another answer by using admin control of the database to restrict access to those users you have created and invited with a special flag in the database (that only you can modify using the admin SDK) that acts as a gateway into your app. If you perform the security properly, that should prevent those whom you didn't invite from using the app, even if they can effectively authenticate with it.
I am new to the DocuSign integration. It seems I need to use the OAuth Authorization Code Grant so I am doing a GET with something like this:
https://account-d.docusign.com/oauth/auth?response_type=code,&scope=signature,&client_id=my_integrator_key,&state=some_string,&redirect_uri=my_callback_URL
I have set the Redirect_URI on the Integrator Key to be the same value as my_callback_URL above, and I have set a Secret Key (though I do not know what that is for).
When the logon page displays it shows this error in red above the email address box:
The client id provided is not registered with DocuSign.
I have spent quite some time trying to figure out why this is but no luck. I figure this is a common mistake but I do not see it.
Your redirect url is not right--do not include commas.
Your example should be:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=my_integrator_key&state=some_string&redirect_uri=my_callback_URL
Once your redirect_uri is called with the authorization code, you'll use your secret when requesting a bearer token for use with your API calls.
See the docs.
Assuming your my_callback_URL query parameter corresponds to a valid redirect URI you configured, and seeing that you are hitting the demo OAuth endpoint, are you possibly trying to use the production system?
To login to DocuSign's demo (sandbox) environment you go through:
https://account-d.docusign.com/#/web/login
To login to your live production account go through:
https://account.docusign.com/#/web/login
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.