יישום OAuth2: מדריך מקיף לאימות צד שלישי

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

מה זה OAuth2?

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

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

מושגי מפתח ב- OAuth2

הבנת מושגי הליבה של OAuth2 היא חיונית ליישום מוצלח:

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

סוגי מענקים של OAuth2

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

1. מענק קוד הרשאה

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

1. יישום הלקוח מעביר את בעל המשאב לשרת ההרשאות.
2. בעל המשאב מאמת את זהותו בשרת ההרשאות ומעניק הרשאה ליישום הלקוח.
3. שרת ההרשאות מעביר את בעל המשאב בחזרה ליישום הלקוח עם קוד הרשאה.
4. יישום הלקוח מחליף את קוד ההרשאה באסימון גישה ובאסימון רענון.
5. יישום הלקוח משתמש באסימון הגישה כדי לגשת למשאבים מוגנים בשרת המשאבים.

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

2. מענק מרומז

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

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

3. מענק אישורי סיסמת בעל משאב

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

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

4. מענק אישורי לקוח

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

דוגמה: יישום ניטור שצריך לגשת למדדי שרת מספק שירותי ענן עשוי להשתמש בסוג מענק זה.

5. מענק אסימון רענון

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

יישום OAuth2: מדריך שלב אחר שלב

יישום OAuth2 כולל מספר שלבים מרכזיים:

1. רישום יישום הלקוח שלך

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

דוגמה: בעת רישום היישום שלך בשירות OAuth2 של Google, תצטרך לספק כתובת URI להפניה מחדש, שתתאים לכתובת ה-URI שהיישום שלך ישתמש בה כדי לקבל את קוד ההרשאה. יהיה עליך גם לציין את ההיקפים שהיישום שלך דורש, כגון גישה ל-Google Drive או ל-Gmail.

2. הפעלת זרימת ההרשאות

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

• client_id: מזהה הלקוח שהונפק על ידי שרת ההרשאות.
• redirect_uri: כתובת ה-URI שאליה שרת ההרשאות יעביר את בעל המשאב לאחר אימות.
• response_type: סוג התגובה הצפוי משרת ההרשאות (לדוגמה, code עבור מענק קוד ההרשאה).
• scope: היקפי הגישה הרצויים.
• state: פרמטר אופציונלי המשמש למניעת התקפות זיוף בקשות חוצות אתרים (CSRF).

דוגמה: כתובת URI להפניה מחדש עשויה להיראות כך: https://example.com/oauth2/callback. הפרמטר state הוא מחרוזת שנוצרה באקראי שהיישום שלך יכול להשתמש בה כדי לוודא שהתגובה משרת ההרשאות לגיטימית.

3. טיפול בתגובת ההרשאה

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

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

• grant_type: סוג המענק (לדוגמה, authorization_code).
• code: קוד ההרשאה שהתקבל משרת ההרשאות.
• redirect_uri: אותה כתובת URI להפניה מחדש המשמשת בבקשת ההרשאה.
• client_id: מזהה הלקוח שהונפק על ידי שרת ההרשאות.
• client_secret: סוד הלקוח שהונפק על ידי שרת ההרשאות (עבור לקוחות סודיים).

4. גישה למשאבים מוגנים

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

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

  
  GET /api/v1/me HTTP/1.1
  Host: api.example.com
  Authorization: Bearer [access_token]
  

5. טיפול ברענון אסימון

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

• grant_type: סוג המענק (לדוגמה, refresh_token).
• refresh_token: אסימון הרענון שהתקבל משרת ההרשאות.
• client_id: מזהה הלקוח שהונפק על ידי שרת ההרשאות.
• client_secret: סוד הלקוח שהונפק על ידי שרת ההרשאות (עבור לקוחות סודיים).

שיקולי אבטחה

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

• השתמש ב-HTTPS: כל התקשורת בין יישום הלקוח, שרת ההרשאות ושרת המשאבים צריכה להיות מוצפנת באמצעות HTTPS כדי למנוע האזנות סתר.
• אמת כתובות URI להפניה מחדש: אמת בזהירות כתובות URI להפניה מחדש כדי למנוע התקפות הזרקת קוד הרשאה. אפשר רק כתובות URI להפניה מחדש רשומות וודא שהן מעוצבות כראוי.
• הגן על סודות לקוחות: שמור על סודות לקוחות בסודיות. לעולם אל תאחסן אותם בקוד בצד הלקוח או תחשוף אותם לגורמים לא מורשים.
• יישם פרמטר מצב: השתמש בפרמטר state כדי למנוע התקפות CSRF.
• אמת אסימוני גישה: שרת המשאבים חייב לאמת אסימוני גישה לפני מתן גישה למשאבים מוגנים. זה בדרך כלל כרוך באימות החתימה של האסימון ותוקף התפוגה שלו.
• יישם היקף: השתמש בהיקפים כדי להגביל את ההרשאות שניתנו ליישום הלקוח. הענק רק את ההרשאות הנחוצות המינימליות.
• אחסון אסימונים: אחסן אסימונים בצורה מאובטחת. עבור יישומים מקוריים, שקול להשתמש במנגנוני האחסון המאובטח של מערכת ההפעלה. עבור יישומי אינטרנט, השתמש בעוגיות מאובטחות או בפגישות בצד השרת.
• שקול PKCE (הוכחת מפתח לחילופי קוד): עבור יישומים שאינם יכולים לאחסן באופן מאובטח סוד לקוח (כמו SPA ואפליקציות מקוריות), השתמש ב-PKCE כדי להפחית את הסיכון ליירוט קוד הרשאה.

OpenID Connect (OIDC)

OpenID Connect (OIDC) היא שכבת אימות הבנויה על גבי OAuth2. היא מספקת דרך סטנדרטית ליישומי לקוח לאמת את זהותו של בעל המשאב בהתבסס על האימות שמבוצע על ידי שרת ההרשאות, כמו גם להשיג מידע בסיסי על פרופיל בעל המשאב בצורה ניתנת לפעולה הדדית ודמוית REST.

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

בעת יישום OIDC, התגובה משרת ההרשאות תכלול גם אסימון גישה (לגישה למשאבים מוגנים) וגם אסימון מזהה (לאימות זהותו של המשתמש).

בחירת ספק OAuth2

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

חלק מספקי OAuth2 פופולריים כוללים:

• פלטפורמת הזהויות של Google
• התחברות לפייסבוק
• Microsoft Azure Active Directory
• Auth0
• Okta
• Ping Identity

בעת בחירת ספק OAuth2, שקול גורמים כגון:

• תמחור
• תכונות
• אבטחה
• אמינות
• קלות שילוב
• דרישות תאימות (לדוגמה, GDPR, CCPA)
• תמיכת מפתחים

OAuth2 בסביבות שונות

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

יישומי אינטרנט

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

יישומי מובייל

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

יישומי דסקטופ

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

מכשירי IoT

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

פתרון בעיות נפוצות ב-OAuth2

יישום OAuth2 יכול להיות מאתגר לפעמים. הנה כמה בעיות נפוצות וכיצד לפתור אותן:

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

מסקנה

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

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