משאבים · 43
OAuth ו-OpenID Connect: לאמת אינטגרציה מקצה לקצה
להפריד הרשאות כניסה, האצלה ונתונים, ולאחר מכן לבדוק הפניות, אסימונים, הפעלות וביטול. מדריך
מעודכן · 3 min
מה מדריך זה עוזר להשיג
- הפרדת זהות מהרשאה
- דחיית הפניות וטוקנים לא מכוונים
- בדיקת דחיות בקפידה כמו הצלחות
- אימות הסרת גישה לאחר יציאה או תקרית
בדיקה מהירה
- איזה ספק ומנפיק צפויים?
- האם URI ההפניה רשום במדויק?
- האם אסימון זיהוי משמש בטעות כאסימון גישה?
- האם כל משאב בודק בעלות?
- איזו גישה שורדת את הביטול?
שיטה שלב אחר שלב
- 1
שרטוט הזרימה שנפרסה
זיהוי לקוח ציבורי או סודי, דפדפן, שרת הרשאות, API וספק OIDC. רישום לאן קודים ואסימונים עוברים, מי מאחסן אותם ואילו תפקידים מוענקים. דיאגרמת מכירות אינה קובעת את הפריסה בפועל.
תוצר: זרימה, גבולות אמון ובעלי רכיבים.
- 2
בדיקת טרנזקציית הכניסה.
שימוש בזרימת הקוד עם PKCE המתאים ללקוח. בדיקת S256, קשירת טרנזקציות, הפניות רשומות והגנה מפני בקשות מזויפות. בדיקת URI בלתי צפוי, מאמת שגוי, קוד שהופעל מחדש ומנפיק בלתי צפוי. RFC 9700 מפריד דרישות והמלצות לפי סוג לקוח.
תוצר: תוצאות בדיקה מותרות ונדחות.
- 3
אימות הטוקן הנכון.
ה-API מאמת את טוקן הגישה שלו בהתאם לפורמט ולכללי הספק: חתימה או התבוננות פנימית, מנפיק, קהל, תפוגה והרשאות. לקוח OIDC מאמת בנפרד את טוקן הזהות. חתימה תקפה אינה קובעת שהטוקן שייך ל-API זה.
תוצר: אימות חוזה ובדיקות קהל ופג תוקף.
- 4
בדיקת הרשאות עסקיות
בדיקת אובייקט בבעלות חשבון אחר, תפקיד נמוך יותר, שדה פרטי ופעולה ניהולית. טווח או שער מאומת אינם מחליפים בדיקות בצד השרת על המשאב המבוקש. השתמש בחשבונות ונתונים של בדיקה מורשים.
תוצר: תפקיד, אובייקט, פעולה ומטריצת דחייה צפויה.
- 5
תפוגת מועד וביטול של תרגילים
הפרדת הפעלה מקומית, הפעלה של ספק, אסימון גישה ואסימון רענון. בדיקת יציאה, אובדן מכשיר, שינוי תפקיד, סיבוב מפתח חתימה והפסקת פעילות ספק. תיעוד זמן גישה שיורי במקום להניח שיציאה מבטלת הכל באופן מיידי.
תוצר: ציר זמן להסרת גישה וחריגים.
- 6
מעקב ללא חשיפת סודות
רישום הפניה לעסקה, החלטת אימות, קטגוריית שגיאה וגרסת תצורה. אי הכללת קודים, אסימונים וסודות. הכנת אבחון, כיבוי אינטגרציה והחזרה לתצורה מאומתת; הפעלה חוזרת של בדיקות לאחר שינויי ספק.
תוצר: בדיקות נוהל הפעלה ורגרסיה.
דוגמה בדיונית
סיטואציה להמחשה
סיטואציה לדוגמה: שני לקוחות משתמשים בספק זהויות אחד. אסימון תקף עבור הראשון מוצג ל-API של הלקוח השני.
החלטה וראיות צפויות
ה-API דוחה את הקהל הלא נכון, רושם מעקב ללא אסימון ואינו מחזיר נתונים. הדחייה הופכת למבחן רגרסיה.
הבחנה בין המנגנונים
| מנגנון | מטרה | אימות או הגבלה |
|---|---|---|
| OAuth 2.0 | האצלת גישת משאבים | הרשאות אובייקט בצד השרת |
| OpenID Connect | קביעת זהות באמצעות אסימון זיהוי מאומת | אימות מנפיק, קהל ועסקאות |
| סשן יישום | שמירה על כניסה ליישום | הגנה מפני תפוגה, ביטול והפעלה |
מדדי ניהול
| מדד | מה הוא מודד | פעולה ראשונה |
|---|---|---|
| תיקון דחיות | מקרים אסורים שנחסמו בפועל | תיקון כל קבלה בלתי צפויה |
| עיכוב ביטול | זמן עד להיעלמות הגישה הרלוונטית | בדיקת סשנים ואסימונים בנפרד |
| כשלים באימות | דחיות לפי סיבה וגרסה | הפרדת התקפות משגיאות תצורה |
טעויות נפוצות
- בלבול בין אימות להרשאה
- קבלת כל קהל לאחר בדיקת החתימה
- רישום URI רחב להפניה מחדש
- רישום אסימונים לנוחות קלה יותר ניפוי שגיאות
שאלות נפוצות
האם PKCE מחליף כל פקד?
לא. הוא מגן על חילופי הקוד בזרימה המיועדת; אימות אסימונים, הפניות מחדש, הרשאת עסקים והפעלות עדיין דורשים בדיקה.
האם JWT הוא הרשאה?
JWT הוא פורמט. תביעות הופכות לשימושיות רק לאחר אימות ויישום של כללי ה-API שלך.
האם יש לבנות אימות מאפס?
עדיף ספרייה מתוחזקת ותיעוד ספק, ולאחר מכן בדוק את התצורה שלך. ספרייה נכונה עדיין יכולה להיות מוגדרת באופן שגוי.
הפניות רשמיות
הפניות תומכות בשיטה. התאימו את הבדיקות להקשר שלכם; הן אינן הסמכה. כותרות הפניות ומסמכי המקור המקוריים עשויים להיות בשפה אחרת.
