This blog will contain information about MSAL, ADAL, OAuth and some tokens. I will also show you how you could use MSAL authentication with PowerShell to change the Device Category in Intune

I will divide this blog into multiple parts

  1. Information about ADAL and MSAL
  2. Information about the Token
  3. Taking a good look at the access token
  4. Comparing the ADAL and MSAL methods
  5. Using MSAL to change the device category in Intune

MSAL? ADAL? What do they mean?

MSAL = Microsoft Authentication Library

ADAL = Azure Active Directory Authentication Library

I guess the name just says it all, both of them are methods to authenticate to Graph. When we are authenticating against Graph we need to show some kind of proof we are allowed to access the graph data in our Microsoft 365 Tenant.

We can do this by:

*Interactive / Delegated Authentication Username/Password Prompt

* Non-Interactive / Programmatic / Application Authentication –> like an example: Authentication by providing a secret from an app registration

As mentioned before with both of them you can authenticate to Graph. There are little differences between these two authentication flows because both of them are sending an HTTP request to the OAuth Endpoint.

OAuth (Open Authorization) 2.0 it’s not a protocol but it defines a delegation protocol. It’s the open standard for authorization and specifies how tokens are transferred. This framework is used as a way to grant a user limited access to its protected resources. Designed to work specifically with Hypertext Transfer Protocol (HTTP)

One big important difference between ADAL and MSAL to keep in mind, ADAL integrates with the Azure AD for developers (v1.0) endpoint, where MSAL integrates with the Microsoft identity platform v2 Endpoint.


And not to forget the V2 endpoint gives you a converged experience, it allows you to enter your Office 365 (Azure AD) accounts or your personal Microsoft Accounts ( The v1 Adal Endpoint only allows you to authenticate with your Azure Ad account.

But I guess we are done speaking about ADAL, because Starting June 30th, 2022, support will end for ADAL and Azure AD Graph and no longer technical support or security updates are provided. So please don’t use ADAL anymore for your authentication!

Update your applications to use Microsoft Authentication Library and Microsoft Graph API – Microsoft Tech Community

Even the new Azure Ad Connect version is going to use MSAL instead of ADAL, so the only thing left to talk about is MSAL. MSAL enables users to acquire tokens from the Microsoft identity platform in order to authenticate and access secured web APIs, like Microsoft Graph.

Like I showed you earlier tokens are needed to communicate with Graph. Tokens are a random string generated by the authorization server and are issued when the client requests them.

It’s important to beware of the fact that there are 3 types of tokens

*Identity (ID) Token I am who I say I am Authentication

Information in ID Tokens allows the client to verify that a user is, who he/she claims to be. ID tokens are intended to be understood by third-party applications. ID tokens should not be used for authorization purposes.

Here is a good example, how an ID Token looks like

*Access Token I have the proper permissions to do what I need to do!

This token is the most important one because this token will allow the data to be accessed by a third-party application. Luckily it has a limited lifetime, this is defined by the authorization server.

And of course, just like with the ID token, here is a good example, how an Access Token looks like

*Refresh Tokens You can think of it like the old school Ticket Granting Ticket in an on-premise environment. This token is used to acquire new access tokens. This refresh token is only valid for the same user (Identity) who requested it and for the same application it wants to open (Authorization)

A big difference with an access token, refresh tokens are long-lived while access tokens are short-lived.

A quick Token summary

-ID tokens are carrying identity information that is encoded in the JWT token itself

-Access tokens are used to get access to specific resources by using them as bearer tokens

-Refresh tokens only exist to retrieve more access tokens

Like mentioned earlier when we want to use the Microsoft Graph API we need to show it our access token.

An access token has two important roles:

1: It will prove authentication (proof of identity)

2:It will prove authorization (permissions).

Please beware that each request created needs to submit a request header that contains the access token.

I guess you probably noticed the name: “Bearer” in the picture above or maybe because I marked it?

The Bearer (JSON WEB) Token is created for you by the Authentication server. When a user is authenticating with the client/application, the authentication server generates a Token. Bearer Tokens are the main type of access token used with OAuth 2.0.

A Bearer token basically says “Give the bearer of this token access without further identification”. Let’s take a look at what’s inside this bearer access token.

In the example below I used the module jwt-details (install-module -name jwtdetails) to get some details

I told you I was done speaking about ADAL, but I guess I still need to show the difference between the old school ADAL script to acquire the access token and the new modern and supported method


$clientId = “d1ddf0e4-d672-4dae-b554-9d5bdfd93547”

$redirectUri = “urn:ietf:wg:oauth:2.0:oob”

$resourceURI = “”

$authority = “”

$AadModule = Import-Module -Name AzureAD -ErrorAction Stop -PassThru

$adal = Join-Path $AadModule.ModuleBase “Microsoft.IdentityModel.Clients.ActiveDirectory.dll”

$adalforms = Join-Path $AadModule.ModuleBase “Microsoft.IdentityModel.Clients.ActiveDirectory.Platform.dll”

[System.Reflection.Assembly]::LoadFrom($adal) | Out-Null

[System.Reflection.Assembly]::LoadFrom($adalforms) | Out-Null

$authContext = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.AuthenticationContext” -ArgumentList $authority

$platformParameters = New-Object “Microsoft.IdentityModel.Clients.ActiveDirectory.PlatformParameters” -ArgumentList “Always”

$authResult = $authContext.AcquireTokenAsync($resourceURI, $ClientID, $RedirectUri, $platformParameters)

$accessToken = $authResult.result.AccessToken


#Install-Module -Name MSAL.PS -force

$authResult = Get-MsalToken -ClientId ‘d1ddf0e4-d672-4dae-b554-9d5bdfd93547’ -Scopes ‘’

$accesstoken = $authresult.accesstoken

I guess I don’t have to tell you which method I prefer? Just with 2 simple lines of text, you can get your access token!

Now let’s see MSAL in action. We are going to change the device category in Intune with PowerShell.

First, we need to fetch the right id corresponding to the right device. So let’s fire up a PowerShell session and connect to Graph


Before we begin I will show you how the existing category is configured in Intune and with PowerShell



Get-IntuneManagedDevice | Get-MSGraphAllPages

If you want to export all devices, you can export them to a csv

Get-IntuneManagedDevice | Get-MSGraphAllPages | Select ID, DeviceName |Export-Csv -Path “c:exportdevices.csv”

Let’s take a look at the csv and retrieve the device id we need. In my example I’m going to use the id corresponding to desktop-57rfgtn

Now we have the device id, we still need the device categories. You can retrieve them by entering this command: Get-DeviceManagement_DeviceCategories

So let’s remember these Device Categories

2b259feb-0bca-48ed-9dbb-1b87c627521b = personal owned devices

377fdc15-6f3c-4165-b5b3-98261a8243da = company owned devices

Let’s create the variables before we continue

$DeviceID = “(‘bd93f0f3-fe56-43fe-823c-c41a99b4737f’)”

$DeviceCategory = ‘3deae90a-1692-446a-97e0-46ee2ce673ab’

$authResult = Get-MsalToken -ClientId ‘d1ddf0e4-d672-4dae-b554-9d5bdfd93547’ -Scopes ‘’

$accesstoken = $authresult.accesstoken

$body = @”



$apiurl = “$deviceid/deviceCategory/`$ref”

$Data = Invoke-RestMethod -Headers @{Authorization = “Bearer $($accesstoken)”} -Uri $apiUrl -Body $body -Method Put -ContentType ‘application/json’

Looking at the script above, I guess after reading this blog we understand why we need the specify the authorization by specifying the bearer access token

I hope this blog showed you why you need to use MSAL and what and how you can use the tokens!

Update your applications to use Microsoft Authentication Library and Microsoft Graph API as ADAL will no longer be supported after 2022.

But beware, be very aware! If you have existing apps that rely on SAML or WS-Federation and you need to update/migrate them you can’t use the Microsoft identity platform! The Microsoft platform only supports OpenID Connect and OAuth 2.0.

But if you are building a new application and you need to support personal Microsoft Accounts please use the Microsoft Identity Platform

Serious Face GIF | Gfycat

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.