بنناجح
المرحلة 2: الـ Tokens والـ JWT والـ OAuth · الدرس 4 من 4 · 45 دقيقة

OAuth 2.0 و OpenID Connect

قبل 2007، عشان تطبيق يجيب جهات اتصالك من Gmail كان بياخد باسورد Gmail نفسه. الدرس ده بيحكي إزاي OAuth حل ده، وبيمشي معاك في "Login with Google" من أول click لآخر token، وبيوريك ليه OAuth لوحده مش Authentication.

في الدرس ده هتتعلم
  • تشرح المشكلة اللي OAuth اتعمل عشانها، وأدواره الأربعة
  • تمشي في Authorization Code Flow وتعرف ليه فيه كود الأول، و state و PKCE بيعملوا إيه
  • تختار الـ flow الصح لكل موقف، وتعرف إيه اللي اتلغى وليه
  • تفرّق بين ID Token و Access Token، وتعرف أنهي باكدج لارافيل لأنهي حالة

1. OAuth 2.0 (Delegated Authorization)

المشكلة اللي اتعمل عشانها

قبل 2007، لو تطبيق عايز يجيب جهات الاتصال بتاعتك من Gmail، كان بيقولك “اكتب إيميلك وباسورد Gmail هنا”. وده معناه إن التطبيق بقى معاه حسابك كله: يقرا إيميلاتك، ويغيّر الباسورد، ويمسح كل حاجة. ومتقدرش تشيل صلاحيته غير لما تغيّر الباسورد، وده هيبوّظ كل التطبيقات التانية.

التشبيه المشهور اللي OAuth اتعمل بيه هو مفتاح الـ Valet. بعض العربيات بيبقى معاها مفتاح مخصوص بتديه لعامل الركن، يشغّل بيه العربية ويمشيها مسافة صغيرة، بس ميفتحش الشنطة ولا التابلوه. صلاحية محدودة، لغرض محدد، وتقدر تاخدها منه.

الأدوار الأربعة

الدور معناه في مثال “shop-lab يقرا صورتك من Google”
Resource Owner صاحب الداتا إنت
Client التطبيق اللي عايز صلاحية shop-lab
Authorization Server اللي بيسألك وبيطلّع الـ tokens accounts.google.com
Resource Server الـ API اللي فيه الداتا Google People API

كلمات هتقابلها

  • Client ID: اسم التطبيق بتاعك عند Google، ومش سر.
  • Client Secret: باسورد التطبيق، ولازم يفضل على السيرفر بس.
  • Redirect URI: العنوان اللي Google هيرجّعك عليه. لازم يكون متسجل مسبقاً بالظبط، وإلا أي حد يقدر يخلي Google يبعت الكود لموقعه.
  • Scope: الصلاحيات المطلوبة، زي profile و email.
  • Consent Screen: الشاشة اللي بتقولك “shop-lab عايز يشوف اسمك وإيميلك. توافق؟”.

OAuth بيدّي التطبيق Access Token بـ scopes محددة: صلاحية محدودة، وتقدر تعملها revoke، ومن غير ما الباسورد يوصل للتطبيق.

2. Authorization Code Flow و PKCE

Login with Google في shop-labمحاكاة
0

دوس ▶ شغّل، أو امشي خطوة خطوة بالأسهم.

متصفحكUsershop-labClient (server)GoogleAuthorization Serverclick "Login with Google"1state + code_verifier → session2302 → accounts.google.com3login + consent4302 → /callback?code=XYZ&state5GET /callback?code=XYZ&state6state matches? ✓7POST /token (code, secret, verifier)8SHA256(verifier) == challenge?9access_token + id_token10GET /userinfo11logged in ✓12click302consentcodecodecode+secrettokensaccesssession

ليه كود الأول وبعدين token؟ ليه مش token على طول؟

الطلب بيعدّي على طريقين مختلفين:

  • Front Channel: الـ redirects اللي بتعدّي في المتصفح. أي حاجة هنا بتظهر في الـ URL والـ history والـ logs وممكن extension يقراها.
  • Back Channel: الـ request المباشر من السيرفر بتاعك لسيرفر Google. محدش شايفه.

عشان كده اللي بيعدّي في المتصفح هو كود: صالح لاستخدام واحد ولدقيقة تقريباً، ومينفعش يتبدّل من غير الـ client secret. والـ token الحقيقي بييجي في الـ back channel بس.

الـ state بيعمل إيه؟

من غيره، الهاكر يقدر يبدأ login بحسابه هو على Google، ياخد كود، ويبعتلك لينك الـ callback بالكود بتاعه. إنت تفتحه، فتلاقي نفسك داخل shop-lab بحساب الهاكر، وأي كارت تضيفه أو عنوان تكتبه يروح لحسابه. ده Login CSRF.

Login CSRF: لو مفيش stateمحاكاة
0

دوس ▶ شغّل، أو امشي خطوة خطوة بالأسهم.

الهاكرAttackerمتصفحكVictimshop-labno state checkstart Google login (his account)1code=EVIL (stopped here)2link: /callback?code=EVIL3GET /callback?code=EVIL4logged in as HACKER5loginEVILlinkEVILsession

الـ state رقم عشوائي بيتحط في الـ session قبل التحويل لـ Google، ولازم يرجع زي ما هو. لو مش مطابق، ترفض.

PKCE (بتتنطق “بِكسي”)

تطبيق الموبايل أو الـ SPA مينفعش يبقى معاه client secret، لأن أي حد يفك التطبيق هيلاقيه. ومن غير secret، أي حد يسرق الكود في السكة (مثلاً تطبيق خبيث سجّل نفس الـ redirect scheme على الموبايل) يقدر يبدّله.

  1. قبل ما يبدأ، التطبيق يعمل نص عشوائي اسمه code_verifier ويحتفظ بيه.
  2. يبعت لـ Google الـ hash بتاعه بس، واسمه code_challenge.
  3. وقت تبديل الكود، يبعت الـ code_verifier الأصلي.
  4. Google يعمل hash ويقارن. اللي سرق الكود معاهوش الـ verifier، لأنه عمره ما عدّى في الـ front channel.

شغّل المحاكي مرة بـ PKCE ومرة من غيره:

PKCE خطوة بخطوةSHA-256 حقيقي
  1. التطبيق يعمل سر عشوائي ويحتفظ بيه: …code_verifier · مبيخرجش من التطبيق
  2. يبعت لـ Google الـ hash بتاعه بس: …code_challenge = BASE64URL(SHA256(verifier))
  3. Google يرجّع كود في الـ redirect (front channel): code=XYZ
  4. وقت التبديل:
    التطبيق الحقيقيcode=XYZ + verifier
    ☠ الهاكرcode=XYZ + ???
دوس شغّل.

PKCE اتعمل الأول للموبايل، وبعدين بقى مطلوب لكل الـ clients في OAuth 2.1، حتى اللي معاهم secret.

الكود بيعدّي في المتصفح والـ token بيعدّي بين السيرفرات، و state بيحمي من Login CSRF، و PKCE بيضمن إن اللي سرق الكود ميقدرش يستخدمه.

3. باقي الـ Flows (Grant Types)

الـ Flow بيتستخدم إمتى مثال الحالة
Authorization Code + PKCE فيه مستخدم بني آدم Login with Google، تطبيق موبايل الأساسي
Client Credentials سيرفر بيكلم سيرفر من غير مستخدم سيرفر الشحن بيسحب الأوردرات الجديدة كل ساعة مستخدم
Device Authorization جهاز ملوش كيبورد Smart TV يقولك “روح على الموبايل واكتب الكود ABCD” مستخدم
Refresh Token تجديد الـ access token الدرس اللي فات مستخدم
Implicit كان للـ SPAs: الـ token بيرجع في الـ URL على طول - اتلغى: الـ token بيعدّي في الـ front channel
Password (ROPC) التطبيق ياخد اليوزر والباسورد ويبدلهم بـ token - اتلغى: ده بالظبط اللي OAuth اتعمل عشان يمنعه

اختبر نفسك: أنهي flow لكل موقف؟

أنهي Flow؟0 / 5

اختار الـ flow المناسب.

لو فيه مستخدم استخدم Authorization Code مع PKCE، ولو مفيش مستخدم استخدم Client Credentials، والاتنين التانيين اتلغوا في OAuth 2.1.

4. OpenID Connect (OIDC)

OAuth لوحده مش Authentication

الـ Access Token زي كارت فندق: بيفتح أوضة 304، بس مكتوبش عليه اسم مين. أي حد ماسكه يدخل. الـ Access Token بيقول “مسموحلك تقرا الـ contacts”، ومش بيقول “اللي معاك ده محمد”.

الناس كانت بتستخدم OAuth للـ login بطريقة غلط: تاخد access token وتسأل بيه “مين صاحبك؟”. المشكلة إن access token معمول لتطبيق تاني ممكن يتقبل عندك، ومتقدرش تفرّق. وكل شركة كانت عاملة الحكاية دي بطريقتها.

OIDC وحّد الحل:

  • بتضيف openid للـ scopes.
  • بترجعلك ID Token فيه sub (رقم المستخدم الثابت عند Google)، و aud = الـ Client ID بتاعك بالظبط، و nonce بيمنع إن الـ token يتعاد استخدامه.
  • فيه endpoint ثابت اسمه /.well-known/openid-configuration بيقولك كل الـ URLs والمفاتيح.
ID Token Access Token
بيجاوب على المستخدم مين؟ مسموحلي بإيه؟
معمول لمين الـ Client (تطبيقك) الـ Resource Server (الـ API)
شكله JWT دايماً أي شكل، وممكن opaque
تبعته لـ API؟ لأ أيوه

SSO و SAML

SSO (Single Sign-On) معناه إنك تدخل مرة واحدة وتفتح كل الأنظمة، زي ما Gmail و YouTube و Drive بيفتحوا بحساب واحد. OIDC هو الطريقة الحديثة لده. أما SAML فطريقة أقدم مبنية على XML، ولسه منتشرة جوه الشركات الكبيرة.

OAuth 2.0 بروتوكول Authorization (Delegated Access)، و OpenID Connect طبقة فوقه بتضيف Authentication عن طريق الـ ID Token.

5. الخريطة في لارافيل

الباكدج بتعمل إيه استخدمها لما
Sanctum (SPA mode) session cookies للـ SPA بتاعتك Vue أو React على نفس الـ domain
Sanctum (API tokens) Opaque tokens متخزن منها hash تطبيق موبايل، أو tokens يعملها المستخدم لنفسه
Passport OAuth 2.0 Server كامل إنت اللي عايز تبقى “Google”: تطبيقات تانية تطلب صلاحيات على حسابات مستخدمينك
Socialite OAuth Client “Login with Google” أو GitHub في موقعك

Sanctum لتطبيقاتك إنت، و Socialite عشان تدخل بحساب برا، و Passport لما إنت اللي تبقى مزوّد الهوية.

أسئلة الإنترفيو

فكّر في إجابتك الأول، وبعدين افتح السؤال.

01OAuth 2.0 ده Authentication؟

لأ، ده delegated authorization. الـ access token بيقول مسموحلك بإيه ومش بيقول إنت مين. الـ authentication فوقه هو OpenID Connect، اللي بيدّي ID Token فيه sub و aud.

02ليه Authorization Code Flow فيه كود الأول بدل token على طول؟

لأن الـ redirect بيعدّي في المتصفح (front channel)، وأي حاجة فيه ممكن تتسرب من الـ URL أو الـ history أو الـ logs. الكود صالح لمرة واحدة ولوقت قصير ومحتاج client secret أو PKCE عشان يتبدّل. والـ token بييجي في الـ back channel بس.

03إيه هو PKCE وليه بنحتاجه؟

التطبيق يعمل code_verifier عشوائي ويبعت الـ hash بتاعه (code_challenge) في البداية، وبعدين يبعت الـ verifier وقت التبديل. اللي يسرق الكود معاهوش الـ verifier. اتعمل للموبايل والـ SPA اللي مينفعش يبقى معاهم secret، وبقى مطلوب للكل في OAuth 2.1.

04الـ state parameter بيعمل إيه؟

بيمنع Login CSRF. من غيره الهاكر يخليك تكمّل login بالكود بتاعه، فتدخل بحسابه. الـ state رقم عشوائي في الـ session قبل التحويل، ولازم يرجع زي ما هو.

05ليه الـ Implicit و Password grants اتلغوا؟

الـ Implicit بيرجّع الـ token في الـ URL، يعني في الـ front channel. والـ Password grant بيدّي التطبيق باسورد المستخدم، وده عكس هدف OAuth كله. وبقى بديلهم Authorization Code مع PKCE.

06الفرق بين ID Token و Access Token؟

الـ ID Token معمول لتطبيقك عشان يعرف المستخدم مين، ودايماً JWT، ومتبعتوش لـ API. الـ Access Token معمول للـ API عشان يحدد الصلاحيات، وممكن يبقى أي شكل.

07في Login with Google، تربط المستخدم بالإيميل ولا بإيه؟

بالـ sub، لأنه ثابت ومميز عند الـ provider. الإيميل بيتغيّر، وممكن ميكونش متأكد منه عند بعض الـ providers، والربط بيه ممكن يسمح لحد يدخل على حساب حد تاني.

08صمم الـ Auth لمتجر فيه موقع وتطبيق موبايل وشركات شحن.

الموقع: session cookies بـ HttpOnly و SameSite و CSRF tokens. الموبايل: Authorization Code + PKCE أو Sanctum tokens، مع access قصير و refresh بـ rotation ومتخزنين في Keychain أو Keystore. شركات الشحن: Client Credentials بـ scopes محدودة زي orders:read. ولو النظام اتقسم services: JWT بـ RS256 والـ services تتأكد بالـ JWKS. وفي كل ده rate limiting على الـ login والـ token endpoints.

علّم عليه لما تقدر تجاوب أسئلة الإنترفيو من غير ما تبص.