all Technical posts

Passwordless last-mile security with Azure API Management

One of the main reasons to introduce an API gateway is to establish uniform security controls on top of your API infrastructure. The focus is mostly on the frontdoor security. However, securing the last mile should also be high on your priority list. Thanks to recent integrations of Azure API Management with Azure Active Directory, there's now the capability to secure that last mile without passwords, keys or certificates. Let's have a look!

Managed Service Identity

The magic is performed by Managed Service Identity (MSI), which is a feature of Azure Active Directory (AAD). Instead of creating an explicit service principal, you can enable MSI on your Azure API Management instance. This gives a unique AAD identity to your APIM instance. You can use this identity to access Azure services that support AAD authentication, such as Blob Storage, SQL Database, Azure Resource Manager, etc… The great thing is that you don’t need to store a client id & secret, as everything is managed by the Azure runtime itself.

The MSI authentication policy

You can establish a passwordless backdoor security, by using the – recently addedAuthenticate with managed identity policy.

<authentication-managed-identity resource=”resource” output-token-variable-name=”token-variable” ignore-error=”true|false”/>

The documentation is quite clear on the usage of the policy. It’s important to understand that you should adapt the resource, depending on the service you need to authenticate to. Some common examples are:

  • Azure Resource Manager: https://management.azure.com/
  • Azure Key Vault: https://vault.azure.net
  • Azure Service Bus: https://servicebus.azure.net/
  • Azure Blob Storage: https://storage.azure.com/
  • Azure SQL: https://database.windows.net/

In case you want to authenticate against a web API, you can also provide the App ID as the resource. This approach will be used in one of my follow up posts.

Under the hood, APIM is requesting an OAuth2 access token, using the client credentials flow. This access token (JWT) is added as a Bearer token inside the authorization HTTP header.  Pretty similar to this complex policy that had to be used in the past.

Use cases

You can use this authentication policy for all backend services that support Azure AD authentication. A complete and up-to-date list of AAD-supported services can be found here. Some use cases that really benefited from this authentication policy are explained in more depth over here:

Conclusion

Very useful addition to our toolbox. I was surprised to see that there was not a lot of noise about this Managed Service Identity support. It’s really a hidden gem and extremely powerful. No more passwords to maintain, no more keys to rotate, no more certificates that might expire…

Happy learning!
Toon

Subscribe to our RSS feed

Let's talk, what's your first name?

Press Enter

Press Enter

Hi , what's on your mind?

Press Enter

Great! Leave your email and we'll be in touch
Submit
Thanks, we’ll be in touch soon!