בטבלה הבאה מפורטים פרטי הכניסה שאפליקציה צריכה לנהל. מידע נוסף על סוגי אפליקציות זמין בתיעוד של OAuth 2.0 של Google Identity.
| תהליך העבודה של האימות | פרטי כניסה | סוג פרטי הכניסה | מטרה |
|---|---|---|---|
|
אפליקציות אינטרנט ב-JavaScript אפליקציות ל-Android |
מזהה לקוח ב-OAuth | פרטי כניסה לאפליקציה | מזהה באופן ייחודי את האפליקציה במהלך תהליך OAuth. |
| טוקן גישה וטוקן רענון | פרטי הכניסה של המשתמש | ההרשאה של המשתמש לאפשר לאפליקציה לגשת לחשבון Google Ads שלו בשמו. | |
|
אפליקציות אינטרנט בצד השרת אפליקציות למחשב ולאייפון אפליקציות לטלוויזיה ולמכשירים |
מזהה לקוח וסוד לקוח ב-OAuth | פרטי כניסה לאפליקציה | מזהה באופן ייחודי את האפליקציה במהלך תהליך OAuth. |
| טוקן גישה וטוקן רענון | פרטי הכניסה של המשתמש | ההרשאה של המשתמש לאפשר לאפליקציה לגשת לחשבון Google Ads שלו בשמו. | |
| חשבונות שירות | מפתח של חשבון שירות OAuth | פרטי כניסה לאפליקציה | משמש לחתימה על בקשת OAuth. |
| טוקן הגישה של חשבון השירות | פרטי הכניסה של המשתמש | מייצג את ההרשאה של חשבון השירות כשמשתמש משתף את חשבון Google Ads שלו עם חשבון השירות. |
יש כמה נקודות שכדאי להביא בחשבון כשמנהלים את פרטי הכניסה לאפליקציית Google Ads API.
טיפול מאובטח בפרטי הכניסה לאפליקציות
פרטי הכניסה של האפליקציה הם הגדרות שספציפיות לאפליקציה שלכם ולא משתנות ממשתמש למשתמש. חשוב לשמור על פרטי הכניסה של אפליקציית ה-OAuth שלכם בקפידה רבה, כי הם מאפשרים לכל מי שיש לו אותם להשתמש בזהות של האפליקציה כדי לקבל גישה למידע על המשתמשים. חשוב לאחסן את פרטי הכניסה של אפליקציית OAuth במקום מאובטח ולהגן עליהם, בדיוק כמו שמגנים על סיסמה. במקרים שבהם אפשר, מומלץ להשתמש בכלי לניהול סודות, כמו Google Cloud Secret Manager, כדי לאחסן את פרטי הכניסה של האפליקציה. אסור לשמור פרטי כניסה של לקוח במאגרי קוד שזמינים לציבור. מומלץ מאוד להימנע מהעלאה שלהם למאגר המקורות של הקוד כלשהו.
טיפול מאובטח בפרטי הכניסה של המשתמשים
פרטי כניסה של משתמשים הם אסימוני OAuth שמייצגים את ההרשאה של המשתמש. המשתמשים נותנים לכם הרשאה לפעול ולגשת לנתונים בשמם – באופן ישיר על ידי אימות האפליקציה שלכם, או באופן עקיף על ידי שיתוף חשבון Google Ads שלהם עם חשבון השירות שלכם. אסור להעביר טוקנים בטקסט לא מוצפן, ותמיד צריך לאחסן טוקנים מוצפנים במצב מנוחה כדי לספק שכבת הגנה נוספת במקרה של פרצה באבטחת מידע. צריך לבטל את האסימונים או את ההרשאות של חשבון השירות כשכבר לא צריך גישה לחשבון של משתמש. אחרי ביטול האסימונים, צריך למחוק אותם באופן סופי מהאפליקציה או מהמערכת.
טיפול בביטול ובתפוגה של אסימון רענון
אם אתם משתמשים בתהליך אימות משתמש, חשוב לזכור שאפשר לבטל את התוקף של טוקנים לרענון בכל שלב. לדוגמה, אם אתם משתמשים בתהליך אימות למשתמשים מרובים, המשתמש יכול לבטל את הגישה לאפליקציה שלכם. אמנם הסיכוי שאפליקציה שמשתמשת בתהליך אימות חד-משתמשי תושפע מכך נמוך יותר, אבל תהליך ידני או אוטומטי שנועד להגן על משתמשים עדיין יכול למחוק את טוקן הרענון, או שטוקן הרענון יכול לפוג. אם האפליקציה שלכם דורשת הודעה על ביטול אסימון כדי לספק חוויה טובה למשתמשים, אתם צריכים לבצע שילוב עם שירות ההגנה על כל החשבונות.
שימוש חוזר בפרטי הכניסה של המשתמשים בבקשות ה-API
התוקף של טוקנים של גישה מסוג OAuth הוא קצר והם פוקעים אחרי שעה. אם אתם משתמשים בספריית לקוח של Google Ads API, הספרייה מטפלת בתפוגה של אסימוני הגישה ומרעננת אותם באופן בטוח לשימוש בשרשור. יוצרים אובייקט לקוח של Google Ads API עם פרטי הכניסה המתאימים ב-OAuth, ומשתמשים בו שוב ושוב במהלך חייו.
אם אתם בונים אסטרטגיה משלכם לרענון ולניהול אסימוני גישה, עליכם לעקוב אחרי תפוגת התוקף של אסימוני הגישה ולעשות שימוש חוזר באסימונים כל עוד הם בתוקף. כשמבקשים רענון של טוקן, שרת ההרשאות מחזיר טוקן גישה חדש יחד עם משך החיים שנותר בשניות (expires_in). מומלץ לרענן את טוקן הגישה באופן יזום אם נותרו פחות מ-5 דקות עד לתפוגה.