GNAP: OAuth הדור הבא

השנה הייתה 2012, ופרוטוקול אבטחה מתוקן בשם OAuth 2 סחף את הרשת ומאפשר למשתמשים להשתמש בספקי אבטחה בכדי להתחבר לאתרים בקלות. מערכות כניסה יחידות רבות, החל מהקוגניטו של AWS ועד Okta, מיישמות את OAuth. OAuth הוא מה שמאפשר לך "לבצע אימות עם Google" או ספקים אחרים לאתר או ליישום אחר לגמרי.

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

למרבה הצער, OAuth הוא פסטיבל הבירה הטוב ביותר שיש 2020 להציע.

שוחחתי עם דן מור מ- FusionAuth על OAuth ועל תחליף מוצע בשם GNAP - שככל הנראה מבוטא ללא ה- G כ"תנומה ". ההגייה מקדמת את הרעיון שביטחון הוא תחום מרגש באמת. GNAP מטפל בכמה מגבלות של OAuth ומתבל אותו עם תכונות חדשות.

למה להחליף, או ליתר דיוק להגדיל, OAuth? OAuth תוכנן סביב דפדפנים. זה מניח שהמקור שמגיש את הבקשה יכול לטפל בהפניית HTTP. מיקוד דפדפן אינטרנט זה מהווה אבן נגף לאפליקציות לנייד או לכל סוג של "דבר" ב"אינטרנט של הדברים ". בנוסף, צדדי OAuth כמו זה הם 2007 ומחייבים לפרסם פרמטרים של טפסים במקום JSON.

המפרט של OAuth היה מעורפל במקומות מסוימים, והעולם השתנה מאז 2012. יש מגוון של RFC ו BCP, למעשה מפרט תוספת שאתה צריך ליישם כדי לקבל יכולות רבות יותר, אבטחה טובה יותר ותאימות כללית. מאמץ נפרד בשם OAuth 2.1 מקווה למוטט חלק מהתוספים הללו למפרט יחיד קוהרנטי יותר. לחלק מהמניעים ל- OAuth 2.1, ראה לי מקגוברן מהפוסט של אוקטה "כמה RFCs צריך כדי להחליף נורה." OAuth 2.1, בניגוד ל- GNAP, הוא רק שחרור מצטבר ללא שינויים משמעותיים חדשים מלבד שילוב ערימת המפרט למפרט יחיד.

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

מטרה מרכזית של GNAP היא ההפרדה בין מי שמבקש את המשאבים (RQ) לבין מי שיש לו את המשאבים (RO).

IETF

GNAP מציעה גם לתמוך בתכונות אבטחה חדשות כגון:

  • הפעלה של אסינכרוני וכתובת אתר. מדובר בנתיבי אימות שונים המאפשרים ללקוח לבצע אימות ללא הפניה מחדש. GNAP מאפשר גם ליישומים לבצע אימות למשאבים של צד שלישי שאליהם אין לשרת המשאבים ולשרת ההרשאה גישה ישירה.
  • בקש המשך. אלה מאפשרים ללקוחות לנהל משא ומתן על דברים כמו הפניות מחדש או פרטי אימות אחרים במהלך תהליך האימות. הם גם מאפשרים ללקוח לנהל משא ומתן על הרשאות נוספות או אסימוני גישה.
  • אסימוני גישה מרובים. אלה מאפשרים ללקוחות לבצע אימות למשאבים רבים בבת אחת, למשל כמשתמשים ומנהלי מערכת.
  • אסימונים למגבלת שולחים. אמנם יש תוספות ל- OAuth 2 עבור פונקציונליות זו הנקראת DPOP ו- MTLS, אך GNAP יבנה זאת ישירות בפרוטוקול. חזור לדוגמא לאוהל הבירה שלנו. מה אם נצטרך גם ללחוש סיסמה לאוזנו של המוכר בזמן שנמסור להם את האסימון? אם האסימון שלנו הושמט (או יירט), זה לא היה משנה כי לנושא לא תהיה הסיסמה.
  • ו- GNAP גורם לרוחו של קרברוס לצרוח.

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

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