Rate limits и API auth

Public и partner API нуждаются в **authentication**, **authorization** и **rate limits** как в одной системе — лимиты без identity легко обойти; auth без квот приглашает abuse.

Паттерны auth:

• **API keys** для server-to-server (scoped, rotatable, не во frontend bundles).
• **OAuth2/OIDC** для user-delegated access (короткоживущие access tokens, rotation refresh).
• **mTLS** или signed requests для high-trust B2B.

Authorization на каждый запрос: subject, action, resource, tenant context. Fail closed.

Измерения rate limiting:

• Per key / user / IP / tenant.
• Token bucket или sliding window для burst + sustained limits.
• Отдельные бюджеты для дорогих endpoints.

					HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1710000060

{"type":"rate_limit_exceeded","detail":"Try again in 60 seconds"}
				

На интервью: 401 vs 403, хранение hashed API keys, distributed rate limiting (Redis), graceful degradation под атакой.

Типовые ошибки: лимиты только по IP (боль NAT), нет Retry-After, authZ только в одном слое, долгоживущие tokens без rotation.

Компромисс: строгая безопасность против developer friction — документируйте квоты, sandbox keys, self-service rotation.

Чеклист:

• Scoped credentials с least privilege.
• 429 с Retry-After и limit headers.
• Центральная authZ policy или согласованный middleware.
• Мониторинг abuse и аномальных всплесков.