I have been trying to implement JWT Auth grant for our back end application which will be creating URLs for signing operations for our end users.
What I want to active is that there will be no login/granting consent operations while sending the envelopes and creating signing URL. I want to dedicate one user for creating envelopes and sending them for signature.
Firstly, I've created a demo account and an organization. I also created an integration key and a RSA key. I needed to choose Implicit Grant or Authorization Code Grant while creating the integration key and I chose Implicit Grant. Lastly, I gave signature impersonation permissions to the integration key.
I have checked and made experiments with jwt example project after configuring with the required info of the user that I want to dedicate. It asked for the consent. After I gave consent, it worked finely. Then I configured the back end with the same integration key and the guid of the user, again it was working with our back end application that I was able to send automated envelopes.
I created another demo account in DS and this time I directly put it to our back end, I am getting consent_required error which I understand that I couldn't give the admin consent properly and it was just working with previous demo account because I gave the consent to that.
I want to know that how long that consent would last. or Is it the correct way to achieve what I want? because I think, ideally, I need to give admin consent to this dedicated user to have it able to send automated envelopes.
Thank you a lot in advance.
I see two questions:
How long consent would last? - forever. Or if you go and explicitly remove it.
Is it the correct way to achieve what I want? I don't know what you want, but the title says "Sending envelopes from one dedicated user" so, in theory that is correct. However, keep in mind that that user will be different when you move to production ("go live") when your application is ready for real usage.
Related
I know that we could use Auth Code Grant, implicit grant or JWT grant. But I have the following scenario:
I have my own app. All users are usually logging in to my app, so I use JWT grant. But sometimes the contract should be assigned from a future employee, who does not have any account yet. Therefore I want to use Authenticaion Code Grant (send him a link via email and he authenticate and assign on DocuSign).
Is is possible to use two different authentication methods for two different recipients in one document/evelope?
I tested each one separelty and works. But both of them in one app?
Yes it is technically possible, but I'm not certain that's the best way to go about this. If you want to generate an OAuth token for a specific user they're required to have their own DocuSign account as they need to provide documented consent for whatever scopes you're requesting.
But to answer your question, an OAuth token gives access to any account that the authenticated user has access to. Once the tokens themselves are generated there isn't any rule or blocker that would prevent you from creating a token for a secondary user and then alternating between the two, as long as the token is used to auth against an account that it has access to. It becomes a little more difficult to keep track of the multiple tokens and corresponding userId -- but you can absolutely do that.
If you want to have one of these envelopes signed by a user that doesn't have an account yet -- I would agree with Inbar that embedded signing would be the correct way to go. Embedded signers aren't required to have their own accounts -- however in order to generate a recipientViewToken you need to authenticate as the sending user. On the customer side what they would see is a one-time-use URL that has a default lifetime of 6 minutes. This URL is typically loaded into a browser tab or some sort of modal window which then takes them directly into the signing session.
If you don't want to use embedded signing and would rather use the email link, you can still do that. Unless you're using a CFR 21 part 11 account users can still sign documents without an account -- they'll just be prompted to sign up for one afterwards so there's somewhere to house the envelope. I think based on this it would be better to use the embedded model, but we can support you on either path.
A strange situation that I am unable to find other people having to deal with. We are using Microsoft AspNetCore.Identity to handle our authentication. Everything is working fine.
The problem is that for a user to perform certain actions, they MUST get another user to 'sign' that action. This act of signing of course requires that other user to use their user name and password to sign the action.
The issue with this is that the other user's details are readily visible in the request payload. So if I am sneaky, I can open the developer tools in my browser (and hide it), then ask my admin to come and sign my action, and when they have gone i can go to the network tab and see their username and login in plain text!
Of course this is all over https but still, we can't allow one user to see another's sensitive information.
How are we to manage to allow a second userB to 'sign' an action for userA while in user A's active session, while removing the capacity for userA to steal userB's credentials??? Any ideas? (Front end is angular.js)
I imagine it's a big rework, but instead of having the "admin" sign the request on the user's machine, the admin could receive a "user A requires this action to be signed, proceed? [ok] [cancel]" on their account, the action would be stored in the database (perhaps temporarily?) & then all of the sensitive information is kept within each user's session with no cross over.
Then the authentication of who is permitted to approve actions can be handled in the backend via standard identity methods.
The user's "Please wait while an admin signs this action" modal (assumption) could then poll an API to determine the status of the action and then proceed once accepted.
I second #justcompile's answer if you need an authorised and authenticated user to sign/confirm the action, more work but the only secure way.
If you just need a second pair of eyes to confirm you could message a private group or slack channel that only "authorised" people have access to with a one-time URL containing a token (that maybe expires after a period of time too).
Assuming admins only access that channel they can follow the link, the app can validate the token and confirm the action.
Saves a second (admin) user logging in on their own machine and the need to build a workflow and UI etc, but again exposes you to risk if nefarious types get access to the channel or the links sent to it.
Depends on your appetite for risk I guess.
another user performs signing action on your local system? and you are sly?
there is no way to protect their password.
use two factor authentication.
The way this would normally be handled is for the user to request an action. This (unsigned) action-request is recorded in the database. The admin user is able to see this unsigned request in their account, and make an (authenticated) request to sign it. The user would be able to see the status of their request, and whether it has been signed yet.
My use case is thus:
I will have access to a single DocuSign account which would belong to Acme Inc. (I am currently using a sandbox account).
Acme Inc. has many branches, each with it's own employees with different documents that they must sign depending on which branch they work in.
From my internal application, the Admins of the branches will upload documents and set the emails addresses that the documents must be sent to.
The employees will complete the signing ceremony after following the link in the mail that they will receive.
MAIN ISSUE - Once the signing ceremony is complete, I require the employee to be redirected to a certain page of the internal application where they must complete some additional steps.
What I have so far:
I ran the example provided here. The issue with this is the permission request. I do not want an access prompt, rather, I want this done in the Admin Panel itself so that requests to the DocuSign API from my Server Application contain a valid token or receive a new one in case the existing one has expired. I saw from here that the JWT Grant system fit my use case, and I ran that using consent from a single user, however, I am stuck trying to figure out how to redirect the signer (employee) to the page I want with some parameters in the redirection URI. This can be as simple as the one provided (state=123) in the (eg-01) Embedded Signing example provided with the Auth Grant sample.
I apologize for not having any code snippet to show as I have not integrated anything into my internal application as of yet, I am merely running the code from the GitHub examples. Please let me know if I need to provide any additional information in order to facilitate your understanding of my requirements.
Any help provided would be much appreciated!
I think your main issue is the authentication type you are using.
You used the example showing Auth Code Grant, which does require users to log in.
You could instead use JWT (JSON Web Token) which does not require that (only once, and that can be done by you).
The code for making APIs and redirecting after signing ceremony etc. is the same. All you have to do is change the code that was used to obtain the access token (and also you need some configuration changes).
You can find nodeJS example of JWT here - https://github.com/docusign/eg-01-node-jwt
If you want to read more about JWT - https://developers.docusign.com/esign-rest-api/guides/authentication/oauth2-jsonwebtoken
I have a running website, where users already have accounts. And I am trying to create a Google Assistant agent, accessible on Android, to help users access their information.
My issue is that I can't detect returning users on Android Smartphones, each time they have to sign in.
I tried Anonymous User Identity, but it is soon to be deprecated.
Is there an other way to keep track of users?Using some kind of userId that I can store, so I can make "my own Acount Linking" linking the person/Smartphone with already existing user accounts.
There are a few angles to your question.
Is there any way to keep track of users?
Yes... but...
You can store a userId that you generate in the user storage area. You do need to treat this like you would a cookie, so some jurisdictions might impose restrictions on this, but this is one approach to moving from the anonymous ID that is being turned off soon.
But...
How do I let them log into my service through the Action?
That is the problem. The General Policies states the following limitation for collecting user data:
Authentication Data
(including passwords, PINs, and answers to security questions)
Don't collect authentication data via the conversational interface (text or speech).
After a user's account has been linked, PINs or passwords may be used as part of a second verification process.
So you need to use Account Linking to connect to the existing account on your service.
How can I do Account Linking if I don't require Google Sign-In?
You can still use Google Sign-In for Assistant if it will (or may) provide the information as part of the profile that match what you have. So it doesn't need to use the same account - just have the same email (for example).
But that still may not be enough.
For other cases, you can look into setting things up to work with an OAuth server that you control.
So why use Google Sign-In if I setup an OAuth server that uses Google Sign-In?
Google Sign-In is good for a more streamlined flow, if you can use it. It can be done completely with voice, such as with a smart speaker, instead of requiring the user to go to a phone to complete the login. So if you have the user's email address in your account system, and you also get this from Google Sign In, then you can connect the two accounts.
In some cases, such as if the user is expected to have logged into the account on your website first, they won't even need to do that. If both the voice client and web client use the same Google project, then authentication will take place automatically.
I need to have the following workflow:
Third-party company registers new admin user for Office365 (I can't control this process).
Then pass credentials of this user to us and we configuring it (add domains, additional users etc).
I need to automate this process and this should be done by background task. So, after registration we catch this event and add message to queue and then our Azure Functions add domains, register new users etc.
But for calling Microsoft Graph admin have to accept permissions manually (go to web page and accept). Without this action token is not valid. And it breaks our automate process :(
Any way to accept it without going to web page and logging by admin for accepting?
From how you describe this process it seems like what you really need is to create an application that uses Application Only permissions that your customer grants consent too. There should be no need for them to manually create an admin user and give you credentials for this user.
And to specifically answer your question, I do not believe there is anyway to automate the user consent process via an API call. That would defeat the purpose of user consent.