אימות API

כל בקשת API מגיעה עם שאלה מרומזת: האם לסמוך עליך?

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

אימות הוא הדרך שבה APIs מוודאים זהות. הוא עונה על "מי אתה?" כדי שה-API יוכל להחליט אם להכניס אותך ומה מותר לך לגעת בו ברגע שנכנסת.

אימות מול הרשאה

שני מושגים אלה עובדים יחד אך פותרים בעיות שונות.

אימות מוודא זהות. הוא עונה על "מי אתה?" מפתח API תקף או אסימון גישה מוכיח שאתה מי שאתה טוען להיות.

הרשאה קובעת הרשאות. היא עונה על "מה אתה יכול לעשות?" היות מאומת לא אומר שאתה יכול למחוק את כל המשתמשים או לגשת לנתונים פרטיים של מישהו אחר.

כל בקשת API זקוקה לשניהם: קודם מאמתים את הזהות, ואז בודקים הרשאות.

מפתחות API

מפתחות API הם מנגנון האימות הפשוט ביותר — מחרוזות ייחודיות שמונפקות לכל יישום.

אתה נרשם אצל ספק API ומקבל מפתח (מחרוזת אקראית ארוכה). יש לכלול אותו בכל בקשה:

GET /users
Authorization: ApiKey sk_live_abc123def456

מפתחות API עובדים היטב לתקשורת שרת-לשרת. הם פשוטים לממש, נוחים למפתחים, ומאפשרים מעקב אחר שימוש לפי יישום.

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

שיטות עבודה מומלצות: החלף מפתחות מעת לעת. השתמש במפתחות שונים לפיתוח וייצור. העבר רק דרך HTTPS.

אסימוני Bearer

אסימון Bearer הוא בדיוק מה שנשמע: מי שנושא אותו — נכנס. כמו כרטיס קולנוע — הקולנוע לא מתעניין מי קנה אותו, רק מי מחזיק בו.

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

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

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

OAuth 2.0

OAuth פותר בעיה אלגנטית: כיצד מאפשרים לאפליקציה של צד שלישי לגשת לנתונים שלך מבלי לתת לה את הסיסמה שלך?

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

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

הרכיבים:

• אסימוני גישה מעניקים גישה ל-API, בדרך כלל לזמן קצר (שעות או ימים)
• אסימוני רענון מאפשרים קבלת אסימוני גישה חדשים מבלי להטריד את המשתמש שוב
• טווחי הרשאות מגדירים מה האפליקציה יכולה לעשות — "read:posts" לעומת "write:posts" לעומת "delete:account"

OAuth מורכב משמעותית ממפתחות API. מימושו דורש שרתי הרשאות, ניהול אסימונים, אימות טווחי הרשאות וטיפול באסימוני רענון. רוב ה-APIs משתמשים בספקי OAuth (Auth0, Okta, Firebase) במקום לבנות את המערכת בעצמם.

JWT (JSON Web Tokens)

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

ל-JWT יש שלושה חלקים המופרדים בנקודות: כותרת, מטען, חתימה.

header.payload.signature

המטען מכיל טענות — מזהה משתמש, הרשאות, זמן תפוגה:

{
  "sub": "user123",
  "name": "John Doe",
  "role": "admin",
  "exp": 1735689600
}

החתימה מבטיחה שהאסימון לא שונה. אם מישהו משנה את המטען, החתימה לא תתאים.

היתרון: אין צורך באחסון סשנים בצד השרת. כל שירות יכול לאמת JWT באופן עצמאי — מושלם למיקרו-שירותים.

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

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

אימות HTTP בסיסי

אימות בסיסי שולח שם משתמש וסיסמה עם כל בקשה, מקודדים ב-Base64:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

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

אימות מבוסס סשן

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

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

אימות מכונה-למכונה

כאשר APIs מדברים עם APIs אחרים ללא מעורבות משתמש, חלים דפוסים שונים:

• חשבונות שירות הם חשבונות ייעודיים ליישומים
• הענקת פרטי לקוח של OAuth מאפשרת לשירותים לאמת זה את זה
• TLS הדדי משתמש בתעודות לאימות גם הלקוח וגם השרת
• מפתחות API עובדים היטב לאימות שירות-לשירות פשוט

שיטות עבודה מומלצות

השתמש תמיד ב-HTTPS. פרטי זיהוי ואסימונים חייבים להיות מוצפנים בזמן העברה. לעולם אל תשלח פרטי אימות דרך HTTP רגיל.

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

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

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

לעולם אל תרשום פרטי זיהוי או אסימונים. רישום מפתחות API או אסימונים יוצר פגיעויות. צנזר אותם.

החלף מפתחות API מעת לעת. ספק למפתחים מנגנון להחלפת מפתחות ללא השבתה.

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

טיפול בכשלי אימות

החזר קודי סטטוס מתאימים:

• 401 Unauthorized עבור פרטי זיהוי חסרים או לא תקינים
• 403 Forbidden עבור אימות תקין אך הרשאות לא מספיקות

ספק הודעות שגיאה ברורות:

{
  "error": "authentication_required",
  "message": "No authentication credentials provided"
}

אל תחשוף פרטי אבטחה. לעולם אל תאמר "סיסמה שגויה" לעומת "שם משתמש לא נמצא" — רק "פרטי זיהוי שגויים". זה מונע מתוקפים לאשר אילו שמות משתמש קיימים.

יישם נעילות לאחר כשלים חוזרים. רשום כשלי אימות לצורך ניטור אבטחה.

שאלות נפוצות על אימות API

מה ההבדל בין מפתחות API לאסימוני OAuth?

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

האם להשתמש ב-JWT או באסימונים אטומים?

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

כיצד אני מאבטח מפתחות API באפליקציות מובייל?

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

איזה זמן תפוגה כדאי להשתמש עבור אסימוני גישה?

קצר יותר בטוח יותר אך פחות נוח. טווחים נפוצים: 15 דקות ליישומים בעלי רמת אבטחה גבוהה, שעה ל-APIs טיפוסיים, 24 שעות לתרחישים בסיכון נמוך. שלב אסימוני גישה קצרי-מועד עם אסימוני רענון ארוכי-מועד כדי שמשתמשים לא יצטרכו להתאמת שוב ושוב.