For the Authorization Code Grant, is the Secret Key supposed to be mapped to
each individual user?
When an email is sent out, what would be the sender's email?
thanks,
J
Additional info for Larry:
This is awesome!. Stockflow is really actively monitored by Docusign! I'm using JWT.
I have a user configured.
I assume email body will be similar to following one.
My question is if secret key is used to identify application, the customer knows the email is sent from the application, but how does he know which employee using the application send the email?
Please see following email body: Test --------------> User name
maaaa#example.com ------->User's email (This indicates the user's email address sending document via docusign)
signer name,
Please DocuSign a.pdf
Thank You, Test
For Authorization Code grant, the application identifies itself via its client id (Integration Key) and its Secret.
The secret is associated with the application, not with the user.
When you say "email ... sent out" what email are you referring to?
Related
Echosign allows us to send a document to Echosign to sign and then Echosign sends us a URL that we can then embed in our own email and send it to the signer. DocuSign's remote signing has Docusign sending the email to the signer instead. Is there a way to do what we did in Echosign in Docusign?
Thanks for this question Faulkner. I think you are confused about terminology.
Remote Signing
This means that an email is sent to the recipient with a URL that would enable them to sign on any device anywhere.
Embedded Signing
This means that the signing will take place inside an app. No email is sent. The app developers embed the URL for signing as part of the flow of their application.
For more information on Embedded Signing:
https://developers.docusign.com/esign-rest-api/guides/features/embedding
Re: Is there a way to do what we did in Echosign in DocuSign?
Yes, there are two solutions:
Easier: Change the branding of the email sent to the signer. See docs. You can update the colors, add your logo etc.
More work: Create your own "start-to-sign" url and include it in emails that you then send out. Here's the high-level flow:
Assuming that you want to send an envelope to Pat Smith to be signed. And you want to send the email link:
Create a record in your app's database of the signer's name, email, and other app-related information. Record the keyId of the record you've created. Note that there should be one record per recipient, not one record per envelope.
Create the DocuSign envelope with Pat Smith (and her email) as a signer recipient. Include recipient attribute clientId set to the keyId of the database record. Doing so will suppress the invite email and set the recipient as an embedded recipient. Save the resulting envelopeId
Update the keyId record in your app's database with the envelopeId from DocuSign.
Update the keyId record in your app with a new attribute of urlId. In this column generate a UUID. Do not use a sequence/key/etc. It is important that the urlId be unguessable.
Create a URL endpoint in your app. Something like https://apps.mycompany.com/thisapp/signFromEmail/[urlId]
Then, include that url (with the urlId for Pat Smith substituted for urlId) in your email to Pat. That will be the start-to-sign url for Pat for that envelope.
When Pat clicks on the url, your app should:
Look up the recipient record in your app database where urlId = the provided urlId
Use that record's data to create an EnvelopeViews::createRecipient call to DocuSign. The result is a url link that must be used within a couple of minutes.
Redirect the browser to the url link -- Pat will then see the DocuSign signing ceremony.
I'm creating a site with user auth, and I plan to limit access using either invites or some other method.
The site is built on Node, Express, and MongoDB. I plan to use Passport JS, mainly because it's the only method I've learned (this is my first personal project).
The only idea I have is a "secret code" on the registration page. Thus only those I've told the code can register. I have a feeling there are more elegant or secure ways to handle this, and would love any recommendations!
I think your idea is correct in principle - it's the same method used for registration/beta keys for games. You generate a unique 'key' for each user you invite to register. They register with that key and it is marked 'used' in your database; this prevents other users from discovering that key and re-using it.
You could also use email addresses in essentially the same way. The email address that is used to register must be on your 'invite list'. And when you 'confirm' an address by sending a 'click this link to confirm' email you will have to generate another key for authenticity.
Therefore, upon registration with an invited email, you could generate a key as follows:
require('crypto').randomBytes(48, function(err, buffer) {
var key = buffer.toString('base64');
// then save the key with the new user in the database
});
Then send an email with a confirm link containing the key, for example:
https://www.mywebsite.com/users/confirm_email/{key}
This link would call a 'confirm_email' action on your server, look up the specified key, and enable the account it is associated with.
You might want to add an expiry along with each key creation for a bit added security. Maybe only 24 hours to confirm the email.
You don't need any secret codes if it's with invitations :
When someone invites someone else, you store the email invited somewhere. You simply need to check that a new user is "on your guest list" when he tries to register.
Of course, to be "secure" this approach assumes you actually checks that an email address properly belongs to the user that registers, for instance with a verification email, as done usually. The point is that you don't need an additional token.
One solution I can think of just generates the token using the senders token (use jsonwebtoken signed with expiry time and sender's token). Now when the user who is invited will receive the link, let say: http://localhost:5000/invite/${token} and the link is clicked then a GET request will be sent to the server so catch that request and then in that request in the backend decode that token and check your user database if that user exists i.e sender and token is not expired then it's valid invitation so now directly redirect the invitation receiver to the register page else send the message that invitation is not valid.
Hope this help.
Let me know your views.
I just setup the basic JHipster application and set in the FB client ID and secret. However, when I try to login by not sharing the email - I see that it gets redirected to my app with a success. I can handle the no email exception on application.
Instead , I wanted FB to make sure that my email was a mandatory field. How do I do that?
You can't force Facebook to return an email address for a user. It may also be null on their end (if the user signed up with a phone number). You will have to handle it in your application. This is the same case with Twitter - they simply don't provide the user's email.
Note, even if you request the email permission it is not guaranteed you will get an email address. For example, if someone signed up for Facebook with a phone number instead of an email address, the email field may be empty.
https://developers.facebook.com/docs/facebook-login/permissions/
Like you mentioned, you need to handle it in your application. You could catch the fact the email is null and prompt the user to enter an email.
I have a web app which I use to collect some information from a user (not name or email) and then plan on having them electronically sign a document via DocuSign immediately online (not via email).
In order to get a signing url (aka recipient view), it appears I have to provide a definition of a recipient. Part of the definition of a "recipient" is a username and email address. Is this true?
Does the DocuSign API/SDK require me to provide an end-user's (aka signer) name and email address? It seems like the API/SDK will always return a validation error if I don't provide these things. What if I don't have that information?
You need to provide the signer's name and their client_user_id within your app. You also need to supply an email for them.
The client_user_id must be unique per signer.
If you have the signer's email, use it.
If you don't, use a unique email address that includes the client_user_id to guarantee uniqueness. Eg noreply_{client_user_id} #your_company.com
Added
Re comments:
Yes, an email address is required by DocuSign to generate an embedded signing ceremony. But it is okay to fake one (that includes your app's client_user_id for the signer) if you don't, in fact, have the signer's email.
Re: Why is this the case? Because the email and name are used by DocuSign to index the "captive signer" (someone who signs your account's envelopes but doesn't have their own account with DocuSign). That's why a fake email must be unique to this person.
This technique of using name + email to identify people enables DocuSign to, for example, not require the signer to agree to the consumer agreement to use eSignatures on second and subsequent document signings with your account. -- This provides a better UX.
Since it is very common for web apps to know their user's email, this is usually not a problem. But if you don't know the signer's email, then everything works fine with a fake email as described above.
Added more
Re:
please provide a source for DocuSign being Okay with fake email address in this case? I mean is it legal?
Currently this technique for providing a fake email address for embedded signing (when a real email address is not available), is not documented on the DocuSign web site. I will add it to the embedded signing recipe when I revise it in 2017.
Re legality: the important issue is how your app authenticates the signer. Email is one way. Depending on the use case, email authentication may or may not provide a strong enough assurance to the relying party (the person who receives the signed document).
But we digress. Even if you do have a person's email address, it is common to authenticate the person beyond using their email. DocuSign has many different types of additional authentication built-in and easy to use including 2FA via SMS, pre-shared secret, in-person signing (which can include in-person verification of government ID), e-notary, digital certificates, telephone authentication, knowledge based authentication, and more. Most of these can be included with embedded signing if you wish.
Or your app (which is using embedded signing) can itself authenticate the person. When someone signed up for your app, did they have to first prove their identity? That was the authentication step. If no one else can log in as them, then they're still authenticated when you give them the embedded signing ceremony from DocuSign.
If I set the recipients to get Access Code through email, then do I need to program separately to send the email with access code or Docusign API will automatically send the access code email to all recipients?
Also do I need to enable any setting from my DocuSign account to turn on this feature? I have a developer Docusign Account.
When using the Access Code authentication feature, it's up to the sender how to actually get the code over to the signer. For example, if you have their phone number you can call them and give it to them. Or you can instant message them or send an SMS, or some other means. In general though I would shy away from sending them the code through email as that pretty much defeats the purpose of multi-factor authentication (i.e. if someone has compromised their email they will get both the signature request email AND the access code email).
Similarly, the SMS Authentication feature is used the same way but in this case the code is explicitly sent to their mobile phone number. With Access Code it's up to you how to provide to the recipient.