List of all posts in the #30DaysMSGraph series

-Today’s post written by Vincent Biret

In Day 19 we assigned user permissions to an Office 365 Group (unified group) using Microsoft Graph requests.  Today we’ll introduce device code authentication and modify the .Net Core console application to utilize this authentication flow.

Why different flows?

Authentication and authorization are complex problems to solve, especially if you include the diversity of scenario, devices, networks and systems that can come into play.

Azure Active Directory, the main identity service behind Microsoft 365 and the Microsoft Graph, implements industry standards like OAuth 2.0 and Open Id Connect.

The examples of this series so far have leveraged one type of authentication:

• Confidential Client flow: this solution relies on an application registration id and secret to authenticate and authorize the application being executed. It supposes you, as a developer, administrator or more generally an organization, will be able to store securely the secret and have direct control over the execution environment. This solution is well suited when building background processes, APIs and similar solutions.

Note: The confidential client flow was also configured to use application permissions.  That means only the identity of the current application is reflected and there is no information about the current user being carried to the called APIs. While this might work to implement privileges escalation patterns and/or daemon applications it will rapidly become a constraint or even a security concern if you are building functionalities that end users access.

A future form of authentication which we will cover in a later post is the following:

• OAuth 2.0 implicit flow: this solution relies on cookies and redirections to make authentication and authorization almost transparent for the end user. As you probably guessed, cookies and redirections work well in a web browser context for front end applications but it also requires an “advanced http client” capable of many more things than only http requests.

The device code flow

The device code flow is another type of authentication flow that is designed for native applications (desktop, mobile…) which are by nature considered “insecure” (in the sense that you do not have direct control over the execution context). Here is the basic process:

1. The application displays a link from the authentication provider (ex. https://microsoft.com/devicelogin for AAD, https://spotify.com/pair for Spotify, https://youtube.com/activate for YouTube, …) and a unique code.
2. The user opens a browser, navigates to the link and enters the code.
3. The authentication provider helps the user selecting the desired account, consenting to the application.
4. The user closes the browser window.
5. The authentication provider notifies your application with an authentication context ready to be used

The authentication flow was designed with the following key considerations in mind:

• Browsers often are already authenticated by the authentication provider.
• Users typically prefer not to type credentials again and again in a small and limited browser frame via an application.
• Some execution contexts can’t display browser frames (special editions of Windows, old version of Android/iOS…).
• The user can use a different device to run the authentication sequence if he or she prefers.

Try it out

With today’s article we prepared another sample to walk you through implementing a device code flow in a console application.  Navigate to the dotnetcore-console-sample repo.  Do one (or both) of the following:

Day 20 repo link

1. Clone the repo and configure the project in the Day 20 sub-folder.
2. Follow the instructions in Day 20 sub-folder to build the project from scratch yourself.

If you run into any issues while building or configuring the project please create a new Issue on the repo.

Join us tomorrow as we interact with Planner using the device code authentication flow covered today in Day 21.