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.
Related
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.
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
We have a client who has a simple Instagram feature on the site to pull photos by a certain tag. They just noticed it isn't working. Getting an error - invalid access token. I guess since the 1st because of the updates. We didn't used to need an access token since we're not doing anything with users - just tags.
Now it looks like we need one and the documentation makes zero sense on how to obtain one. And it seems like they're not accepting most apps. The app is in sandbox mode too. So I'm assuming it's because it got switched to that? Got no notification of this happening.
The first step in documentation to get an access token is "Direct the user to our authorization url." What does that even mean? There's not a link provided or anything. It also says "Company Name, Contact Email and Privacy Policy URL are required to start a submission." Our app doesn't have a privacy policy... it's just a simple tag feed. I don't understand why everything is so complex to have a simple tag feed.
Is there a wait time to get the app approved..if it gets approved... Do I have to have it approved before getting an access token? This isn't outlined anywhere.
You got it right. As of June 2016 any Instagram API calls require an access token.
Getting an access token is described in the documentation. App approval is not required.
There are two ways to get one: server-side or client-side. The second option (called implicit authentication) can only be used when implicit OAuth is enabled in the client settings (Manage Clients > Edit Client > Security > Disable implicit OAuth). It is disabled by default.
In either case you need to redirect the user to the authorization URL to obtain an access token.
The URL for explicit mode (server side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
The URL for implicit mode (client side) is:
https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=token
After this you will be redirected to the REDIRECT-URI, which will be passed an argument. For explicit mode this will be a query string with a code, while for implicit mode you will get the access token directly as a hash:
http://your-redirect-uri?code=CODE
http://your-redirect-uri#access_token=ACCESS-TOKEN
For implicit mode you can then get the access token from the window.location.hash in Javascript.
For explicit mode, however, you need to further process the code to obtain the access token. You can read how this can be done in the API Documentation. I'm not going to take this any further here.
The problem is that every user who wants to see your feed needs to login to Instagram (and have an account) in order to view it. In your case this might not be desired. However, there are a few options to get around this (rather annoying) problem:
You can reuse your own (already obtained) access token(s) to display the Instagram feed for every user. You will need to be aware of rate limits for each token. For sandboxed apps this is 500 API calls / hour, while live mode allows 5000 API calls / hour. [source] You could store tokens in a table and use them in a round-robin manner, to allow more API calls. This involves manually obtaining a bunch of tokens which your application can use (the more the better). This might not be the ideal solution considering Instagram doesn't warrant access tokens to have an unlimited lifetime.
You can retreive JSON data without authentication by appending /media/ to a user page URL, as described in this post. No tokens or client IDs are required for this to work. However, this only works for users, not for tags. Besides, Instagram doesn't document this feature so it is not garanteed to work in the future.
You can use an aggregator like Juicer or Dialogfeed instead which will handle access tokens for you. This is usually not free of charge.
I'm also in the process of making an Instagram feed for my website, and this is what I concluded from my research. Please bare with any errors I made.
Edit: Here are some more limitations for sandbox apps.
In sandbox mode you can only access data from sandbox users (thus users who received a sandbox invite). This means that:
Media retreived by user, e.g. /users/{user-id}/media/recent, will return an empty response if the user is not any of the sandbox users.
Media retreived by tag, e.g. /tags/{tag-name}/media/recent, will only contain tagged media belonging to sandbox users.
Thus, for a tag feed to work, it needs to be live (reviewed and approved). If you don't want to do this, the only alternative is to use an aggregator as I mentioned above.
For a web application, where we need to store and manage users (SSO or openauth or what not is off the table), where we manage important business data, how risky is it to use an email address + password as the sign in?
For the last 15 years or so, encryption and protection techniques have improved, but we continue to use a proprietary user id, akin to using your bank card number for online banking; an id that will not be reused elsewhere. Customers and product owners are pushing to use email address because it is easier to remember.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
I'm looking for some article or argument why using email+password for a site with sensitive business/financial information would be dangerous; or why it is not so bad. Again, I realize that provisioning our own accounts is not the ideal thing and am not looking for solutions at outsourcing authentication.
The "risk" of using a single authentication method for signing onto your application is difficult to determine without a risk assessment, and clearly defined system boundaries.
NIST 800-61 and NIST 800-63 gives guidelines on authentication methods for different levels of sensitive systems (in your case, a application). It will give you ideas on how to present your argument, and maybe an alternative solution, i.e., multi-factor authentication if the customer wants to authenticate using an e-mail address. This would mitigate the risk associated with malicious websites which collected e-mail addresses and passwords.
Keep in mind, password policy can also be managed to mitigate the risk behind a single authentication method using an e-mail and a compromised password associated with that e-mail.
All in all, it's not the ID that is important, but the authentication method and policies in place to mitigate the risks.
Using email + password as credentials is the widely accepted method of allowing users to log into sites on the web.
The advantage of using email is that everyone remembers their email address, whereas people will have difficulty in remembering which username or user ID they first signed up with if this is not their email address.
Username should not be considered private. This is the job of the password. Encourage your users to use a password manager such as LastPass where it can generate a 20 character completely random password (128 bits - uncrackable) which is different per site. LastPass will remember the username if this is not their email, so that solves this problem, however not using email can bring other problems such as username enumeration. If any signup function asks for a user to specify their username and you say that it is already in use, an attacker can use this to narrow the list of users in order to prepare for a password guessing attack. If you ask for email as step one of password reminder or signup forms, the system can send an email with a password reset link if already registered, or send an email with a link to the next step in the registration process if not.
In the end it all comes down to the value of the data your application is protecting. Adding two factor authentication is always a good step and can protect against password guessing and password reuse.
SSO or openauth or what not is off the table
Why is the case? Can't you use OAuth with claims based authorisation? You can still secure your application and make sure only the correct business users have access - it would just be that another entity is managing access for you.
I am concerned that there are a lot of websites that collect email + password pairs in order to use them to try to hack other sites; presumably asking you to sign up for an account for some humble service or other. What is this activity called?
Credential harvesting?