Securing Azure Functions with API Management and IdentityServer4.

A step-by-step guide.

Published in

Microsoft Azure

6 min readApr 15, 2020

Integration of a serverless API with an existing infrastructure and an identity provider is a cost-effective step towards migrating to Azure Functions while keeping old services up and running. At least in my experience :).

So this is the sequel to my previous article about IdentityServer4 and Azure Functions HTTP request authentication with C#. While the topic seems to be appropriately covered by documentation and StackOverflow, feedback from this article proved otherwise, and the time has come for a guide on Azure API Management(APIM) Consumption(Serverless) tier integration with IdentityServer4 and Functions.

TL;DR; I will explain how to create and configure Azure API Management Consumption tier to validate a bearer token issued by IdentityServer4, how to integrate it with Functions and provide a HTTP request latency comparison with other authentication options.

The key components of this article are the official demo instance of IdentityServer4, Azure CLI infrastructure script, configuration via Azure Portal, APIM jwt validation policy, Postman client to test the results, and a good mood :).

Introduction.

There are several Azure App Service platform authentication features like Active Directory, Microsoft ID, Facebook, Google, Twitter. And a Function level authentication provides Anonymous, Function, and Admin options.

So for this article, I’m going to use the Function(code) authentication option and integration with Azure API Management, which is the better combo in terms of security and reliability.

Azure API Management Consumption tier seems like a natural choice to go with Functions in terms of cost and scalability, but it has limitations too, notably no caching.

But before we start, let’s look at the HTTP response time comparison table. The anonymous auth column represents a custom solution from my previous article with anonymous access to a function and token validation in C#. Azure API Management Consumption plan latency (16–25s) is a significant improvement over the previous year(25–50s).

+---------------+----------------+--------------------------------+
|               | Function call  | Direct Function call           |
|               |      via       +--------------+-----------------+
|               | API Management | Code auth    | Anonymous auth  |
+---------------+----------------+--------------+-----------------+
| Cold start    | ~20.22 s       | ~3.5s        | ~3.7s           |
+---------------+----------------+--------------+-----------------+
| Warm instance | ~139 ms        | ~84 ms       | ~98 ms          |
+---------------+----------------+--------------+-----------------+

Solution.

The action plan is pretty simple.

Deploy infrastructure via Azure CLI script.
Create a new Function via Azure Portal in the deployed Function App.
Connect the Function app with API Management instance.
Open registered API and change configured prefix to “test.”
Create a new Product via API Management Portal interface.
Open a new Product, select Policies and add provided XML policy and assign registered API. You can also assign a policy for the entire APIM, selected API, or particular request.
Register a new OIDC provider in API Management.
Check if the IdentityServer4 demo instance is live and get m2m client info.
Create a new HTTP GET request in Postman with parameters and an access token from IdentityServer4 instance.

Unfortunately, some steps require Azure Portal interactions, Azure CLI for API Management in preview and contain only several commands. While PowerShell contains a lot of commands for proper CI/CD automation and deployment,there are extra steps for the integration of the Function app with APIM. If you need a full Powershell script, please ping me back and I will publish it.

Let’s deploy the infrastructure via Azure CLI script.

BTW, Application Insights instance will be created automatically for a function app without any infrastructure code, it’s something new - wow.

Azure CLI for infrastructure. https://gist.github.com/staslebedenko/e41956d4aabd37aa7cfa021e4d89ebff

The next step is to create a new HTTP Function via Azure Portal in the deployed Function App. Alternatively, you can create a Function app from Visual Studio and deploy it online via a publishing profile or a Git repository.

Open a new Function app and create a new function with the name “call.”

Then its time to connect the Function app to API management instance via corresponding interface option. If you select this option in the old platform configuration UI, it will redirect to the new UI.

You have to select deployed APIM instance, enable Application Insights, and set API prefix to “test” (it can be changed later).

There is an additional configuration step where you can assign an API prefix for API.

Let’s continue and add a new Product to APIM instance and select the registered API.

Then we need to edit the newly created Product and add a new JWT validation policy provided below.

APIM policies allow advanced scenarios with checking for customer claims and transforming requests according to your needs.

Inbound JWT validation policy. https://gist.github.com/staslebedenko/ef9d5839dbe8e5fe7bf06bfd0717a1b8

Register a new OpenID Connect server with the following parameters. Access token URL is for further Postman configuration.

client id: m2m
client secret: secret
Metadata endpoint: 
https://demo.identityserver.io/.well-known/openid-configuration
Access token url:
https://demo.identityserver.io/connect/token

Registration of OpenID Connect provider.

Be aware that APIM is connecting to the Function application with a Host Key that is stored in the “Named values” configuration of APIM and the “Management” configuration of a Function App Service. You can recycle it later on via configuration or remove it to disconnect functions from APIM.

Host key registered in APIM named values and Function configuration.

Testing API with Postman.

The final step is to test infrastructure with an HTTP Get request via Postman.

Postman provides straightforward UI with the big orange button “Create request,” then you have to set request type to GET and paste the following sample URL.

https://identity-demo.azure-api.net/test/call

Then configure settings by adding the parameter “name” with the value “User.”

Then switch to the Auth tab, select OAuth 2.0, click the orange button “Get new access token,” enter configuration information, click “Request token,” and then click “Use token.”

This token will have a lifetime of 60 minutes and can be checked via jwt.io.

Postman Auth tab configuration and token request.

The last step is to click the “Send” button and receive the response “Hello, User.”

The summary.

Usage of API facade improves the reliability and security of a hosted serverless application, but at the cost of additional latency. But the latter can be addressed with external cache, and the rich functionality of APIM will be handy. In the case of enterprise usage, the APIM Consumption tier can be pre-warmed during working hours.

APIM is an excellent service that includes rich functionality and tons of options, namely Portal, API versioning, request transformation, etc. But the goal of this tutorial was to solve a particular authentication scenario. I highly recommend diving deeper into the APIM topic.

BTW, it seems that Microsoft is working on additional OIDC/OAuth authentication options(link), but in the meantime, this guide can help.

PS. Let me know via twitter if there is a need for APIM configuration Powershell script and further materials on APIM production use cases.

That’s it, thanks for reading. Cheers!