מבוא
כניסה באמצעות חשבון Google (SiwG) היא דרך מהירה ומאובטחת למשתמשים להיכנס לאפליקציה או לאתר שלכם. יישום נכון של התכונה הזו לא רק מפשט את תהליך ההרשמה של המשתמשים, אלא גם משפר את האבטחה של האפליקציה. במסמך הזה מפורטות השיטות המומלצות לשילוב של 'כניסה באמצעות חשבון Google' בפלטפורמות של אינטרנט, Android ו-iOS. המסמכים האלה מתמקדים רק באימות. הרשאה לא נכללת במסגרת המסמך הזה.
רשימת משימות לשילוב
רשימת המשימות הבאה היא מפת דרכים כללית שתעזור לכם בתהליך השילוב של 'כניסה באמצעות חשבון Google'. הוא מחולק לשלבים מרכזיים, מההגדרה הראשונית ועד להשקה בייצור. אפשר להשתמש ברשימה הזו כדי לעקוב אחרי ההתקדמות, וללחוץ על הקישורים כדי לעבור להנחיות המפורטות לכל אבן דרך.
שלב 0: תחילת העבודה (אופציונלי)
מתחילים את השילוב בעזרת סדנאות תכנות מעשיות למפתחים, עם הוראות מפורטות.
אתר: כדי ליצור שילוב בסיסי לאתר, משלימים את ה-Codelab בנושא One-Tap וכפתור הכניסה באמצעות חשבון Google.
Android: כדי ללמוד את היסודות של מנהל פרטי הכניסה ב-Android, כדאי להשלים את ה-Codelab בנושא Android.
iOS: כדי לקבל מבוא ל-iOS SDK, כדאי לעבור על ה-codelab בנושא iOS.
שלב 1: הגדרת פרויקט בענן של Google והמותג
כדאי לוודא שהפרויקט מוגדר בצורה שתאפשר לכם להשיג את המטרות שהצבתם לעצמכם.
מבנה הפרויקטים ב-Google Cloud עבור סביבות ומותגים שונים.
משלימים את ההגדרה של מסך הסכמה ל-OAuth עם כל המידע הנדרש לגבי המיתוג והתמיכה.
יוצרים את סוג מזהה הלקוח הנכון של OAuth לכל פלטפורמה (אינטרנט, Android, iOS).
שלב 2: פיתוח ליבה: חזית קדמית ובק-אנד
יוצרים את הלוגיקה המאובטחת של השרת ואת חוויית המשתמש שספציפית לפלטפורמה.
בפיתוח הקצה הקדמי:
כדאי לעיין בשיטות המומלצות הכלליות לחוויית משתמש (UX) וליישם אותן כדי למקסם את אימוץ המוצר על ידי המשתמשים ואת האמון שלהם בו.
באינטרנט: משתמשים בספריית JavaScript הרשמית ומשלבים את תהליכי ההרשמה באמצעות לחצן ותהליכי ההרשמה בלחיצה אחת.
Android: משתמשים ב-Android SDK הרשמי לשילוב.
iOS: כדי לבצע שילוב, צריך להשתמש ב-official iOS SDK.
בפיתוח ה-Backend:
מטמיעים אימות מאובטח של אסימונים מזהים של Google בקצה העורפי.
משתמשים בטענת sub כמזהה משתמש ייחודי וקבוע במערכת.
אם רלוונטי, מתכננים את ההפרדה בין היקפי האימות וההרשאה.
שלב 3: חיזוק האבטחה והשקה של הסביבה
חשוב לוודא שהשילוב מאובטח, עומד בדרישות ומוכן לסביבת הייצור.
כדאי לעיין בשיטות המומלצות לאבטחה וליישם אותן.
צריך להשלים את תהליך אימות אפליקציית OAuth לפני ההשקה.
חשוב לוודא שהאפליקציה מטפלת בצורה נכונה בביטול הטוקן כשחשבון המשתמש נמחק.
שיטות מומלצות כלליות (לכל הפלטפורמות)
השיטות האלה רלוונטיות לכל פלטפורמה שאתם מפתחים עבורה. כדי לוודא שאתם עומדים בכל הדרישות, כדאי למפתחים לעיין גם במדיניות הכללית בנושא OAuth 2.0.
הגדרת פרויקט בענן ב-Google Cloud
בקטע הזה מפורטות שיטות מומלצות לארגון הפרויקטים ב-Google Cloud ולהגדרת לקוחות OAuth לצורך אבטחה ותאימות למיתוג.
שימוש בפרויקטים נפרדים לבדיקה ולייצור
מכיוון שחלק ממדיניות Google חלה רק על אפליקציות בייצור, אתם צריכים ליצור פרויקטים נפרדים ב-מסוף Google Cloud עבור סביבות הפריסה השונות שלכם, כמו פיתוח, הכנה לייצור וייצור. פרטים נוספים מופיעים בדף הזה.
שימוש בפרויקטים נפרדים לכל מותג או דומיין
אם הארגון שלכם מנהל כמה אפליקציות עם מותגים שונים, לכל מותג צריך להיות פרויקט ייעודי משלו ב-Google Cloud. המידע שמוצג למשתמשים במסך ההסכמה, כמו שם האפליקציה, הלוגו, כתובת האימייל לתמיכה וקישורים לתנאים ולהגבלות ולמדיניות הפרטיות, מוגדר ברמת הפרויקט. כלומר, כל מזהי הלקוח ב-OAuth שנוצרו במסגרת פרויקט יחיד ישתמשו באותו מותג. הקצאת פרויקט נפרד לכל מותג מבטיחה שהמשתמשים יראו את המיתוג הנכון ואת המידע המשפטי הנכון לגבי האפליקציה הספציפית שבה הם משתמשים.
צריך לציין כתובת אימייל כללית לתמיכה
כתובת האימייל לתמיכה במשתמשים מוצגת באופן ציבורי במסך ההסכמה של OAuth. כדי לשמור על מקצועיות ולהבטיח רציפות, תמיד צריך להגדיר כתובת אימייל כללית לתמיכה (לדוגמה
support@yourdomain.com) בהגדרות של מסך הסכמה ל-OAuth בפרויקט Google Cloud, במקום כתובת אימייל של עובד ספציפי. פרטים נוספים זמינים בדף הזה.לקוח OAuth לכל פלטפורמה
צריך ליצור לקוח OAuth נפרד לכל פלטפורמה שבה האפליקציה פועלת (למשל, אינטרנט, Android, iOS), והכול במסגרת אותו פרויקט Google Cloud. חשוב להשתמש בסוג הלקוח הנכון לכל פלטפורמה משתי סיבות עיקריות:
- אבטחה משופרת: כל סוג לקוח מאפשר תכונות אבטחה ספציפיות לפלטפורמה. לדוגמה, אפשר לנעול לקוח Android באמצעות שם החבילה ואישור החתימה שלו, כדי למנוע שימוש לא מורשה במזהה הלקוח.
- פונקציונליות תקינה: ה-SDK מבטיח שהאפליקציה שלכם משתלבת בצורה נכונה עם ערכות SDK ותכונות ספציפיות לפלטפורמה, כמו Credential Manager ב-Android או כניסה באמצעות חשבון 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 ול-iOS.ניהול שיטות כניסה לרשתות חברתיות: מספק קטע מרכזי של 'חשבונות מקושרים' בהגדרות המשתמש, שבו המשתמשים יכולים לנהל שיטות שונות של כניסה לרשתות חברתיות (למשל, Google).
קישור: הוספת לחצן 'כניסה באמצעות חשבון Google' למשתמשים קיימים שמשתמשים בשיטות אחרות (למשל, שם משתמש וסיסמה). לחיצה על הקישור הזה תתחיל את תהליך האימות לקישור חשבון Google לפרופיל הקיים.
ביטול הקישור: צריך לספק אפשרות לניתוק החשבון. כדי להשלים את הפעולה הזו, צריך לבטל את הטוקנים ולהסיר את השיוך של Google מהמסד הנתונים.
הטמעה ב-Android (אפליקציות ומשחקים)
אפליקציות Android רגילות
ביישומים ל-Android, מומלץ להשתמש בCredential Manager. זו הגישה המומלצת לטיפול בפרטי הכניסה של המשתמשים, והיא מספקת חוויית כניסה מאוחדת, מאובטחת ועקבית ב-Android.
משתמשים במזהה הלקוח ב-OAuth עבור Android לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, אינטרנט, iOS), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג Android באותו פרויקט Google Cloud.
תהליכי הטמעה
הטמעה חזקה צריכה לכלול גם את ממשק המשתמש של Credential Manager וגם את הלחצן 'כניסה באמצעות חשבון Google'.
- Bottomsheet: זוהי הצעה לפעולה שמוצגת על ידי Credential Manager כשהמשתמש מגיע למסך הכניסה שלכם. ההצעה הזו מופעלת על ידי מפתחים ומוצגת בצורה לא פולשנית.
- כפתור לכניסה באמצעות חשבון Google: זהו תהליך כניסה מפורש שמתחיל על ידי המשתמש בלחיצה על הכפתור.
- הגדרת פרויקט בענן מדויקת ב-Google Cloud היא חיונית. התהליך כולל יצירה של סוגים נכונים של מזהי לקוחות ב-OAuth ומתן פרטים ספציפיים כמו
SHA-1טביעת אצבע לאישור של האפליקציה. כדי לוודא שההגדרה נכונה, חשוב לפעול בדיוק לפי ההוראות במדריך הרשמי למפתחים של Android.
תמיד צריך לכלול את רצף הפעולות של הלחצן, כי יכול להיות שהמשתמש יסגור את התחתית או ישבית אותה בהעדפות שלו. הכפתור מאפשר להם להתחיל את תהליך הכניסה בכל שלב.
אסטרטגיית מיקום
כפתור לכניסה באמצעות חשבון Google:
- מיקום: מציגים את הלחצן לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
- מיקום: מומלץ למקם את הלחצן במקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
גיליון מידע בתחתית המסך של Credential Manager:
- הפעלה: צריך להפעיל את ה-bottomsheet באופן אוטומטי כשדף הכניסה מופעל או כשהאפליקציה מתחילה לפעול. אסור שההודעה תופיע כשמשתמש מקיש על לחצן.
- כניסה אוטומטית: למשתמשים חוזרים מומלץ מאוד להפעיל את האפשרות כניסה אוטומטית ב-Credential Manager. כך משתמשים חוזרים (שנתנו בעבר הסכמה) יכולים להיכנס מחדש לאפליקציה שלכם ללא אינטראקציה.
משחקי Android
במשחקי Android, לא מומלץ להשתמש ב-Credential Manager. במקום זאת, מפתחי משחקים צריכים להשתמש בגישה של Google Play Games Services (PGS), שמתמקדת בזהות בפלטפורמות שונות של Google באמצעות כניסה באמצעות חשבון Google. מידע נוסף זמין במסמכי התיעוד בנושא המשכיות בפלטפורמות שונות באמצעות SiWG.
הטמעה ב-iOS
שימוש ב-SDK הרשמי של 'כניסה באמצעות חשבון Google'
באפליקציות ל-iOS, צריך להשתמש ב-SDK הרשמי של 'כניסה באמצעות חשבון Google' ל-iOS ול-macOS. הספרייה הזו מספקת את הדרך המאובטחת והידידותית ביותר למשתמש לשילוב של 'כניסה באמצעות חשבון Google'.
משתמשים במזהה הלקוח ב-OAuth עבור iOS לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, אינטרנט, Android), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג iOS באותו פרויקט Google Cloud.
הוספת הלחצן 'כניסה באמצעות חשבון Google'
- מיקום: מוסיפים את הלחצן 'כניסה באמצעות חשבון Google' לתצוגת הכניסה של האפליקציה, גם בדפי ההרשמה וגם בדפי הכניסה. כדאי למקם אותו במקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
- שימוש ברכיבים מומלצים: צריך להשתמש ברכיבי הלחצנים הרשמיים שסופקו על ידי ה-SDK גם עבור SwiftUI וגם עבור UIKit. הרכיבים האלה יוצרים באופן אוטומטי לחצן שעומד בספר המותג של Google, והם הדרך המומלצת להצגת הלחצן.
שחזור מצב הכניסה של משתמש
- חזרה חלקה: כשמפעילים את האפליקציה, קוראים ל-
restorePreviousSignInכדי לנסות לשחזר את מצב הכניסה של משתמשים שכבר עברו אימות באמצעות Google. כך משתמשים חוזרים לא צריכים להיכנס לחשבון בכל פעם שהם פותחים את האפליקציה, והחוויה חלקה כמו כניסה אוטומטית בפלטפורמות אחרות.
שיפור האבטחה באמצעות App Check
כדי להגן על משאבי הקצה העורפי מפני ניצול לרעה, צריך לוודא שהבקשות ללקוח OAuth 2.0 מגיעות מהאפליקציה המקורית שלכם. App Check משתמש בספק אישורים כדי לוודא שהבקשות מגיעות ממופע מקורי של האפליקציה שלא בוצעו בו שינויים, ודוחה את הבקשות שלא עומדות בתנאי הזה. פרטים נוספים זמינים במאמר בנושא App Check לכניסה באמצעות חשבון Google ב-iOS.
הטמעה באתר
הנחיות לאתרים ולאפליקציות אינטרנט.
שימוש בספריית JavaScript הרשמית של 'כניסה באמצעות חשבון Google'
להטמעות באינטרנט, מומלץ להשתמש בספריית JavaScript הרשמית של 'כניסה באמצעות חשבון Google'. זוהי הגרסה האחרונה של ספריות הזהויות של Google לאינטרנט, והיא כוללת את התכונות Button ו-לחיצה אחת.
משתמשים במזהה הלקוח ב-OAuth עבור אינטרנט לצורך הטמעה. אם כבר הטמעתם את 'כניסה באמצעות חשבון Google' בפלטפורמות אחרות (למשל, Android, iOS), אתם צריכים ליצור מזהה לקוח OAuth חדש מסוג אינטרנט באותו פרויקט Google Cloud.
הטמעה של תהליכי כפתור ותהליכי מעבר בלחיצה אחת
מומלץ להטמיע גם את הלחצן 'כניסה באמצעות חשבון Google' וגם את חוויית הכניסה בלחיצה אחת.
- כפתור לכניסה באמצעות חשבון Google: זהו תהליך מפורש של כניסה או הרשמה שמתחיל על ידי המשתמש.
- לחיצה אחת: זוהי בקשה חלקה עם מעט הפרעות לכניסה או להרשמה.
- משתמשים באותו מזהה לקוח ב-OAuth עבור Web בשני ההטמעות.
תמיד כדאי לכלול את הלחצן כאמצעי התחברות ראשי. המשתמשים יכולים לסגור או להשבית את הכניסה בלחיצה אחת בהגדרות של חשבון Google, אבל הכפתור תמיד יהיה זמין, כדי שהמשתמשים לא ייחסמו מכניסה לחשבון.
אסטרטגיית מיקום
כפתור לכניסה באמצעות חשבון Google:
- מיקום: מציגים את הכפתור המותאם אישית לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
- חשוב לזכור שאין דפוס אחד שמתאים לכל האתרים (למשל הפניה אוטומטית לעומת חלון קופץ). צוות עיצוב האתר או צוות חוויית המשתמש צריך לבדוק את רצפי הפעולות האלה ולבצע בהם אופטימיזציה כדי להגדיל את שיעורי ההשלמה של תהליכי ההרשמה והכניסה.
- מיקום: מומלץ למקם את הלחצן במקום בולט לצד שיטות כניסה אחרות, כמו שדות של שם משתמש וסיסמה או ספקי כניסה אחרים לרשתות חברתיות.
- בדיקה: כדאי לעיין בקטע שיקולים לגבי כפתור הכניסה באמצעות חשבון Google כדי להבין איך להגדיר את הכפתור בצורה אופטימלית ולשפר את הביצועים.
- מיקום: מציגים את הכפתור המותאם אישית לכניסה באמצעות חשבון Google בדפי ההרשמה או הכניסה הייעודיים.
הנחיה בלחיצה אחת:
- מיקום: הצגת ההנחיה 'הצטרפות בלחיצה אחת' בכמה דפים באתר, כמו דפים של מוצרים ספציפיים, דפים של מאמרים ואפילו דף הבית. היתרון העיקרי של התכונה 'לחיצה אחת' הוא שהיא מאפשרת למשתמשים להיכנס לחשבון או ליצור חשבון בלי לצאת מהדף הנוכחי.
- כניסה אוטומטית: למשתמשים חוזרים, מומלץ מאוד להפעיל את האפשרות כניסה אוטומטית ב-One Tap. כך משתמשים חוזרים (שנתנו בעבר הסכמה) יכולים להיכנס מחדש לאפליקציה שלכם בלי לבצע שום פעולה.
- בדיקה: כדאי לעיין בקטע שיקולים לשימוש בתכונה 'הצטרפות בלחיצה אחת' כדי להבין איך להגדיר את התכונה בצורה אופטימלית ולשפר את הביצועים.