You can develop, but can you develop for the cloud? Harness your development skills and learn how to create robust solutions for Microsoft Azure, aiming for your Microsoft Certified: Azure Developer Associate certification!
Gauge your current knowledge
Gauge your current knowledge
Azure API Management uses subscriptions as the primary way to control who can call your APIs. A subscription acts as a named container for a pair of security keys (the primary and secondary keys) that a developer must include in every HTTP request, usually through the Ocp-Apim-Subscription-Key header. If the key is missing or invalid, the gateway rejects the request immediately to protect backend services from unauthorized use. Subscriptions are scoped to products (a bundle of APIs), to a single API, or to the global level (every API in the instance). You should treat global scope with caution because it gives access to all APIs.
Managing the lifecycle of these keys is a critical security task. You must manually regenerate keys regularly—for example, after a leak or as part of a rotation policy—because Azure does not rotate them automatically. Tools like PowerShell can automate key regeneration so that one key can be replaced while the other remains active, preventing downtime. Always store secret keys in Azure Key Vault using API Management named values, never in plain text or policy files. APIs are organized into products; a protected product requires a subscription key, while an open product allows anonymous access. You can also set access policies on products to enforce quotas, rate limits, and manual subscription approval, giving you fine-grained control over who consumes your APIs and how much they can use them.
Transport-level security in Azure API Management focuses on encrypting and authenticating the communication channel between clients and the gateway. Mutual TLS (mTLS) uses client certificates to verify the identity of both sides. The gateway’s validate-client-certificate policy checks certificate thumbprints and expiration dates, ensuring that only trusted clients reach the backend. For network-level protection, IP address filtering creates allow-lists that permit traffic only from known IP addresses. You can further hide the API from the public internet by placing the gateway inside a Virtual Network (VNET) or using Private Link.
To prevent common web attacks, you should configure a CORS policy without wildcards—explicitly list the allowed origins instead. Validation policies check the size and format of incoming requests: they validate JSON and XML schemas, check required headers and query parameters, and enforce maximum request sizes to avoid resource exhaustion. Every API should be part of a product that requires a valid subscription key for every call. This setup lets you track usage, apply quotas and rate limits, and approve or deny subscription requests manually. For defense in depth, place a Web Application Firewall (WAF) in front of the gateway to block malicious bots and common web threats before they reach your API.
Products are logical groupings of one or more APIs that share a common usage policy. Subscriptions provide the named containers for subscription keys, and they control access at three scopes: global (all APIs), product, or an individual API. To govern access effectively, you should publish APIs through products that have the Requires subscription setting enabled and require manual approval for new subscriptions. Avoid open products that do not need a key, because they can lead to overly permissive access. Each subscription comes with a primary and secondary key, which makes key rotation possible without disrupting service. You can rotate keys using Azure PowerShell or SDKs, replacing one key while the other stays active.
Because API Management does not automatically expire subscription keys, consider using token-based authentication with built-in expiration (like JWT) or applying policies that enforce time limits. Store all secrets—such as subscription keys—in named values integrated with Azure Key Vault rather than in plain text. For additional security, apply validation policies to enforce JSON and XML schemas, validate headers and query parameters, and restrict maximum request or response sizes. Use the restrict caller IPs policy with an allowlist to limit access to known IP addresses. By governing access through products and subscriptions, you ensure that only authorized developers can call your APIs and that you can control how much they use them.
Azure API Management acts as a protective layer between clients and backend services. Security policies control who can access an API and how they interact with it. For authentication, you can use subscription keys, client certificates for mutual TLS, or managed identities to connect APIM to other Azure resources without managing passwords. The validate-jwt policy checks that incoming JSON Web Tokens (JWT) are valid and contain the correct claims, such as audience and issuer, ensuring only trusted identities reach the backend.
To protect web clients, the CORS policy defines which specific origins (not wildcards) are allowed to call your API. The IP filter policy restricts access to known, trusted IP addresses. Throttling prevents unrestricted resource consumption: rate limits control traffic over short bursts, while quotas manage total usage over longer periods like days or months. These mechanisms prevent one user from overwhelming the backend and help control costs. Content validation policies check that request and response data matches a specific JSON or XML schema, blocking malformed or malicious payloads. Always store sensitive secrets—like client IDs and keys—in named values linked to Azure Key Vault, never in plain text within policy files.
Azure API Management (APIM) enables you to enforce OAuth 2.0 and OpenID Connect protocols to authenticate API consumers. You integrate APIM with an identity provider such as Azure AD B2C by registering both your API and client applications in that tenant. You then collect the API’s Application (client) ID, the OpenID Connect well-known metadata URL (.well-known/openid-configuration) from your user flow, and the issuer URI. These values feed into an inbound policy that validates incoming JWT tokens.
In the APIM inbound policy, you use a validate-jwt element that checks the Authorization header. You specify the openid-config URL for retrieving signing keys, the audiences to match your API’s client ID or App ID URI, and the issuers to ensure the token comes from your AD B2C tenant. To enforce fine-grained authorization, you define scopes (such as demo.read and demo.write) in AD B2C under Expose an API and assign those scopes to client apps under API permissions. In your APIM policy, you use `` to check for the correct scope, enforcing the least-privilege principle. Always store client IDs and secrets in named values tied to Azure Key Vault, require HTTPS on all endpoints, monitor authentication failures through APIM analytics, and regularly rotate keys and secrets to keep your APIs secure under OAuth 2.0 and OpenID Connect standards.
StudyCerts
StudyCerts