This is the fourth and last part in the series about securing your Logic Apps. In the previous post, I've described how to secure your logic app using Azure Active Directory. In this post, I'm going to show you how you can leverage the Validate JWT Access Restriction Policy for your Logic App inside the API Management Service.
The Validate JWT policy enforces existence and validity of a JSON Web Token (JWT) extracted from either a specified HTTP Header or a specified query parameter. It is based on oAuth 2.0, which is basically the standard nowadays for API's.
, so we can use this authentication method as an example for this post as well.
For this article, I've used the Logic App which is created in the
of this series, the API Management service which is created in the
and the Logic App uses Azure Active Directory for authentication, which is described step-by-step in my
Validate JWT Policy
In this example, we are going to add a Validate JWT policy which checks the audience inside the JWT token. When the audience is correct, then the call is made to Azure Active Directory to authenticate the user.
Retrieve JWT Token
The first step is to retrieve the JWT token when a call is made to the Logic App which is already registered inside Azure Active Directory. This way we can investigate what is inside of the JWT token and use certain claims from the token in our policy. This way we can reject calls that don't contain a certain claim right at the door without doing a request to Azure AD. For this example, we are going to use the "Audience" claim. We can obtain the token using Fiddler and the API Management Developer portal.
Open the Developer portal by navigating to the Azure API Management Service inside the Azure Portal. In there, click
in the left menu.
Click on the
Then, click APIs in the top menu, click
and click the
Switch back to the API Management Portal where the test page for the API is opened now. Scroll down a bit and under
, and from the dropdown select the OAuth 2.0 server which is configured in the
A login window pops up. Log in with your Azure AD credentials and switch back to Fiddler. Select the GET request to the Azure AD API from fiddler which contains the following URL: "/oauth2/authorizationcode/acquiretoken". Open the inspectors view and copy the Access Token which is returned from Azure AD after login in using your Azure AD credentials.
JWT Token Details
We now have obtained the Access Token and to look into it in further detail, we can use a site called "JWT" (
). Click the
menu item in the top menu and past the Access token inside the
The token gets decoded and on the right side you can see all the claims that are inside of it. Like mentioned before, we are going to use the audience for this example, which is "
" in my case.
If you want more information about the JWT token and all the properties inside of it, you can refer to the home page of the
Setting up the Validate JWT Token policy
Switch back to the Azure API Management Service inside the Azure Portal, and again, click
in the left menu.
Select the SecureLogicApp and click on the arrow next to Inbound Processing. Select
at the right side of the screen.
Add the below code inside the
tag to check the audience inside the JWT token from the caller of the endpoint. If the audience does not match, the API Management Service will simply block the request.
To test this policy, switch over to the Developer Portal of the API Management Service. Under the Authorization section, reset the OAuth2 Server to
, like show in the below image.
button and you will get a 401 Unauthorized response with the response message which is specified in the policy:
This is the last Access Restriction Policy in this series, that you can use to secure your Logic App using API Management. The other ones are described in the
of this series.
The JWT Validate Policy is, in my opinion, a very effective way of securing your API. Based on certain claims, or even certain permissions, you can block your API right at the door even without making a call to your authentication provider to check if the caller has permissions to access the API. This reduces unnecessary time and traffic, which will result in a better experience for the requestor of the API.