Recently the Teams API has been extended so that applications can set the availability / presence for a user logged into Teams: https://learn.microsoft.com/en-us/graph/api/presence-setpresence
However, the permissions for this API do not allow access with delegated permissions, only with permission type application:
https://learn.microsoft.com/en-us/graph/api/presence-setpresence?view=graph-rest-1.0&tabs=http#permissions
Am I right in assuming, that this means I will need an administrators consent from every tenant if I intend to build an application using this API?
Is it therefore impossible / impractical to implement this into my app that allows a user to set their presence based on the activity in my app? Because, and please correct me if I am mistaken, a user by themself cannot actually give my app the permission to do this. Right?
(Doesn't this make this api point sort of nearly useless?)
This API supports only Application permission, so on behalf of user token, you can not change the status where as using application token, you can update the status: https://learn.microsoft.com/en-us/graph/api/presence-setpresence?view=graph-rest-1.0&tabs=http#permissions
Related
We have an app registered on Azure AD (we got app ID, secret, redirect URL). This app is a daemon/background application which is performing actions on behalf of a user, there is no signed-in user that can grant permissions. In particular, the app will periodically retrieve all emails from a particular outlook mailbox called my.test#org.com
We are following the permission scoping documentation and the permission documentation when there is no signed in user.
In my understanding we need
to give application-permissions on the API permissions page in Azure AD
create a security group which is somehow assigned to the mailbox we want to read from via
New-ApplicationAccessPolicy
-AppId e7e4dbfc-046f-4074-9b3b-2ae8f144f59b
-PolicyScopeGroupId EvenUsers#contoso.com <-- would I put here my.test#org.com or the ID of the security group?
-AccessRight RestrictAccess
-Description "Restrict this app to members of distribution group EvenUsers."
Is my understanding correct that both of the above steps are needed. It seems strange that in the first step we can only give tenant wide permissions to the application when we really only need to limit it to one particular mailbox.
Thanks for the help
The above steps looks good to me and i would do the same as well. Just provide necessary Graph permissions while you grant permissions to access your/others mailboxes - as described in the documentation/steps.
I am trying to read a person's Out of Office text with MSGraph. I understand the only way to do this is by getting the person's mailbox settings as indicated here.
Is there another way to read a person's Out of Office Message?
Assuming there is no other way I then have read for example in this link that to call GET /users/{id|userPrincipalName}/mailboxSettings you need to have Application Permissions for MailboxSettings.Read, MailboxSettings.ReadWrite. Is this still the case? It does not make sense to me that you need Application level permissions. Is there not a delegated (admin consent required) MailboxSettings.Read.All??? The problem is that most IT departments will be hesitant (or pigs are going to fly before some IT departments) give an application this permission to run without a signed in user.
Alternatively, I see that there is a User property of mailboxsettings, thus using the $select query parameter you can call this https://graph.microsoft.com/v1.0/users/{id}?$select=mailboxSettings does or should this work with the User.Read.All.
UPDATE in accordance with the suggestion below I have added 2 suggestions to the MSGraph user voice.
A person's out of office information should be included with their calendar / freebusy (getschedule) information.
There should be a Mailboxsettings.Read.All permission.
Please click on the link and vote them up if you agree.
No, there is no MailboxSettings.Read.All or MailboxSettings.Read.Shared. You can see the list at https://learn.microsoft.com/graph/permissions-reference#mail-permissions. I encourage you to request this as a feature at https://microsoftgraph.uservoice.com.
One possible approach given the currently available permissions around this API is to use app permissions and configure an app access policy to limit the mailboxes it can access - if that's the concern you're mentioning. I'm not clear on why it would be preferable to give a user account access to this info for all mailboxes in an org but not an app service principal.
It isn't included as part of User.Read.All by design. It's not really a property on the user, it's config stored in the mailbox. It's abstracted as a property in Graph, but it requires additional permissions to access.
We are building a web app that lets Office365 customers create a realistic plan for their week, by showing them how much time they actually have to work each day (it's called Weekly if you're interested).
The problem we are running into however is that some companies, primarily large ones, block apps entirely from making Microsoft Graph calls to their users. What's tricky is that we send them to Office365 to grant us permissions, their company blocks the access request, and we never see those users again, so currently don't have any way of knowing what happened.
We'd like to be able to display our own message that says something like "Your company has blocked access to our application, please contact your IT department for help".
Is there any way of knowing before sending the user over to grant access that their company (the domain) even allows apps? If not is there some way to send the user back to the requesting app with some details about why the grant failed (did the user not grant permissions, did the company block access, etc.)?
Thanks for your help!
If the administrator disables the ability for users in the organization to consent then the error message will be something like:
AADSTS90093: An administrator of {tenantDisplayName} has set a policy that prevents you from granting {name of app} the permissions
it is requesting. Contact an administrator of {tenantDisplayName}, who
can grant permissions to this app on your behalf.
https://apps.dev.microsoft.com/portal/tools/errors?errorName=graph_user_unauthorized
We are using webhook to get AD user changes within our system through subscription. For this we have a App registered within Azure AD which has read access to user changes through Graph API .
As webhook subscription expires in 2.5 days we require to renew the subscription through our application. Can anyone help to let me know what will be the minimum privilege App requires on Graph to renew the webhook as we cannot give lot of access to this app .
App having the consent to ‘User.Read.All’ should be sufficient for creating & updating subscriptions on ‘users’ resource type.
https://developer.microsoft.com/en-us/graph/docs/api-reference/beta/api/subscription_update
Is that not working ?
According to the Microsoft Graph Doc here (Permissions Section): Creating a subscription requires read permission to the resource for which the app will receive notifications - so, if creating requires it, you can bet that renewing it will too. For instance, if the subscription you want to renew monitors a mailbox, the service needs to have Mail.Read permission IN ADDITION TO the Users.Read.All permission which is required to read the user accounts (for which subscription is an attribute).
Also, some other helpful hints from hours of banging my head against the wall:
1) You also need to be aware that there are two types of permission: Delegated and Application. When I first started using the MS Graph, I always got tripped up on this - so you can read up here to make sure you understand it and have applied the appropriate permissions.
2) In addition, make sure that your admin has consented AND if you change any permissions at anytime, your admin has to re-consent in order to have the new permissions take effect - i.e. when you update them to have the Mail.Read or whatever else. Also remember that when you do this, you are going to want to make sure to flush your previous auth token caches to force a refresh so your new token will have the appropriate permissions there as well.
On my site users should be able to authenticate using their twitter account. Another optional feature is, that users should be able to have tweets sent in their name on certain events.
For this I've setup the twitter application to be read & write.
My problem now is, when a user is using twitter to authenticate, then he is automatically also granting read/write permissions. But I'd like to leave it up to the user to decide at a later stage if he trusts me enough, to grant me this permission..
I can't find any setting/parameter in the api which would allow this split. The only solution I can currently see, is splitting the twitter app into two: One read-only app for authentication and one read-write app for tweeting etc.
Send users to https://api.twitter.com/oauth/authorize?oauth_token=xyz and add a parameter of oauth_access_type with a value of read. That should restrict that particular user to read only permissions.
https://groups.google.com/forum/#!topic/twitter-development-talk/1P765h9ecBk