כותרות Authorization

כל משאב מוגן באינטרנט שואל את אותה שאלה: מי אתה, ואיך אני יודע שאתה אומר אמת?

כותרת ה-Authorization היא התשובה שלך. זוהי שורה יחידה בבקשת HTTP שנושאת כל הוכחה שהשרת דורש — סיסמה, טוקן, חתימה קריפטוגרפית. תעשה זאת נכון, ואתה בפנים. תטעה, ותקבל 401 Unauthorized שמבקש ממך לנסות שוב.

מבנה כותרת ה-Authorization

כל כותרת Authorization עוקבת אחרי אותו תבנית:

Authorization: <scheme> <credentials>

ה-scheme אומר לשרת איך אתה מוכיח את עצמך. ה-credentials הם ההוכחה עצמה. סכמות שונות מייצגות תשובות שונות לשאלה ישנה: איך אני מוכיח שאני אני מבלי לוותר על יותר מדי?

Basic Authentication: הגישה הישירה

Basic auth הוא פשוט באופן מפתיע. אתה שולח את שם המשתמש והסיסמה שלך, מופרדים בנקודותיים, מקודדים ב-Base64:

Authorization: Basic YWxpY2U6c2VjcmV0MTIz

אותה מחרוזת מוזרה מפוענחת ל-alice:secret123. כל אחד יכול לפענח אותה:

atob('YWxpY2U6c2VjcmV0MTIz'); // Returns: "alice:secret123"

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

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

השתמש ב-Basic auth עבור:

• כלים פנימיים מאחורי VPN
• סביבות פיתוח
• סקריפטים פשוטים שמדברים עם APIs שאתה שולט בהם
• כל מקום שבו הפשטות שווה יותר מהתחכום של האלטרנטיבות

לעולם אל תשתמש בו על HTTP פשוט. זה שליחת סיסמאות על גלויות.

Bearer Tokens: החזקה היא ההוכחה

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

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

השם "bearer" מדויק: מי שנושא את הטוקן — מקבל גישה. כמו מפתח פיזי: לא משנה מי אתה, רק שהמפתח בידך.

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

JWTs: טוקנים שמוכיחים את עצמם

רוב ה-bearer tokens כיום הם JWTs — JSON Web Tokens. הם חכמים: במקום להיות מחרוזות אקראיות שהשרת חייב לחפש במסד נתונים, JWTs נושאים בתוכם את הוכחת תקפותם.

ל-JWT יש שלושה חלקים, מופרדים בנקודות:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkFsaWNlIn0.signature

Header: מציין כיצד הטוקן חתום (אלגוריתם, סוג) Payload: מכיל claims — מי אתה, מתי הטוקן פג, מה מותר לך לעשות Signature: הוכחה קריפטוגרפית שה-header וה-payload לא שונו

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

מחזור החיים של הטוקן

לטוקנים יש קצב:

1. אימות פעם אחת: שלח את הפרטים האמיתיים שלך לנקודת קצה של התחברות
2. קבלת טוקנים: קבל בחזרה access token (קצר מועד) ולרוב גם refresh token (ארוך מועד)
3. שימוש ב-access token: כלול אותו בכותרות Authorization
4. רענון כשצריך: כשה-access token פג, השתמש ב-refresh token כדי לקבל אחד חדש
5. אימות מחדש בסופו של דבר: כשגם ה-refresh token פג, התחל מחדש

// שלב 1: המרת פרטי גישה לטוקנים
const { accessToken, refreshToken } = await login(username, password);

// שלב 2: שימוש ב-access token לקריאות API
const response = await fetch('/api/data', {
    headers: { 'Authorization': `Bearer ${accessToken}` }
});

// שלב 3: כשה-access token פג, רענן אותו
const { accessToken: newToken } = await refresh(refreshToken);

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

Digest Authentication: גיבוב במקום שליחה

Digest auth ניסה לפתור את חולשת Basic auth מבלי לדרוש הצפנה. במקום לשלוח את הסיסמה, אתה שולח גיבוב של הסיסמה שלך משולב עם ערך אקראי שהשרת סיפק (nonce):

Authorization: Digest username="alice", nonce="abc123", response="hash..."

השרת מבצע את אותו חישוב גיבוב. אם התוצאות תואמות — אתה בוודאי יודע את הסיסמה.

חכם, אבל מסובך. אפליקציות מודרניות נטשו ברובן את Digest auth לטובת bearer tokens על גבי HTTPS. ההצפנה מטפלת באבטחה; סכמת האימות מטפלת בזהות.

API Keys: אמון פשוט

APIs רבים מדלגים על המורכבות לחלוטין:

Authorization: ApiKey sk_live_abc123xyz

או בכותרת מותאמת אישית:

X-API-Key: sk_live_abc123xyz

API keys הם bearer tokens ללא הטקסים — ללא תהליכי OAuth, ללא refresh tokens, ללא תפוגה (בדרך כלל). אתה מקבל מפתח, משתמש בו, והמפתח מזהה אותך.

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

OAuth 2.0: הרשאה כשירות

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

תהליך Authorization Code (הנפוץ ביותר לאפליקציות ווב):

1. האפליקציה שלך מפנה את המשתמש לשרת ההרשאות (Google, GitHub וכד')
2. המשתמש מתחבר שם ומעניק הרשאה
3. שרת ההרשאות מחזיר אותו לאפליקציה עם קוד
4. האפליקציה שלך מחליפה את הקוד ב-access token
5. האפליקציה שלך משתמשת בטוקן הזה בכותרות Authorization

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

התוצאה עדיין bearer token:

Authorization: Bearer ya29.access-token-from-oauth

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

כשאימות נכשל

שרתים אומרים לך בדיוק מה הם רוצים. תגובת 401 Unauthorized כוללת כותרת WWW-Authenticate שמציינת את הסכמה הנדרשת:

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

המשמעות: "אני מצפה ל-bearer token; מה ששלחת אינו תקין." ה-realm מתאר מה מוגן, והשגיאה נותנת פרטים.

עבור Basic auth:

WWW-Authenticate: Basic realm="Secure Area"

דפדפן שרואה זאת יציג תיבת דו-שיח לשם משתמש וסיסמה. זוהי חוויית Basic auth — פולשנית אך פונקציונלית.

עיקרי האבטחה

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

טוקנים צריכים לפוג. access tokens קצרי מועד (15 דקות עד שעה) מבטיחים שלטוקן גנוב יש שימוש מוגבל. refresh tokens מאריכים סשנים מבלי להרחיב סיכונים.

מקום האחסון חשוב. בדפדפנים:

• קוקיות HttpOnly אינן נגישות ל-JavaScript (עמידות ל-XSS)
• localStorage נגיש לכל סקריפט בדף (פגיע ל-XSS)
• זיכרון הוא הבטוח ביותר אך אינו שורד רענון דף

לאפליקציות מובייל, השתמש באחסון המאובטח של הפלטפורמה: iOS Keychain, Android Keystore.

לעולם אל תשים פרטי גישה ב-URLs. הם דולפים לתוך לוגים, היסטוריית דפדפן וכותרות Referer:

// מסוכן: פרטי גישה ב-URL
fetch('https://api.example.com/data?token=secret');

// בטוח: פרטי גישה בכותרת
fetch('https://api.example.com/data', {
    headers: { 'Authorization': 'Bearer secret' }
});

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

שאלות נפוצות על כותרות Authorization

מה ההבדל בין authentication לבין authorization?

Authentication מוכיח מי אתה. Authorization קובע מה מותר לך לעשות. כותרת ה-Authorization (שם קצת מבלבל) מטפלת ב-authentication — הוכחת זהות. מה שמותר לך לעשות עם אותה זהות היא החלטה נפרדת שהשרת מקבל לאחר שאימת את פרטיך.

למה להשתמש ב-bearer tokens במקום לשלוח שם משתמש וסיסמה בכל פעם?

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

האם JWTs יכולים להיות מוצפנים?

כן, אבל בדרך כלל הם רק חתומים, לא מוצפנים. החתימה מוכיחה שהטוקן לא שונה, אבל ה-payload מקודד רק ב-Base64 — כל אחד יכול לקרוא אותו. אל תשים סודות ב-JWT payloads. אם אתה צריך טוקנים מוצפנים, עיין ב-JWE (JSON Web Encryption), אבל רוב האפליקציות לא צריכות זאת.

איך מתנתקים עם bearer tokens?

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