דף זה תורגם על ידי Cloud Translation API.

OAuth 2.0 לאפליקציות טלוויזיה ולקלט קלט מוגבל

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

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

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

חלופות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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=

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

curl -d "client_id=client_id&scope=" \
     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.

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

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

אזהרה: שני הערכים האלה עשויים להשתנות, ואסור לבצע קידוד קשיח של אף ערך בקוד. כמו כן, אין לשנות את הערכים בכל צורה אחרת, מלבד הסרה של הסכימה מ-verification_url.

שלב 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, ואם הוא לא מחובר עדיין לחשבון, הוא יראה מסך הסכמה כמו זה שמוצג בהמשך:

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

שרת ההרשאות של Google מגיב לכל בקשת סקר באחת מהתשובות הבאות:

הגישה הותרה

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

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

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

הגישה נדחתה

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

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

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

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

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

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

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

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

שגיאות אחרות

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

שגיאה	קוד סטטוס HTTP	תיאור
`admin_policy_enforced`	`400`	לחשבון Google אין הרשאה להעניק הרשאה להיקף הרשאות אחד לפחות, עקב המדיניות של האדמין ב-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

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

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

דוגמאות ל-HTTP GET

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

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 קשורה. אפשר לרענן אסימון גישה בלי לבקש הרשאה מהמשתמשים (כולל כשהמשתמש לא נוכח) אם ביקשת גישה אופליין להיקפי ההרשאות המשויכים לאסימון.

כדי לרענן אסימון גישה, האפליקציה שולחת בקשת 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"
}

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

ביטול אסימון

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

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

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

OAuth 2.0 לאפליקציות טלוויזיה ולקלט קלט מוגבל

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

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

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

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

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

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

דוגמאות

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

תשובה מוצלחת

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

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

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

דוגמאות

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

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

הגישה הותרה

הגישה נדחתה

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

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

שגיאות אחרות

קריאה ל-Google APIs

דוגמאות ל-HTTP GET

curl דוגמאות

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

ביטול אסימון

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

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

Drive API

ממשק API של YouTube

`curl` דוגמאות