أطلق العنان لقوة OAUTH: رحلة نحو تطبيقات آمنة وموثوقة

تم التحديث: ٢٧ مارس ٢٠٢٦

#oauth #authentication #security #recreated

Unlock the Power of OAUTH a Journey to Secure and Reliable Applications

ملخص

يحل OAuth 2.0 (مع توحيد OAuth 2.1 الجاري حاليًا) محل المصادقة القائمة على كلمة المرور بتفويض مفوض — حيث يمنح المستخدمون تطبيقك الإذن دون مشاركة بيانات الاعتماد. تجعل مسودة OAuth 2.1 تقنية PKCE إلزامية لـ جميع العملاء في تدفق رمز التفويض (وليس فقط العملاء العامين)؛ وتوفر مفاتيح المرور/WebAuthn بديلًا بدون كلمة مرور؛ وتتعامل منصات مثل Auth0 وClerk وBetter Auth وAuth.js (المعروف سابقًا باسم NextAuth.js) مع تعقيدات OAuth، مما يترك لك المجال للتركيز على تطبيقك.

لقد قام كل مطور ببناء نموذج تسجيل دخول. اسم مستخدم، كلمة مرور، تخزينها بشكل آمن، تشفيرها (hash)، والتحقق منها مع كل طلب. إنها طريقة تعمل، لكنها مملة وعرضة للأخطاء. كما يكره المستخدمون إدارة كلمات المرور عبر عشرات التطبيقات.

يحل OAuth هذه المشكلة من خلال السماح للمستخدمين بتفويض تطبيقك باستخدام حساب لديهم بالفعل — Google، GitHub، Apple، إلخ. أنت لا ترى كلمة مرورهم أبدًا. يقومون بالمصادقة مع المزود، ويمنحون تطبيقك الإذن، وتتلقى أنت رمزًا (token) يثبت أنهم وافقوا على وصولك.

في عام 2026، أصبحت المصادقة القائمة على كلمة المرور اختيارية للعديد من المستخدمين. يهيمن OAuth على تسجيل الدخول الاجتماعي. وتكتسب مفاتيح المرور (WebAuthn) أرضية في المنصات الكبرى. وتتعامل الخدمات المدارة مثل Auth0 وClerk وSupabase Auth مع التعقيد، مما يتيح لك تنفيذ مصادقة آمنة في دقائق.

يشرح هذا الدليل تدفق OAuth، والممارسات الأمنية الحديثة، وكيفية دمجها في تطبيقك.

المشكلة التي يحلها OAuth

تخيل أن مستخدمًا يريد ربط تطبيقك بحسابه على Google Drive. تقليديًا، كنت ستطلب منه كلمة مرور Google الخاصة به. يكتبها، وتقوم بتخزينها، والآن لديك كلمة مروره — وهو خطر أمني هائل.

يقضي OAuth على هذا. بدلًا من ذلك، يعمل التدفق على النحو التالي:

ينقر المستخدم على "تسجيل الدخول باستخدام Google"
تقوم بتوجيهه إلى صفحة تسجيل الدخول الخاصة بـ Google
تسأل Google: "هل تريد منح حق الوصول لـ [تطبيقك]؟" — مع إظهار الأذونات التي تحتاجها بالضبط
ينقر المستخدم على "سماح"
تقوم Google بإعادة التوجيه إلى تطبيقك مع رمز تفويض (authorization code)
يقوم الجزء الخلفي (backend) الخاص بك بتبديل الرمز برمز وصول (token)
تستخدم الرمز للوصول إلى بيانات المستخدم نيابة عنه

لا يشارك المستخدم كلمة مرور Google الخاصة به معك أبدًا. ولا تشارك Google كلمة المرور معك أبدًا. الجميع رابح.

OAuth 2.1: اتجاه المسار

كان OAuth 2.0 (RFC 6749، أكتوبر 2012) ثوريًا ولكنه كان يحتوي على ثغرات أمنية. OAuth 2.1 هو توحيد يزيل التدفقات المهجورة ويجعل الأمان هو الوضع الافتراضي. اعتبارًا من مايو 2026، لا يزال OAuth 2.1 مسودة إنترنت نشطة من IETF (draft-ietf-oauth-v2-1-15، نُشرت في مارس 2026) ولم يتم اعتمادها نهائيًا بعد كـ RFC. ومع ذلك، فإن توصياتها الأمنية معتمدة بالفعل في الممارسة العملية — حيث يتعامل مزودو الهوية والأطر الرئيسية مع أنواع المنح المهجورة على أنها محظورة اليوم.

التغييرات الرئيسية في OAuth 2.1

أصبح PKCE (مفتاح الإثبات لتبادل الرموز) إلزاميًا لكل عميل

أوصى OAuth 2.0 فقط بـ PKCE للعملاء العامين (تطبيقات الهاتف، SPA). تتطلب مسودة OAuth 2.1 ذلك لـ جميع العملاء الذين يستخدمون تدفق رمز التفويض، بما في ذلك العملاء السريين الذين لديهم سر عميل (client secret). تدفق OAuth التقليدي عرضة لاعتراض رمز التفويض، خاصة في تطبيقات الهاتف والتطبيقات أحادية الصفحة. يحل PKCE هذا عن طريق إضافة تحدٍ تشفيري.

التدفق مع PKCE:

إنشاء code_verifier عشوائي (43-128 حرفًا)
تشفيره (hashing) لإنشاء code_challenge
تضمين code_challenge في طلب التفويض الأولي
عند تبديل الرمز، قم بتضمين الـ code_verifier الأصلي
يتحقق المزود من أن تشفير المحقق يطابق التحدي

هذا يثبت أن الكيان الذي يستبدل الرمز هو نفسه الذي بدأ عملية تسجيل الدخول.

إزالة التدفق الضمني (Implicit flow)

أصبح التدفق الضمني (إرجاع الرموز مباشرة في عنوان URL) محظورًا الآن. استخدم دائمًا تدفق رمز التفويض مع PKCE.

توقع إبطال الرموز (Token revocation)

يجب أن تكون التطبيقات قادرة على إبطال الرموز عندما يسجل المستخدمون خروجهم. يجب على المزودين دعم نقاط نهاية الإبطال.

تدفق رمز التفويض مع PKCE

إليك تدفق OAuth الحديث الكامل:

الخطوة 1: إعادة التوجيه إلى المزود

GET https://accounts.google.com/o/oauth2/v2/auth?
  client_id=YOUR_CLIENT_ID&
  redirect_uri=https://yourapp.com/callback&
  response_type=code&
  scope=openid profile email&
  code_challenge=YOUR_CODE_CHALLENGE&
  code_challenge_method=S256

الخطوة 2: المستخدم يقوم بالمصادقة ومنح الإذن تتعامل واجهة مستخدم Google مع هذا. يسجل المستخدم دخوله (إذا لم يكن قد فعل ذلك بالفعل) ويرى شاشة الموافقة.

الخطوة 3: إعادة التوجيه مرة أخرى مع رمز التفويض

GET https://yourapp.com/callback?
  code=4/0AX4XfWh...&
  state=random_state_value

الخطوة 4: الجزء الخلفي يبدل الرمز برمز وصول

POST https://oauth2.googleapis.com/token

client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET&
code=4/0AX4XfWh...&
code_verifier=YOUR_CODE_VERIFIER&
grant_type=authorization_code

الاستجابة:

{
  "access_token": "ya29.a0AfH6SMB...",
  "expires_in": 3599,
  "refresh_token": "1//0gkPFV...",
  "scope": "openid profile email",
  "token_type": "Bearer"
}

الخطوة 5: استخدام الرمز

GET https://www.googleapis.com/oauth2/v2/userinfo
Authorization: Bearer ya29.a0AfH6SMB...

الاستجابة:

{
  "id": "123456789",
  "email": "user@example.com",
  "verified_email": true,
  "name": "John Doe",
  "picture": "https://..."
}

أمان الرموز: التخزين والتدوير

تخزين الرموز بشكل آمن أمر بالغ الأهمية. الرموز هي في الأساس كلمات مرور — يمكن لأي شخص يمتلكها الوصول إلى بيانات المستخدم.

أين يتم تخزين الرموز

لا تستخدم: localStorage أو sessionStorage الرموز في JavaScript عرضة لهجمات XSS (حقن البرمجيات الخبيثة عبر المواقع). يمكن لبرنامج نصي ضار سرقتها.

استخدم: ملفات تعريف الارتباط (cookies) من نوع HTTP-only قم بتمييز ملفات تعريف الارتباط كـ HttpOnly حتى لا يتمكن JavaScript من الوصول إليها. يقوم المتصفح بتضمينها تلقائيًا في الطلبات.

Set-Cookie: access_token=ya29.a0AfH6SMB...; HttpOnly; Secure; SameSite=Strict

علامة Secure: يتم الإرسال عبر HTTPS فقط SameSite=Strict: منع هجمات CSRF عن طريق رفض إرسال ملفات تعريف الارتباط عبر المواقع

تدوير رمز التحديث (Refresh Token Rotation)

تنتهي صلاحية رموز الوصول (عادةً بعد ساعة واحدة). بدلًا من إجبار المستخدمين على إعادة المصادقة، استخدم رموز التحديث للحصول على رموز وصول جديدة.

يعمل تدوير رمز التحديث على تحسين الأمان: إصدار رمز تحديث جديد مع كل عملية تحديث، وإبطال الرمز القديم. إذا تم اختراق رمز تحديث، فإن نافذة استخدامه تكون محدودة.

// Node.js with axios
async function refreshAccessToken(refreshToken) {
  const response = await axios.post(
    'https://oauth2.googleapis.com/token',
    {
      client_id: process.env.GOOGLE_CLIENT_ID,
      client_secret: process.env.GOOGLE_CLIENT_SECRET,
      grant_type: 'refresh_token',
      refresh_token: refreshToken,
    }
  );

  const { access_token, refresh_token } = response.data;

  // Store new tokens (securely, in HttpOnly cookies)
  return { access_token, refresh_token };
}

مفاتيح المرور وWebAuthn: مستقبل المصادقة

بينما يتعامل OAuth مع التفويض، فإن WebAuthn (ومفاتيح المرور، وهي تنفيذ سهل الاستخدام لـ WebAuthn) تحل محل كلمات المرور للمصادقة.

مفتاح المرور هو زوج من المفاتيح التشفيرية المخزنة على جهازك. تقوم بالمصادقة عن طريق التوقيع على تحدٍ بمفتاحك الخاص — لا حاجة لكلمة مرور.

المزايا:

مقاومة للتصيد الاحتيالي (المفاتيح تعمل فقط على الموقع الصحيح)
لا توجد كلمة مرور لنسيانها أو اختراقها
تعتمد على المقاييس الحيوية أو رمز PIN (بصمة الإصبع، Face ID، Windows Hello)
متزامنة عبر الأجهزة (iCloud Keychain، Google Password Manager)

اعتمدت المنصات الكبرى مفاتيح المرور: أطلقت Apple دعم مفاتيح المرور في iOS 16 (سبتمبر 2022)، وجعلت GitHub مفاتيح المرور متاحة بشكل عام في سبتمبر 2023، ولدى Google وMicrosoft دعم كامل لمفاتيح المرور عبر Chrome/Android وEdge/Windows على التوالي. بحلول عام 2026، أبلغ تحالف FIDO عن أكثر من مليار مفتاح مرور مفعل عبر المنصات.

استخدام مفاتيح المرور في تطبيقك:

// Registration
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: new Uint8Array(32),
    rp: { name: 'My App' },
    user: {
      id: new Uint8Array(16),
      name: 'user@example.com',
      displayName: 'John Doe',
    },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },   // ES256
      { type: 'public-key', alg: -257 }, // RS256
    ],
    timeout: 60000,
    attestation: 'none', // 'none' is recommended for most apps; only request 'direct' if you need to inspect attestation
  },
});

// Authentication
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: new Uint8Array(32),
    timeout: 60000,
    userVerification: 'preferred',
  },
});

للإنتاج، استخدم مكتبة مثل @simplewebauthn/browser.

مزودو ومكتبات OAuth الشائعة

Auth0

منصة هوية كاملة. تتعامل Auth0 مع OAuth، وتسجيلات الدخول الاجتماعية، والمصادقة بدون كلمة مرور، وMFA، والمزيد.

import { ManagementClient } from 'auth0';

const management = new ManagementClient({
  domain: 'yourapp.auth0.com',
  clientId: 'YOUR_CLIENT_ID',
  clientSecret: 'YOUR_CLIENT_SECRET',
});

const users = await management.getUsers();

المميزات: ميزات كاملة، توثيق ممتاز، مناسب للمؤسسات العيوب: يزداد السعر مع عدد المستخدمين؛ قد يكون مبالغًا فيه للتطبيقات البسيطة

Clerk

مصادقة حديثة لعصر تطوير التطبيقات. توفر Clerk مكونات واجهة مستخدم جاهزة، وإدارة الجلسات، وOAuth، وكل ذلك مع التركيز على تجربة المطور.

import { ClerkProvider } from '@clerk/nextjs';

export default function App({ Component, pageProps }) {
  return (
    <ClerkProvider>
      <Component {...pageProps} />
    </ClerkProvider>
  );
}

المميزات: تجربة مطور (DX) ممتازة، مبني للأطر الحديثة، خطة مجانية سخية العيوب: أحدث من Auth0؛ ميزات مؤسسية أقل شمولاً

Supabase Auth

Supabase هو بديل مفتوح المصدر لـ Firebase. يدعم نظام المصادقة الخاص به OAuth، والجلسات القائمة على JWT، والروابط السحرية (magic links).

import { createClient from '@Supabase/Supabase-js';

const Supabase = createClient(URL, KEY);

const { data, error } = await Supabase.auth.signInWithOAuth({
  provider: 'google',
});

المميزات: مفتوح المصدر، تكامل سلس مع قاعدة البيانات، قابل للاستضافة الذاتية العيوب: نظام بيئي أصغر من Auth0؛ تكاملات أقل

Auth.js (NextAuth.js سابقاً)

مصادقة بدون واجهة (Headless) لـ Next.js. أنت تحدد المزودين وتتعامل مع واجهة المستخدم بنفسك. ظل إصدار Auth.js v5 في مرحلة next-auth@beta لفترة طويلة؛ وفي سبتمبر 2025 تم تسليم الصيانة المستمرة لفريق Better Auth، ويقوم فريق Auth.js الآن بتوجيه المشاريع الجديدة نحو Better Auth مع إبقاء Auth.js في وضع التحديثات الأمنية فقط. تستمر عمليات النشر الحالية للإصدارين v4 و v5-beta في العمل، ولكن إذا كنت تبدأ من الصفر في عام 2026، فقم بتقييم Better Auth بجانبه.

// next-auth@beta (Auth.js v5)
export const { handlers, auth = NextAuth({
  providers: [
    Google({
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    }),
  ],
});

المميزات: مفتوح المصدر، لا يوجد تقيد بمورد معين (vendor lock-in)، قابل للتخصيص بدرجة كبيرة العيوب: الإصدار v5 لا يزال في مرحلة ما قبل الاستقرار؛ Better Auth هو المسار الموصى به الآن لمشاريع Next.js الجديدة؛ أنت تمتلك البنية التحتية

قائمة مراجعة التنفيذ

الخلاصة

يعد OAuth — واتجاه أفضل ممارسات OAuth 2.1 الذي يتقارب معه — هو البديل الآمن وسهل الاستخدام للمصادقة بكلمة المرور. من خلال دمجه مع مفاتيح المرور (passkeys) وخدمات المصادقة المدارة، يمكنك بناء أنظمة مصادقة آمنة ورائعة في نفس الوقت.

ابدأ بتنفيذ OAuth مع مزود اجتماعي (Google أو GitHub). أضف مفاتيح المرور عندما يكون مستخدموك مستعدين. ولا تعيد اختراع العجلة — خدمات مثل Clerk و Auth0 و Supabase Auth تتولى الأجزاء الصعبة، مما يتيح لك التركيز على منتجك الأساسي.

المصادقة التي تتم بشكل صحيح تبني الثقة. يشعر المستخدمون بالأمان مع تطبيقك، وتتجنب أنت صداع الأمان الناتج عن إدارة كلمات المرور.