{
  "title": "یکپارچه‌سازی استراتژی احراز هویت",
  "slug": "team/backend/ADR/ADR-Backend-005",
  "url": "/docs/team/backend/ADR/ADR-Backend-005",
  "frontmatter": {
    "layout": "doc",
    "title": "یکپارچه‌سازی استراتژی احراز هویت",
    "description": "ADR برای تصویب استراتژی یکپارچه احراز هویت شامل Canonical Identity, Magic Code, Google Login, حذف Password/Discord",
    "version": "1.0.0",
    "status": "APPROVED",
    "author": "Antigravity",
    "owner": "Backend Team",
    "created_at": "2026-06-18",
    "updated_at": "2026-06-18",
    "tags": "",
    "reviewers": ""
  },
  "sections": [
    {
      "level": 1,
      "heading": "یکپارچه‌سازی استراتژی احراز هویت",
      "content": "**Authentication Strategy Consolidation**\n\n> **ADR-Backend-005** — جایگزین و تکمیل‌کننده ADR-Backend-002 در بخش‌های مربوط به روش‌های احراز هویت\n\n---"
    },
    {
      "level": 2,
      "heading": "وضعیت",
      "content": "**Status**\n\n✅ **تایید شده (APPROVED)**\n\n---"
    },
    {
      "level": 2,
      "heading": "تاریخ",
      "content": "**Date**\n\n2026-06-18\n\n---"
    },
    {
      "level": 2,
      "heading": "زمینه",
      "content": "**Context**\n\nپس از تحلیل معماری فعلی و بررسی گزینه‌های مختلف (Discovery Report)، تصمیمات نهایی زیر برای یکپارچه‌سازی استراتژی احراز هویت پلتفرم NONS اتخاذ شده است. این تصمیمات جایگزین و تکمیل‌کننده بخش‌های مربوط به روش‌های احراز هویت در ADR-Backend-002 هستند.\n\n---"
    },
    {
      "level": 2,
      "heading": "تصمیمات معماری",
      "content": "**Decisions**"
    },
    {
      "level": 3,
      "heading": "A1 — Email به عنوان شناسه اصلی کاربر (Canonical Identity)",
      "content": "در کل پلتفرم:\n\n- **Email** شناسه یکتا و دائمی کاربر است.\n- هیچ Provider هویتی مالک حساب نیست.\n- Google فقط یک روش احراز هویت است.\n- یک حساب کاربری = یک ایمیل."
    },
    {
      "level": 3,
      "heading": "A2 — حذف مفهوم Registration از UX",
      "content": "پلتفرم مفهومی به نام Sign Up، Registration یا Create Account در رابط کاربری نخواهد داشت. رفتار سیستم:\n\n- اگر ایمیل وجود نداشت → حساب ایجاد شود.\n- اگر ایمیل وجود داشت → ورود انجام شود.\n- تجربه کاربر همیشه «ورود به NONS» است."
    },
    {
      "level": 3,
      "heading": "A3 — روش‌های ورود MVP",
      "content": "1. **Magic Code (Primary):** ورود با ایمیل + کد یکبار مصرف — بدون رمز عبور.\n2. **Google Login (Secondary):** ورود با حساب Google. در صورت تطبیق ایمیل، حساب‌ها ادغام می‌شوند."
    },
    {
      "level": 3,
      "heading": "A4 — حذف Password Authentication",
      "content": "رمز عبور بخشی از MVP نیست. دلایل:\n- افزایش سطح حمله\n- نیاز به بازیابی رمز\n- نیاز به سیاست‌های پیچیده امنیتی\n- تجربه کاربری ضعیف‌تر نسبت به Magic Code"
    },
    {
      "level": 3,
      "heading": "A5 — حذف Discord Authentication",
      "content": "Discord Login از نقشه راه فعال حذف شود. دلایل:\n- عدم تضمین تأییدشدگی ایمیل در تمام سناریوها\n- پیچیدگی لینک حساب‌ها\n- ارزش پایین نسبت به Google"
    },
    {
      "level": 3,
      "heading": "A6 — Magic Code به جای Magic Link",
      "content": "روش رسمی ورود بدون رمز: **Magic Code** — نه Magic Link. دلایل:\n- تجربه یکسان در دسکتاپ و موبایل\n- عدم وابستگی به باز شدن ایمیل روی همان دستگاه\n- عدم جابه‌جایی ناخواسته بین دستگاه‌ها"
    },
    {
      "level": 3,
      "heading": "A7 — تشخیص کاربران جدید (Onboarding Detection)",
      "content": "پس از اولین ورود موفق، سیستم باید بتواند تشخیص دهد کاربر جدید است یا بازگشتی. در MVP فقط ثبت وضعیت کافی است."
    },
    {
      "level": 3,
      "heading": "A8 — معماری آینده",
      "content": "- **Phase Future — Passkeys:** پشتیبانی از Passkey و WebAuthn به عنوان Credential ثانویه.\n- **Phase Future — MFA:** پشتیبانی از TOTP و Authenticator Apps به عنوان لایه امنیتی اختیاری.\n- **Phase Future — Transaction Verification:** برای عملیات حساس (Withdrawal, Payout, Settlement) امکان فعال‌سازی TOTP یا Passkey Confirmation.\n\n---"
    },
    {
      "level": 2,
      "heading": "پیامدها",
      "content": "**Consequences**"
    },
    {
      "level": 3,
      "heading": "پیامدهای مثبت",
      "content": "- **حذف سطح حمله:** عدم ذخیره‌سازی رمز عبور، خطر افشای credentialهای احراز هویت را به حداقل می‌رساند.\n- **UX یکپارچه:** کاربران بدون نیاز به انتخاب بین «ورود» و «ثبت‌نام» از یک مسیر واحد استفاده می‌کنند.\n- **انعطاف‌پذیری:** افزودن روش‌های جدید (Passkey, TOTP) در آینده بدون تغییر معماری هسته امکان‌پذیر است.\n- **سادگی پیاده‌سازی:** Kratos به صورت بومی از OIDC و Code method پشتیبانی می‌کند."
    },
    {
      "level": 3,
      "heading": "پیامدهای منفی",
      "content": "- **حذف Discord:** کاربرانی که تنها حساب Discord دارند، نمی‌توانند با آن وارد شوند.\n- **وابستگی به ایمیل:** کاربران بدون دسترسی به ایمیل، قادر به ورود نخواهند بود (نیاز به راهکار جایگزین در آینده).\n- **تغییر در Kratos Config:** نیاز به فعال‌سازی `code` و `oidc` methods و غیرفعال‌سازی `password`.\n\n---"
    },
    {
      "level": 2,
      "heading": "اسناد متأثر",
      "content": "**Impacted Documents**\n\n- ADR-Backend-002 — بازنویسی بخش روش‌های احراز هویت\n- auth-service.md — حذف password, افزودن Magic Code + Google\n- platform/Architecture.md — بروزرسانی لایه هویت\n- backend/roadmap.md — تغییر M1.1\n- authentication_authorization_flow.md — بروزرسانی دیاگرام\n- gateway/blueprint.md — بروزرسانی جریان ورود\n- gateway/README.md — بروزرسانی سناریوی ورود\n- security-policy.md — به‌روزرسانی سیاست JWT\n- frontend/index.md — افزودن استانداردهای UX برای ورود یکپارچه"
    }
  ]
}