מבוא
כניסה באמצעות חשבון Google (SiwG) היא דרך מהירה ומאובטחת למשתמשים להיכנס לאפליקציה או לאתר שלכם. יישום נכון של התכונה הזו לא רק מפשט את תהליך ההרשמה של המשתמשים, אלא גם משפר את האבטחה של האפליקציה. במסמך הזה מפורטות השיטות המומלצות לשילוב של 'כניסה באמצעות חשבון Google' בפלטפורמות אינטרנט, Android ו-iOS. המסמכים האלה מתמקדים רק באימות. הרשאה לא נכללת במסגרת המסמך הזה.
רשימת משימות לבדיקת מוכנות לשילוב
רשימת המשימות הבאה היא מפת דרכים כללית שתעזור לכם בתהליך השילוב של 'כניסה באמצעות חשבון Google'. הוא מחולק לשלבים מרכזיים, מההגדרה הראשונית ועד להשקה בייצור. אפשר להשתמש ברשימה הזו כדי לעקוב אחרי ההתקדמות, וללחוץ על הקישורים כדי לעבור להנחיות המפורטות לכל אבן דרך.
שלב 0: תחילת העבודה (אופציונלי)
מתחילים את השילוב בעזרת סדנאות תכנות מעשיות למפתחים, עם הוראות מפורטות.
אתר: כדי ליצור שילוב בסיסי לאתר, משלימים את ה-codelab בנושא One-Tap וכפתור הכניסה באמצעות חשבון Google.
Android: כדי ללמוד את היסודות של מנהל פרטי הכניסה ב-Android, כדאי להשלים את ה-codelab Android.
iOS: כדי לקבל מבוא ל-iOS SDK, כדאי להשלים את iOS.
שלב 1: הגדרת פרויקט Google Cloud והמותג
כדאי לוודא שהפרויקט מוגדר בצורה שתאפשר לכם להשיג את המטרות שהצבתם לעצמכם.
מבנה הפרויקטים ב-Google Cloud עבור סביבות שונות ומותגים שונים.
משלימים את ההגדרה של מסך ההסכמה של OAuth עם כל המידע הנדרש לגבי מיתוג ותמיכה.
יוצרים את סוג מזהה לקוח OAuth הנכון לכל פלטפורמה (אינטרנט, Android, iOS).
שלב 2: פיתוח ליבה: חזית עורפית וחזית קדמית
יוצרים את הלוגיקה המאובטחת של השרת ואת חוויית המשתמש שספציפית לפלטפורמה.
בפיתוח הקצה הקדמי:
כדאי לעיין בשיטות המומלצות הכלליות לחוויית משתמש (UX) וליישם אותן כדי למקסם את אימוץ המוצר על ידי המשתמשים ואת האמון שלהם בו.
באינטרנט: משתמשים בספריית JavaScript הרשמית ומשלבים את תהליכי ההצטרפות בלחיצה אחת ואת הלחצן.
Android: משתמשים ב-Android SDK הרשמי לשילוב.
iOS: כדי לבצע שילוב, צריך להשתמש ב-iOS SDK הרשמי.
בפיתוח ה-Backend:
מטמיעים אימות מאובטח של אסימונים מזהים של Google בשרת העורפי.
משתמשים בטענת sub בתור מזהה משתמש ייחודי וקבוע במערכת.
אם רלוונטי, מתכננים את הפרדת היקפי האימות וההרשאה.
שלב 3: חיזוק האבטחה והשקה של הסביבה
חשוב לוודא שהשילוב מאובטח, עומד בדרישות ומוכן להפעלה.
כדאי לעיין בשיטות המומלצות לאבטחה וליישם אותן.
צריך להשלים את תהליך אימות אפליקציית OAuth לפני ההשקה.
חשוב לוודא שהאפליקציה מטפלת בצורה נכונה בביטול טוקן כשחשבון המשתמש נמחק.
שיטות מומלצות כלליות (לכל הפלטפורמות)
השיטות האלה רלוונטיות לכל פלטפורמה שאתם מפתחים עבורה. כדי לוודא שהם עומדים בכל הדרישות, המפתחים צריכים לעיין גם במדיניות הכללית בנושא OAuth 2.0.
הגדרת פרויקט Google Cloud
בקטע הזה מפורטות שיטות מומלצות לארגון הפרויקטים ב-Google Cloud ולהגדרת לקוחות OAuth לצורך אבטחה ותאימות למיתוג.
שימוש בפרויקטים נפרדים לבדיקה ולייצור
מכיוון שחלק ממדיניות Google חלה רק על אפליקציות בייצור, אתם צריכים ליצור פרויקטים נפרדים ב-Google Cloud Console עבור סביבות הפריסה השונות שלכם, כמו פיתוח, הכנה לייצור וייצור. פרטים נוספים זמינים בדף הזה.
שימוש בפרויקטים נפרדים לכל מותג או דומיין
אם הארגון שלכם מנהל כמה אפליקציות עם מותגים שונים, לכל מותג צריך להיות פרויקט ייעודי משלו ב-Google Cloud. המידע שמוצג למשתמשים במסך ההסכמה, כמו שם האפליקציה, הלוגו, כתובת האימייל לתמיכה וקישורים לתנאים ולהגבלות ולמדיניות הפרטיות, מוגדר ברמת הפרויקט. המשמעות היא שכל מזהי הלקוח ב-OAuth שנוצרו במסגרת פרויקט יחיד ישתמשו באותו מיתוג. הקצאת פרויקט נפרד לכל מותג מבטיחה שהמשתמשים יראו את המיתוג הנכון ואת המידע המשפטי הנכון של האפליקציה הספציפית שבה הם משתמשים.
צריך לספק כתובת אימייל כללית לתמיכה
כתובת האימייל לתמיכה במשתמשים מוצגת באופן ציבורי במסך ההסכמה ל-OAuth. כדי לשמור על מקצועיות ולהבטיח את המשכיות, תמיד צריך להגדיר כתובת אימייל כללית לתמיכה (למשל,
support@yourdomain.com) בהגדרת מסך ההסכמה ל-OAuth בפרויקט Google Cloud, במקום כתובת האימייל של עובד ספציפי. פרטים נוספים זמינים בדף הזה.לקוח OAuth לכל פלטפורמה
צריך ליצור לקוח OAuth נפרד לכל פלטפורמה שבה האפליקציה פועלת (למשל אינטרנט, Android, iOS), והכול באותו פרויקט ב-Google Cloud. חשוב להשתמש בסוג הלקוח הנכון לכל פלטפורמה משתי סיבות עיקריות:
- אבטחה משופרת: כל סוג לקוח מאפשר תכונות אבטחה ספציפיות לפלטפורמה. לדוגמה, אפשר לנעול לקוח Android באמצעות שם החבילה ואישור החתימה שלו, כדי למנוע שימוש לא מורשה במזהה הלקוח.
- פונקציונליות תקינה: ה-SDK מוודא שהאפליקציה משתלבת בצורה נכונה עם תכונות וערכות SDK ספציפיות לפלטפורמה, כמו Credential Manager ב-Android או Sign in with Google SDK ל-iOS.
המבנה הזה גם מפשט את חוויית המשתמש. ההסכמה מתקבלת ברמת פרויקט Google Cloud, ולכן המשתמשים צריכים להעניק אותה פעם אחת בלבד לאפליקציה בכל הפלטפורמות. פרטים נוספים זמינים במדיניות הרשמית בנושא OAuth 2.0.
איך משלימים אימות של אפליקציות ב-OAuth
כדי שהשם והלוגו של האפליקציה שלכם בייצור יוצגו, היא צריכה להיות מאומתת. סוג האימות תלוי בנתונים שאתם מבקשים מהמשתמש.
- התכונה כניסה באמצעות חשבון Google מבקשת רק היקפי הרשאה לאימות (
email,profileו-openid), ולכן היא כפופה לתהליך פשוט יותר של אימות מותג. התהליך הזה בדרך כלל מהיר יותר, והוא מתמקד באימות זהות המותג שלכם.
כדי לעזור לכם לתכנן את ציר הזמן של ההשקה, Google מספקת פירוט של סוגי האימות השונים וזמני הבדיקה הצפויים שלהם. פרטים נוספים על מדיניות האימות זמינים במרכז העזרה בנושא אימות אפליקציות OAuth.
- התכונה כניסה באמצעות חשבון Google מבקשת רק היקפי הרשאה לאימות (
אבטחה וטיפול באסימונים
בקטע הזה נתמקד בדרישות בזמן הריצה ובאמצעי האבטחה שמפתחים צריכים להטמיע בשרתי הקצה העורפי שלהם.
שילוב של טוקנים של מזהה Google עם ה-Backend
- אימות אסימון המזהה: חשוב תמיד לאמת את השלמות של אסימון המזהה של Google בשרת העורפי. לעולם אל תסמכו על אסימון רק בגלל שהוא נשלח מהלקוח שלכם. מומלץ להשתמש בספריית לקוח של Google API לצורך האימות הזה. מידע נוסף זמין במאמר בנושא אימות אסימון מזהה של Google בצד השרת.
- שימוש בטענת
sub: משתמשים רק בשדהsubשל אסימון Google ID כמזהה של המשתמש, כי הוא ייחודי ויציב בכל חשבונות Google, ואף פעם לא נעשה בו שימוש חוזר. מומלץ לאחסן את השדהsubולשייך אותו למשתמש במערכת לניהול החשבון. אפשר להשתמש בכתובת האימייל מטוקן ה-ID כדי לבדוק אם למשתמש יש חשבון קיים, אבל לא מומלץ להשתמש בכתובת האימייל כמזהה, כי לחשבון Google יכולות להיות כמה כתובות אימייל בנקודות זמן שונות.
ביטול טוקנים במחיקת חשבון
מומלץ מאוד לספק למשתמשים שנכנסים באמצעות חשבון Google את האפשרות לנתק את חשבון Google שלהם מהאפליקציה. אם משתמש בוחר למחוק את החשבון שלו, אתם צריכים לבטל את כל הגישה ואת כל טוקני הרענון שהאפליקציה שלכם קיבלה.
פרטים על ביטול אסימון בצד הלקוח זמינים במסמכי התיעוד של אינטרנט, Android ו-iOS. לביטול הרשאה בצד השרת, אפשר לעיין במאמר בנושא שימוש ב-OAuth 2.0 לאפליקציות אינטרנט.
הפרדה בין אימות להרשאה
ערכות ה-SDK של 'כניסה באמצעות חשבון Google' מבקשות רק את ההרשאות שנדרשות לאימות. אם האפליקציה שלכם צריכה גישה לשירותי Google אחרים (כמו יומן Google או Drive), אתם צריכים לבקש את ההרשאות האלה בנפרד ורק כשהמשתמש מנסה לבצע פעולה שדורשת אותן. לפרטים נוספים, ראו רגעים נפרדים של אימות והרשאה.
שיטות מומלצות לאבטחה
כדי לבצע שילוב מאובטח, צריך תמיד לאמת את אסימון המזהה בשרת העורפי באמצעות ספריית הלקוח של Google API. כדי לקבל הגנה מקיפה יותר מפני איומים שונים, כדאי להטמיע את חבילת האבטחה ואת ההגנה על כל החשבונות (RISC). בנוסף, באפליקציות ל-iOS מומלץ מאוד לשלב את App Check כדי לוודא שהבקשות מגיעות מהאפליקציה המקורית שלכם.
חוויית משתמש (UX)
בקטע הזה נתמקד באופטימיזציה של הרכיבים שמוצגים למשתמשים ובתהליכי הכניסה וההרשמה.
הצגת הכפתור באופן בולט: הכפתור 'כניסה באמצעות חשבון Google' צריך להיות גלוי ונגיש בדף הכניסה וההרשמה.
פועלים בהתאם להנחיות המיתוג: כדי להבטיח חוויית משתמש עקבית ומהימנה, צריך להשתמש בלחצני הכניסה הרשמיים עם המיתוג של Google. קוראים את ההנחיות הרשמיות למיתוג של 'כניסה באמצעות חשבון Google'.
הרשמה חלקה: למשתמשים חדשים, יצירת חשבון באופן אוטומטי או הפניית משתמשים לתהליך יצירת חשבון חדש אחרי הכניסה הראשונה שלהם באמצעות תהליך הכניסה עם Google. בצד השרת, בודקים אם קיים משתמש עם מזהה
subנתון. אם לא, יוצרים חשבון חדש. כך מצמצמים את המאמץ שנדרש להרשמה.כניסה פשוטה יותר: משתמשים חוזרים יכולים להשתמש במזהה
subכדי להזדהות ולהיכנס לחשבון הקיים שלהם. כדי להחזיר את המשתמשים לאפליקציה במהירות ובאופן מאובטח, כדאי להטמיע תכונות כמו כניסה אוטומטית לאינטרנט ול-Android.ניהול שיטות כניסה באמצעות חשבונות ברשתות חברתיות: מספק קטע מרכזי של 'חשבונות מקושרים' בהגדרות המשתמש, שבו המשתמשים יכולים לנהל שיטות שונות של כניסה באמצעות חשבונות ברשתות חברתיות (למשל, Google).
קישור: הוספת לחצן 'כניסה באמצעות חשבון Google' למשתמשים קיימים שמשתמשים בשיטות אחרות (למשל, שם משתמש וסיסמה). לחיצה על הקישור הזה תתחיל את תהליך האימות לקישור חשבון Google לפרופיל הקיים.
ביטול הקישור: צריך לספק אפשרות לניתוק החשבון. כדי להשלים את הפעולה הזו, צריך לבטל את הטוקנים ולהסיר את השיוך של Google מהמסד הנתונים.
הטמעה ב-Android (אפליקציות ומשחקים)
אפליקציות Android רגילות
ביישומים ל-Android, מומלץ להשתמש בCredential Manager. זו הגישה המומלצת לטיפול בפרטי הכניסה של המשתמשים, והיא מספקת חוויית כניסה מאוחדת, מאובטחת ועקבית ב-Android.
משתמשים במזהה הלקוח ב-OAuth ל-Android לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, אינטרנט, iOS), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג Android באותו פרויקט Google Cloud.
תהליכי הטמעה
הטמעה חזקה צריכה לכלול גם את ממשק המשתמש של Credential Manager וגם את הלחצן 'כניסה באמצעות חשבון Google'.
- תחתית דף: זוהי הצעה לפעולה שמוצגת על ידי מנהל פרטי הכניסה כשהמשתמש מגיע למסך הכניסה שלכם. ההצעה הזו מופעלת על ידי מפתחים ומוצגת בצורה לא פולשנית.
- כפתור לכניסה באמצעות חשבון Google: זהו תהליך כניסה מפורש שמתחיל על ידי המשתמש בלחיצה על הכפתור.
- הגדרת פרויקט מדויקת ב-Google Cloud היא חיונית. התהליך כולל יצירה של סוגים נכונים של מזהי לקוחות ב-OAuth ומתן פרטים ספציפיים כמו
SHA-1טביעת האצבע של האישור של האפליקציה. כדי לוודא שההגדרה נכונה, חשוב לפעול בדיוק לפי המדריך הרשמי למפתחים של Android.
חשוב תמיד לכלול את תהליך הלחיצה על הלחצן, כי יכול להיות שהמשתמש יסגור את התפריט או ישבית אותו בהעדפות שלו. הכפתור מבטיח שהם תמיד יוכלו להתחיל את תהליך הכניסה.
אסטרטגיית מיקום
כפתור לכניסה באמצעות חשבון Google:
- מיקום: מציגים את הלחצן לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
- מיקום: כדאי למקם את הלחצן במקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
גיליון מידע תחתון של Credential Manager:
- הפעלה: צריך להפעיל את התחתית באופן אוטומטי כשדף הכניסה מופעל או כשהאפליקציה מתחילה לפעול. אסור שההודעה תוצג בעקבות הקשה של המשתמש על לחצן.
- כניסה אוטומטית: למשתמשים חוזרים מומלץ מאוד להפעיל את האפשרות כניסה אוטומטית במנהל האישורים. כך משתמשים חוזרים (שנתנו בעבר הסכמה) יכולים להיכנס מחדש לאפליקציה שלכם ללא כל אינטראקציה.
משחקי Android
במשחקי Android, לא מומלץ להשתמש במנהל פרטי הכניסה. במקום זאת, מפתחי משחקים צריכים להשתמש בגישה של Google Play Games Services (PGS), שמתמקדת בזהות Google חוצת פלטפורמות באמצעות 'כניסה באמצעות חשבון Google'. פרטים נוספים זמינים במסמכי התיעוד בנושא זהות Google חוצת פלטפורמות באמצעות כניסה באמצעות חשבון Google.
הטמעה ב-iOS
שימוש ב-SDK הרשמי של 'כניסה באמצעות חשבון Google'
באפליקציות ל-iOS, צריך להשתמש ב-Sign in with Google for iOS and macOS SDK הרשמי. הספרייה הזו מספקת את הדרך המאובטחת והידידותית ביותר לשילוב של 'כניסה באמצעות חשבון Google'.
משתמשים במזהה הלקוח ב-OAuth ל-iOS לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, אינטרנט, Android), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג iOS באותו פרויקט ב-Google Cloud.
הוספת הלחצן 'כניסה באמצעות חשבון Google'
- מיקום: מוסיפים את הלחצן 'כניסה באמצעות חשבון Google' לתצוגת הכניסה של האפליקציה, גם בדפי ההרשמה וגם בדפי הכניסה. הכפתור צריך להיות במיקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
- שימוש ברכיבים מומלצים: צריך להשתמש ברכיבי הלחצנים הרשמיים שסופקו על ידי ה-SDK גם עבור SwiftUI וגם עבור UIKit. הרכיבים האלה יוצרים באופן אוטומטי לחצן שעומד בהנחיות המיתוג של Google, והם הדרך המומלצת להצגת הלחצן.
שיפור האבטחה באמצעות בדיקת אפליקציות
כדי להגן על משאבי הקצה העורפי מפני ניצול לרעה, צריך לוודא שהבקשות ללקוח OAuth 2.0 מגיעות מהאפליקציה המקורית שלכם. כדי לוודא שהבקשות מגיעות ממופע מקורי של האפליקציה שלא בוצעו בו שינויים, App Check משתמש בספק אישורים ומדחה בקשות שלא עומדות בתנאי הזה. פרטים נוספים זמינים במאמר בנושא App Check לכניסה באמצעות חשבון Google ב-iOS.
הטמעה באתר
הנחיות לאתרים ולאפליקציות אינטרנט.
שימוש בספריית JavaScript הרשמית של 'כניסה באמצעות חשבון Google'
להטמעות באינטרנט, מומלץ להשתמש בספריית JavaScript הרשמית של 'כניסה באמצעות חשבון Google'. זוהי הגרסה האחרונה של ספריות הזהויות של Google לאינטרנט, והיא כוללת את התכונות Button ו-One Tap.
משתמשים במזהה הלקוח ב-OAuth עבור אינטרנט לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, Android, iOS), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג אינטרנט באותו פרויקט Google Cloud.
הטמעה של תהליכי Button ו-One Tap
מומלץ להטמיע גם את הלחצן 'כניסה באמצעות חשבון Google' וגם את חוויית הכניסה באמצעות One Tap.
- כפתור לכניסה באמצעות חשבון Google: זהו תהליך כניסה או הרשמה מפורש שמתחיל על ידי המשתמש.
- One Tap: בקשה חלקה ולא מפריעה לכניסה או להרשמה.
- משתמשים באותו מזהה לקוח ב-OAuth עבור Web בשני ההטמעות.
תמיד כדאי לכלול את הלחצן כאפשרות כניסה ראשית. המשתמשים יכולים לסגור או להשבית את הכניסה בלחיצה אחת בהגדרות של חשבון Google, אבל הכפתור תמיד יהיה זמין, כדי שהמשתמשים לא ייחסמו ולא יוכלו להיכנס לחשבון.
אסטרטגיית מיקום
כפתור לכניסה באמצעות חשבון Google:
- מיקום: הצגת כפתור מותאם אישית לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
- חשוב לזכור שאין דפוס אחד שמתאים לכל האתרים (למשל הפניה אוטומטית לעומת חלון קופץ). צוות עיצוב האתר או צוות חוויית המשתמש צריך לבדוק את תהליכי ההרשמה והכניסה ולבצע בהם אופטימיזציה כדי להגדיל את שיעורי ההשלמה שלהם.
- מיקום: כדאי למקם את הלחצן במקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
- בדיקה: כדאי לעיין בקטע שיקולים לגבי כפתור הכניסה באמצעות חשבון Google כדי להבין איך להגדיר את הכפתור בצורה אופטימלית ולשפר את הביצועים.
- מיקום: הצגת כפתור מותאם אישית לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
הנחיה בלחיצה אחת:
- מיקום: הצגת ההנחיה להצטרפות בלחיצה אחת בכמה דפים באתר, כמו דפים של מוצרים ספציפיים, דפים של מאמרים ואפילו דף הבית. היתרון העיקרי של התכונה 'הקשה אחת' הוא שהיא מאפשרת למשתמשים להיכנס לחשבון או ליצור חשבון בלי לעזוב את הדף הנוכחי.
- כניסה אוטומטית: למשתמשים חוזרים, מומלץ מאוד להפעיל את האפשרות כניסה אוטומטית ב-One Tap. כך משתמשים חוזרים (שנתנו בעבר הסכמה) יכולים להיכנס מחדש לאפליקציה שלכם בלי לבצע שום פעולה.
- בדיקה: כדאי לעיין בקטע שיקולים לשימוש בתכונה 'הצטרפות בלחיצה אחת' כדי להבין איך להגדיר את התכונה בצורה אופטימלית ולשפר את הביצועים.