I am trying to create a embeded sign in url from backend webservice and open that url in the mobile application for signing.
For that in backend first of all i need to get Auth token.
To fetch auth token i need to get Auth code. For this i need to build a url with redirect url and when i open this url it will be redirected to given redirect url with auth code.
https://account-d.docusign.com/oauth/auth?
response_type=code
&scope=YOUR_REQUESTED_SCOPES
&client_id=YOUR_INTEGRATION_KEY
&state=YOUR_CUSTOM_STATE
&redirect_uri=YOUR_REDIRECT_URI
&login_hint=YOUR_LOGIN_HINT
But this process is manual and auth code from this is valid for 2 minutes only. So each time i have to build url and get auth code.
Is there any automated programmatical way to fetch auth code or generate auth code which will not expire.
If the signer is also the DocuSign account user, then Authorization Code Grant is the right way to go.
It sounds like you're not implementing authorization code grant correctly:
You redirect the user's browser to the DocuSign OAuth service (account.docusign.com for production, account-d.docusign.com for development).
After the user finishes authenticating with DocuSign, the authentication service will redirect the user's browser to your redirect_uri, which you supplied earlier.
Your application, initiated via the redirect_uri then exchanges the authorization code for an access token. There's nothing "manual" about this process other than manually entering the email/password for authentication.
JWT Grant when the DocuSign account user is not present
It could also be that the signer does not have an account on the DocuSign system. (This is the more common situation.) Signers do not need DocuSign accounts, only senders do.
In this case, your application should use the JWT Grant flow to impersonate a DocuSign account user--either a real person or a "system account" such as "Payroll Department."
The JWT Grant flow is used to obtain an access token. Then your server-side software would use the API to send the envelope, and then to obtain an embedded signing ceremony URL. Next, redirect the user's browser (on the phone) to the signing ceremony URL. After the signer signs, the DocuSign signing ceremony software will redirect the user's browser back to your application.
Related
I'm writing a Python/Django integration with DocuSign, where users will be sent from another application to DocuSign to sign a document, and then be sent back to the initial application. These users do not have DocuSign accounts.
I am currently using "request_jwt_user_token" alongside our service account generate the an envelope, attach a document, and create a recipient view. At the end this returns us a url like:
https://demo.docusign.net/Signing/MTRedeem/v1/[random_string]?slt=[random_long_string]
I'm pretty sure the first random string is an identifier and the latter is an access token?
What I'm trying to understand is how secure this info is to pass on to arbitrary users. I'm keeping the jwt expiration low and setting the jwt scope to ["signature", "impersonation"]. But can the slt token be used to access other envelopes or do other signature api calls? I assume it can't be used for anything outside of signing due to the scope.
The URL you posted here has nothing to do with JWT. It's an embedded signing URL that you can redirect your user in order to complete signing. They can then be redirected back to your app after they're done.
This URL expires in 5 minutes (or 2 minutes) and so it's very secure. It is also a URL that can be used only by one user (the one you set as the user signing the envelope and generated with the clientUserId)
The access token can be used to access other envelopes etc, but that access token is NOT in this URL and should never be shared etc.
I need to add DocuSign to my chat app (iOS, Android, Windows) in order to ask to sign documents to all the chat group members.
I want to implement DocuSign signing flow without Server implementation: only Sender and Recipients client side implementation (is it possible?).
Flow that I imagined:
An authenticated Sender create the envelope with Envelopes: create REST call.
Other members must sign the document (no DocuSign account needed)...
...so I need to generate a "recipient url" for every member using the REST call EnvelopeViews: createRecipient (who call this endpoint?)
I tested this flow with Postman and I've some questions:
EnvelopeViews: createRecipient require X-DocuSign-Authentication header, so this request must be called from Sender side, is it?
EnvelopeViews: createRecipient return an url that can be used once, why? The second time I use this url I get 404 as response.
So what I notice is the Recipient can't use the url (provided by the Sender) twice but he can't generate a new url every time because it isn't authenticated (no X-DocuSign-Authentication).
How can I implement this flow properly?
Lots of good questions:
EnvelopeViews: createRecipient require X-DocuSign-Authentication header, so this request must be called from Sender side, is it?
Do not use the X-DocuSign-Authentication header. That's "legacy authentication" and DocuSign does not support it for new REST eSignature apps. Instead, use OAuth. Probably the OAuth JWT grant flow since that flow enables your application to impersonate a DocuSign user (such as the sender), when the user is not present.
You can call EnvelopeViews: createRecipient from your server or from your browser app. If you call from your browser then you'll need to implement a private CORS gateway.
Either way, when the signer is ready to sign, you obtain the signing ceremony URL from the EnvelopeViews: createRecipient API call, then redirect the signer's browser to the URL.
EnvelopeViews: createRecipient return an url that can be used once, why?
For security reasons. That's part of our information security architecture. And not only is the signing ceremony URL only usable once, it is also time limited. It should be used within a minute or two from when you receive it from DocuSign. It will expire 5 minutes after it was created.
The second time I use this url I get 404 as response.
Yes, that's as designed. You get the URL, then you immediately redirect the signer to the URL. Then they sign. Then they're redirected back to your application.
If you want to provide a URL to a signer that the signer can use later on, you can implement that flow yourself. I've described how in other answers.
So what I notice is the Recipient can't use the url (provided by the Sender) twice but he can't generate a new url every time because it isn't authenticated (no X-DocuSign-Authentication).
How can I implement this flow properly?
You're almost there. Implement the JWT grant flow in your application. That way your app can impersonate the sender even when they're not around. When the signer wants to sign, your app gets the signing ceremony URL from DocuSign, and then redirects to enable signing.
An alternative which also works fine is for the sender to sign in to DocuSign by using the standard OAuth Authorization Code grant. This provides your app with an access token and a refresh token.
Your app enables the sender to send the enveloper by using the access token.
Later, when the signer wants to sign, your app uses the refresh token that it stored to generate a new access token. Use the access token with the EnvelopeViews: createRecipient API method to obtain the signing ceremony URL.
X-DocuSign-Authentication header is legacy authentication, please don't use this as it's not as secure as modern OAauth.
Again, security. Every time you want someone to sign your code should generate the URL. Also, note you cannot generate two URLs. Only one is valid at a time. You need your app to have some logic to ensure that only one user is signing and only at that point in time the URL is generated.
I have the following flow for sign in / sign up, when using sign-up:
Present user with sign up screen, allow them to enter email/password/name
Validate input, then send email (rest api) and set verification attributes in b2c custom extension properties
User then receives email with verification link
User clicks link from email and gets sent to a new user journey for the return trip
New user journey gets parameters from the querystring (email + verif code)
B2C validates the verif code + expiry
IF user is verified, they're set as verified via custom extension attributes, then sent to the (ASP.NET MVC) application.
Here's where I'm stuck - B2C is sending the jwt token back to the app, but the user doesn't get 'signed-in'.
Am I missing something at step 7? I don't have the "state" variable in my querystring, am I expected to build and include it somehow so that B2C and the app can communicate? I'm lost at this point. I'd post some of the b2c policy xml but not sure what would even help...
EDIT: reply to Jas:
Is that the only way (make an app call b2c for an auth request)? We have multiple apps that a user can use to sign up through b2c, so I was hoping to avoid having to make changes to each of them. Instead I was hoping that B2C could tell the app after account verification that "this user is ok".
I did previous look at https://github.com/azure-ad-b2c/samples/tree/master/policies/sign-in-with-magic-link (written by you!), but again, was hoping I could avoid having to do that work inside of each of our apps.
Here's an example of the jwt 'id_token' I'm trying to pass to the app:
id_token
Side note: Is 'id_token' the same as 'id_token_hint'? I couldn't find whether they're the same or different when googling it.
What you need to do is send the invite link in the email as a link to the app, eg https://myapp.com?id_token_hint=value.
Then have your apps account controller make an auth request to the policy to complete the account redemption along with an extra query parameter “id_token_hint=value”. Now a proper auth can happen with your applications openId middleware initialised.
I have checked Docusign Request the Authorization Code related documentation and set all the settings on Docusign Admin. But when I run the below url in the browser it wants login details and accept screen. My query is how can I skip this login and accept steps. Here is the request url
https://account-d.docusign.com/oauth/auth?response_type=code&scope=YOUR_REQUESTED_SCOPES&client_id=YOUR_INTEGRATION_KEY
&state=YOUR_CUSTOM_STATE&redirect_uri=YOUR_REDIRECT_URI
You cannot skip this login page if you are using the authorization grant flow as this is part of the oauth protocol security. To get a token, you need to authenticate (or your customer/user would need to). This token is typically valid for 8 hours and a cookie is stored on the device which means you won't be asked again to login for the next 8 hours, but you do need to do this initially.
I need to use docusign in the app to let the user sign the contract, but I found that the REST api using docusign requires authorization, and the authorization requires the user to log in to their docusign account.
Is there another way for users to authorize and sign without logging in?
Yes, to send an envelope (transaction), an access token is needed. But not for signing. There are several workflows available to you and your app:
Use a Powerform. In this use case, a DocuSign user creates the template for the envelope and turns it into a powerform. Now, anyone with the url (including your Android app) can cause an envelope to be created automatically and then start the signing process. No access token needed by the signer!
Use a server-side process to create the envelope, including any customization needed. Since the server process is operating on its own, it'd use JWT authentication to obtain an access token for creating the envelope. It'd also create the signing ceremony url from DocuSign. Your Android app would then open the signing ceremony url to let the app user sign the document(s). No access token is needed by the Android app.
Your Android app could obtain a DocuSign access token from its server. Then your Android app could directly use the DocuSign API to create an embedded signing url for the app user to use. The access token would represent the app, not the person signing on your app.
Code examples
JWT authentication code examples
Embedded signing examples: see example eg001 source from any of the repos.