Metadata-Version: 2.4
Name: userbot_auth
Version: 1.0.11
Summary: Ryzenth UBT | Enterprise Security Framework.
Author: TeamKillerX
License: MIT
Project-URL: Source, https://github.com/TeamKillerX/Userbot-Auth/
Project-URL: Issues, https://github.com/TeamKillerX/Userbot-Auth/issues
Keywords: Userbot-Auth-API,Ryzenth-SDK
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Python :: 3.8
Classifier: Programming Language :: Python :: 3.9
Classifier: Programming Language :: Python :: 3.10
Classifier: Programming Language :: Python :: 3.11
Classifier: Development Status :: 5 - Production/Stable
Classifier: License :: OSI Approved :: MIT License
Classifier: Operating System :: OS Independent
Classifier: Intended Audience :: Developers
Classifier: Natural Language :: English
Requires-Python: ~=3.7
Description-Content-Type: text/markdown
License-File: LICENSE
Requires-Dist: requests
Requires-Dist: aiohttp
Dynamic: author
Dynamic: classifier
Dynamic: description
Dynamic: description-content-type
Dynamic: keywords
Dynamic: license
Dynamic: license-file
Dynamic: project-url
Dynamic: requires-dist
Dynamic: requires-python
Dynamic: summary

# 🛡️ Userbot-Auth Library Mode

## ✨ Features

Userbot-Auth Library Mode is a **server-enforced authentication and control layer** for userbots. It is designed to keep authority on the backend, not inside copied client code.

## Feature Highlights

### 🔐 **Server-Issued Runtime Keys**
All runtime access is controlled by server-generated keys bound to a specific user identity.

### 🛑 **Deploy Control & Remote Blocking**
Deployments can be disconnected or blocked remotely, even if client code is copied or modified.

### 🔄 **Key Rotation & Revocation**
Runtime keys can be rotated at any time to invalidate existing deployments instantly.

### 📊 **Plan-Based Rate Limiting**
Request limits are enforced by server-defined plans (FREE / PRO / MAX) with optional per-user overrides.

### 🕶️ **One-Time Key Exposure**
Runtime keys are shown only once during issuance to reduce leakage risk.

### 📝 **Audit-Friendly Key Issuance**
Every issued key includes a unique `issued_id` for tracking, review, and incident response.

### 🔒 **Hardened Request Validation**
Supports timestamp checks, nonce-based HMAC signatures, and timing-safe comparisons.

### 🏛️ **Centralized Enforcement**
All authorization decisions are made on the backend, not in client code.

### ⚡ **Anti-Reuse & Anti-Repack Design**
Copied source code cannot bypass server validation or rate limits.

### 📚 **Library-First Architecture**
Designed to integrate cleanly into existing userbot frameworks or backend services without lifecycle coupling.

## 🔑 Authentication and Identity

- **Server-issued runtime keys** (`ubt_live_*`, optional `ubt_test_*`)
  Keys are issued by the server and verified on every request.

- **Per-user identity binding**
  Every key is associated with a specific `user_id`. The server decides whether that identity is valid.

- **Strict separation of secrets**
  Provisioning secrets and runtime keys are isolated to prevent privilege escalation.

---

## ⚙️ Provisioning and Key Control

- **Controlled key provisioning**
  Runtime keys can only be issued through a protected provision flow.

- **Key rotation and revocation**
  Keys can be rotated to invalidate old deployments immediately.

- **One-time key visibility**
  Runtime keys are displayed once during issuance to reduce leakage risk.

- **Audit identifiers (`issued_id`)**
  Every issued key can be traced and reviewed through an audit-friendly identifier.

## ⚡ Runtime Enforcement

- **Connected-user verification**
  Requests are accepted only when the server confirms the user is connected and authorized.

- **Remote deploy blocking**
  The server can block deployments at runtime (disconnect or ban), regardless of client code.

- **Automatic disconnect on invalid credentials**
  Invalid keys or mismatched identity triggers server-side disconnect logic.

## 📈 Plan System and Rate Limiting

- **Plan-based limits**
  Traffic limits are enforced by plan tiers (FREE / PRO / MAX).

- **Per-user overrides**
  Limits can be customized per user (including unlimited access for trusted accounts).

- **Server-side rate enforcement**
  Limits cannot be bypassed by modifying client code, because counters and windows live on the server.

- **Consistent 429 responses with reset metadata**
  The API can return retry timing information for clean client backoff behavior.

## 🔐 Security Hardening

- **Timestamp freshness validation**
  Prevents delayed or replayed requests outside allowed time skew.

- **Nonce-based request signing (HMAC)**
  Provides integrity checks and replay resistance for sensitive endpoints.

- **Replay protection strategy**
  Requests can be rejected if a nonce is reused within a time window.

- **Timing-safe comparisons**
  Protects secret comparisons from timing-based attacks.

## Operational Visibility

- **Deployment and runtime telemetry**
  The server can track version, platform, device, and last-seen activity.

- **Actionable status responses**
  Standardized responses for states like `DISCONNECTED`, `BANNED`, and `RATE_LIMIT`.

- **Central enforcement policies**
  Your backend defines enforcement rules, and the library ensures they are applied consistently.

## Intended Use

- 🔒 Private userbot frameworks
- 💼 Commercial or restricted deployments
- 🛡️ Projects requiring deploy control and anti-reuse enforcement
- 👨‍💻 Developers who need server authority and auditability
