mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-03 22:02:08 +03:00
f44ec7e1f2
T-30 — ADRs:
- 6 ADRs: SQLite, Fallback Strategy, OAuth, JS+JSDoc, Single-Tenant, Translator Registry
T-33 — JSDoc Coverage:
- Full JSDoc on all new modules (100% exported functions documented)
T-35 — Accessibility:
- a11yAudit.js: lightweight WCAG AA checker (aria-label, dialog role, alt text, labels)
T-38 — Password Reset CLI:
- bin/reset-password.mjs: interactive CLI tool for admin password reset
T-39 — Playwright Specs:
- tests/e2e/responsiveSpecs.mjs: viewports (375/768/1280), 4 pages, test matrix
T-42 — Eval Framework:
- evalRunner.js: 4 strategies (exact, contains, regex, custom) + golden set (10 cases)
T-43 — Compliance:
- audit_log table, noLog opt-out per API key, LOG_RETENTION_DAYS cleanup
TASKS.md: 46/46 Concluído ✅
Tests: 144/144 pass (119 existing + 25 new)
1.7 KiB
1.7 KiB
ADR-003: OAuth Strategy — Multi-Flow Support
Date: 2025-11-01
Status: Accepted
Deciders: @diegosouzapw
Context
OmniRoute supports 12+ providers, each with different OAuth implementations:
- Authorization Code + PKCE (Claude, Codex, Gemini, Antigravity, iFlow)
- Device Code Flow (Qwen, GitHub, Kiro, Kilocode, Kimi-Coding, Cline)
- Token Import (Cursor — extracted from local SQLite)
A unified approach is needed to manage authentication across all providers.
Decision
Use a base class + strategy pattern:
OAuthServicebase class (src/lib/oauth/services/oauth.js) — handles common authorization code flow with PKCE- Provider-specific subclasses (e.g.,
GitHubService,ClaudeService) — override authentication methods - Provider registry (
src/lib/oauth/providers.js) — declarative config per provider withflowType,buildAuthUrl,exchangeToken,mapTokens - Constants centralized in
src/lib/oauth/constants/oauth.js
Each provider defines:
flowType:authorization_code_pkce|authorization_code|device_code|import_token- Required hooks:
buildAuthUrl(),exchangeToken(),mapTokens() - Optional hooks:
postExchange()for provider-specific post-auth logic
Consequences
Positive
- Adding new providers requires only a config entry + optional subclass
- PKCE, state validation, and token exchange are shared (DRY)
- Device code flow providers share polling logic
Negative
- Some providers have unique quirks (Kiro uses AWS SSO OIDC with client registration)
- Testing requires mocking external OAuth endpoints
Neutral
- ~1050 lines in
providers.js— could be further split per provider if needed