Azure Active Directory Setup


In our previous post we covered a Developer Local SSL Setup. Next we will look at some variations, starting with Windows Azure.

About Azure Active Directory

There are 2 main reasons why a company will use Azure Active Directory and this post is focused on only the first of these:

  • Use Azure AD as a Standards Based Authorization Server
  • Use Microsoft Vendor Extensions (such as Office 365 Azure APIs)

Features we Require

We have implemented our core features already, in a Standards Based manner, so we hope they will work in Azure AD without many changes:

  • Users must be able to login to the SPA using the Implicit Flow
  • Azure AD must issue access tokens and id tokens to our SPA
  • Our SPA must be able to do Implicit Flow token validation
  • Our API must be able to Validate Access Tokens
  • Our SPA must be able to use Short Lived Access Tokens
  • Our SPA must be able to do Silent Token Renewal
  • Our UI must be able to get User Info
  • Users must be able to do a Basic Logout

Azure Sign Up

I used the Azure Free Trial offer and signed up for a developer account. You may have a more complete Company Setup, including Azure B2C features.

Portal for Azure AD Applications

The main portal is at and this is where we will register applications, since these OAuth endpoints have the best standards support.

Azure AD Authorization Server

In the main Azure Portal, identify your Tenant Id, which is a value such as the following:

The Authorization Server Base URL will then be of the following form, and we can view metadata by browsing  to /.well-known/openid-configuration:


Azure AD Standards Limitations

We will run into the following Azure AD standards limitations, and we will work around them:

  • There is no API token introspection endpoint for validating tokens
  • JWKS and UserInfo endpoints are not callable from a browser

Configure a User Profile

Under Azure Active Directory / Users and Groups, select your user and then select the below Profile option:

Next fill in the First Name and Last Name fields, and also scroll down and fill in the Email Address:

Registering our API in Azure AD

Under Azure Active Directory / App Registrations, select New Application Registration and add a BasicAPI entry:

Make a note of the following App ID URI value, which will be used as the Audience for Access Tokens later.

Registering our SPA in Azure AD

Next register a Basic SPA, and enter its URL, which will be our SPA’s OAuth Redirect URI. Note also that we will use the Application Id as our OAuth Client Id:

Next select the Manifest option and enable the Implicit Flow, by changing the default false value to true:

Finally, under All Settings / Required Permissions, select Add / Select an API, then search for our API and add delegated permissions to it:

Azure AD 2.0 Endpoints

Note that Azure AD also has some newer endpoints at the below base URL, You can use them in a similar manner, starting with the metadata URL:


If you want to try to use the newer endpoints you must register the API and SPA on a different portal at

I started with the above endpoints but was unable to get my standards based requirements working, especially in the area of OAuth scopes:

  • I wanted to use standard Open Id Connect scopes ‘openid profile email‘ so that OIDC Client functionality worked in my Javascript UI
  • I wanted the SPA to be able to send the Access Token to my (custom) API, and to implement API token validation
  • There is no User Info endpoint so I wanted to call the Microsoft Graph API to get the User Profile, then display the User Name in the UI

To achieve the above I wanted the Access Token to have a custom scope access_as_user and also a Microsoft Graph scope User.Read.

However, I did not find usage intuitive, ran into many cryptic errors and came to the conclusion that what I wanted was not supported. The older endpoints seem to have better Standards Based options for the time being.

Where Are We?

We have an Azure setup and next we will next update our Code Sample. It will work a little differently due to Azure limitations and vendor specific functionality, but we hope to meet the same Company Requirements.

Next Steps