OAuth 2.0 לאפליקציות במכשירי טלוויזיה ומכשירים עם יכולות קלט מוגבלות

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

OAuth 2.0 מאפשר למשתמשים לשתף נתונים ספציפיים עם אפליקציה, תוך שמירה על שמות משתמש, סיסמאות ומידע אחר באופן פרטי. לדוגמה, אפליקציה בטלוויזיה יכולה להשתמש ב-OAuth 2.0 כדי לקבל הרשאה לבחור קובץ המאוחסן ב-Google Drive.

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

חלופות

אם אתם כותבים אפליקציה לפלטפורמה כמו Android, iOS, macOS, Linux או Windows (כולל Universal Windows Platform), שיש לה גישה לדפדפן ולקלט מלא יכולות, השתמשו בתהליך OAuth 2.0 לניידים ואפליקציות בשולחן העבודה. (עליך להשתמש בתהליך זה גם אם האפליקציה שלך היא שורת פקודה ללא ממשק גרפי).

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

דרישות מוקדמות

הפעלת ממשקי API לפרויקט

כל אפליקציה שקוראת ל-Google APIs צריכה להפעיל את ממשקי ה-API האלה API Console

כדי להפעיל API לפרויקט:

  1. Open the API Library ב- Google API Console.
  2. If prompted, select a project, or create a new one.
  3. API Library מציגים את כל ממשקי ה-API הזמינים, מקובצים לפי מוצר המשפחה והפופולריות. אם ממשק ה-API שאתם רוצים להפעיל לא מופיע ברשימה, צריך להשתמש בחיפוש כדי למצוא אותו, או ללחוץ על הצגת הכול במשפחת המוצרים שאליה הוא שייך.
  4. בוחרים את ה-API שרוצים להפעיל ולוחצים על הלחצן הפעלה.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

יצירת פרטי כניסה להרשאה

לכל אפליקציה שמשתמשת ב-OAuth 2.0 כדי לגשת ל-Google APIs חייבים להיות פרטי כניסה להרשאה שמשמש לזיהוי האפליקציה בשרת OAuth 2.0 של Google. בשלבים הבאים נסביר איך יוצרים פרטי כניסה לפרויקט. לאחר מכן האפליקציות שלך יכולות להשתמש בפרטי הכניסה כדי לגשת לממשקי API שהפעלתם עבור הפרויקט הזה.

  1. Go to the Credentials page.
  2. לוחצים על Create credentials > מזהה הלקוח ב-OAuth.
  3. בוחרים בסוג האפליקציה טלוויזיות ומכשירי קלט מוגבלים.
  4. נותנים שם ללקוח OAuth 2.0 ולוחצים על יצירה.

זיהוי של היקפי גישה

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

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

לרשימת היקפי ההרשאות המותרים של אפליקציות או מכשירים מותקנים.

קבלת אסימוני גישה מסוג OAuth 2.0

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

  1. האפליקציה שולחת בקשה לשרת ההרשאות של Google שמזהה את היקפי ההרשאות שהאפליקציה שלכם תבקש הרשאת גישה אליה.
  2. השרת מגיב עם כמה פרטי מידע שנעשה בהם שימוש בשלבים הבאים, כמו קוד המכשיר וקוד המשתמש,
  3. אתם מציגים מידע שהמשתמש יכול להזין במכשיר נפרד כדי לתת הרשאה אפליקציה.
  4. האפליקציה מתחילה לדגום את שרת ההרשאות של Google כדי לקבוע אם המשתמש אישר/ה את האפליקציה שלך.
  5. המשתמש עובר למכשיר שיש בו יכולות קלט עשירות יותר, מפעיל דפדפן אינטרנט, עובר לכתובת ה-URL שמופיעה בשלב 3 ומזין קוד שמוצג גם בשלב 3. לאחר מכן, המשתמש יוכל להעניק (או לדחות) גישה לאפליקציה.
  6. התשובה הבאה לבקשת הסקר תכלול את האסימונים שהאפליקציה צריכה לאשר בקשות בשם המשתמש. (אם המשתמש סירב לגישה לאפליקציה, התגובה לא מכיל אסימונים.)

התמונה הבאה ממחישה את התהליך הזה:

המשתמש מתחבר במכשיר נפרד שמכיל דפדפן

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

שלב 1: מבקשים קודים של מכשירים ומשתמשים

בשלב הזה, המכשיר שולח בקשת HTTP POST לשרת ההרשאות של Google, בכתובת https://oauth2.googleapis.com/device/code, שמזהה את האפליקציה שלך וגם את היקפי הגישה שהאפליקציה שלכם רוצה לגשת אליהם בשם המשתמש. צריך לאחזר את כתובת ה-URL הזו מסמך Discovery באמצעות ערך של מטא-נתונים device_authorization_endpoint. צריך לכלול את בקשת ה-HTTP הבאה :

פרמטרים
client_id חובה

מזהה הלקוח של האפליקציה. אפשר למצוא את הערך הזה API Console Credentials page.
scope חובה

א' קובץ מופרד ברווחים רשימת היקפים שמזהים את המשאבים שהאפליקציה יכולה לגשת אליהם בשם המשתמש. הערכים האלה קובעים את מסך ההסכמה ש-Google מציגה משתמש. לצפייה רשימת היקפי הרשאות מותרים לאפליקציות או למכשירים מותקנים.

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

דוגמאות

קטע הקוד הבא מציג בקשה לדוגמה:

POST /device/code HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&scope=email%20profile

בדוגמה הזו מוצגת פקודת curl לשליחת אותה בקשה:

curl -d "client_id=client_id&scope=email%20profile" \
     https://oauth2.googleapis.com/device/code

שלב 2: טיפול בתגובה של שרת ההרשאות

שרת ההרשאות יחזיר אחת מהתגובות הבאות:

תגובה מוצלחת

אם הבקשה תקינה, התגובה תהיה אובייקט JSON שמכיל את הפרטים הבאים נכסים:

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

הקוד הזה מאפשר למכשיר שמפעיל את האפליקציה באופן מאובטח אם המשתמש העניק או דחיית הגישה.
expires_in משך הזמן, בשניות, שהdevice_code הערכים user_code תקינים. אם בפרק הזמן הזה המשתמש לא ישלים את תהליך ההרשאה והמכשיר שלך לא עורך גם סקר כדי לאחזר מידע על בהחלטה של המשתמש, יכול להיות שתצטרכו להתחיל מחדש את התהליך הזה משלב 1.
interval משך הזמן (בשניות) שהמכשיר צריך להמתין בין הבקשות לסקרים. עבור לדוגמה, אם הערך הוא 5, המכשיר צריך לשלוח בקשת סקרים אל שרת האימות של Google מדי חמש שניות. צפייה שלב 3 לקבלת פרטים נוספים.
user_code ערך תלוי אותיות רישיות שמזהה ל-Google את היקפי ההרשאות שהאפליקציה נשלחה בקשת גישה אל. ממשק המשתמש שלך ינחה את המשתמש להזין את הערך הזה למכשיר נפרד עם יכולות קלט עשירות יותר. Google משתמשת בערך כדי להציג את הקבוצה הנכונה של היקפים כאשר מבקשים מהמשתמש להעניק גישה לאפליקציה.
verification_url כתובת URL שהמשתמש צריך לעבור אליה, במכשיר נפרד, כדי להזין את user_code ולהעניק גישה לאפליקציה שלך או לדחות אותה. ממשק המשתמש יציג גם את הערך הזה.

בקטע הקוד הבא מוצגת תגובה לדוגמה:

{
  "device_code": "4/4-GMMhmHCXhWEzkobqIHGG_EnNYYsAkukHspeYUk9E8",
  "user_code": "GQVQ-JKEC",
  "verification_url": "https://www.google.com/device",
  "expires_in": 1800,
  "interval": 5
}

תגובה לחריגה מהמכסה

אם בקשות הקוד של המכשיר חרגו מהמכסה המשויכת למזהה הלקוח שלכם, לקבל תגובת 403, עם השגיאה הבאה:

{
  "error_code": "rate_limit_exceeded"
}

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

שלב 3: הצגת קוד המשתמש

מציגים את ה-verification_url וה-user_code שהתקבלו בשלב 2 עם משתמש. שני הערכים יכולים להכיל כל תו שניתן להדפסה מתוך מערכת התווים US-ASCII. התוכן שאתה מציג למשתמש צריך להורות למשתמש לנווט verification_url במכשיר נפרד ומזינים את user_code.

חשוב להביא בחשבון את הכללים הבאים כשמתכננים את ממשק המשתמש:

  • user_code
    • יש להציג את user_code בשדה שיכול להכיל 15 'W' מידה תווים. כלומר, אם אתם יכולים להציג את הקוד WWWWWWWWWWWWWWW בצורה נכונה, ממשק המשתמש שלכם תקין, ואנחנו ממליצים להשתמש בערך המחרוזת הזה כשבודקים את הדרך user_code יוצג בממשק המשתמש.
    • השדה user_code הוא תלוי אותיות רישיות ואין לשנות אותו בשום צורה, כמו כמו שינוי גודל האותיות או הוספת תווי עיצוב אחרים.
  • verification_url
    • המרחב שבו מוצגים verification_url צריך להיות רחב מספיק כדי היא צריכה לכלול מחרוזת של כתובת URL באורך של 40 תווים.
    • אין לשנות את verification_url בכל דרך שהיא, מלבד להסיר את סכמת התצוגה. אם אתם מתכוונים להסיר את הסכמה (למשל, https://) מכתובת ה-URL מטעמי תצוגה, צריך לוודא שהאפליקציה יכולה לטפל גם וריאציות של http וגם https.

שלב 4: סקרו את שרת ההרשאות של Google

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

המכשיר ששולח את הבקשה אמור להמשיך לשלוח בקשות לסקרים עד שהוא יקבל תגובה. מציינת שהמשתמש הגיב לבקשת הגישה או עד device_code ו-user_code התקבלו ב- שלב 2 כבר לא בתוקף. הערך interval שהוחזר בשלב 2 מציין את הכמות בשניות, שצריך להמתין בין הבקשות.

כתובת ה-URL של נקודת הקצה של הסקר היא https://oauth2.googleapis.com/token. בקשת ההצבעה מכילה את הפרמטרים הבאים:

פרמטרים
client_id מזהה הלקוח של האפליקציה. אפשר למצוא את הערך הזה API Console Credentials page.
client_secret סוד הלקוח של client_id שסיפקתם. אפשר למצוא את הערך הזה API Console Credentials page.
device_code השדה device_code שהוחזר על ידי שרת ההרשאות במדינות הבאות: שלב 2.
grant_type צריך להגדיר את הערך הזה כ-urn:ietf:params:oauth:grant-type:device_code.

דוגמאות

קטע הקוד הבא מציג בקשה לדוגמה:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=client_id&
client_secret=client_secret&
device_code=device_code&
grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code

בדוגמה הזו מוצגת פקודת curl לשליחת אותה בקשה:

curl -d "client_id=client_id&client_secret=client_secret& \
         device_code=device_code& \
         grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Adevice_code" \
         -H "Content-Type: application/x-www-form-urlencoded" \
         https://oauth2.googleapis.com/token

שלב 5: המשתמש מגיב לבקשת גישה

בתמונה הבאה מוצג דף שדומה לדף שהמשתמשים רואים כשהם עוברים אל verification_url שהוצג בשלב 3:

חיבור מכשיר באמצעות הזנת קוד

לאחר הזנת user_code, ואם עדיין לא התחברת, התחברות ל-Google, המשתמש רואה מסך הסכמה כמו זה שמוצג בהמשך:

דוגמה למסך הסכמה ללקוח במכשיר

שלב 6: טיפול בתשובות לבקשות לסקרים

שרת האימות של Google מגיב לכל בקשת דגימה באמצעות אחד מהפרטים הבאים תגובות:

קיבלת גישה

אם המשתמש העניק גישה למכשיר (בלחיצה על Allow במסך ההסכמה), התגובה תכיל אסימון גישה ואסימון רענון. האסימונים מאפשרים למכשיר שלך לגשת ל-Google APIs בשם המשתמש. (scope בנכס בתגובה קובע אילו ממשקי API שהמכשיר יכול לגשת אליו.)

במקרה כזה, תגובת ה-API תכיל את השדות הבאים:

שדות
access_token האסימון שהאפליקציה שלכם שולחת כדי לאשר בקשת Google API.
expires_in משך החיים שנותר לאסימון הגישה, בשניות.
refresh_token אסימון שאפשר להשתמש בו כדי לקבל אסימון גישה חדש. אסימוני הרענון תקפים עד המשתמש מבטל את הגישה. חשוב לזכור שאסימוני רענון תמיד מוחזרים למכשירים.
scope היקפי הגישה שהוענקה על ידי access_token, מוצגים כרשימה של מחרוזות תלויות-רישיות, שמופרדות ברווחים.
token_type סוג האסימון המוחזר. בשלב הזה, הערך בשדה הזה תמיד מוגדר כ- Bearer

בקטע הקוד הבא מוצגת תגובה לדוגמה:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
  "token_type": "Bearer",
  "refresh_token": "1/xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

הגישה נדחתה

אם המשתמש מסרב להעניק גישה למכשיר, לתגובת השרת קוד הסטטוס של תשובת HTTP 403 (Forbidden). התשובה תכיל את השגיאה הבאה:

{
  "error": "access_denied",
  "error_description": "Forbidden"
}

בהמתנה להרשאה

אם המשתמש עדיין לא השלים את תהליך ההרשאה, השרת מחזיר קוד הסטטוס של תשובת HTTP 428 (Precondition Required). התגובה מכיל את השגיאה הבאה:

{
  "error": "authorization_pending",
  "error_description": "Precondition Required"
}

עריכת סקרים בתדירות גבוהה מדי

אם המכשיר שולח בקשות לסקרים בתדירות גבוהה מדי, השרת יחזיר 403 קוד הסטטוס של תשובת HTTP (Forbidden). התשובה תכיל את הפרטים הבאים: שגיאה:

{
  "error": "slow_down",
  "error_description": "Forbidden"
}

שגיאות אחרות

שרת ההרשאות מחזיר גם שגיאות אם בקשת הדגימה חסרה או שכולל ערך פרמטר שגוי. בדרך כלל, הבקשות האלה כוללות 400 (Bad Request) או 401 (Unauthorized) סטטוס של תגובת HTTP דוגמאות לשגיאות כאלה:

שגיאה קוד מצב HTTP תיאור
admin_policy_enforced 400 חשבון Google לא יכול לתת הרשאה להיקף בקשה אחד או יותר, עקב כללי המדיניות של האדמין ב-Google Workspace. לעזרה לאדמינים ב-Google Workspace לקבוע אילו סוגי צד שלישי אפליקציות פנימיות ניגשות לנתונים של Google Workspace כדי לקבל מידע נוסף על האופן שבו האדמין יכול להגביל את הגישה להיקפים עד שתוענק גישה מפורשת ל-OAuth מזהה לקוח.
invalid_client 401

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

הסוג של לקוח OAuth שגוי. עליך לוודא שהאלמנטים סוג האפליקציה עבור מזהה הלקוח מוגדר לטלוויזיות ומכשירי קלט מוגבלים.
invalid_grant 400 ערך הפרמטר code לא חוקי, כבר נתבעה עליו בעלות או שאי אפשר לממש אותו מנותחים.
unsupported_grant_type 400 ערך הפרמטר grant_type לא תקין.
org_internal 403 מזהה הלקוח ב-OAuth שצוין בבקשה הוא חלק מפרויקט שמגביל את הגישה לחשבונות Google באופן ספציפי ארגון ב-Google Cloud. מאשרים את סוג המשתמש ההגדרות האישיות של אפליקציית OAuth.

קריאה ל-Google APIs

לאחר שהאפליקציה שלך מקבלת אסימון גישה, אפשר להשתמש באסימון כדי לבצע קריאות API בשם נתון חשבון משתמש, אם היקפי הגישה הנדרשים על ידי ה-API הוענקו. כדי לעשות את זה, צריך לכלול אסימון הגישה בבקשה ל-API על ידי הכללת שאילתת access_token או ערך Bearer של כותרת HTTP בAuthorization. כשהדבר אפשרי, עדיף להשתמש בכותרת HTTP, כי מחרוזות השאילתה בדרך כלל גלויות ביומני השרת. במרבית במקרים מסוימים תוכלו להשתמש בספריית לקוח כדי להגדיר את הקריאות ל-Google APIs (לדוגמה, שליחת קריאה ל-Drive Files API).

אפשר לנסות את כל ממשקי ה-API של Google ולצפות בהיקף שלהם בקישור OAuth 2.0 Playground

דוגמאות ל-HTTP GET

קריאה ל drive.files נקודת הקצה (Drive Files API) באמצעות Authorization: Bearer HTTP עשויה להיראות כך. שימו לב שתצטרכו לציין אסימון גישה משלכם:

GET /drive/v2/files HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

זוהי קריאה לאותו API בשביל המשתמש המאומת באמצעות access_token פרמטר של מחרוזת שאילתה:

GET https://www.googleapis.com/drive/v2/files?access_token=access_token

curl דוגמאות

אפשר לבדוק את הפקודות האלה באמצעות אפליקציית שורת הפקודה curl. הנה דוגמה שמשתמשת באפשרות של כותרת HTTP (מועדף):

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

לחלופין, אפשרות הפרמטר של מחרוזת השאילתה:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

רענון של אסימון גישה

התוקף של אסימוני הגישה פג מדי פעם והם הופכים לפרטי כניסה לא חוקיים לבקשת API קשורה. שלך יכול לרענן אסימון גישה בלי לבקש הרשאה מהמשתמש (גם כשהמשתמש לא קיים) אם ביקשת גישה אופליין להיקפי ההרשאות שמשויכים לאסימון.

כדי לרענן אסימון גישה, האפליקציה שולחת כתובת URL מסוג HTTPS מסוג POST לשרת האימות של Google (https://oauth2.googleapis.com/token) כוללת את הפרמטרים הבאים:

שדות
client_id מזהה הלקוח שהתקבל מ- API Console.
client_secret סוד הלקוח שהתקבל מ- API Console.
grant_type בתור מוגדר ב- מפרט OAuth 2.0, הערך בשדה הזה צריך להיות refresh_token.
refresh_token אסימון הרענון שהוחזר מהמרת קוד ההרשאה.

קטע הקוד הבא מציג בקשה לדוגמה:

POST /token HTTP/1.1
Host: oauth2.googleapis.com
Content-Type: application/x-www-form-urlencoded

client_id=your_client_id&
client_secret=your_client_secret&
refresh_token=refresh_token&
grant_type=refresh_token

שרת האסימון לא ביטל את הגישה שהוענקה לאפליקציה כל עוד המשתמש לא ביטל את הגישה מחזירה אובייקט JSON שמכיל אסימון גישה חדש. בקטע הקוד הבא מוצגת דוגמה תגובה:

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly",
  "token_type": "Bearer"
}

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

ביטול אסימון

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

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

כדי לבטל אסימון באופן פרוגרמטי, האפליקציה שולחת בקשה ל- https://oauth2.googleapis.com/revoke והוא כולל את האסימון כפרמטר:

curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \
        https://oauth2.googleapis.com/revoke?token={token}

האסימון יכול להיות אסימון גישה או אסימון רענון. אם האסימון הוא אסימון גישה ויש לו אסימון הרענון התואם, גם אסימון הרענון יבוטל.

אם הביטול בוצע בהצלחה, קוד סטטוס ה-HTTP של התשובה 200 במקרים של שגיאות, מוחזר קוד מצב HTTP 400 עם קוד שגיאה.

היקפי הרשאות מותרים

תהליך OAuth 2.0 למכשירים נתמך רק בהיקפים הבאים:

OpenID Connect, כניסה באמצעות חשבון Google

  • email
  • openid
  • profile

Drive API

  • https://www.googleapis.com/auth/drive.appdata
  • https://www.googleapis.com/auth/drive.file

ממשק API של YouTube

  • https://www.googleapis.com/auth/youtube
  • https://www.googleapis.com/auth/youtube.readonly

יישום הגנה על כל החשבונות

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

אלה כמה דוגמאות לסוגי האירועים שנשלחים לאפליקציה שלכם על ידי שירות ההגנה על כל החשבונות של Google:

  • https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
  • https://schemas.openid.net/secevent/oauth/event-type/token-revoked
  • https://schemas.openid.net/secevent/risc/event-type/account-disabled

לצפייה הגנה על חשבונות משתמשים באמצעות הדף 'הגנה על כל החשבונות' כדי לקבל מידע נוסף על ההטמעה של הגנה על כל החשבונות ולרשימה המלאה של האירועים הזמינים.