You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/api-management/api-management-access-restriction-policies.md
+8-5Lines changed: 8 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -186,7 +186,7 @@ If `identity-type=jwt` is configured, a JWT token is required to be validated. T
186
186
| authorization-id | The authorization resource identifier. | Yes ||
187
187
| context-variable-name | The name of the context variable to receive the [`Authorization` object](#authorization-object). | Yes ||
188
188
| identity-type | Type of identity to be checked against the authorization access policy. <br> - `managed`: managed identity of the API Management service. <br> - `jwt`: JWT bearer token specified in the `identity` attribute. | No | managed |
189
-
| identity | An Azure AD JWT bearer token to be checked against the authorization permissions. Ignored for `identity-type` other than `jwt`. <br><br>Expected claims: <br> - audience: https://azure-api.net/authorization-manager <br> - `oid`: Permission object id <br> - `tid`: Permission tenant id| No ||
189
+
| identity | An Azure AD JWT bearer token to be checked against the authorization permissions. Ignored for `identity-type` other than `jwt`. <br><br>Expected claims: <br> - audience: https://azure-api.net/authorization-manager <br> - `oid`: Permission object ID <br> - `tid`: Permission tenant ID| No ||
190
190
| ignore-error | Boolean. If acquiring the authorization context results in an error (for example, the authorization resource is not found or is in an error state): <br> - `true`: the context variable is assigned a value of null. <br> - `false`: return `500`| No | false |
191
191
192
192
### Authorization object
@@ -225,8 +225,7 @@ To understand the difference between rate limits and quotas, [see Rate limits an
225
225
> * This policy can be used only once per policy document.
226
226
> *[Policy expressions](api-management-policy-expressions.md) cannot be used in any of the policy attributes for this policy.
227
227
228
-
> [!CAUTION]
229
-
> Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between configured and the real number of allowed requests varyies based on request volume and rate, backend latency, and other factors.
@@ -301,8 +300,7 @@ To understand the difference between rate limits and quotas, [see Rate limits an
301
300
302
301
For more information and examples of this policy, see [Advanced request throttling with Azure API Management](./api-management-sample-flexible-throttling.md).
303
302
304
-
> [!CAUTION]
305
-
> Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between configured and the real number of allowed requests vary based on request volume and rate, backend latency, and other factors.
@@ -491,6 +491,9 @@ For more information and examples of this policy, see [Advanced request throttli
491
491
492
492
To understand the difference between rate limits and quotas, [see Rate limits and quotas.](./api-management-sample-flexible-throttling.md#rate-limits-and-quotas)
Copy file name to clipboardExpand all lines: articles/api-management/api-management-sample-flexible-throttling.md
+5-2Lines changed: 5 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,13 +25,16 @@ Rate limits and quotas are used for different purposes.
25
25
### Rate limits
26
26
Rate limits are usually used to protect against short and intense volume bursts. For example, if you know your backend service has a bottleneck at its database with a high call volume, you could set a `rate-limit-by-key` policy to not allow high call volume by using this setting.
Quotas are usually used for controlling call rates over a longer period of time. For example, they can set the total number of calls that a particular subscriber can make within a given month. For monetizing your API, quotas can also be set differently for tier-based subscriptions. For example, a Basic tier subscription might be able to make no more than 10,000 calls a month but a Premium tier could go up to 100,000,000 calls each month.
30
33
31
34
Within Azure API Management, rate limits are typically propagated faster across the nodes to protect against spikes. In contrast, usage quota information is used over a longer term and hence its implementation is different.
32
35
33
-
> [!CAUTION]
34
-
> Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between the configured and the real number of allowed requests vary based on request volume and rate, backend latency, and other factors.
Rate throttling capabilities that are scoped to a particular subscription are useful for the API provider to apply limits on the developers who have signed up to use their API. However, it does not help, for example, in throttling individual end users of the API. It is possible for a single user of the developer's application to consume the entire quota and then prevent other customers of the developer from being able to use the application. Also, several customers who might generate a high volume of requests may limit access to occasional users.
> When underlying compute resources restart in the service platform, API Management may continue to handle requests for a short period after a quota is reached.
> Due to the distributed nature of throttling architecture, rate limiting is never completely accurate. The difference between the configured and the actual number of allowed requests varies based on request volume and rate, backend latency, and other factors.
0 commit comments