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

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

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

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 לפרויקט:

Open the API Library ב- Google API Console.
If prompted, select a project, or create a new one.
בדף Library אתם יכולים למצוא ולהפעיל את YouTube Data API. מאתרים את ממשקי ה-API האחרים שהאפליקציה שלכם משתמשת בהם ומפעילים גם אותם.

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

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

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

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

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

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

ממשק YouTube Data API v3 משתמש בהיקפים הבאים:

טווחים
https://www.googleapis.com/auth/youtube	ניהול חשבון YouTube שלך
https://www.googleapis.com/auth/youtube.channel-memberships.creator	הצגת רשימה מעודכנת של החברים הפעילים במועדון החברים של הערוץ, הרמה הנוכחית שלהם והתאריך שבו הם הצטרפו למועדון
https://www.googleapis.com/auth/youtube.force-ssl	הצגה, עריכה ומחיקה לצמיתות של סרטונים, דירוגים, תגובות וכתוביות ב-YouTube
https://www.googleapis.com/auth/youtube.readonly	הצגת חשבון YouTube שלך
https://www.googleapis.com/auth/youtube.upload	ניהול הסרטונים שלך ב-YouTube
https://www.googleapis.com/auth/youtubepartner	הצגה וניהול של הנכסים והתכנים הקשורים שלך ב-YouTube
https://www.googleapis.com/auth/youtubepartner-channel-audit	הצגת מידע פרטי של ערוץ YouTube שלך הרלוונטי בתהליך הביקורת של שותף YouTube.

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

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

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

ממשק YouTube Data API v3 משתמש בהיקפים הבאים:

טווחים
https://www.googleapis.com/auth/youtube	ניהול חשבון YouTube שלך
https://www.googleapis.com/auth/youtube.channel-memberships.creator	הצגת רשימה מעודכנת של החברים הפעילים במועדון החברים של הערוץ, הרמה הנוכחית שלהם והתאריך שבו הם הצטרפו למועדון
https://www.googleapis.com/auth/youtube.force-ssl	הצגה, עריכה ומחיקה לצמיתות של סרטונים, דירוגים, תגובות וכתוביות ב-YouTube
https://www.googleapis.com/auth/youtube.readonly	הצגת חשבון YouTube שלך
https://www.googleapis.com/auth/youtube.upload	ניהול הסרטונים שלך ב-YouTube
https://www.googleapis.com/auth/youtubepartner	הצגה וניהול של הנכסים והתכנים הקשורים שלך ב-YouTube
https://www.googleapis.com/auth/youtubepartner-channel-audit	הצגת מידע פרטי של ערוץ YouTube שלך הרלוונטי בתהליך הביקורת של שותף YouTube.

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

דוגמאות

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

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

client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl

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

curl -d "client_id=client_id&scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.force-ssl" \
     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://) מכתובת האתר מטעמי תצוגה, צריך לוודא שהאפליקציה יכולה לטפל גם וריאציות של 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, ואם עדיין לא התחברת, התחברות ל-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 (לדוגמה, שליחת קריאה ל-YouTube Live Streaming API).

שימו לב ש-YouTube Live Streaming API לא תומך בזרימה של חשבון השירות. מאז אין דרך לקשר חשבון שירות לחשבון YouTube, מנסה לאשר בקשות באמצעות חשבון זה התהליך הזה יפיק את השגיאה NoLinkedYouTubeAccount.

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

דוגמאות ל-HTTP GET

קריאה ל liveBroadcasts.list נקודת קצה (API של YouTube סטרימינג בשידור חי) באמצעות ה-HTTP Authorization: Bearer עשויה להיראות כך. שימו לב שתצטרכו לציין אסימון גישה משלכם:

GET /youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

`curl` דוגמאות

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/liveBroadcasts?part=id%2Csnippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/liveBroadcasts?access_token=access_token&part=id%2Csnippet&mine=true

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

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

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

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

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` דוגמאות