מה זה OAuth ו'התחבר עם Google'?

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

אז מה זה OAuth באמת?

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

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

OAuth הוא ראשי תיבות של 'open authorization' (הרשאה פתוחה), והמילה 'הרשאה' חשובה. OAuth הוא בעצם על מתן הרשאה מוגבלת. כשאפליקציה מבקשת 'להתחבר עם Google', היא יכולה גם לבקש הרשאות מסוימות - למשל לקרוא את היומן או אנשי הקשר - ואפשר לאשר או לדחות כל אחת. מוסרים מפתח צר ומוגדר, לא את מפתח האב לכל החשבון.

הדימוי של הכרטיס המגנטי

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

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

למה OAuth בטוח יותר מסיסמאות

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

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

מה ההטמעה של OAuth אומרת לאפליקציה שלך

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

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

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

שאלות הפרטיות שכדאי להבין

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

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

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

אז האם צריך להתייחס ל-OAuth?

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

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