X-DocuSign-Authentication=[<DocuSignCredentials><SendOnBehalfOf>UserId from CheckAccountMemberResult</SendOnBehalfOf><Username>apiusername</Username><Password>passs</Password><IntegratorKey>apikey</IntegratorKey></DocuSignCredentials>]}
I was testing “Send On Behalf Of” feature and received an error in the subject.
Please let me know what I am missing?
Do I have to take the Auth Token route? If that is the case, do I have to use operating user's password as opposed api user's password. I am confused.
Thanks
N
Update: Another surprise. The authentication was working fine for the API credentials (without the SendOnBehalfOf tag). Now it's not. Hope Docusign is not doing any maintenance.
When using Send On Behalf Of with SOAP, the sending user is identified within the Email element of the authentication header. For example, let's say that my API user name is "apiuser#example.com" and my sending user name is "sender#example.com". If using the DSAPI.asmx endpoint, the authentication header would look like this:
X-DocuSign-Authentication: <DocuSignCredentials><Username>[sender#example.com]apiuser#example.com</Username><Password>mypassword</Password><IntegratorKey>EXPL-00000000-0000-0000-0000-000000000000</IntegratorKey></DocuSignCredentials>
When using WS-Security and the API.asmx endpoint, a similar structure is used:
<SOAP-ENV:Header>
<wsse:Security mustUnderstand="true">
<wsse:UsernameToken>
<wsse:Username>[EXPL-00000000-0000-0000-0000-000000000000][sender#example.com]apiuser#example.com</wsse:Username>
<wsse:Password>mypassword</wsse:Password>
<wsse:Nonce>00000000000000000000000000000000</wsse:Nonce>
<wsu:Created>2013-10-29T20:37:59.241468Z</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
</SOAP-ENV:Header>
For reference, OAuth2 is not required and is not supported in the SOAP API at this time.
Have you read through the "Send On Behalf Of Functionality in the DocuSign REST API" section (p16-18) of the DocuSign REST API Guide (http://www.docusign.com/sites/default/files/REST_API_Guide_v2.pdf)? This content provides a decent overview of how to use SOBO with the DocuSign REST API, and even includes some examples.
Related
My DocuSign App failed the "Go Live Review" due to me not using OAuth 2.0 authentication.
I have now read the documentation on how to "Get an access token with JWT Authentication" below:
https://developers.docusign.com/platform/auth/jwt/jwt-get-token/
Following this documentation I am able to get the JWT using jwt.io as suggested.
The Verified Signature code from jwt.io is then used to exchange for an DocuSign access_token using POSTMAN.
All this works as expected.
After some time the Verified Signature optained from jwt.io expires and calling https://account-d.docusign.com/oauth/token from POSTMAN results in this error:
{
"error": "invalid_grant",
"error_description": "expired_grant"
}
To fix this, I simply go to jwt.io and update the Payload section with new values for "iat" and "ext" and a new Verified Signature is obtained and copied in to POSTMAN for new request of access_token.
My question:
How to solve this expiring issue as DocuSign endpoint does not provide a refresh_token ?
It must be possible to somehow "renew" the Verified Signature as DocuSign endpoint requires this updated value for the field : "assertion" in POSTMAN.
I have tried to construct the three values separated by a period in the Verified Signature manually by base64 encoding, but I can´t figure out how to get the final RSASHA256 value in the Verified Signature.
I have seen the documentation for "Migrate to OAuth 2.0 using the DocuSign eSignature C#SDK" on this link :
https://developers.docusign.com/platform/auth/oauth2-requirements-migration/
Please note that I am not a developer and maybee the solution to my question is obvious for real developers - but I need a bit of help to solve this as I do not work in development-tool as shown on the video.
Please help...
How to solve this expiring issue as DocuSign endpoint does not provide a refresh_token?
The best is to create a new JWT for each OAuth call to DocuSign--and use software, not a website, to do so.
Note: Only obtain a new access token (by sending a fresh JWT) when the old access token has expired or is about to expire.
The DocuSign SDKs include functions to create a JWT. All of the SDKs are open source, so if you don't want to use the SDK as a whole, you can copy out the functions' implementations.
This would depend on what language your app is written in or what kind of tool it's built on. Generally, most programming languages have libraries that can generate the JWT for you without having to use jwt.io manually.
Does your app only make API calls via postman? This post might be helpful for you. It shows how to set up a pre-request script to generate the JWT
I am using Docusign Login information api in a mapping with Informatica Cloud .
The mapping executes successfully with a fault response.The error message in the fault response is as follows.I have tested the same api in postman.I am using Integrator Key provided by Docusign for authentication along with my username and password.The API works perfect in postman.But with Informtica Cloud it gives me following error.
I have created swagger file with username,Password and integrator key as headers for creating the web service in Informatica Cloud.I am using Authentication type as 'Basic' in the connector and in swagger file.Where I am I going wrong with authentication?The Integrator Key or the username and password are valid.
Unauthorized {
"errorCode": "AUTHORIZATION_INVALID_TOKEN",
"message": "The access token provided is expired, revoked or malformed."
}
This question/answer from the Informatica site may be of help.
If the Informatica Cloud connector enables you to pass an X-DocuSign-Authentication header then you can use DocuSign's Legacy authentication.
If not, then you will need to send an Authorization header with value Bearer a_bearer_token
From the Informatica QA, it looks like you will need to create a small application that will use the JWT Grant to create an Access Token, and then return the Access Token to Informatica.
Next, use the Access Token via Informatica to use DocuSign's API.
I'm sure that Informatica Cloud's consultants have come across this issue before, you could also contact them for help.
DocuSign doesn't support Basic Authentication for API calls.
I'm not familiar with Informatica Cloud, are you able to define a custom header so you can properly provide the x-docusign-authentication data block?
I am using docusign-esign-java client SDK for 'docusign' integrations. I need to implement sobo functionality after I have logged into docusign using legacy authentication API of docusign. How I can achieve this?
To activate SOBO (Send On Behalf Of), you just need to add <SendOnBehalfOf>bob.smith#gmail.com</SendOnBehalfOf> to your existing X-DocuSign-Authentication HTTPS header with your call.
Example:
X-DocuSign-Authentication: <DocuSignCredentials><SendOnBehalfOf>bob.smith#gmail.com</SendOnBehalfOf><Username>{name}</Username><Password>{password}</Password><IntegratorKey>{integrator_key}</IntegratorKey></DocuSignCredentials>
Docs (We're working on adding this info to the new docs too.)
We are looking at the DocuSign API integration using .NET.
I've managed to send an email from this correctly and added fields to the form programmatically however I could do with knowing how to use the Send On Behalf feature.
It looks like in the APILogin() function I need to add a default header called X-DocuSign-Act-As-User and then the email address (SOB is enabled on the API account). But then it says I need something to do with a token for this user? But not sure where I get this from?
Thanks,
Alex
X-DocuSign-Act-As-User header is only applicable when using OAuth tokens. For non-token usage, add the X-DocuSign-Authentication header.
Example from the GUIDE:
X-DocuSign-Authentication:<DocuSignCredentials><SendOnBehalfOf>bob.smith#gmail.com</SendOnBehalfOf><Username>{name}</Username><Password>{password}</Password><IntegratorKey>{integrator_key}</IntegratorKey></DocuSignCredentials>
Where {name} is the email address of your API Initiator and {password} is the password of your API Initiator. Those credentials are used to authenticate the API call, but the envelope will be created and owned by "bob.smith#gmail.com" as the Sender.
Note 1: "bob.smith#gmail.com", i.e. the on-behalf user, must be an account member with "send envelopes" permissions.
Note 2: API Initiator credentials - recommendation is to use API Name (the User's GUID) rather than email address, and use the "encrypted password" instead of the plain-text password. This is retrievable via the login_information API call. These forms of the credentials are not useful for logging into DocuSign via the Web interface.
Trying to call the Docusign REST API to Delete/Close User. Passing XML as the documentation in Docusign accepts XML or JSON. But getting 400 status code. I can login using REST API fine. Have had several eyes look at Docusign documentation on the Delete in relation to what I'm passing in XML, but nothing has popped out as to why we are getting 400. Typically, that would mean your XML ... your request is not correct format. Is anyone having this issue with Delete/Close User? Any advice?
Please don't use legacy authentication as it's old and insecure.
You should be using OAuth and if you don't want to have to authenticate each user you can use JWT (JSON Web Token) which would require that you obtain consent for the app to impersonate the user (or any user) that they make API calls on their behalf.
You can find more information about how to use JWT Auth in this article on the DocuSign developer center.
Deleting a user using the REST API is done using this endpoint:
DEL
/restapi/v2.1/accounts/{accountId}/users
The body is a JSON with an array of one or more users to delete. The userId (GUID) is sufficient information to provide to delete a user.