איך OAuth 2.0 עובד באמת, שלב אחר שלב

כפתור "התחברות עם גוגל" נראה כמו קסם - לוחצים, מאשרים, וברגע הבא כבר מחוברים לאתר, בלי להקליד סיסמה. מאחורי הכפתור הזה עומדת זרימה מדויקת של חמישה עד שישה חילופי הודעות בין הדפדפן, האתר, ושרת ההרשאה. בואו נעבור עליה צעד אחר צעד, כי ההבנה של הזרימה הזאת היא הבסיס לכל מה שקורה סביב OAuth, כולל האופן שבו הוא נתקף.

שלושת הצדדים שמעורבים

לפני השלבים, כדאי להכיר את השחקנים. יש את האתר שאתם רוצים להתחבר אליו (client), את שרת ההרשאה שמזהה אתכם באמת (למשל גוגל), ואתכם, בעל המשאב שנותן הרשאה. המטרה של כל הזרימה היא לתת לאתר גישה מוגבלת בשמכם, בלי שהוא יראה את הסיסמה שלכם אצל גוגל בכלל.

הזרימה המלאה - Authorization Code Flow

1. הפניה לשרת ההרשאה. לוחצים "התחברות עם גוגל", והאתר מפנה אתכם לכתובת של גוגל, עם פרמטרים שמזהים איזה אתר מבקש גישה, לאילו הרשאות (scope), ולאיזו כתובת להחזיר אתכם בסוף (redirect_uri).
2. אימות והסכמה. אתם מתחברים לגוגל, אם עוד לא מחוברים, וגוגל מציגה מסך שאומר בדיוק לאילו פרטים האתר מבקש גישה. אתם מאשרים, או דוחים.
3. קבלת קוד הרשאה. אם אישרתם, גוגל מפנה אתכם בחזרה לכתובת ה-redirect_uri שהאתר ציין, עם קוד הרשאה קצר וחד-פעמי (authorization code) בכתובת. הקוד הזה עצמו עוד לא נותן גישה לשום דבר, הוא רק אישור שהתהליך הושלם בהצלחה.
4. החלפת הקוד בטוקן. האתר, מהשרת שלו ולא מהדפדפן שלכם, שולח את הקוד הזה לגוגל, יחד עם סוד לקוח (client secret) שרק לו יש, ומבקש להחליף אותו בטוקן גישה אמיתי (access token). זה קורה בערוץ שרת-לשרת, כדי שהטוקן עצמו לעולם לא יעבור דרך הדפדפן שלכם בגלוי.
5. שימוש בטוקן. מעכשיו, האתר משתמש בטוקן כדי לבקש מגוגל את המידע שהוסכם עליו, כמו כתובת האימייל שלכם, ויוצר או מזהה חשבון מתאים אצלו.

השלב שבו הקוד עובר דרך הדפדפן, אבל הטוקן עצמו לא, הוא בדיוק מה שהופך את הזרימה הזאת לבטוחה יחסית - גם אם מישהו יראה את הקוד באמצע הדרך, בלי ה-client secret הוא לא יכול להחליף אותו בטוקן אמיתי.

אז למה בכלל צריך PKCE

הזרימה שתיארנו מניחה שהאתר מסוגל לשמור סוד לקוח בבטחה, כמו שרת שרץ מאחורי חומת אש. אבל מה קורה עם אפליקציית מובייל או אפליקציית דף יחיד (SPA) שרצה כולה בצד הלקוח? קוד שרץ על המכשיר של המשתמש אי אפשר להסתיר לגמרי, כל סוד שמוטמע בו אפשר תאורטית לחלץ.

בשביל המקרה הזה קיים תוסף לפרוטוקול בשם PKCE, ראשי תיבות של Proof Key for Code Exchange. במקום סוד קבוע, האפליקציה יוצרת בעצמה, בכל התחברות מחדש, ערך אקראי חד-פעמי (code verifier), שולחת גרסה מוצפנת שלו (code challenge) יחד עם בקשת ההרשאה בשלב 1, ובשלב 4, כשהיא מחליפה את הקוד בטוקן, היא שולחת את הערך המקורי כדי להוכיח שהיא אותה אפליקציה שהתחילה את התהליך. אפילו אם מישהו יירט את קוד ההרשאה, בלי ה-code verifier המקורי הוא לא יכול להשלים את ההחלפה לטוקן.

למה זה חשוב להבין ולא רק להשתמש בספרייה

כמעט אף אחד לא מממש את הזרימה הזאת ידנית - יש ספריות מוכרות שעושות את זה. אבל מפתח שמבין את שלבי הזרימה מבין גם מה קורה כשמשהו נכשל, למה יש שני סוגי טוקן (access ו-refresh), ולמה redirect_uri חייב להיות רשום מראש בקפדנות. זו בדיוק ההבנה שהופכת דיבוג של בעיית התחברות מ"זה סתם לא עובד" לזיהוי מדויק של השלב שנכשל.

בקורס צד-שרת בונים זרימת אימות אמיתית עם ספק חיצוני מהיסודות, כדי שתבינו לא רק את התיאוריה אלא גם את הפרטים שמפילים מתחילים.

יש לכם באג בזרימת התחברות שלכם ולא ברור באיזה שלב זה נשבר? זה בדיוק סוג הדבר שכיף לפתור בדיסקורד.

הצטרפו לקהילה בדיסקורד

לסיכום

OAuth הוא לא קסם, הוא זרימה מוגדרת היטב של הפניות וחילופי טוקנים, שנועדה לתת לאתר גישה מוגבלת בשמכם בלי שהוא יראה את הסיסמה שלכם. קוד ההרשאה עובר דרך הדפדפן, הטוקן האמיתי מוחלף רק בערוץ שרת-לשרת, ו-PKCE סוגר את הפער עבור אפליקציות שלא יכולות לשמור סוד בבטחה.