Is there any way to connect DocuSign with api keys only? I am using docusign-esign sdk. I am creating envelope at backend and send email to user to sign that.
Currently, I use to connect it with header X-DocuSign-Authentication and it works perfectly in dev env.
How can I connect that in Production env?
You are using legacy auth which is not as secure as using OAuth.
We highly recommend that you don't use legacy auth, and in fact we would very soon require it and not allow you to create an integration using legacy authentication (X-DocuSign-Authentication header).
You can use JWT such that the user doesn't need to authenticate each time you use your app. You would only need one time consent and you'll never have to login again.
Please don't use X-DocuSign-Authentication to ensure your app is as secure as possible!
Related
DocuSign is introducing App Password authentication, a new way to authenticate via the SOAP API. Will this have any effect on existing REST APIs authentication?
Depends on what you are referring to.
Are you authenticating with the REST APIs using OAuth2?(JWT or Authorisation Code Grant flows) or are you using the old basic authentication using the X-DocuSign-Authentication header?
If it is the former, then you will be fine but if you are using the latter method, then that will be deprecated as per this
App Passwords are for the eSign SOAP API (which does not support OAuth).
App Passwords can be used with eSign REST API apps until you upgrade them to OAuth. You must plan to upgrade your eSign REST API apps to OAuth.
I am working on an existing Next.js web application, and I would like to add the DocuSign Node.JS SDK to use the JWT Auth and generate a token for my front-end application. The Next.JS app is hosted on Vercel, which can run serverless functions.
I am having trouble building the Node.JS endpoint to obtain the JWT Auth token to call the esignatures API. Does anyone know how to integrate the JWT Auth workflow into a Next.JS/React.JS application with serverless functions?
The DocuSign Node.js SDK is currently designed for server side use only.
To use the DocuSign API from the client (browser):
Only the Implicit grant flow can be used from the browser due to restrictions in the OAuth standard.
If the user of your application does not have a DocuSign account (eg the user will be a signer), then you have two options:
using JWT grant auth on a backend server, acquire an access token for a "system user" such "hr#example.com". Use this access token to create an envelope and the signing ceremony (for embedded signing). Or use the access token as needed by your app. If the app includes a (non-DocuSign) login, then you can pass the access token to the browser and make calls from it.
use the PowerForms API if it meets your needs
To make API calls from the client, you will need to build a CORS forwarding proxy since DocuSign doesn't yet support CORS natively. And to make the API calls themselves, call the API directly since no SDK is available at this time.
I am using Docusign for embedded signing in my web application. In my case
I am not expecting users to have Docusign account and that's why i am using X-DocuSign-Authentication in the header for calling the API's and generating the url for e-signing.
Is this process safe to use on production?
Passing 'X-DocuSign-Authentication' wouldn't be considered safe, therefore we recommend to use oauth in production accounts:
https://developers.docusign.com/platform/auth/jwt
X-DocuSign-Authentication is not 'safe' because it requires your application to handle plaintext credentials directly.
For a 'service' application that accountless users interact with, JWT authentication is likely an appropriate replacement: https://developers.docusign.com/platform/auth/jwt/jwt-get-token/
TL;DR:
X-DocuSign-Authentication is no longer supported or allowed for new DocuSign REST API applications. And if you're using it for an existing application then you must upgrade to OAuth.
X-DocuSign-Authentication is no longer supported or allowed for new DocuSign REST API applications.
There is a depreciation schedule for existing API applications that use this authentication type.
I am building a REST API in node.js which needs to use Flutter and a React web app as their clients. The problem I'm facing is that I'm not sure where to handle the authorization. Both Flutter and React have a prebuilt "UI" from Firebase that doesen't even need to be connected to the backend. But also there is an option to just take the password and email from the forms and send them to my API which sends them to Firebase via a post request. The flow should be this, a user signs up with Firebase and is created, while that is happening he is also being "signed" up on my API so I can append and store data in his account.
I only need Firebase as an authorization layer, I feel that at this point in time I can't build anything comparable in terms of security when it comes to the authorization.
If you want to work with Firebase Authentication accounts on your backend, then you will need to use the Firebase Admin SDK to manage users. In particular, what you need to do is have the client app send the ID token provided by the SDK and verify the token so your backend can do things on the user's behalf.
I would recommend you to avoid implementing integration with Firebase in the client side, and do it only in the server side. You can use Firebase-Admin to integrate with Firebase in your node.js server. Then, the sign up/in request will be via your API.
In this way, your clients don't depend on 3rd party and all of the library updates should be in your server.
IS there any way to validate LTPA token previously generated from IBM Tivoli federated Websphere Application Server in my nodejs application.
I have checked "ldapjs", but I could not find something to validate LTPA token.
I have written a small library for this purpose: https://www.npmjs.com/package/ltpa
Once you've extracted your server key you can use the library to validate, and generate LtpaTokens.
There is an Java API related with WSLogin - which allows to validate LTPA. (Technically a re-login here)
But I dont think you can use this with Nodejs.
But my preferred way is to use the BASIC authentication using the URL post from your app.
This requires a provider (Websphere) to expose a URL for you.