Securing an API using OAuth 2.0 in Azure API Management Part 4

Posted On December 10, 2020 by Rushank Karekar Posted in

Part 4: Testing using Developer Portal and JWT Policy Configuration

Introduction

Configuring OAuth 2.0 for your APIs hosted in Azure API Management adds an extra layer of security and prevents unauthorized access. This is a very important configuration form Security point of view for your Endpoints and is provided out of the box by Azure. This is the second part of a series of Blogs on Securing your API using OAuth 2.0 in Azure API Management. Please go through all the parts to find easy and detailed steps that will help you configure the OAuth 2.0 Authentication.

Successfully call the API from the developer portal

Note: This section is new to the Developer Portal and is under changes. So sometimes it might give Un-Authorized or CORS error. Hopefully, this bug gets resolved in future soon.

Now that the OAuth 2.0 user authorization is enabled on your API, the Developer Console will obtain an access token on behalf of the user, before calling the API.

Browse to any operation under the API in the developer portal and select Try it. This brings you to the Developer Console.

Note a new item in the Authorization section, corresponding to the authorization server you just added. Select Authorization code from the authorization drop-down list, and you are prompted to sign in to the Azure AD tenant. If you are already signed in with the account, you might not be prompted.

After successful sign-in, an Authorization header is added to the request, with an access token from Azure AD.
Sign in to the portal

Click on accept

Note an Authorization header is added to the request

The following is a sample token (Base64 encoded):

Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6ImppYk5ia0ZTU2JteFBZck45Q0ZxUms0SzRndyJ9.eyJhdWQiOiJkMTYyODJhYy05N2RlLTRlNGYtODVkZi0xNmVlZDUwNjNjNWUiLCJpc3MiOiJodHRwczovL2xvZ2luLm1pY3Jvc29mdG9ubGluZS5jb20vMjZjNGIyZTQtZWMwNy00YzdiLTkyZTUtOTdmNTI4NjVlOThiL3YyLjAiLCJpYXQiOjE2MDEyOTIxODYsIm5iZiI6MTYwMTI5MjE4NiwiZXhwIjoxNjAxMjk2MDg2LCJhaW8iOiJBVlFBcS84UkFBQUE4RmJoME4rOHFhVVpZSVRDY1hBVXVNOXZMOVNleUhHWnJnSUtiOUJkNW9HWEpBS1ArMEl5Q1FmUGx2NWo0amIxL0tKa0dLeHFOeWRDZlk3cTN3NGMzbHZsK3ovSFl3VmljNHJKMTBPakFsYz0iLCJhenAiOiIzYzcyZjU3ZC04M2YxLTQxMzktOTIzMi05YWFlODNjZTY2NjQiLCJhenBhY3IiOiIxIiwibmFtZSI6IlJ1c2hhbmsgS2FyZWthciIsIm9pZCI6IjU3Mzc4NTNkLTVhZTEtNDU4Ni05YjUzLTE5OWI0NDcyYWVkNyIsInByZWZlcnJlZF91c2VybmFtZSI6InJrYXJla2FyQGNsb3VkZnJvbnRzLmNvbSIsInJoIjoiMC5BQUFBNUxMRUpnZnNlMHlTNVpmMUtHWHBpMzMxY2p6eGd6bEJrakthcm9QT1ptUlVBQTQuIiwic2NwIjoiRmlsZXMuUmVhZCIsInN1YiI6IjY5UGhwWTFKNm1qS3ZhT1FaeDdaNm1jM2hpV2RVUXFoVTZpczZPdVdmZXMiLCJ0aWQiOiIyNmM0YjJlNC1lYzA3LTRjN2ItOTJlNS05N2Y1Mjg2NWU5OGIiLCJ1dGkiOiI5UTB0S1hBWkFreWpMdGw5TE9nNUFBIiwidmVyIjoiMi4wIn0.S-Wx7iH8TK4aW2Wi2msP6wu__oAmUdvpFAaAZi3_n_by2C7ElJRSeBvjYwVImsEzw4gg1zGm6ssH0xUcj2YJ3tZ5ddFW8IZR1DICHvT_sUXFCrRg6ZDlj_VPzeyLor_RmabgSE4ZfMQOmrfCET51AnQHS96-lIp_cB6SkddWQielfQMebhMMVPNyjLsBcSmFxY4gk0e3cEWnGPQHQRRMxwnJnJeqv8Gfm4fMD_xwD05nGyQ3M_mZt3H0UZiLjvVwsRlS9t7MPhVJCZPZBxEIkg0U_2IOE9OQEmuKwdyBLjVM8dNFUxfEOFUvoYUvJ-hd8hwxB5CXBYdQG9kLiAJpOg

Select Send, and you can call the API successfully.

Configure a JWT validation policy to pre-authorize requests

At this point, when a user tries to make a call from the Developer Console, the user is prompted to sign in. The Developer Console obtains an access token on behalf of the user and includes the token in the request made to the API.

1. However, what if someone calls your API without a token or with an invalid token? For example, try to call the API without the Authorization header, the call will still go through. The reason is that API Management does not validate the access token at this point. It simply passes the Authorization header to the back-end API.

You can use the Validate JWT policy to pre-authorize requests in API Management, by validating the access tokens of each incoming request. If a request does not have a valid token, API Management blocks it. For example, add the following policy to the <inbound> policy section of the Echo API. It checks the audience claim in an access token, and returns an error message if the token is not valid. For information on how to configure policies, see Set or edit policies.

<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/{aad-tenant}/.well-known/openid-configuration" />

    <required-claims>

        <claim name="aud">

            <value>{Application ID of backend-app}</value>

        </claim>

    </required-claims>

</validate-jwt>

Note

This openid-config URL corresponds to the v1 endpoint.
For the v2 openid-config endpoint, use https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration.

For our scenario the XML Policy is as follows:

<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/common/v2.0/.well-known/openid-configuration” />

<required-claims>

</claim>

</required-claims>

</validate-jwt>