ההבדל הקריטי בין ID Token ל-Access Token ב-OpenID Connect

By Mirko Peters · 2026-10-28

גלו את ההבדלים המהותיים בין ID tokens ל-access tokens ב-OpenID Connect, ולמדו מדוע ערבוב ביניהם יוצר פרצות אבטחה חמורות.

Automatically translated with AI from the original post. Read the English original

הבנת ההבדל בין ID token ל-access token חיונית למפתחים ולמנהלי IT שעובדים עם אימות מודרני. בעוד ש-OAuth 2.0 מטפל בהרשאות, OpenID Connect מציג את ה-ID token כדי לאשר את זהותו של המשתמש. ערבוב בין שני הטוקנים השונים האלה מוביל לפרצות אבטחה קריטיות ביישומי ענן.

עיקרי הדברים

• ID tokens מוכיחים את זהותו של המשתמש, ואילו access tokens מעניקים הרשאות וסמכויות גישה.
• בלבול בין שני הטוקנים האלה הוא טעות מרכזית באבטחת יישומים פנימיים.
• OpenID Connect מוסיף אישור זהות מעל מסגרת העבודה של OAuth 2.0.
• ניתן לבטל access tokens, וזה מספק מצב אבטחה בטוח יותר מאשר אחסון סיסמאות.
• יישומים חייבים לאמת באופן קריפטוגרפי ID tokens נכנסים, ולא לסמוך עליהם באופן עיוור.

הדילמה המרכזית: זהות מול הרשאה

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

כדי לפתור חלק מהחידה, הגיע OAuth 2.0. עם זאת, OAuth 2.0 מעולם לא נבנה כדי לענות על השאלה מיהו אדם. מטרתו המלאה היא לספק "פתקי הרשאה", הידועים כ-access tokens, המאפשרים ליישום לגשת לנקודות קצה ספציפיות של נתונים מטעם המשתמש. access token מתאר מה היישום רשאי לעשות, אך הוא נותר שותק לחלוטין לגבי זהותו של האדם שמחזיק בו. פער יסודי זה הביא לכך שחברות שניסו לבנות חוויות כניסה אחידה (single sign-on) נאלצו לחבר בדיקות זהות מותאמות אישית אל OAuth, מה שהוביל ליישומים מפוצלים שכמעט never התאימו זה לזה.

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

אנטומיה של ה-ID token: מה יש בפנים

כאשר משתמש לוחץ על הכפתור "Sign in with Microsoft", ספק הזהות מעבד את פרטי הכניסה, מטפל בדרישות אימות רב-שלבי, ולבסוף מחזיר את המשתמש אל היישום יחד עם ID token. הטוקן הזה ארוז כ-JSON Web Token, המכונה בקיצור JWT ונהגה "ג'ות". במבט ראשון, JWT נראה כמחרוזת מאיימת ובלתי חדירה של תווים המופרדים בנקודות. עם זאת, המבנה הפנימי שלו פשוט להפליא לאחר פענוח.

בתוך ID token תמצאו מספר טענות תקניות, שלכל אחת מהן תפקיד מוגדר:

• Issuer: מזהה את ספק הזהות הספציפי (כמו Microsoft Entra ID) שיצר וחתם על הטוקן.
• Subject (sub): משמש כמזהה ייחודי ובלתי ניתן לשינוי של המשתמש. החשוב מכל: התכנון הוא שהערך הזה לא ישתנה גם אם המשתמש יעדכן את שם התצוגה או כתובת הדוא"ל שלו.
• Audience (aud): מציין את היישום המדויק שעבורו נוצר האסימון, וכך מבטיח שאסימון שנועד ליישום אחד לא ייתפס ויבוזבז בזדון על ידי יישום אחר.
• חותמות זמן: מפרטות מתי הונפק האסימון, מתי הוא פג תוקף, והרגע המדויק שבו המשתמש אימת את זהותו.
• Nonce: פועל כמספר קבלה מאובטח שמקשר את האסימון שנוצר להפעלת הכניסה הספציפית שיזמה את הבקשה, ובכך חוסם למעשה מתקפות הפעלה חוזרת (replay).

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

הסכנה שבהתייחסות לזהות כאל גישה

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

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

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

סיכום

שליטה בגבול שבין זהות להרשאה עוזרת לפרק לגורמים את הארכיטקטורה המודרנית של הענן. כאשר אסימוני ID מתמקדים אך ורק בהוכחה של מי נמצא מול המקלדת, ואסימוני הגישה קובעים אילו פעולות מותרות, מפתחים יכולים לבנות אינטגרציות חזקות ומאובטחות עם פלטפורמות כמו Microsoft Entra ID. כדי לשמוע הסבר מקיף על המושגים האלה ולראות כיצד תהליכי כניסה מודרניים פועלים באקosystem של Microsoft, כדאי לצפות בדיון המלא. האזינו לפרק המלא והתעמקו במנגנונים של זהות בענן כבר היום!

שאלות נפוצות

האם אפשר להשתמש באסימון ID כדי לקרוא ל-APIs או לגשת למשאבים מוגנים?

לא. אסימון ID מכיל רק תביעות זהות לגבי זהות המשתמש. כדי לקרוא ל-APIs או לגשת למשאבים מוגנים, היישום חייב להשתמש באסימון גישה שהונפק דרך OAuth 2.0.

מדוע OpenID Connect ו-OAuth 2.0 משתמשים באסימונים נפרדים?

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

מה קורה אם יישום מקבל אסימון ID בלי לבדוק את החתימה שלו?

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

היכן ערך ה-'nonce' משתלב בתהליך החלפת האסימונים?

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