So if I have an app with many users on board, all from different companies/places, I'm thinking that an individual 'connect to docusign' with OAuth is the right flow.
I think I could have an admin connect their account and impersonate the entire company, but it doesn't sound great from a security perspective.
I also see some places asking people for their docusign admin username/password which I assume is highly discouraged.
Question: I am planning on using just one 'integration' for my app to manage all this, should I be aiming to use one integration per docusign account I interact with? i.e. Should I ask the companies to each make an integration and give me the id/secret?
Several questions here:
OAuth flow
Yes, if your DocuSign users will have their own DocuSign user IDs then you can add a "Connect to DocuSign" button and use the OAuth Authorization Code grant flow. Include the extended scope so you can use the refresh token on an ongoing basis. Remember to use secure non-volatile storage for the refresh tokens since they can be used to obtain access tokens.
See Authentication for ISVs
I think I could have an admin connect their account and impersonate the entire company, but it doesn't sound great from a security perspective.
Correct. It is best to use JWT grant (impersonation) only if the end users can't use the Authorization Code grant flow. For example, if your app is a back-end app or doesn't have a web interface.
JWT (impersonation) flow is fine when needed, but it incurs significant customer confusion and work to provide consent. So Authorization Code grant is preferred if it fits your needs as an ISV.
One DocuSign client_id (integration key) or one per end-customer?
Best is to use one DocuSign client_id (integration key) for your application, not one per customer. See ISV docs
Should I ask customers to give me an integration key and secret that they created?
Please no. Your customers are not developers. Asking them to become DocuSign developers and create a client id (integration key) is a lot of work for them. There's no need to go down this path. Just use the same OAuth Authorization Code grant redirect_uri for all of your customers. Remember that you can use the state parameter as needed to handle the OAuth redirect from DocuSign.
Use your free partner account to manage your application's client id and its settings.
asking for a DocuSign administrator name/pw from your customers
Correct: don't do that!
you want your customers to set up their DocuSign accounts in a specific way
Your app can do that for them by having including a "Setup DocuSign account" button. That button (when used by an authenticated DocuSign admin) would update the account settings as your app needs. For example, setting up a Connect
users have multiple accounts
Extra: remember that it is common for DocuSign customers to have access to multiple DocuSign accounts. Eg, a general account, an account for HR, etc. They may or may not set up a special account for your application, depending on the use case.
After a user authenticates, your app can either use the user's default account, or if your application uses a dedicated account, check that the user has a access to it.
Related
I have a DocuSign app that uses 'Auth Code Grant' for individual users to create and send envelopes, and uses 'JWT Grant' for polling and downloading signed documents (i.e., automated operations as described by the documention).
All the examples and documentation I've encounter seem focused on using an admin/system account for JWT Grant, and specifically for impersonating users. I don't need user impersonation functionality in general.
I am currently using a regular (non-admin) user that is assigned a custom permission profile. The profile is simple with only the 'Allow view and manage envelope rights through API' checked. This works in the dev sandbox. I have no problems polling or pulling documents with this user and JWT Grant.
Is it acceptable to use a non-admin user for JWT Grant as in this instance?
Can anyone possibly point me documentation surrounding using JWT Grant for automated processes that do not require heavy integration or admin-level access?
Yes, it is acceptable, I'm not aware of any reason it won't be.
This JWT Best Practices Guide on the DocuSign Developer center. Not sure what else you may need, but feel free to ask specific questions.
Yes, you can use the JWT Grant flow to impersonate account users who are not administrators. This is a common use case for JWT Grant.
I am running a POC for a Service-based DocuSign integration with JWT Authentication. We would like to leverage embedded sending, enabling multiple customers to send documents for signatures. I am trying to understand how we will manage users and consent in this scenario.
To grant consent for multiple clients, do we need to have a user created in or organization for each of our customers? Do these users need to be admins? Are we able to grant consent to a DocuSign user outside our organization?
Thank you
So, JWT requires consent of the user, but only once. This process is the same as Auth Code Grant, requires the user has a membership in a DocuSign account, log in (not in an iframe) by either entering their password or using IDP for SSO and then they are asked to allow the integration to access specific resources (eSignature in your case) as well as allow it to impersonate them. That is critical for JWT.
If you want to make it a bit easier, you'll have to become an ISV. As an ISV there are ways to consent to an app for an organization and you can also have some level of control over your customers' accounts.
Partner Integration Guide for ISVs
We are working on an integration to offer embedded document signing through customer websites we host. We want this to be a comprehensive solution, so envelopes should count against our quota, but will need to be under the user account provisioned through Docusign. We are using the JWT authentication method to impersonate the provisioned accounts and want to make sure we understand any requirements to gain consent.
When we request and provision accounts for our customers, is our integration key automatically granted consent on that account? Will we need to set up a service user account that can be impersonated on each customer account and grant consent individually? Thank you for any help you are able to provide.
If you (as an ISV) intend to purchase and provide the envelopes on behalf of your clients, you will need to be under an ISV License agreement with DocuSign. Architecturally, you would not be adding your clients are users in the accounts owned and managed by you. You would instead use a "system user" to represent each client organization. This works especially well for embedded signing integrations. As for consent, it would be a one-time consent that your configuration team would accomplish when onboarding the new client.
At this time we don't have these capabilities for ISVs.
Consent has to be given in the organization/account level (admin consent).
Which means if your customers are not in your organization, each of them would have to consent once.
Using administrator consent, your customers would only have to go through this process 1 time for your application.
Please free to send a feature request to partners#docusign.com or contact your partner account manager (make sure you're a DocuSign Partner).
My company (C1) has DocuSign implementation feature set up with RestApi and we use oAuth to authenticate users with email and password to create and send envelopes. This functionality works perfect.
One of our clients said they have SSO enabled in their org and would like to SSO directly to DocuSign from my company page instead of providing password option. In our current implementation, users are prompted for email address first and then the password.
If clients have SSO enabled, I assume they go directly to Docusign but to get that functionality, is there anything I need to do regarding changing the existing workflow or implementation for RestAPI.
Do we need to obtain consent for our Client (who has SSO enabled)?
Thanks in advance
You don't need to do anything differently. These clients would be able to authenticate to your integration/app using SSO. If they are already autneticated, a cookie remembers it and they would automatically be redirected back to your app. The first time, the would have to give consent to your app to enable it to do things for them, but after that - smooth sailing, without any need to login or anything.
Feel free to let me know if you run into any issues. Otherwise, you'r good.
As Inbar says, if your application uses either the OAuth Authorization Code or OAuth Implicit grant flow, then your application will automatically support SSO once the user's DocuSign account has been set for SSO.
If your application uses the OAuth JWT grant, then SSO has no bearing on your application since your application is itself authenticating with DocuSign and impersonating a user.
And the above is why Authorization Code grant or Implicit grant is preferred over JWT grant whenever there's an option to not use JWT grant.
If you're using Legacy Header authentication, your application won't be able to authenticate as users who have SSO Login enforced. Until you're able to implement one of the OAuth workflows, users who need to use your API integration will need to have their Login Policy set to allow them to login with a password. More info on Login Policy is available here: https://support.docusign.com/en/articles/How-to-exclude-specific-users-from-SSO-requirements
I'm new to Azure ADB2C, and am confused by some of the terminology.
I am building a motorcycle ride monitoring website that I would like users to be able to log in to by verifying a social media identity (Google & Microsoft Account, for now).
But I only want users who are members of the site to be able to use certain features. For example, I'd like everyone who authenticates to be able to apply for membership, read about the benefits of membership, etc., but I only want members to be able to initiate ride monitoring.
Is the recommended approach here to only authorize (rather than authenticate, if I'm understanding the terminology correctly) certain authenticated users (i.e., members) to use the ride monitoring services?
If so, what's the best way to authorize a member? Look up their email (which I require to be returned from the authentication process) in a standalone database and proceed accordingly? If I go that way, what's the simplest way of adding their membership status to their credential, so I can access it throughout the site?
Apologies for not providing code here. I've got a bit of it hanging around :) but this is more of a design question than a coding one.
Azure AD B2C is primarily Authentication as a Service. There are ways in which it can be used for what you are trying to achieve here.
You can use custom (extension) attributes in AADB2C (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-custom-attr) in combination with AAD Graph apis (https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet). So when user authenticates and applies for membership, you can call AAD graph api to set the custom attribute on user object. You can get the extension attribute in a the token after the authentication happens. This token will give you membership of the user.
You can also use AAD Groups instead of custom attributes. In the tenant, create membership groups. Once user authenticates, call AADGraph to set/get user's membership of a group and that will give the authorization information.
You can also do what you described, maintaining the info in a database store of your application. But the first two functionalities provide in-built functionalities for user management.