Lately you might you might notice I’ve been on a bit of a kick with Azure AD in some recent blog posts. In this post I want to talk about something called OpenID Connect, a technology that Microsoft’s Azure AD supports and adds some extra sauce to the authentication story in your custom apps.
Check out my Pluralsight course Office 365 APIs - Overview, Authentication and the Discovery Service, specifically modules 3 & 4, that go deep into the authentication process.
First, Azure AD 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 Azure AD supports, the user will first be redirected to Azure AD to login. This first stop is called the authorization endpoint as it is where you plug your email and password in to authenticate with Azure AD. When you do this you typically request an authorization code which I is a special string that can then be used on Azure AD’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 Azure AD 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 login 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 Azure AD 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 Azure AD 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: Azure AD & 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.comments powered by Disqus