Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .prettierignore
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ docs/keto/cli/
docs/kratos/cli/
docs/oathkeeper/cli/
package-lock.json
rate-limits.json
.docusaurus/
build/
.next
Expand Down
11 changes: 11 additions & 0 deletions docs/guides/load-performance-testing.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
---
id: load-performance-testing
title: Load and performance testing
sidebar_label: Load and performance testing
---

Load testing, stress testing, and performance testing against Ory Network require prior written approval. Unauthorized load
testing may be detected as abusive traffic and result in temporary blocking of your project or IP addresses.

For eligibility, request procedures, and requirements, see the
[Load Testing Policy](https://www.ory.sh/legal/load-testing-policy).
59 changes: 59 additions & 0 deletions docs/guides/rate-limit-endpoint.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,59 @@
---
id: rate-limits-endpoint
title: Endpoint rate limits for Ory Network
sidebar_label: Endpoint rate limits
---

Endpoint-based rate limits apply to individual API endpoints regardless of your project rate limits. They protect specific
endpoints against brute-force and credential stuffing attacks, which typically originate from a limited set of IP addresses or JA4
fingerprints.

Benefits:

- Enhanced security: Restricts requests from specific sources, making attacks significantly harder to succeed
- Bot protection: Differentiates genuine users from harmful automated activity
- Granular control: Fine-tunes security for individual endpoints without compromising user experience

## Types of endpoint-based protection

Ory implements two layers of endpoint-based protection:

- Volumetric: Limits the total amount of traffic over time.
- Inflight: Limits the number of concurrent active requests.

### Volumetric rate limits

Volumetric rate limits analyze incoming request patterns based on:

- Source identification: IP addresses and JA3/JA4 fingerprints
- Request frequency: Detects volumetric attacks and system overwhelm attempts
- Authentication status: Different limits for authenticated vs. unauthenticated requests
- HTTP method: Varying limits based on GET, POST, etc.

### Inflight rate limits

Inflight rate limits protect critical endpoints from concurrent request attacks. By preventing multiple requests to the same
resource at once, they eliminate race conditions, ensure data consistency, and let critical operations complete safely.

The following endpoints are protected by rate limits.

| Type | Endpoint | HTTP Methods | Ratelimit Key | Action: enforced vs report-only |
| :------- | :------------------------------------------ | :----------------------- | :----------------------------------------------- | :------------------------------------- |
| Inflight | `/admin/identities` | `POST`, `PATCH` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}` | `PUT`, `PATCH`, `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}/credentials/{type}` | `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}/sessions` | `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/sessions/{id}` | `DELETE` | `{project_id} + {full_path}` | Logs concurrent requests (report-only) |
| Inflight | `/admin/sessions/{id}/extend` | `PATCH` | `{project_id} + {full_path}` | Logs concurrent requests (report-only) |
| Inflight | `/self-service/recovery` | `POST` | `{project_id} + {path} + "/" + {email\|flow_id}` | Logs concurrent requests (report-only) |

:::note

Enforced-endpoints return HTTP 429 when the rate limit is exceeded. Report-only-endpoints currently only log rate limit
violations; they don't block requests. GET, OPTIONS, and HEAD requests are exempt from rate limiting.

:::

### Configuration and rule management

The endpoint-based rate limit rules are set and managed by Ory. These rules aren't directly configurable by customers.
256 changes: 256 additions & 0 deletions docs/guides/rate-limits-legacy.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,256 @@
---
id: rate-limits-legacy
title: Legacy Ory Network rate limits
sidebar_label: Legacy rate limits
---

:::info

This page describes the legacy rate limit policy, which applies to existing Ory Network customers who haven't been migrated to the
new rate limit policy yet. If you're a new customer or have already been migrated, see the
[new rate limits](/docs/guides/rate-limits-new). See [Rate limits](/docs/guides/rate-limits) to learn about both policies and the
migration plan.

:::

This page provides a high-level overview of the rate limiting mechanisms employed by Ory to ensure system security and
availability. Rate limiting protects your applications against abuse and attacks, prevents service disruptions, and ensures fair
usage for all our customers.

## Types of rate limits

Ory implements two main rate limit types:

1. Project rate limits: Based on your subscription plan and environment (Production, Staging, or Development). These control the
overall request volume your projects can make to Ory's APIs.
2. Endpoint-based rate limits: Additional security controls that protect specific endpoints against attacks like brute-force,
credential stuffing, and concurrent request abuse, regardless of your project limits.

## Project rate limits in workspaces

With the introduction of workspaces in Ory Network, rate limits are now applied to projects based on their assigned environment
and the workspace's subscription plan. This approach ensures fair resource allocation and maintains the stability of the Ory
Network across different usage scenarios.

### How project rate limits work in workspaces

Rate limits for each project are determined by two main factors:

1. Workspace subscription: Your subscription plan (Developer, Production, Growth, or Enterprise) sets the baseline for your rate
limits.
2. Project environment: Within each workspace, projects can be assigned to Production, Staging, or Development environments, each
with specific rate limit configurations.

For a detailed explanation of workspaces and environments, see our [Workspaces and environments guide](/docs/guides/workspaces).

### Rate limit structure

Each rate limit policy includes two limits:

1. Burst limit: Maximum requests per second (rps), allowing for short traffic spikes.
2. Sustained limit: Maximum requests per minute (rpm), ensuring consistent performance over time.

### Determine your project's rate limits

To identify the rate limits that apply to your project:

1. Check your workspace subscription plan (Developer, Production, Growth, or Enterprise).
2. Identify the environment (Production, Staging, or Development) assigned to your project.
3. Refer to the tables below based on your subscription plan and project environment.

### Rate limit tables by subscription plan

#### Developer plan rate limits

| Environment | Path / Bucket | Burst (rps) | Sustained (rpm) |
| :---------- | :-------------------------------- | ----------: | --------------: |
| Development | `/sessions/whoami` | 10 | 300 |
| | `/admin/oauth2/introspect` | 10 | 300 |
| | `/relation-tuples/check` | 10 | 300 |
| | `GET /admin/identities` | 1 | 10 |
| | `POST /admin/identities` | 1 | 10 |
| | `PATCH /admin/identities` | 1 | 10 |
| | `POST /admin/recovery/*` | 1 | 10 |
| | `POST /self-service/registration` | 1 | 10 |
| | `POST /self-service/recovery` | 1 | 10 |
| | `POST /self-service/settings` | 1 | 10 |
| | `POST /self-service/verification` | 1 | 10 |
| | `/scim/**` | 1 | 10 |
| | `*` | 5 | 150 |

:::note

For Developer plans, all environments (Production, Staging, Development) use the same rate limits.

:::

#### Production plan rate limits

| Environment | Path / Bucket | Burst (rps) | Sustained (rpm) |
| :-------------------- | :-------------------------------- | ----------: | --------------: |
| Production | `/sessions/whoami` | 80 | 1800 |
| | `/admin/oauth2/introspect` | 80 | 1800 |
| | `/relation-tuples/check` | 80 | 1800 |
| | `GET /admin/identities` | 10 | 300 |
| | `POST /admin/recovery/*` | 10 | 30 |
| | `/scim/**` | 10 | 300 |
| | `*` | 40 | 900 |
| Development / Staging | `/sessions/whoami` | 10 | 300 |
| | `/admin/oauth2/introspect` | 10 | 300 |
| | `/relation-tuples/check` | 10 | 300 |
| | `GET /admin/identities` | 1 | 10 |
| | `POST /admin/identities` | 1 | 10 |
| | `PATCH /admin/identities` | 1 | 10 |
| | `POST /admin/recovery/*` | 1 | 10 |
| | `POST /self-service/registration` | 1 | 10 |
| | `POST /self-service/recovery` | 1 | 10 |
| | `POST /self-service/settings` | 1 | 10 |
| | `POST /self-service/verification` | 1 | 10 |
| | `/scim/**` | 1 | 10 |
| | `*` | 5 | 150 |

:::note

Production plan rate limits also apply to the Legacy `Essential` plan.

:::

#### Growth plan rate limits

| Environment | Path / Bucket | Burst (rps) | Sustained (rpm) |
| :-------------------- | :-------------------------------- | ----------: | --------------: |
| Production | `/sessions/whoami` | 800 | 18000 |
| | `/admin/oauth2/introspect` | 800 | 18000 |
| | `/relation-tuples/check` | 800 | 18000 |
| | `GET /admin/identities` | 20 | 600 |
| | `POST /admin/recovery/*` | 10 | 300 |
| | `/scim/**` | 10 | 300 |
| | `*` | 400 | 9000 |
| Development / Staging | `/sessions/whoami` | 10 | 300 |
| | `/admin/oauth2/introspect` | 10 | 300 |
| | `/relation-tuples/check` | 10 | 300 |
| | `GET /admin/identities` | 1 | 10 |
| | `POST /admin/identities` | 1 | 10 |
| | `PATCH /admin/identities` | 1 | 10 |
| | `POST /admin/recovery/*` | 1 | 10 |
| | `POST /self-service/registration` | 1 | 10 |
| | `POST /self-service/recovery` | 1 | 10 |
| | `POST /self-service/settings` | 1 | 10 |
| | `POST /self-service/verification` | 1 | 10 |
| | `/scim/**` | 1 | 10 |
| | `*` | 5 | 150 |

:::note

Growth plan rate limits also apply to the legacy `Scale` plan.

:::

#### Enterprise plan rate limits

The Enterprise plan has the same default rate limits as the Growth plan. If your use case requires higher limits,
[get in touch with us to discuss your requirements](https://ory.com/contact).

| Environment | Path / Bucket | Burst (rps) | Sustained (rpm) |
| :-------------------- | :-------------------------------- | ----------: | --------------: |
| Production | `/sessions/whoami` | 1200 | 36000 |
| | `/admin/oauth2/introspect` | 1200 | 36000 |
| | `/relation-tuples/check` | 1200 | 36000 |
| | `GET /admin/identities` | 60 | 1200 |
| | `POST /admin/recovery/*` | 20 | 600 |
| | `/scim/**` | 20 | 600 |
| | `*` | 800 | 18000 |
| Development / Staging | `/sessions/whoami` | 10 | 300 |
| | `/admin/oauth2/introspect` | 10 | 300 |
| | `/relation-tuples/check` | 10 | 300 |
| | `GET /admin/identities` | 1 | 10 |
| | `POST /admin/identities` | 1 | 10 |
| | `PATCH /admin/identities` | 1 | 10 |
| | `POST /admin/recovery/*` | 1 | 10 |
| | `POST /self-service/registration` | 1 | 10 |
| | `POST /self-service/recovery` | 1 | 10 |
| | `POST /self-service/settings` | 1 | 10 |
| | `POST /self-service/verification` | 1 | 10 |
| | `/scim/**` | 1 | 10 |
| | `*` | 5 | 150 |

## Endpoint-based rate limits

Endpoint-based rate limits are controls applied to individual API endpoints within your Ory projects. Unlike project rate limits,
which govern overall project request volumes, endpoint-based rate limits focus on safeguarding specific functionalities against
abuse.

:::note

Endpoint-based rate limits operate independently from project rate limits in workspaces. While project rate limits control overall
request volumes based on your subscription and environment, endpoint-based rate limits provide additional security for specific
endpoints regardless of your project rate limit values.

:::

### Purpose of endpoint-based rate limits

Endpoint-based rate limits protect individual endpoints against common attack vectors like brute-force and credential stuffing.
These attacks typically involve numerous attempts to guess credentials or exploit vulnerabilities, often from a limited set of IP
addresses or JA4 fingerprints.

Benefits:

- Enhanced security: Restricts requests from specific sources, making attacks significantly harder to succeed
- Bot protection: Differentiates genuine users from harmful automated activity
- Granular control: Fine-tunes security for individual endpoints without compromising user experience

### Types of endpoint-based protection

Ory implements two layers of endpoint-based protection:

#### Volumetric rate limits

Analyzes incoming request patterns based on:

- Source identification: IP addresses and JA3/JA4 fingerprints
- Request frequency: Detects volumetric attacks and system overwhelm attempts
- Authentication status: Different limits for authenticated vs. unauthenticated requests
- HTTP method: Varying limits based on GET, POST, etc.

#### Inflight rate limits

Inflight rate limits protect critical endpoints from concurrent request attacks. By preventing multiple requests to the same
resource at once, it eliminates race conditions, ensures data consistency, and lets critical operations complete safely.

:::note

These limits mainly protect against write requests to the same resource happening in parallel — usually caused by implementation
issues.

:::

### Protected endpoints

The following endpoints are protected by different types of rate limiting:

| Type | Endpoint | HTTP Methods | Ratelimit Key | Action |
| :--------- | :------------------------------------------ | :----------------------- | :----------------------------------------------- | :------------------------------------- |
| Volumetric | | | | To be added later |
| Inflight | `/admin/identities` | `POST`, `PATCH` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}` | `PUT`, `PATCH`, `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}/credentials/{type}` | `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/identities/{id}/sessions` | `DELETE` | `{project_id} + {full_path}` | Blocks concurrent requests (enforced) |
| Inflight | `/admin/sessions/{id}` | `DELETE` | `{project_id} + {full_path}` | Logs concurrent requests (report-only) |
| Inflight | `/admin/sessions/{id}/extend` | `PATCH` | `{project_id} + {full_path}` | Logs concurrent requests (report-only) |
| Inflight | `/self-service/recovery` | `POST` | `{project_id} + {path} + "/" + {email\|flow_id}` | Logs concurrent requests (report-only) |

:::note

Report-only endpoints are observed over a period of time before enforcement is enabled. They currently log rate limit violations
for monitoring purposes but don't block requests, while enforced endpoints return HTTP 429 when rate limits are exceeded. GET,
OPTIONS, and HEAD requests are exempt from rate limiting.

:::

### Configuration and management

#### Rule management

The endpoint-based rate limit rules are set and managed by Ory. These rules aren't directly configurable by Enterprise and Growth
customers yet.
Loading
Loading