Using https://github.com/docusign/eg-01-php-jwt
I haven't successfully implemented the above repository for JWT authentication, I have the return:
C O N S E N T R E Q U I R E D
Ask the user who will be impersonated to run the following url:
https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature%20impersonation&client_id=xxxxx-xxxxxx-xxxxx&redirect_uri=https://www.docusign.com
It will ask the user to login and to approve access by your application.
Alternatively, an Administrator can use Organization Administration to
pre-approve one or more users.
When accessing the informed URL I cannot login, it says that the credentials are invalid.
Yes I have a demo account, I am accessing it with login and password in another tab, this is all right.
But in my integration it generates the message and I can't proceed, I'm trying to generate the token for access. The integration is all completed, I developed it with the token generator available (developers.docusign.com/oauth-token-generator), it is just missing that part of JWT authentication that is causing me problems
Thanks
If you're not able to log in to the Demo environment, you'll likely need to do a Password Reset using the Forgot Password link on the login page. Do keep in mind that while you can sign up for a Demo account using the same email address as a Prod account, those two accounts will have separate passwords, so be careful to track of which environment you're taking action in.
If you don't have a Demo/Sandbox account at all, they're freely available from the DocuSign Developer Center: https://developers.docusign.com/ > Click 'Create Sandbox'
I suggest trying the URL provided by the example in an incognito browser window. Normally there is no problem using a regular browser window for this one-time step.
The consent url simply enables you to login via the in-person OAuth Authorization Code flow. You authenticate and then grant consent.
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.
I searched through previous questions but I haven't found a clear answer. My work flow is as follows:
I have a front end web app that talks to a node back end.
The node backend create a PDF and we would like for the user to sign it.
We use Authorization Code Grant
The user is redirected to the Obtain Consent screen
Once consent is granted they are redirected back to our app with a code that is swapped for an access token
We then use that access token to create our envelope and redirect our user to docusign for signing.
I would like to REMOVE the NEED for the user to provide consent. I have seen other companies leverage docusign without needing it.
My questions are:
- Is Authorization Code Grant the right authentication approach or should I be using JWT Grant?
- How can I get an access token for the user without obtaining consent? This seems like a necessary step?
- If I switch to the "Organizational Admin" approach, does my work flow change where I no longer re-direct the user to obtain consent? IF this is the case, how do I get an access token?
The users who are signing the document are not part of our company and do not share the same 'company email domain'.
I'd really welcome all feedback on this. Thank you.
If you just need users to sign, they do not need to log in to DocuSign at all. They don't even need to have a DocuSign account to sign.
Consent is only needed once per user/app. It cannot be avoided, as the user must agree to the app doing things for them.
If you use JWT - there's no need to login except once.
Hope this helps.
I am trying a post-call to generate an access token using the client username and password. I would like to know how we can achieve this through Node Js Code.
Generally speaking, access_token are rattached to the OAuth2 authentication framework, which doesn't require the application owner (you) to have access to one of your user email/password. This is a more secure approach that is broadly adopted.
The way OAuth2 works on the Google Calendar API is a 3-parties (or 3-legged) authorization. Let's take the example of a user that browses your website and want to sign-in using its Google Account. The steps to authenticate him are the following:
The user clicks on "Sign-in with Google"
The application owner (you) performs a request to Google saying that a user wants to connect (that's the OAuth consent screen)
Google replies by giving you a URL (authorizationUrl) where to redirect the user
On that URL, the user is prompted with several information about your application and can grant access.
When the user has granted access, Google will redirect the user to your application success page (callbackUrl) with a unique code.
Using that code, the application can retrieve an access_token, which temporarly lets your application performs requests on behalf of a user.
These steps are a rapid overview of the OAuth-flow, also known as the OAuth dance. To make POST requests to the Google Calendar API, you will have to perform that OAuth dance for every single of your users.
Implementing that flow can be tricky. Fortunately, Google gives very helpful documentation on that. If you don't want to bother, you can also use API-tools (like Pizzly) that takes care of that for you.
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.