The course is part of these learning paths
See 1 moreThis course deals with how to deploy, configure, and manage some keys aspects of Azure API management (APIM). In particular, we focus on the authentication mechanism and go into depth about how to set up OAuth 2.0, including creating the Azure AD required application registrations. To help with understanding and troubleshooting the OAuth flow, we utilize Postman to check and validate our configuration.
Next, we take a look at how we can alter API requests at various scopes using API policies. Finally, we look at how to view effective API policies that span multiple scopes and also how to trace API policies during runtime.
Learning Objectives
- Deploy Azure API Management and import an existing API
- Gain an understanding of how the configure authentication against APIM using OAuth 2.0
- Implement API policies against the imported API to alter the API request
- Use Postman to make API requests against APIM and request and use OAuth authorization tokens
- Secure the imported API by requiring a valid Azure AD token
Intended Audience
- People who want to become Azure developers and who design and build cloud solutions
- People preparing for Microsoft’s AZ-203 exam
Prerequisites
There are different types of OAuth grants: authorization code, implicit, password, client credentials, device code, and refresh token. We will be taking a look at the authorization code grant, which is what we are setting up for our scenarios. Having an understanding of the code flow is very useful when implementing and troubleshooting.
An authorization code flow is when a client obtains a user's approval and gets an authorization code that can be exchanged for an access token which is used to gain access to privileged resources.
Let's take a closer look at the OAuth flow for authorization code. Here we can see we have a user and their browser, a client application, the user's authorization server, and a privileged resource server.
Let's walk through the eight steps. First, the process will be initiated by the user trying to get into a client application. Second, the client will redirect the user to an authorization server that they trust. Third, the user will log into the authorization server with their username and password. Fourth, the authorization server will validate the user's credentials and redirect them to the client application to the reply or callback URL with an authorization token. Fifth, the browser hands the authorization token to the client application. Sixth, the client application will send the authorization token to the authorization server, to the token endpoint, and get an access token. It will also gain a refresh token. Seventh, the application will submit the access token to the resource server. Eighth, the resource server will validate the access token and will allow the client application access to the resource.
With an authorization code grant, at no stage does the user give their credentials to the app. They enter their credentials into a server they know and trust. The other benefit of this flow is the access token does not pass through the browser, which makes it harder to be compromised.
Next, we are going to set up the AAD applications and delegated permissions that are required to implement this.
Matthew Quickenden is a motivated Infrastructure Consultant with over 20 years of industry experience supporting Microsoft systems and other Microsoft products and solutions. He works as a technical delivery lead managing resources, understanding and translating customer requirements and expectations into architecture, and building technical solutions. In recent years, Matthew has been focused on helping businesses consume and utilize cloud technologies with a focus on leveraging automation to rapidly deploy and manage cloud resources at scale.