ניהול פרטי כניסה

בטבלה הבאה מפורטים פרטי הכניסה שהאפליקציה צריכה לנהל. למידע נוסף על סוגי אפליקציות, קראו את המסמכים של Google Identity בנושא OAuth 2.0.

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

אם אתם יוצרים אסטרטגיה משלכם לרענון ולניהול של אסימוני גישה, אתם צריכים לעקוב אחרי תפוגת התוקף של אסימוני הגישה ולהשתמש שוב באסימונים כל עוד הם בתוקף. כשמבקשים רענון של טוקן, שרת ההרשאה מחזיר טוקן גישה חדש יחד עם משך החיים שנותר בשניות (expires_in). מומלץ לרענן באופן יזום את טוקן הגישה אם נותרו פחות מ-5 דקות לפני שתוקף הטוקן יפוג.