OpenID Connect: איך OAuth 2.0 הופך לאימות זהות אמיתי

מאת צוות מדיה דיל · 07.08.2026 · API Engineering · 8 דק׳

OAuth 2.0 נותן הרשאת גישה, לא הוכחת זהות. OpenID Connect סוגר את הפער — ID Token, discovery אוטומטי, ו-SSO ארגוני. מדריך עומק.

כל צוות שמנסה להוסיף "התחברות עם Google" או single sign-on ארגוני לאפליקציה שלו נתקל מהר מאוד במונח OpenID Connect (OIDC), ולעיתים קרובות מתבלבל בינו לבין OAuth 2.0 שממנו הוא נבנה. הבלבול הזה לא מקרי — OIDC הוא בפועל שכבה דקה שנבנתה מעל OAuth 2.0, ומשתמשת באותם flows ובאותה תשתית, אבל פותרת בעיה שונה לחלוטין: OAuth 2.0 עונה על "האם לאפליקציה הזו יש הרשאה לפעול בשמי מול משאב מסוים", בעוד OIDC עונה על "מי אני בכלל, בוודאות מוכחת קריפטוגרפית".

ההבחנה הזו קריטית כי צוותים רבים משתמשים ב-OAuth 2.0 לבדו כדי "לאמת" משתמשים — למשל, מקבלים access token מ-Google ומניחים שזה מוכיח את זהות המשתמש. הבעיה היא ש-access token של OAuth נועד להרשאת גישה למשאב (למשל Google Calendar API), לא לזיהוי, ואין ערבות פורמלית שהוא מכיל בכלל מידע אמין על מי המשתמש. OIDC סוגר את הפער הזה במפורש, עם token ייעודי לאימות זהות שיש לו מבנה, סמנטיקה, וערבויות אבטחה מוגדרות בבירור בתקן.

ID Token: הרכיב שמבדיל בין OIDC ל-OAuth רגיל

הרכיב המרכזי ש-OIDC מוסיף מעל OAuth 2.0 הוא ה-ID Token — JWT חתום שמכיל claims מוגדרים בתקן על זהות המשתמש: sub (מזהה ייחודי וקבוע), email, name, ולעיתים תמונת פרופיל ופרטים נוספים, בהתאם ל-scopes שהאפליקציה ביקשה. בניגוד ל-access token, שהוא בעצם "כרטיס כניסה" למשאב מסוים וייתכן שאין לו מבנה מחייב, ה-ID Token תמיד בנוי לפי מפרט קבוע שכל client יכול לפרסר ולסמוך עליו באופן עקבי.

{
  "iss": "https://accounts.example-idp.com",
  "sub": "10769150350006150715113082367",
  "aud": "client_id_12345",
  "email": "user@example.com",
  "email_verified": true,
  "exp": 1723347600
}

שדה ה-iss (issuer) וה-aud (audience) קריטיים לאימות: ה-client חייב לוודא שה-iss הוא בדיוק ה-Identity Provider שהוא מצפה לו, ושה-aud תואם ל-client_id שלו עצמו — בלי הבדיקות האלה, טוקן שהונפק לאפליקציה אחרת לגמרי עלול להתקבל בטעות כתקף.

Discovery ו-JWKS: איך client יודע איך לאמת טוקן בלי קונפיגורציה ידנית

אחד ההיבטים האלגנטיים ביותר של OIDC הוא מנגנון ה-discovery: כל Identity Provider תואם-OIDC חושף endpoint קבוע (well-known/openid-configuration) שמפרסם את כל המידע שה-client צריך — כתובות ה-authorization endpoint, token endpoint, וחשוב מכל, כתובת ה-JWKS (JSON Web Key Set) שבה נמצאים המפתחות הציבוריים לאימות חתימת הטוקנים. זה אומר ש-client לא צריך לקבל ידנית מפתח ציבורי מה-IdP ולעדכן אותו כל פעם שהוא מתחלף — הוא פשוט שולף אותו דינמית מה-endpoint המפורסם, וה-IdP יכול לסובב מפתחות בלי לתאם עם כל client בנפרד.

המנגנון הזה הוא הסיבה המרכזית ש-OIDC הפך לסטנדרט הדה-פקטו ל-single sign-on ארגוני ובין-ארגוני: כל client חדש שרוצה להתחבר ל-IdP קיים צריך רק לדעת כתובת אחת (ה-discovery endpoint), ומשם כל שאר הקונפיגורציה נטענת אוטומטית, מה שהופך אינטגרציה חדשה לעניין של דקות במקום פרויקט תיאום ארוך.

ה-Flows המרכזיים: Authorization Code ו-PKCE

Authorization Code Flow הוא הזרימה המומלצת לרוב האפליקציות עם משתמש קצה — משתמש מועבר ל-IdP, מתחבר שם (לא באפליקציה עצמה, כך שהאפליקציה אף פעם לא רואה סיסמה), ומועבר חזרה עם קוד זמני קצר-טווח שהאפליקציה מחליפה ב-backend מול ה-IdP לקבלת ID Token ו-access token אמיתיים. ההחלפה קורית בצד השרת, לא בדפדפן, כדי שהטוקנים הסופיים לא יעברו דרך ה-URL או קוד JavaScript חשוף.

עבור אפליקציות שאין להן backend מאובטח (Single Page Applications, אפליקציות מובייל native), נדרש הרחבה בשם PKCE (Proof Key for Code Exchange) — מנגנון שמוסיף אימות קריפטוגרפי נוסף לתהליך, כדי למנוע מתוקף ליירט את קוד ההרשאה באמצע ולהחליף אותו בעצמו בטוקנים. PKCE הפך היום לברירת מחדל מומלצת גם לאפליקציות עם backend, לא רק ל-SPA, כי הוא מוסיף שכבת הגנה בעלות נמוכה כמעט ללא חיסרון.

Refresh Tokens: איך נשארים מחוברים בלי לסכן אבטחה

ID Token ו-access token, כפי שצוין, מיועדים לתוקף קצר יחסית — דקות עד שעה. בלי מנגנון נוסף, זה היה מחייב את המשתמש להתחבר מחדש כל פעם שהטוקן פג, חוויה בלתי אפשרית לאפליקציה אמיתית. הפתרון הוא refresh token — טוקן נפרד, ארוך-טווח משמעותית, שנשמר בבטחה בצד ה-client ומשמש לבקש טוקנים חדשים מה-IdP בלי לדרוש מהמשתמש להתחבר שוב ולהזין סיסמה מחדש.

refresh token דורש זהירות אבטחתית מיוחדת, כי משך התוקף הארוך שלו הופך אותו ליעד אטרקטיבי יותר לתקיפה מאשר access token קצר-טווח. מומלץ ליישם rotation גם עליו — בכל שימוש ב-refresh token להנפיק אחד חדש ולבטל את הישן (refresh token rotation), כך שאם refresh token נגנב ונעשה בו שימוש כפול, ה-IdP יכול לזהות את החריגה (שני שימושים באותו טוקן שכבר בוטל) ולבטל את כל השרשרת מיידית, מה שמגביל משמעותית את חלון הפגיעות גם במקרה של דליפה.

Claims מותאמים אישית ו-Scopes: מה בדיוק חושפים למי

מעבר לclaims הסטנדרטיים כמו sub ו-email, OIDC מאפשר להגדיר scopes ו-claims מותאמים אישית — למשל תפקיד ארגוני, שיוך למחלקה, או מזהה ארגון (tenant) במערכת multi-tenant. הרחבה כזו נוחה כי היא מאפשרת לכלול מידע רלוונטי ישירות בטוקן, בלי שה-client יצטרך לבצע קריאת API נוספת כדי לברר אותו. המחיר הוא שגודל הטוקן גדל, וכל שינוי בclaim (למשל שינוי תפקיד) לא משתקף מיד — המשתמש ימשיך להיראות עם התפקיד הישן עד שהטוקן הנוכחי פג ומתחדש, מה שדורש תכנון זהיר של אילו נתונים בטוח לשים בטוקן ואילו עדיף לשלוף בזמן אמת.

כלל אצבע מעשי: claims שמשתנים לעיתים רחוקות (מזהה ארגון, למשל) בטוחים לשים בטוקן; claims שמשתנים בתדירות גבוהה (הרשאות עדינות שמתעדכנות תדיר) עדיף לשלוף מה-API בזמן אמת ולא לסמוך על הטוקן, כדי למנוע מצב שבו משתמש ממשיך לפעול לפי הרשאות שכבר בוטלו.

Single Sign-On: הערך העסקי המרכזי של OIDC

מעבר לאימות בודד לאפליקציה יחידה, OIDC מאפשר Single Sign-On (SSO) אמיתי — משתמש מתחבר פעם אחת ל-IdP מרכזי (Okta, Auth0, Azure AD, Google Workspace), ומכל אפליקציה נוספת בארגון שתומכת ב-OIDC מול אותו IdP, הוא מקבל גישה בלי להתחבר שוב. זה לא רק נוחות משתמש — זה גם שיפור אבטחה ארגוני משמעותי: כשעובד עוזב את הארגון, ביטול הגישה שלו ב-IdP המרכזי חוסם אותו אוטומטית מכל האפליקציות בבת אחת, במקום לדרוש חסימה ידנית בכל מערכת בנפרד, שקל מאוד לשכוח חלק ממנה.

עבור SaaS שרוצה להשתלב בארגונים גדולים, תמיכה ב-SSO ארגוני (לרוב דרך OIDC או SAML הישן יותר) היא לעיתים דרישת סף — מחלקות IT ארגוניות רבות פשוט לא מאשרות אימוץ מערכת חדשה בלי אינטגרציית SSO, כי היא מרכזית למדיניות האבטחה שלהן.

OIDC מול SAML: מתי משתמשים בכל אחד

SAML הוא הקודם ההיסטורי של OIDC — תקן מבוסס XML שהיה הסטנדרט השולט ל-SSO ארגוני במשך שנים רבות, ועדיין נפוץ מאוד בארגונים גדולים וותיקים, במיוחד בסקטורים כמו פיננסים וממשלה. OIDC נבנה מאוחר יותר כתחליף מודרני יותר, מבוסס JSON ו-REST במקום XML ו-SOAP, ומתאים משמעותית יותר לאפליקציות web ומובייל מודרניות. עם זאת, ארגונים ותיקים רבים עדיין מפעילים תשתית SAML קיימת שקשה ויקר להחליף, ולכן SaaS שרוצה לשרת שוק ארגוני רחב לרוב צריך לתמוך בשני התקנים במקביל, ולא רק ב-OIDC המודרני יותר.

איפה בארכיטקטורה קורה האימות בפועל

בארכיטקטורת microservices, מומלץ לרכז את זרימת ה-OIDC כולה — כולל redirect ל-IdP וקבלת הטוקנים — בשכבה אחת, בדרך כלל ב-API Gateway או בשירות אימות ייעודי (auth service), ולא בכל microservice בנפרד. שירותים פנימיים מקבלים אז access token או context מזוהה שכבר עבר אימות, ולא צריכים לדעת דבר על תהליך ה-OIDC המלא. הרחבנו על ריכוז האימות בשכבת ה-Gateway במדריך ארכיטקטורת API Gateway, ועל ההבדל בין אימות להרשאה במדריכים אימות API ו-הרשאות API.

טעויות נפוצות בפרודקשן

הטעות הראשונה היא אי-בדיקת ה-iss וה-aud בטוקן שהתקבל — client שמאמת רק את החתימה, בלי לוודא שהטוקן הונפק על ידי ה-IdP הנכון ומיועד לאפליקציה שלו ולא לאפליקציה אחרת, פתוח להתקפות שבהן טוקן תקף ממערכת אחרת מוזרם למערכת הלא-נכונה. טעות שנייה היא בלבול בין ID Token לבין access token — שימוש ב-ID Token כדי לקרוא ל-API-ים חיצוניים (כמו Google APIs), במקום ה-access token שנועד בדיוק לכך; ID Token נועד רק להוכיח זהות מול ה-client עצמו, לא לשמש כאישור גישה למשאבים חיצוניים.

טעות שלישית היא אי-מימוש PKCE באפליקציות SPA או מובייל, מתוך הנחה מוטעית ש-Authorization Code Flow לבדו מספיק — בסביבות שבהן אי אפשר לשמור סוד client מאובטח (secret), PKCE הוא לא אופציונלי אלא הכרחי. טעות רביעית היא הסתמכות על תוקף ID Token ארוך מדי בלי refresh flow תקין — ID Token נועד להיות תקף לזמן קצר, ואפליקציות שמנסות "לחסוך" ומרחיבות את תוקפו מסתכנות בכך שמשתמש שנחסם ב-IdP המרכזי ימשיך להיחשב מאומת באפליקציה עוד זמן רב אחרי שהגישה שלו בוטלה בפועל. טעות חמישית היא אי-יישום refresh token rotation למרות שהתקן ממליץ עליו במפורש עבור client-ים ציבוריים (SPA, מובייל) — בלי rotation, טוקן ארוך-טווח שדלף פעם אחת נשאר שמיש לתוקף המלא שלו, ללא שום דרך לזהות שהוא נמצא בשימוש כפול חשוד.

מתי OIDC הוא הבחירה הנכונה

OIDC מתאים כשצריך אימות זהות אמיתי, לא רק הרשאת גישה — כלומר כמעט בכל תרחיש עם משתמש קצה שמתחבר לאפליקציה. הוא הבחירה הטבעית כש-SSO ארגוני נדרש, כשבונים "התחברות עם Google/Microsoft/Apple", וכשרוצים להימנע מניהול סיסמאות בעצמכם לחלוטין. הוא פחות רלוונטי לתקשורת server-to-server טהורה בלי משתמש קצה כלל, ששם Client Credentials flow של OAuth 2.0 לבדו, בלי שכבת OIDC, מספיק ופשוט יותר.

סיכום

OpenID Connect סוגר את הפער שבין "יש לך הרשאה" (OAuth 2.0) ל"אנחנו יודעים בוודאות מי אתה" — דרך ID Token מובנה, מנגנון discovery אוטומטי, ותמיכה טבעית ב-SSO ארגוני. ההשקעה בהבנת ההבדל בין OAuth ל-OIDC משתלמת כבר בשלב התכנון, כי בלבול בין השניים הוא מקור נפוץ לפרצות אבטחה שקשה לזהות אחרי המעשה.

תגיות: OpenID Connect · OIDC · OAuth 2.0 · SSO · ID Token · PKCE · SAML · identity provider

← חזרה לבלוג · צור קשר