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.
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 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.
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.
I am creating this post after doing quite a lot of research on OpenID Connect myself including reading the specs and the more I read the more questions come up. I hope that someone is able to help me and clear my confusion.
The OpenID Connect specs are good but only contain very basic examples that do not match my usecase. Please let me try to explain my situation and then ask my question:
I try to use OIDC in conjuction with SharePoint Online and two applications. One is a webservice (back-end) that is supposed to interact with SharePoint and the other one is a simple single page application (front-end) running in the browser of the user that allows him to interact with the webservice. My IdentityProvider is Active Directory. The task of the webservice is to do some actions in user context on SharePoint but it is also supposed to allow the user to execute a limited set of actions that only an administrator of SharePoint would be allowed to do (e.g. I want to allow the user to create a SiteCollection but not delete it) For that reason I managed to register the webservice with SharePoint so that it receives a Special access_token which grants it admin access in SharePoint.
My thoughts so far:
1) If the user logs into SharePoint he receives an id_token and an access_token from the AD. He can use the id_token to log to SharePoint and interact with it directly. (I got this working)
2) I also want to authenticate the user in the front-end single page application because some users should not be able to make certain calls to the webservice and I want to hide these buttons from them in my application. For that I could use the id_token from step 1).
3) If my webservice should do something in the context of a user I can just pass the access_token that was created for that given user in step 1) to the webservice and then forward it to SharePoint.
4) If my webservice should execute a privileged function that the user is not allowed to do on his own, I want to use the Special access_token that the webservice already pocesses to make the call. In that case I have to authenticate the user at my webservice with his id_token from step 1) to make sure that I want to allow this request of his.
My question:
Does every client have to make a request for his own id/access_token? (These different flows are described in the OIDC and OAuth specs here and here) and will this still be Single-Sign-On?
Or can I just generate a single id_token and access_token for a user in step 1) and then pass these on to all clients that need them?
Thank you very much in advance!!
I have managed to create an iOS app that successfully authenticated the user and connects to the Nest structures and device settings. Using the access token, the app connects automatically to the Nest server each time the app is launched.
However, I am unable to find any documentation that explains what procedure to follow if the app needs to provide the functionality to enable log on/off for different user accounts, e.g. monitoring devices at different locations under separate user accounts from the same app.
The only way that I can change the login for a different user at this time is when I delete and re-install the app, which is not practical.
Does anyone have a suggestion as to how to solve this issue?
Your help is much appreciated.
You'll want to just create a routine for getting the access token that can be reused. The login is part of the authentication process in retrieving an access token.
Once you have an access token, there isn't any open session per user account so there isn't a need to logout. Instead, just reuse the same method that got you the first access token and store as many access tokens as necessary.
Each access token is effectively a session id.