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

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

#oauth #authentication #security #recreated

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

ملخص

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

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

يحل OAuth 2.1 هذه المشكلة من خلال السماح للمستخدمين بتفويض تطبيقك باستخدام حساب لديهم بالفعل — 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 (الذي تم الانتهاء منه في عام 2012) ثوريًا ولكنه كان يحتوي على ثغرات أمنية. OAuth 2.1 هو دمج يزيل التدفقات المهجورة ويجعل الأمان هو الوضع الافتراضي.

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

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

تدفق OAuth التقليدي عرضة لاعتراض رمز التفويض في تطبيقات الهاتف والتطبيقات أحادية الصفحة (SPA). يعالج PKCE هذا بإضافة تحدٍ تشفيري.

التدفق مع PKCE:

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

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

إزالة التدفق الضمني (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

الاستجابة:

{
  : "ya29.a0AfH6SMB...",
  : 3599,
  : "1//0gkPFV...",
  : "openid profile email",
  : "Bearer"
}

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

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

الاستجابة:

{
  : "123456789",
  : "user@example.com",
  : true,
  : "John Doe",
  : "https://..."
}

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

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

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

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

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

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

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

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

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

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

// Node.js مع 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;

  // تخزين الرموز الجديدة (بشكل آمن، في ملفات تعريف ارتباط HttpOnly)
  return { access_token, refresh_token };
}

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

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

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

المزايا:

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

تتبنى المنصات الكبرى مفاتيح المرور: Apple و Google و Microsoft و GitHub جميعها تدعمها اعتبارًا من عام 2025.

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

// التسجيل
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 }],
    timeout: 60000,
    attestation: 'direct',
  },
});

// المصادقة
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} = await Supabase.auth.signInWithOAuth({
  provider: 'google'});

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

Auth.js v5 (المعروف سابقًا بـ NextAuth.js)

مصادقة بدون واجهة (Headless) لـ Next.js. أنت تحدد المزودين وتتولى واجهة المستخدم بنفسك.

export const { handlers} = NextAuth({
  providers: [
    Google({
      clientId: process.env.GOOGLE_CLIENT_ID      clientSecret: process.env.GOOGLE_CLIENT_SECRET    })  ]});

المميزات: مفتوح المصدر، لا يوجد تقييد لمورد معين، قابل للتخصيص بدرجة كبيرة العيوب: يتطلب إعدادًا أكثر من الخدمات المدارة؛ أنت تمتلك البنية التحتية

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

الخاتمة

يعتبر OAuth 2.1 البديل الآمن وسهل الاستخدام لمصادقة كلمات المرور. ومن خلال دمجه مع الـ passkeys وخدمات المصادقة المدارة، يمكنك بناء أنظمة مصادقة تتسم بالأمان والروعة في نفس الوقت.

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

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