From DocuSign, this is Developing with DocuSign.
This video is a continuation of our multi-part instructional series
on how to migrate your application from DocuSign Legacy auth to OAuth.
My name is Nima Poulad, a Developer Advocate with DocuSign.
In this video, I will tackle Python applications.
Please check out our videos in this series for other SDK languages.
Am I using insecure legacy auth? How do I know which authentication method I'm using in my
integration? The simplest way to find out which authentication method you're using is a search
for X dash DocuSign dash Authentication in your code. If you find that keyword and if you see
yourself setting that header in your DocuSign calls, then you're using legacy authentication.
You should start planning to migrate your integration to newer auth methods,
as DocuSign will stop supporting legacy authentication in September
of 2022 for applications currently in production.
Let's look at the following example together.
Here, we have a simple code of snippet that lists envelopes in your account.
To authenticate, we're setting the X dash DocuSign dash Authentication header with your
account password and username, in plain text. It goes without saying that this is insecure.
Let's go ahead and change this code to a better, more secure JWT authentication.
But before we do so, we need to gather some information from our admin dashboard.
First, let's go ahead and collect some information that we're going to need to perform OAuth.
Navigate to your apps and keys page,
and then find the Integrator Key that you will be using in your integration.
Then, navigate down to RSA Keypairs and generate a pair. You want to go ahead and save the public
key and your private key in a safe location, as you will needing them in order to perform OAuth.
Next up, you want to navigate to the user page and you want to find the user ID of the user
that you will be impersonating. So select a user and go ahead and open it and make note of the
API username. This is a user ID that you'll be using to impersonate when you use OAuth.
All right, now let's look at our code after migration to the new OAuth 2.0 authentication.
There are a couple of notable differences I will discuss here. First, we're using a JWT
auth Grant flow here. This is the easiest way to migrate your code away from legacy auth.
If the account user is not present or the web browser can't be redirected,
then the legacy has to be replaced with JWT Grant.
In your scopes variable you'll define the scopes you need.
For e-signature applications, use a signature scope. The impersonation of scope is assumed
and is not needed in a JWT Grant request. You then specify the user ID you that you're impersonating
when calling requests underscored jwt underscore user underscore token. You
will also need to use the RSA key you created previously, along with your integrator key,
and include the private key as a byte array when you call request JWT user token.
The private key is used to digitally sign the token payload before sending it to request.
After the JWT method returns the access key,
set the authorization header by calling set default header. Please keep in mind that the
token is only valid for an hour, and you need to get a new token when the old one expires.
Use the same access token to make Api calls while the token is valid. Do not get a new access token
for every Api call. Only get a new access token when your application is about to make
an Api call, and the old token has expired or will expire within the next 10 minutes.
The rest of your code remains intact. That's it, it really is the simple to migrate your
auth from insecure legacy auth over to the latest OAuth that our security supports.
Thank you for joining us today. Please be sure to subscribe to our channel so you
can follow the future videos that I'll be posting in this series. Thank you so much.