בטבלה הבאה מפורטים סוגי האישורים שאפליקציה צריכה לנהל. מידע נוסף על סוגי אפליקציות זמין בתיעוד של OAuth 2.0 של Google Identity.
| תהליך העבודה של האימות | פרטי כניסה | סוג פרטי הכניסה | מטרה |
|---|---|---|---|
|
אפליקציות אינטרנט ב-JavaScript אפליקציות ל-Android |
מזהה לקוח ב-OAuth | פרטי כניסה לאפליקציה | מזהה באופן ייחודי את האפליקציה במהלך תהליך OAuth. |
| טוקן גישה וטוקן רענון | פרטי הכניסה של המשתמש | מייצג את ההרשאה של המשתמש לאפשר לאפליקציה לגשת לחשבון Google Ads שלו בשמו. | |
|
אפליקציות אינטרנט בצד השרת אפליקציות למחשב ול-iOS אפליקציות לטלוויזיה ולמכשירים אחרים |
מזהה לקוח וסוד לקוח ב-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 דקות עד לתפוגה.