אימות משתמשים

כדי לאמת משתמשים ב Google Cloud אפליקציות, Google מציעה את שיטות אימות המשתמשים הבאות:

שירות אימות סיכום
‫Identity Platform (מומלץ) אימות משתמשים באמצעות סיסמאות, מספרי טלפון, ספקי זהויות פופולריים ומאוחדים כמו Google,‏ Facebook,‏ Twitter וכל ספק שתומך בפרוטוקול SAML או OpenID Connect. הוא מציע תכונות לארגונים, כולל אימות רב-שלבי, תמיכה ב-SSO ב-OIDC וב-SAML, ריבוי דיירים, הסכם רמת שירות (SLA) של 99.95% ועוד.

השיטה המומלצת כשמתחילים פרויקט חדש, כדי שתוכלו להשתמש ביכולות של Identity Platform וגם בתכונות מדור קודם של אימות ב-Firebase.
אימות ב-Firebase אימות משתמשים באמצעות אפשרויות אימות שונות, כולל באמצעות Google, ‏ Facebook ו-Twitter. האימות ב-Firebase תומך במספר הגדול ביותר של משתמשים, תוך שמירה על כמות הקוד הקטנה ביותר.

השיטה המומלצת לפריסת פתרון במספר הקטן ביותר של שלבים.
Google Identity Services for Web אימות משתמשים באמצעות חשבונות משתמשים של Google מ-Gmail ומ-Google Workspace.

השיטה המומלצת לתמיכה בחשבונות רק של Google או לתמיכה בחשבונות Google במערכת כניסה קיימת.
OAuth 2.0 ו-OpenID Connect מספק זהות מאוחדת מהספק שתבחרו, כולל Google.

השיטה המומלצת אם רוצים ליצור את פרוטוקול אימות המשתמש בעצמכם.
שרת proxy לאימות זהויות (IAP) השירות מספק אימות על ידי הוספת שכבת אימות של ניהול זהויות והרשאות גישה (IAM) מעל אפליקציית App Engine. שרת IAP מאפשר לשלוט בגישה לשירותי App Engine לפני שהבקשות מגיעות למשאבי האפליקציה. לכן, השימוש ב-IAP לא מתאים להגנה מפני פעילות באותו פרויקט. Google Cloud

השיטה המומלצת אם רוצים להשתמש בחשבונות Google וב-IAM כדי לשלוט בגישת המשתמשים.
‫Users API אימות משתמשים שמשתמשים בחשבונות Google ו-Google Workspace. הגישה לשירות Users של App Engine אפשרית רק דרך חבילת השירותים מדור קודם.

Identity Platform

‫Identity Platform היא פלטפורמה לניהול זהויות והרשאות גישה של לקוחות (CIAM), שמאפשרת לארגונים להתאים אישית את הזהות והאימות של משתמשים שנרשמים ונכנסים לאפליקציות שלהם. ב-Identity Platform יש תמיכה במספר שיטות אימות (SAML,‏ OIDC,‏ אימייל/סיסמה, רשתות חברתיות, טלפון ואימות בהתאמה אישית) כדי לספק אפשרויות שילוב גמישות לכל פתרון זהויות. הפלטפורמה Identity Platform מבוססת עלGoogle Cloud, ומציעה ביצועים, רשת ואבטחה ברמה גלובלית, וגם תמיכה ברמה ארגונית והסכם רמת שירות (SLA) כדי לענות על הדרישות של כמעט כל אפליקציה או שירות.

הפתרון הזה מתאים לרוב המשתמשים שרוצים אפשרויות אימות גמישות שמבוססות על תכונות אמינות ברמה ארגונית ועל הסכמי רמת שירות (SLA).

ל-Identity Platform יש מערכת משלה לזהות משתמשים. אם אתם כבר משתמשים ב-Google Workspace בדומיין שלכם ורוצים לאמת משתמשים על סמך הכניסה הזו, אתם צריכים להשתמש ב-Google Identity Services for Web.

כדי ללמוד על שילוב של Identity Platform עם App Engine, אפשר לעיין במדריך כניסת משתמשים ל-App Engine.

אימות ב-Firebase

אימות ב-Firebase הוא שירות זהויות ואימות שניתן לשלב ולהתאים אישית, ומיועד להרשמה ולכניסה של משתמשים. בדומה ל-Identity Platform, אימות ב-Firebase תומך במספר שיטות אימות (SAML,‏ OIDC,‏ אימייל/סיסמה, רשתות חברתיות, נייד ואימות בהתאמה אישית) כדי לספק אפשרויות שילוב גמישות לכל פתרון זהויות.

ההבדל בין אימות ב-Firebase לבין Identity Platform הוא שחסרים בו תכונות מסוימות שמתאימות לארגונים. מידע נוסף זמין במאמר ההבדלים בין Identity Platform לבין האימות ב-Firebase.

הפתרון הזה מתאים במיוחד אם אתם רוצים להגדיר אימות משתמשים באפליקציית App Engine בצורה הקלה ביותר. עבור משתמשים רבים, אימות ב-Firebase הוא הדרך המהירה ביותר להטמיע או לבדוק אימות.

כדי לקבל מידע נוסף על אימות ב-Firebase, אפשר לנסות את האפשרויות הבאות:

‫Google Identity Services לאינטרנט

‫Google Identity Services for Web היא ספריית לקוח לכניסה לחשבון Google, שמבוססת על הפרוטוקולים OAuth 2.0 ו-OpenID Connect. הוא מאפשר כניסה מהירה ופשוטה באמצעות כפתור 'כניסה באמצעות Google' שמופיע באתר או באפליקציה.

הפתרון הזה מתאים במיוחד אם רוצים לאמת משתמשים על סמך חשבון Google שלהם, או אם משתמשים במסוף Google Admin עבור הדומיין.

‫OAuth 2.0 ו-OpenID Connect

‏OpenID Connect היא שכבת זהות שמתלבשת על פרוטוקול OAuth 2.0. ‫Google מציעה הטמעה של OAuth 2.0 שתואמת למפרט של OpenID Connect ומאושרת על ידי OpenID. יש גם כמה ספקים אחרים שזמינים.

הפתרון הזה מתאים במיוחד אם אתם רוצים התאמה אישית ושליטה מלאות בהטמעה של האימות.

מידע נוסף זמין במאמר בנושא OpenID Connect.

שרת proxy לאימות זהויות (IAP)

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

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

השימוש ב-IAP לא מגן מפני פעילות בתוך פרויקטים, כמו שירות App Engine אחד ששולח בקשת גישה לשירות אחר באותו פרויקט.

הפתרון הזה מתאים במיוחד אם רוצים להשתמש בחשבונות משתמשים של Google וב-IAM כדי לאשר גישת משתמשים.

במדריך למתחילים בנושא IAP מוסבר איך להגדיר את IAP למשאבי App Engine.

Users API

ה-API של המשתמשים מאפשר לאפליקציית App Engine לבצע את המשימות הבאות:

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

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

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

מידע על שילוב של Users API מופיע בסקירה הכללית על Users API.

שירותי אימות אחרים

‫Auth0 מספק אימות עם ספקי זהויות שונים ותכונות של כניסה יחידה (SSO).