הערה. תרגום: המאמר הנהדר הזה של Okta מסביר כיצד OAuth ו- OIDC (OpenID Connect) פועלים בצורה פשוטה וברורה. ידע זה יהיה שימושי למפתחים, מנהלי מערכות ואפילו "משתמשים רגילים" של אפליקציות אינטרנט פופולריות, שככל הנראה גם מחליפים נתונים סודיים עם שירותים אחרים.
בתקופת האבן של האינטרנט, שיתוף מידע בין שירותים היה קל. פשוט נתת את פרטי הכניסה והסיסמה שלך משירות אחד לאחר, כך שהוא נכנס לחשבון שלך וקיבל כל מידע שהוא צריך.
"תן לי את חשבון הבנק שלך." "אנחנו מבטיחים שהכל יהיה בסדר עם הסיסמה והכסף. זה כנה, כנה!" *חי חי*
חֲרָדָה! אף אחד לא צריך לדרוש ממשתמש לשתף שם משתמש וסיסמה, אישורים, עם שירות אחר. אין ערובה שהארגון שעומד מאחורי שירות זה ישמור על אבטחת הנתונים ולא יאסוף מידע אישי יותר מהנדרש. זה אולי נשמע מטורף, אבל אפליקציות מסוימות עדיין משתמשות בתרגול הזה!
כיום קיים תקן בודד המאפשר לשירות אחד להשתמש בצורה מאובטחת בנתונים של אחר. למרבה הצער, תקנים כאלה משתמשים בהרבה ז'רגון ומונחים, מה שמקשה על ההבנה שלהם. מטרת החומר הזה היא להסביר איך הם פועלים באמצעות איורים פשוטים (האם אתה חושב שהציורים שלי דומים להטחת ילדים? נו טוב!).
אגב, המדריך הזה זמין גם בפורמט וידאו:
גבירותיי ורבותיי, ברוכים הבאים: OAuth 2.0
הוא תקן אבטחה המאפשר לאפליקציה אחת לקבל הרשאה לגשת למידע באפליקציה אחרת. רצף שלבים למתן היתר [רְשׁוּת] (או הַסכָּמָה [הַסכָּמָה]) מתקשרים לעתים קרובות הרשאה [הרשאה] או אפילו הרשאה מאצילה [הרשאה מואצלת]. עם תקן זה, אתה מאפשר לאפליקציה לקרוא נתונים או להשתמש בפונקציות של אפליקציה אחרת בשמך מבלי לתת לה את הסיסמה שלך. מעמד!
כדוגמה, נניח שאתה מגלה אתר בשם "Unlucky Pun of the Day" [משחק מילים נורא של היום] והחליט להירשם אליו כדי לקבל משחקי מילים יומיומיים בצורת הודעות טקסט בטלפון. מאוד אהבת את האתר, והחלטת לשתף אותו עם כל החברים שלך. אחרי הכל, כולם אוהבים משחקי מילים מפחידים, נכון?
"משחק מילים מצער של היום: שמעת על הבחור שאיבד את החצי השמאלי של גופו? עכשיו הוא תמיד צודק!" (תרגום משוער, כי למקור יש משחק מילים משלו - בערך תרגום)
ברור שכתיבה לכל אדם מרשימת אנשי הקשר היא לא אופציה. ואם אתה אפילו קצת כמוני, אז תעשה מאמצים רבים כדי להימנע מעבודה מיותרת. למרבה המזל, משחק המילים הנורא של היום יכול להזמין את כל החברים שלך לבד! לשם כך, אתה רק צריך לפתוח גישה למייל של אנשי הקשר שלך - האתר עצמו ישלח להם הזמנות (חוקי OAuth)!
"כולם אוהבים משחקי מילים! - כבר מחובר? "האם תרצה לאפשר לאתר Terrible Pun of the Day לגשת לרשימת אנשי הקשר שלך? - תודה! מעתה ואילך נשלח תזכורות בכל יום לכל מי שאתה מכיר, עד קץ הימים! אתה החבר הכי טוב!"
- בחר את שירות הדוא"ל שלך.
- במידת הצורך, עבור אל אתר הדואר והיכנס לחשבונך.
- תן ל-Trible Pun of the Day הרשאה לגשת לאנשי הקשר שלך.
- חזור לאתר משחק המילים הנורא של היום.
במקרה שתשנה את דעתך, יישומים המשתמשים ב-OAuth מספקים גם דרך לבטל גישה. לאחר שתחליט שאינך רוצה יותר לשתף אנשי קשר עם Terrible Pun of the Day, תוכל להיכנס לאתר הדואר ולהסיר את אתר משחק המילים מרשימת היישומים המורשים.
זרימת OAuth
זה עתה עברנו את מה שנקרא בדרך כלל זְרִימָה [זְרִימָה] OAuth. בדוגמה שלנו, זרימה זו מורכבת משלבים גלויים, וכן מספר שלבים בלתי נראים, שבהם שני שירותים מסכימים על החלפת מידע מאובטחת. הדוגמה הקודמת של Terrible Pun of the Day משתמשת בזרימת ה-OAuth 2.0 הנפוצה ביותר, הידועה כזרימת "קוד ההרשאה". [זרימת "קוד הרשאה"].
לפני שנצלול לפרטים של אופן הפעולה של OAuth, בואו נדבר על המשמעות של כמה מונחים:
- בעל משאבים:
זה אתה! אתה הבעלים של האישורים שלך, הנתונים שלך ושולט בכל הפעילויות שעשויות להתבצע בחשבונות שלך. - לקוח:
אפליקציה (לדוגמה, שירות משחק המילים הנורא של היום) שרוצה לגשת או לבצע פעולות מסוימות בשם בעל משאבים'א. - שרת הרשאה:
האפליקציה שיודעת בעל משאבים'א ובו u בעל משאביםיש כבר חשבון. - שרת משאבים:
ממשק תכנות יישומים (API) או שירות זה לקוח רוצה להשתמש מטעם בעל משאבים'א. - הפנייה מחדש של URI:
הקישור ש שרת הרשאה יפנה מחדש בעל משאבים'ואחרי מתן רשות לקוח'בְּ. לפעמים זה מכונה "כתובת האתר להתקשרות חוזרת". - סוג תגובה:
סוג המידע הצפוי להתקבל לקוח. הנפוץ ביותר סוג תגובה'אוהם זה הקוד, כלומר לקוח מצפה לקבל קוד אימות. - היקף:
זהו תיאור מפורט של ההרשאות הנדרשות לקוח'y, כגון גישה לנתונים או ביצוע פעולות מסוימות. - הסכמה:
שרת הרשאה לוקח סקופסביקש לקוחאה, ושואל בעל משאביםא, האם הוא מוכן לספק לקוחיש את ההרשאות המתאימות. - זיהוי הלקוח:
מזהה זה משמש לזיהוי לקוח'א על שרת הרשאהה. - סוד הלקוח:
זו הסיסמה שרק ידועה לקוחאתה ו שרת הרשאה'בְּ. זה מאפשר להם לשתף מידע באופן פרטי. - קוד אימות:
קוד זמני עם תקופת תוקף קצרה, אשר לקוח מספק שרת הרשאה'י בתמורה ל אסימון גישה. - אסימון גישה:
המפתח שהלקוח ישתמש בו כדי לתקשר איתו שרת משאבים'אומ. מעין תג או כרטיס מפתח המספק לקוחיש רשות לבקש נתונים או לבצע פעולות עליהם שרת משאביםבשמך.
שים לב: לפעמים שרת ההרשאות ושרת המשאבים הם אותו שרת. עם זאת, במקרים מסוימים, אלו עשויים להיות שרתים שונים, גם אם אינם שייכים לאותו ארגון. לדוגמה, שרת ההרשאות עשוי להיות שירות של צד שלישי מהימן על ידי שרת המשאבים.
כעת, לאחר שכיסינו את מושגי הליבה של OAuth 2.0, בואו נחזור לדוגמא שלנו ונסתכל מקרוב על מה שקורה בזרימת OAuth.
- אתה, בעל משאבים, אתה רוצה לספק את שירות משחק המילים הנורא של היום (לקוחy) גישה לאנשי הקשר שלך כדי שיוכלו לשלוח הזמנות לכל החברים שלך.
- לקוח מפנה את הדפדפן לדף שרת הרשאה'א ולכלול בשאילתה זיהוי הלקוח, הפנייה מחדש של URI, סוג תגובה ואחד או יותר סקופס (הרשאות) שהוא צריך.
- שרת הרשאה מאמת אותך, מבקש שם משתמש וסיסמה במידת הצורך.
- שרת הרשאה מציג טופס הסכמה (אישורים) עם רשימה של כולם סקופסביקש לקוח'אומ. אתה מסכים או מסרב.
- שרת הרשאה מפנה אותך לאתר לקוח'א, באמצעות הפנייה מחדש של URI עם קוד אימות (קוד אימות).
- לקוח מתקשר ישירות עם שרת הרשאה'אוהם (עוקף את הדפדפן בעל משאבים'א) ושולח בבטחה זיהוי הלקוח, סוד הלקוח и קוד אימות.
- שרת הרשאה בודק את הנתונים ומגיב עם אסימון גישה'om (אסימון גישה).
- עכשיו לקוח יכול להשתמש אסימון גישה לשלוח בקשה אליו שרת משאבים כדי לקבל רשימה של אנשי קשר.
זיהוי לקוח וסוד
הרבה לפני שהרשית למשחק המילים הנורא של היום לגשת לאנשי הקשר שלך, שרת הלקוח וההרשאות יצרו קשרי עבודה. שרת ההרשאות יצר את מזהה הלקוח ואת סוד הלקוח (נקרא לפעמים App ID и סוד האפליקציה) ושלחו אותם ללקוח להמשך אינטראקציה בתוך OAuth.
"- שלום! הייתי רוצה לעבוד איתך! - בטח, אין בעיה! הנה זיהוי הלקוח והסוד שלך!"
השם מרמז שסוד הלקוח חייב להישמר בסוד כך שרק הלקוח ושרת ההרשאות ידעו זאת. אחרי הכל, בעזרתו שרת ההרשאות מאשר את אמיתות הלקוח.
אבל זה לא הכל... אנא ברוך הבא ל-OpenID Connect!
OAuth 2.0 מיועד רק עבור הרשאה - כדי לספק גישה לנתונים ולפונקציות מאפליקציה אחת לאחרת. (OIDC) היא שכבה דקה על גבי OAuth 2.0 שמוסיפה את פרטי הכניסה והפרופיל של המשתמש שנכנס לחשבון. הארגון של פגישת התחברות מכונה לעתים קרובות אימות [אימות], ומידע על המשתמש המחובר למערכת (כלומר בערך בעל משאבים'ה), - מידע אישי [זהות]. אם שרת ההרשאות תומך ב-OIDC, הוא מכונה לפעמים ספק של נתונים אישיים [ספק זהות]כי זה מספק לקוח'יש מידע על בעל משאביםה.
OpenID Connect מאפשר לך ליישם תרחישים שבהם ניתן להשתמש בכניסה בודדת במספר יישומים - גישה זו ידועה גם בשם כניסה יחידה (SSO). לדוגמה, אפליקציה עשויה לתמוך בשילוב SSO עם רשתות חברתיות כמו פייסבוק או טוויטר, מה שמאפשר למשתמשים להשתמש בחשבון שכבר יש להם ומעדיפים להשתמש בו.
הזרימה (הזרימה) OpenID Connect נראית זהה למקרה של OAuth. ההבדל היחיד הוא שבבקשה הראשית, ההיקף הספציפי בו נעשה שימוש הוא openid, - א לקוח בסופו של דבר נהיה כמו אסימון גישהו - אסימון מזהה.
בדיוק כמו בזרימת OAuth, אסימון גישה ב-OpenID Connect, זהו ערך כלשהו שאינו ברור לקוח'בְּ. מנקודת מבט לקוח'א אסימון גישה מייצג מחרוזת תווים המועברת יחד עם כל בקשה אל שרת משאבים'y, שקובע אם האסימון תקף. אסימון מזהה מייצג דבר אחר לגמרי.
ID Token הוא JWT
אסימון מזהה הוא מחרוזת תווים בפורמט מיוחד המכונה JSON Web Token או JWT (לפעמים אסימוני JWT מבוטאים כמו "סימנים"). למשקיפים מבחוץ, JWT אולי נראה כמו ג'יבריש לא מובן, אבל לקוח יכול לחלץ מידע שונה מה-JWT, כגון מזהה, שם משתמש, זמן התחברות, תאריך תפוגה אסימון מזההא, נוכחותם של ניסיונות להפריע ל-JWT. נתונים בפנים אסימון מזההנקראים יישומים [טוען].
במקרה של OIDC, יש גם דרך סטנדרטית לפיה לקוח עשוי לבקש מידע נוסף על האדם [זהות] מ שרת הרשאה', למשל, כתובת אימייל באמצעות אסימון גישה.
למידע נוסף על OAuth ו-OIDC
אז, סקרנו בקצרה כיצד פועלים OAuth ו- OIDC. מוכנים לחפור יותר לעומק? הנה משאבים נוספים שיעזרו לך ללמוד עוד על OAuth 2.0 ו-OpenID Connect:
כמו תמיד, אתם מוזמנים להגיב. כדי להתעדכן בחדשות האחרונות שלנו, הירשם ל и Okta למפתחים!
נ.ב מהמתרגם
קרא גם בבלוג שלנו:
- «";
- «";
- «";
- «".
מקור: www.habr.com
