OAuth 2.0 for Microsoft Accounts (installed applications running HttpListener)

This is the the modern version of the tutorial. It supports both .NET Framework and .NET Core, does not use DotNetOpenAuth (which is not available for .NET Core), and demonstrates how your app can start a local web server (HttpListener) for a short interval of time to process authorization code from Microsoft server. This spares the end users from manual copy-pasting authorization codes from the browser to your app.

In this guide, we'll configure a .NET Core application which can access Outlook.com, Hotmail.com or Live.com account of a user via IMAP and SMTP without knowing the password of this user. The app has no .NET Core specific code so you can convert it into a .NET Framework 4.5+ app if needed.

UWP/UAP notes
Register Microsoft project
Configure application in Visual Studio
Run application in Visual Studio

UWP/UAP notes

Running HttpListener is not supported in Universal Windows apps (UWP allows listening on localhost for debugging purposes only, productions apps are not allowed to do this). For UWP, you need to register a URL schema handler and make the browser to call your application when being redirected from the OAuth provider web site. Refer to OAuth 2.0 for Universal Windows apps guide for details.

Register Microsoft project

Create an application in Application Registration Portal. You may need to create an account there first.

For OAuth 2.0, create a Live SDK application. Click Add an app in Live SDK applications section.

On the next screen, click Add Platform and select Web. Then add a Redirect URL, such as http://localhost:49217/signin-microsoft, then save changes. The port number can be different, it's not actually required to run the local web server on this exact port. Also, it's not a problem that it's http and not https. The network traffic won't leave the local system, it will be the browser accessing the local resource.

Application ID (Client ID) and password (application secret) are there as well. You'll need them both for your application.

Make sure to add the required permissions (scopes) as well:

Microsoft is changing things there often. Sometimes, Live SDK app simply doesn't work and you may try creating a Converged application. Also, you may be asked to use Azure portal instead of apps.dev.microsoft.com site. At the moment of writing, Azure portal was not stable enough for that.

Configure application in Visual Studio

Open My Documents\MailBee.NET Objects\Samples\WinForms.NET Core 2.0\C#\MicrosoftRegularAccounts sample project. It runs on .NET Core platform but can be easily ported to .NET Framework with no code changes.

In Program.cs, set ClientId and ClientSecret to the values obtained from apps.dev.microsoft.com portal, and set MailBee.Global.LicenseKey to your MailBee.NET Objects license key.

Run application in Visual Studio

Now build and run the application. How it works:

Checks if token.json file exists in the current folder. If yes, it reads the stored OAuth token from there.
If token.json is not there, the app starts HttpListener (a local web server) on any unoccupied local port, then opens the browser which connects to Microsoft OAuth server and displays the consent screen of your application registered on apps.dev.microsoft.com portal. If the user gives consent, the Microsoft server causes the browser to redirect to the localhost. The redirect URL contains the authorization code.
The HttpListener gets the incoming request (which is coming from the browser) and gets the authorization code from the URL. Then we shut the local server down.
Authorization code is used to get the access and refresh tokens. We store them in token.json.
The app then uses the access token for multiple purposes:
- To get e-mail address and display name of the user.
- To build XOAUTH2 key which we then use to get the inbox of Microsoft account the user authenticated with or to send an email to that account. useImap bool variable in the code controls whether the action to perform will be "checking mail" or "sending mail".
On further runs, when token.json is there, we also check if the access token is still valid (it expires in an hour). If it's about to expire soon, we refresh it using the refresh token. There is expiresAtUtc = expiresAtUtc.AddMinutes(-59); line which you can uncomment to test access token expiration without the need to wait for an hour (for debugging purposes).

Send feedback to AfterLogic