Lately you might you might notice I’ve been on a bit of a kick with Microsoft Entra ID in some recent blog posts. In this post I want to talk about something called OpenID Connect, a technology that Microsoft’s Microsoft Entra ID supports and adds some extra sauce to the authentication story in your custom apps.
First, Microsoft Entra ID is build on top of the OAuth2 protocol which is defines different methods of authentication that ultimately end with you obtaining an access token that’s used to authenticate against a given resource. In a few of the different OAuth2 authentication flows that Microsoft Entra ID supports, the user will first be redirected to Microsoft Entra ID to sign in. This first stop is called the authorization endpoint as it is where you plug your email and password in to authenticate with Microsoft Entra ID. When you do this you typically request an authorization code which I is a special string that can then be used on Microsoft Entra ID’s token endpoint to obtain an access token. The authorization code is usually given to the custom application by the user so the app can go get necessary access tokens that it needs when talking to different resources (because each access token is only good for one resource… in other words, an access token for the Microsoft Entra ID Graph API is not valid for the SharePoint Online REST API).
Here’s what the URL looks like when you make a request to the authorization endpoint for an authorization code… Notice the request for a code… that’s tells the endpoint “when the user authenticates, send them an authorization code proving they just logged in":
Now, when you sign in and get the authorization code you don’t get anything else… just that encoded string. But you just authenticated… Wouldn’t it be nice to tell your custom app who you are without having to request it from the Graph API or what your unique ID is?
This is where OpenID Connect comes into play. This is an extra layer on top of OAuth2 that is an open standard… and Microsoft Entra ID supports it! What happens is that when you go to the authorization endpoint, you can request not just the authorization coe, but also an id_token. This token contains information about the user like their name (both full & broken up into given & surname), unique ID, the Microsoft Entra ID tenant they belong to, etc. best of all you get this in the same response as when the user authenticates to get the authorization code.
Here’s what the same request from above looks like but this time I’m asking for an id_token as well:
So what does the token look like? It’s just a standard JWT token so you can use a tool like this to parse it to see the contents. Here’s what mine looks like:
Neat huh? Thankfully Microsoft has also provided NuGet packages to make it easy to parse these out and request them. Check out my blog post from s few weeks ago that’s demonstrates this: Microsoft Entra ID & ASP.NET MVC - Walkthrough Implementing ADAL & OWIN.
Interested in learning more? Check out my course Pluralsight Office 365 APIs - Overview, Authentication and the Discovery Service, specifically modules 3 & 4, that go deep and demonstrate how you can acquire an id token using OpenID Connect.