OAuth2 ו-OIDC: ההבדל שמפתחים רבים מתבלבלים בו

מאת צוות מדיה דיל · 05.08.2026 · אבטחת מידע · 6 דק׳

OAuth2 ו-OpenID Connect נשמעים דומים ולעיתים קרובות מוטמעים ביחד, אבל הם פותרים שאלות שונות לגמרי: הרשאה מול זהות.

"התחברות עם Google" באתר משתמשת בשילוב של שתי טכנולוגיות שנשמעות דומות אבל פותרות שאלות שונות לגמרי: OAuth2 עונה על "מה מותר לאפליקציה הזו לעשות בשמי", ו-OpenID Connect (OIDC) עונה על "מי אתה בכלל".

OAuth2: פרוטוקול הרשאה, לא זהות

OAuth2 נועד במקור לפתור בעיית הרשאה: לאפשר לאפליקציה גישה מוגבלת למשאבים בשם משתמש, בלי שהמשתמש ייתן לה את הסיסמה שלו. לדוגמה, לאשר לאפליקציית תמונות גישת קריאה בלבד לתיקיית Google Drive — בלי לחשוף לה את חשבון Google המלא.

הטעות הנפוצה: להשתמש ב-OAuth2 לזיהוי

הרבה מפתחים השתמשו ב-OAuth2 גם לזיהוי משתמשים — "אם הצליח לקבל טוקן גישה, זה אומר שזה המשתמש הנכון". הבעיה: OAuth2 לא נועד לזה במקור, ואין בו דרך סטנדרטית לוודא באופן מהימן מי בדיוק המשתמש. זה בדיוק הפער ש-OIDC בא לסגור.

OpenID Connect: שכבת זהות מעל OAuth2

OIDC נבנה כשכבה נוספת מעל OAuth2, ומוסיף ID Token — אסימון חתום שמכיל מידע מאומת על זהות המשתמש (מזהה, אימייל, שם). בעוד Access Token של OAuth2 אומר "מה מותר לך לעשות", ID Token של OIDC אומר "מי אתה בוודאות".

Access Token מול ID Token

Access Token נשלח לשרת המשאבים (למשל Google Drive API) כדי לאשר גישה בפועל, ולרוב לא צריך להיות מובן על ידי האפליקציה עצמה. ID Token נועד לאפליקציה עצמה — היא מפענחת אותו כדי לדעת מי המשתמש שהתחבר, ולא אמורה לשלוח אותו הלאה לשום שרת אחר.

Authorization Code Flow: הזרימה המומלצת

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

PKCE: הגנה נוספת לאפליקציות ציבוריות

אפליקציות מובייל או Single Page Applications, שלא יכולות לשמור סוד לקוח בבטחה, משתמשות בהרחבת PKCE שמוסיפה אימות קריפטוגרפי נוסף לזרימה — כך שגם אם קוד ההרשאה נחשף, תוקף לא יכול להשתמש בו בלי הסוד שנוצר רק בצד הלקוח המקורי.

למה זה קריטי גם למערכות AI

סוכן AI שמתחבר בשם משתמש למערכות חיצוניות — יומן, מייל, CRM — צריך להשתמש בדיוק באותם עקרונות: הרשאה מוגבלת (OAuth2) שמאפשרת רק את מה שבאמת נדרש, לא גישה גורפת. זו אותה עקרון הרשאה מינימלית שהרחבנו עליו במאמר על Zero Trust Architecture.

Refresh Token: הארכת הרשאה בלי התחברות חוזרת

Access Token תקף לרוב לזמן קצר יחסית (דקות עד שעות), כדי לצמצם נזק אם הוא נגנב. Refresh Token, בעל תוקף ארוך יותר, מאפשר לקבל Access Token חדש בלי לדרוש מהמשתמש להתחבר מחדש — אבל דורש אחסון זהיר במיוחד, כי גניבה שלו מאפשרת חידוש הרשאה מתמשך.

Scope: הגבלת ההרשאה לפרטים המדויקים

מעבר לזהות עצמה, OAuth2 מאפשר להגדיר Scope מדויק — בדיוק אילו נתונים ואילו פעולות מותרים לאפליקציה המבקשת. בקשת Scope רחב מדי "ליתר ביטחון" היא טעות אבטחה נפוצה; הבקשה הנכונה מצומצמת בדיוק למה שהאפליקציה באמת צריכה לתפקד.

State ו-Nonce: הגנה מפני התקפות CSRF

פרמטר State שנוצר לפני תחילת הזרימה ונבדק בסיומה מונע התקפות CSRF שבהן תוקף מנסה לגרום לקורבן להשלים זרימת התחברות בשמו. Nonce, באופן דומה, מונע שימוש חוזר בזדון ב-ID Token שנחשף. שני הפרמטרים קטנים בקוד אבל קריטיים לאבטחה בפועל.

בונים מערכת התחברות או הרשאות ואתם רוצים לוודא שהיא בנויה נכון? מוזמנים לפתוח שיחה בוואטסאפ.

תגיות: OAuth2 · OpenID Connect · OIDC · Authentication · Authorization

על הכותב

קובי חן — מייסד ו-CTO של מדיה דיל. מוביל פיתוח דיגיטלי מאז 2017, עם מעל 450 פרויקטים שליווה מאפיון ועד השקה. מפתח Full Stack (React, Next.js, Node.js, Supabase, Vercel, AWS) ומומחה למודלי בינה מלאכותית: בחירת מודל והתאמתו למשימה, הנדסת פרומפטים, RAG ועיגון בידע ארגוני, קריאה לכלים ובניית סוכנים אוטונומיים על מודלי שפה גדולים. מתמחה במערכות פרודקשן מורכבות — פלטפורמות SaaS, מנועי SEO בקנה מידה גדול, סוכני AI ואוטומציות עסקיות, כולן בבעלות מלאה של הלקוח לרבות הקוד.

הפרופיל המלא

מאמרים נוספים

לשיחת ייעוץ · למחירון · ← חזרה לבלוג