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
Related
I want to authenticate a valid Azure Directory user from my application. So the output that I want is the user is valid or not?
I use this API https://login.microsoftonline.com/{tenantID}/oauth2/v2.0/token with following urlencoded body like client_id, scope, client_secret, username, password, grant_type the for the authentication but this API is working only when the user disabled their MFA, but I want to authenticate even the user has enabled MFA.
You have hit one of the limitations of the ROPC flow.
It is not possible to authenticate a user with MFA enabled with that flow.
The solution will be to change your application to use an interactive flow like Authorization Code flow.
This will require that your app forwards the user to Azure AD to sign in, and then your application gets access tokens in exchange.
Pros:
You don't need to handle passwords
All the security features of Azure AD can be used, including MFA
Cons:
Complexity will increase (libraries help here)
Docs: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow
If you have a Javascript front-end app, you can use MSAL.js to handle the authentication.
Other OpenID Connect compatible libraries can also be used.
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.
We have a web application where we log users in with Google's auth2.
We also have crone jobs that are used to reply to certain emails through the gmail api.
Is the authorization for signing in and for gmail's api the same? If it is, how can we sign users out of the web app while still authorizing crone jobs?
If what you meant by signing is by using Google+ Sign-in, it says from this documentation:
Why use Google for authentication?
Providing OAuth 2.0 user authentication directly or using Google+
Sign-in reduces your development overhead. It also provides a trusted
and secure login system that's familiar to users, consistent across
devices, and removes the burden of users having to remember another
username and password.
Wherein Gmail uses the OAuth 2.0 protocol for authenticating a Google account and authorizing access to user data. This will be the same.
At a high level, all apps follow the same basic authorization pattern:
During development, register the application in the Google API Console.
When the app launches, request that the user grant access to data in their Google account.
If the user consents, your application requests and receives credentials to access the Gmail API.
Refresh the credentials (if necessary).
The difference is you will need to enable Gmail API for the credentials.
Here's the details for server-side authentication.
Within our application we provide a DocuSign integration which uses DocuSign.eSign.dll from DocuSign C# Client.
We currently use the Legacy Header Authentication to authenticate.
One of our customers, would like to enable single sign on using Azure Active Directory. They have set up their account as described on Tutorial: Azure Active Directory integration with DocuSign already (for the DocuSign App).
How do we change our integration to allow Single Sign On using SAML? What API methods do we use? Does the DocuSign C# Client support this?
Legacy Header does not support SSO Authentication. For legacy header to work, users must have a password.
You will either need to grant a Login Policy Exception (to allow them to bypass SSO) to each user that needs to authenticate via the API, or you will need to implement OAuth token authentication.
An example of OAuth token authentication in C# is available on GitHub: https://github.com/docusign/eg-03-csharp-auth-code-grant-core
Once SSO is implemented by your client and has enabled mandatory SSO in their DocuSign configuration, then you should use OAUTH either using Authorization Code Grant-User Application or JSON Web Token Grant-System Integration to generate AccessToken for your Client API user. JSON Web Token Grant is normally used when System Integration is happening in your Integration with DocuSign. In Either way, you need to ask Client API user to provide User Consent to your IntegratorKey, so that your IntegratorKey can generate AccessToken on Client API User's behalf. Obtaining Consent explains how to get User Consent for Either User Application or System Integration. In Providing the consent to your Integrator, Customers will login to DocuSign via their SSO setup, in the same way how they login to DocuSign to access DocuSign WebApp.
I'm working on integrating Azure AD authentication with various apps on different platforms.
Is there a way to get an authentication token id from a user logging in through a web api like 'azureadlogin.com/login?user=ted&password=passwordhash'
There seems to be ways of doing it through node or javascript or C# apps but I'd really like to just have a simple web request way of doing it as there are many different apps on different platforms that need to make use of this feature.
No.
There is a way to authenticate with username + password by doing a POST request and using Resource Owner Password Credentials flow, but I don't recommend it.
ROPC will not work if:
User's password has expired
User is MS account/federated from on-prem AD
User has multi-factor authentication enabled
You have a wide selection of authentication flows which work in all these scenarios too, and don't involve the user giving their password to you.
For example:
Authorization code flow
Implicit grant flow
Device authentication flow
You can use username/password authentication. But if your app has user interface, so it could popup the regular Azure AD login page, I would recommend not to use it. A major reason for using Azure AD (or other identity providers) is that the user doesn't want your app to know his password.
There's a sample which does what you want. The code in question is here.
The sample uses .NET and the ADAL.net library, but you can do similar stuff on other platforms.