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