代表用户从守护程序订阅Office 365流通知

Question

From windows my service I need to be able to subscribe to event notifications in Office 365 meeting room calendars in my tenant. Because of security reasons, there is no way to use push notifications, thus using streaming notifications is only plausible (or polling, but that is the last resort). But as described on that page, the scope of the subscription can not be changed from current user 'me'. Thus I can not rely on application role assignments (which I can already use to poll the calendars of interest with Graph API). Of course, I have user credentials for those meeting room accounts - but basic authentication is not supported for a while.

The challenge: my service needs to act on behalf of the meeting room user(s) to subscribe and to receive notifications but from a daemon service, without user interaction. Practically it will have a management UI, but after adding a meeting room the admin will leave that UI and the service will need to work alone, renew the subscription, re-establish stream in case of server restart.

I suppose, that the device profile is one option.

What approach/flow do you suggest?

Answer 1

I would say you have two options:

• You can use the OAuth client credentials grant supported by Azure AD, which allows a service to get access tokens by simply presenting its client ID & client secret (no user creds required). In order to grant this service the authorization to access the calendar of the meeting room, you would have to get the administrator of the tenant to consent to your service one time. The instructions for getting this consent & getting tokens are described in this article . You should be able to use the calendars.read application permission to subscribe to the notifications (though I haven't tried it myself).
• The other approach would be to have someone log into your service's management UI with the credentials of the meeting room, and grant consent for the service to access its calendar, using the normal OAuth authorization code grant and the calendars.read scope. Yes, this approach requires user interaction in the management console one time. But, your service will receive back a refresh token that will be long-lived, and can be used to acquire new access tokens without further user interaction. This refresh token is non-expiring by default, which may make it viable for your scenario. The refresh tokens lifetime can however be shortened by a tenant administrator, or can be revoked if someone intentionally disables/deletes your service's access.

The device profile flow is pretty much the second option. It still requires the user to sign-in, and the service still acts on behalf of the user. The only difference is how the user enters their credentials. It sounds like for your purposes, the regular OAuth authorization code flow will be more appropriate than the device profile flow (which is meant mostly for limited input devices).