Azure Daemon Application using EWS with OAuth

We've got a fair few samples for implementing a daemon application (one that requires no user interaction) using OAuth against Azure endpoints, but I couldn't find a specific example for EWS.  This guide describes how to set up an application (register it in Azure) and then obtain the correct permissions to be able to run continuously with no further user input.

Part 1: Register the application in Azure

1. Sign into the Azure portal, and open the Azure Active Directory tab.
2. Select App registrations.
3. Click New application registration.
4. Create a new Web app/API:
   
5. Once created, click on the application (from the App registrations node):
   
6. Click Settings, then Required permissions, and then click Add:
   
7. Select Office 365 Exchange Online (Microsoft.Exchange), and then tick Access mailboxes as the signed-in user via Exchange Web Services:
   
8. Click Save, then Done to apply the new permission.
9. The next step depends upon whether you are using certificate authentication or secret key.
   1. Set up certificate authentication:
      1. Generate your certificate (not that this article does not cover that process), with both private and public key.  Suitable file formats are .cer, .pem or .crt.
      2. Upload the public key:
         
   2. Create a secret key:
      1. Enter a key description, then a duration, and click Save:
         
      2. Copy the generated secret key (it will be displayed once only) for use in your application.
10. The application registration is now complete.

Part 2: Acquire the delegate permission, and obtain access/refresh token

This part refers to the sample application, which can be used as a code sample.  This part of the set-up procedure requires user interaction, and so is part of the "install" process.  The sample application demonstrates several important techniques:

• Implementing a token cache.  By default, for a Web API, the ADAL libraries do not cache tokens. However, a token cache can be implemented using the TokenCache class. When this cache is set up, ADAL will automatically check for existing tokens first and use them if found. This is crucial to prevent a service application from needing to prompt the user. The token cache must persist across application/service restarts (so is saved to disk, in this example).
• Obtaining an access token silently. This is another crucial feature for a daemon application. Once the first authorisation has been granted by the user (which requires user interaction), future authorisation requests should not prompt at all.
• Renewing the access token when it expires. Access tokens are only valid for an hour, so must be renewed once they time out. This must also occur silently. Refresh tokens are valid for 90 days, and need to be renewed within 90 days or they are invalidated. A new refresh token is issued with each access token refresh (so an application can keep renewing a token indefinitely, unless the refresh token is revoked).

1. Start the EWSDaemonOAuthSample application and fill in the information for the application:
   
2. Once all the application information is filled in, it is time to acquire the token so that the application can access the mailbox. Note that at this point, we don’t need to specify which mailbox we are accessing, that will be defined by the authenticating user (it will be their mailbox).
   Click Acquire token, and then log in and grant the application permission to access the mailbox (note that it should be the credentials of the service account being used to log-in).
3. Once successfully logged in, the log will show that a token was acquired, and the time of expiry of the access token (which will usually be in one hour). The mailbox identity is read from the Id of the token, and the GUID stored (in the Mailbox to access box). The SMTP address of the mailbox can also be read (this is shown as a tooltip of the Mailbox to access box).
4. Now that the token has been retrieved by the application, it can be used to access the mailbox (using EWS) until the refresh token is invalidated (which will happen if it isn’t used for 90 days, or is manually revoked). If the refresh token is invalidated, then the whole initialisation process (i.e. from step 1 of this section) would need to be repeated.

Part 3: Running as a daemon

Now that parts 1 and 2 are complete, the application has all the information it needs to run indefinitely without any user interaction. This can be manually demonstrated by using the Get inbox count button (which makes an EWS call to the mailbox to retrieve the number of items in the Inbox).
When you click Get inbox count, the application checks if it has a token and whether it is valid (i.e. the access token hasn’t expired). If the application does already have a valid token, it simply uses it to make the EWS call.
If the application hasn’t got a valid token, then it uses the refresh token to acquire one, and can then successfully make the EWS call (without user interaction).
Because the application caches the tokens (by overriding the TokenCache class of ADAL), it can continue to run without user interaction even if it is closed and reopened. On opening, it simply restores the cached tokens so that ADAL can access them (which means no user interaction is needed).

The sample application, which includes full source code, can be downloaded from here.