You can configure the Azure API gateway so that it requires a certificate when making calls. Whereas subscription keys are generated by you and can be quickly supplied, certificates provide greater security. However, the certificate must be generated by a certificate authority and securely provided to your consumers. But when security and control are of the utmost importance, this administrative overhead is worth the effort.
OAuth 2.0 and OpenID Connect
Azure API Gateway also supports user authentication flows. You can choose to define either an OAuth 2.0 or OpenID Connect identity provider. These providers could be external providers such as Google, Facebook, or LinkedIn, or you can use Azure AD integration (depending on the pricing tier you chose).
By setting up authentication flows, you can quickly and easily wrap and protect your APIs, making it possible not just to restrict who can access the APIs but also what actions they can perform once they gain access.
Another form of protection for your APIs can be achieved at the network level using VNet Integration.
VNet Integration
The Developer and Premium service plans support VNet Integration, wherein you can choose to connect it to internal VNets. With VNet Integration, you can also decide whether the gateway will be internal only or externally accessible as well.
Making the gateway externally accessible with VNet Integration means you can expose any APIs running on a VNet, for example, VMs that only have internal IP addresses.
Alternatively, using VNet Integration with internal-only connectivity allows you to expose natively external services, such as web apps and functions, to your internal network. This is an excellent way of securing internal access when you want to completely block off external access to your APIs but make use of PaaS and serverless components such as Azure app services and Azure Functions. The following diagram shows an example of how this might look:
Figure 11.3 – Using Azure API Gateway to provide internal connectivity to app services
When connecting to services in the same region, you use regional VNet Integration with a dedicated subnet for the services you are attaching. If you need to connect to a service in another region, or if you need to integrate with a classic VNet, then you must use an Azure VNet gateway – this is known as gateway-required VNet Integration.
Finally, it is possible to combine the security of forcing internal connectivity and exposing services to the public network using an application gateway. Because the application gateway includes a web application firewall, you get greater security and more control. You can also use the application gateway with the API gateway to expose some APIs internally and externally, as shown in the following diagram:
Figure 11.4 – Using an application gateway with an API gateway
Using APIs in your solutions is a common method for exposing data to various application types, from desktop apps to mobile or web apps. A typical pattern is to build those APIs as smaller services that perform discrete tasks – these are known as microservices.
Leave a Reply