I am building an application that will be used by end users in multiple organizations to create and send envelopes for signatures. I am trying to figure out the correct authorization workflow. For this example, say I am manish#example.com.
My understanding of JWT is that JWT will impersonate manish#example.com when any of these 1000's of end users in different organizations send envelopes. Is that correct? But if so, won't they need to authorize the app to impersonate me when they first try to create an envelope? How will these users get my credentials? Would I have to share my credentials with all these end users of my application? Can they log in with their own credentials instead? But if my application is impersonating my own credentials to send envelopes on behalf of these end users, why do I need permission from these users to use my own credentials? After all, in the JWT workflow, the redirect URL does not return any information about the identity of these users of my application.
So, if my app impersonates me, how do end users get my credentials? And, if my app impersonates me, why can't I give this permission to the app once and for all at the time of creating the app? Why do end users have to permit me to impersonate myself?
On a related note, JWT is working great when I use my own personal DocuSign API credentials to authorize my app in testing. But when I try to use my own organization credentials to authorize the app, I get the following error. I also get this error when I try the AWT workflow. How can I fix this error:
Sorry, but we’re having trouble signing you in.
AADSTS50105: The signed in user 'manish#test.edu' is not assigned to a role for the application '225d2ddd-e3a3-4bed-a310-8a9b8786363e'(Docusign Test).
Help in setting up the correct authorization workflow would be great.
JWT enables developers to request a token on behalf of some user without that user having to log in.
That means that except for the first time when the user have to consent - there's no web UI required to obtain a token.
JWT tokens are for a specific user in a specific account and it's the GUID of that userID that is used to uniquely identify a user. If you have multiple accounts - you will have to ensure you use the right userID for the right user for the right account.
Note also that users in DocuSign have different permissions profiles and may or may not have the access required to do what the API is trying to do.
Finally, clarifying one last thing, you wrote :
when any of these 1000's of end users in different organizations send
If you have thousands of end users that will be sending envelope (not just signing them) then JWT is probably not the best choice for you. You can still use it, but you will need some way to know the userId of the user which means you'll need some uber-auth JWT user that is used first or keep tables of users (I assume users can be added/removed etc.) it's not an ideal way to do things.
Related
My app is using JWT with individual consent. When, as a customer, I go to the Connected Apps screen at https://account-d.docusign.com/me/appconsent and revoke access to my app, the app still keeps working fine. No Docusign API calls fail, I can still create envelopes. Why? Is there another way to revoke?
The documentation page at https://developers.docusign.com/platform/auth/consent/ says "In cases where user consent was provided by an organization administrator (such as the JWT Grant), this consent can be revoked with the DocuSign Admin tool." But there is no link with more if about this "Admin tool" and I can't find it, and I don't think this applies in my case since I'm using individual consent.
I believe that the next time the app tries to use JWT to obtain an access token, it will fail.
But the already in use access token will continue to work until it expires at the end of its one hour lifetime.
If your experimentation doesn't support the above, please update your question.
I have a vuejs SPA. Users have their own accounts with a dashboard. On the dashboard, is a section for PDF signing. All users should have the same PDF displayed, but with their name pre-filled on the PDF, and then 4 spots to sign.
Right now I am stuck on the first part for using the API....which is the auth code.
Why does it seem that the tutorial I followed, requires the owner of the DocuSign account to login and grant rights? I had to do something similar to https://account-d.docusign.com/oauth/auth?response_type=code&scope=signature&client_id=5665656-3506-46fa-b46d-f6acf3b59268&redirect_uri=https://www.google.com and I got a code in return....but how am I even suppose to implement this for my web app?
How do I get the auth code in the background....meaning...I cant have all users go to this URL...am I supposed to do it via ajax GET? I was able to use a correctly formatted URL, but I got the response by visiting the URL in my browser...how can I do this programmatically?
I dont get the granting rights part....because there is no way this would be practical where all the users would have to know my private DocuSign account info?
Of the (3) oauth methods, which is best for my scenario? Authorization Code Grant, Implicit Grant, or JWT Grant
Auth Code Grant was meant for interactive scenarios. It requires UI and a web interface. It cannot be used without UI. Once you have the initial access token, there's a refresh token to be able to obtain a new one without UI, but the initial call requires UI.
The users don't have to know your account info, your account info may not be relevant. The user grant a right to your app/integration to make API calls. That is not your account, it is different. It's a clientId/integration key that you use your account to create, but it can be used with any DocuSign user/account.
JWT would allow for what you asked in #1 but only after a one-time consent was provided (What you asked in #2) by the end-user. You have to do that for users to enable DocuSign to make API calls on their behalf.
Final word, signers do not need an account in DocuSign. I don't know what you're building, but if your end-user just signs - they don't need an account and a lot of 1-3 is moot.
Ive been researching the MS Graph API lately, and I'm running into a problem. My use case is that I want to read a certain mailbox's mail, and send mail for that mailbox. The mailbox is a non user related box, and is used as a service account for emails.
Ive found 2 possible flows for getting into that mailbox. The user authenticated flow, and the application (and admin consented) flow. For the application, I want to read the emails in the background in a NodeJS app, without user interaction.
When I look into the user consented flow, I find that to make it work the user HAS to log in atleast once, by hand, and consent to some stuff I want to do. I found this page, on how this works, and made it work in my NodeJS app. The problem is, when using this flow, I have to login BY HAND atleast once after starting my NodeJS app. Afterwards I can use the refresh token to refresh the access token, but I dont want to do the login by hand.
The second option, and most suitable option for my NodeJS app, is the application flow. I found this tutorial on how to do that, and I made it all work. I fetch a token, and that token grants me access to the box via the Graph API.
But using the application flow, I found that I have to have the roles (i.e.): "User.ReadAll, Mail.Read, Mail.Send". This gives my application rights to read and send mail FOR ALL users in the account.. Which is WAY too much overkill for my situation.
Now my question; Is there a way for me to use MS Graph, with the application authentication flow, but without having access to all users' mailboxes, only to my specific account I want to read?
Thanks in advance,
Caspar
While linking the documentation reference, I saw that I read over the most important footnote:
Important Administrators can configure application access policy to limit app access to specific mailboxes and not to all the mailboxes in the organization, even if the app has been granted the application permissions of Mail.Read, Mail.ReadWrite, Mail.Send, MailboxSettings.Read, or MailboxSettings.ReadWrite.
So it is possible using the application access policies.
I was able to implement a NodeJS application to sign in with my quickbooks developer account using OAuth2.0.I have the client key and the secret key and I am able to get the access token by signing in to quickbooks with their pop up and it redirects me to my application, and then the user is able to send invoices or get data from this quickbooks account.
However, I want the user not to have to sign in to quickbooks in order for it to send invoices or any other operation on quickbooks. I want to be able to write the functionality the application is allow to perform on the QuickbooksAPI by automatically signing in into quickbooks. How can I achieve this?
To word this differently, I want the NodeJS server to log in into quickbooks automatically if application user has the roles or permission to do a quickbooks action, such as creating and invoice or retrieve information. The application should grant itself permission to the OAuth2.0. How do I do this? with a JWT token? Not sure
A bit of background: I was able to accomplish Oauth2.0 authentication by using node-quickbooks by mcohen module.
Thank you in advance
The application should grant itself permission to the OAuth2.0. How do I do this?
You can't.
But you may also be misunderstanding how OAuth is supposed to work.
You need to have the user go through the OAuth process ONCE. EXACTLY once. Never more than once.
Once you have them go through that process once, you get back an access token and a refresh token.
You can then use those tokens to get updated tokens whenever you want (e.g. refresh your access/refresh token programatically, without any user interaction at all). See the docs:
https://developer.intuit.com/app/developer/qbo/docs/develop/authentication-and-authorization/oauth-2.0#refresh-the-token
So, have the user go through OAuth once. Then store the tokens in your app. Refresh the tokens via the refresh token API. The user just has to auth exactly once, and then everything else you can do automatically forever going forward.
We have a case where we have 'clients'. Every client is an different Azure tenant but we keep their tenant id in the database. So we have Angular application where we want to have like a dropdown with all the clients and based on the selected client to query their tenant users so we can add him to our database and give them permissions and stuff to all other applications. As per my readings this in not achievable,
Because this permission application will be used from like 3-4 guys which are part of our tenant only.
Is there a way we can achieve that?
You would need to use the User.Read.All Application permissions and authenticate using the Client Credentials grant. You would then need to retrieve a token from each tenant prior to calling /v1.0/users.
Note that this will require receiving Admin Consent from each tenant you need to query.
Rohit's comment below is an excellent point. If your app is a SPA, meaning the authorization is happening entirely in the browser via Javascript, you're really limited to the OAuth's Implicit Grant.
To use Client Credentials or Authorization Code grants, you need some kind of backend API to handle the authentication and calls to authenticated APIs. I would argue that you should be doing this anyway, if for no other reason than forcing your user to reauthenticate every hour isn't a great user experience.
If you don't mind requiring each user in the tenant to authenticate, you could use the Authorization Code grant. This is a bit more complex of a set up because it requires you to keep track of separate Refresh Tokens for each user. Your backend would need to retrieve the Refresh Token, Exchange it for a set of new tokens (access_token and refresh_token), Store the new Refresh Token, and then call the API using the new Access Token.
Since there is a 1:1 relationship between the Token and the User so, at scale, you're looking at a lot of tokens. You'll also need a bunch of maintenance workflows to handle issues that may come up (refreshing the token fails, new scope requirements, etc.).
It really comes down to the depth of the relationship between your app and the tenant. If you're providing security and analysis to the entire organization, then asking for global Mail.Read is certainly reasonable. If you're providing a service to just part of an organization, it can be hard to get IT to sign off on such a broad permission scope.