
Flutter — Microsoft API Management secured with AD — Secure Gateway
This is the third part of a series to show how to secure your Flutter applications using Microsoft technologies:
- Web API — Setting up your Web API with Visual Studio.
- APIM Service — Creating an API management service in Azure.
- Secure Gateway — Securing requests through the API gateway.
- MSAL — Authenticating your Flutter app on iOS.
- MSAL — Authenticating your Flutter app on Android.
- MSAL — Authenticating your Flutter app on the Web.
- Hosted API — Hosting your Web API’s in Azure.
- Secure Hosted API — Secure requests with the APIM Gateway
This article shows you how to secure your new API via the gateway with Azure Active Directory and then authenticate and access the secured API with Postman.
Register the API application in Azure
Go to

and under Manage select

and register the new application:

Now we need to configure the registration…
Add Web Platform
Select the new registration and under Manage click on

then ‘_Add a platform_’ under platform configurations:


Add the recipes API
Select

then ‘_Add a scope_’ under manage, accept the generated Application ID URI and click

and complete the scope details:

Add permissions to the use the Recipes API
Select

clicking ‘_Add a permission_’, selecting the ‘_My APIs_’ tab and selecting the registered App

then click the Recipe Management checkbox to select the new scope:

and add the permission.
Add an application secret



Copy and save the secret, you only get one chance to do this, if you lose it then recreate the secret.

Set the token version
In

set the access token version:

And

the changes.
Secure requests to the recipes API with a gateway policy to validate a JWT token
Go to the new registered App Overview under Azure Active Directory and make a note of the ClientID

Then click on the

and copy the OpenID Connect metadata document URI.
In your API Management service select APIs, Recipes, All operations and click on </> under Inbound processing to edit the policy as below, substituting
<policies>
<inbound>
<base />
<set-backend-service backend-id="LocalRecipesAPI" />
<validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized. Access token is missing or invalid.">
<openid-config url="https://login.microsoftonline.com/<TenantID>/v2.0/.well-known/openid-configuration" />
<required-claims>
<claim name="aud" match="any">
<value><RegisteredApp-ClientID></value>
</claim>
</required-claims>
</validate-jwt>
</inbound>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
<backend>
<forward-request timeout="10" />
</backend>
</policies>
Now try to retrieve the recipes in the browser and we should see a 401 unauthorised response.


Access the secured API with Postman
Now we are going to switch to use Postman as our client to make it easier to make OAuth2 secured requests.
Download and install and run the Postman client.
Add a new Get request to the Postman client that uses the locally hosted gateway:

Click on the request settings and turn off SSL certificate verification:

Click Send to test it works, you should get a 401 back:

Next select the Authorisation tab and complete it with the following values:


You can copy all the values from your application registration, the overview page has the Client ID, and a link to the endpoints to complete the Auth and Access token URLs, make sure you use the v2 endpoints.
The client secret is the one you noted in the previous step, if lost then create a new secret.
The scope can be copied from the Expose an API section.
Once completed click on

and follow along in your browser, you will need to enable pop-ups if suppressed by the browser.


When the token is retrieved click

and retry the request.
If you have issue getting a token use Fiddler and the logs in the Docker Gateway container to debug your issues.
If you have issues with the token being invalid you can decode and check its contents at jwt.io and the reason it was rejected in the Docker Gateway container logs.
Ta Da



BackBurner
We only authenticate against the Azure AD, the registered Azure App uses delegated permissions of the Authenticated user, this will need to be more granular in the real world using roles and attributes.
More details will be added in a future post once the application requires more granular access e.g. roles, user and administrator.
XP
The API is secured at the edge (Gateway) we can still use swagger and the localhost API endpoints, locally unsecured and don’t need to add any code to the Web API project.
Make sure that you use the v2 endpoints

If you use the V1 endpoints your are likely to encounter the following issues accessing the API through the gateway.


