אנחנו מעדכנים את Data API כך שיתאים לאופן שבו YouTube סופר צפיות ב-Shorts. מידע נוסף

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

OAuth 2.0 לאפליקציות לנייד ולמחשב

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

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

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

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

ספריות ודגימות

באפליקציות לנייד מומלץ להשתמש בגרסה העדכנית של הספרייה המקורית של Google Identity Services ל-Android ובספרייה המקורית של הכניסה באמצעות חשבון Google ל-iOS. הספריות האלה מטפלות בהרשאות משתמשים, והן פשוטות יותר ליישום מהפרוטוקול ברמה הנמוכה שמתואר כאן.

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

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

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

Android

בוחרים בסוג האפליקציה Android.
מזינים שם ללקוח ב-OAuth. השם הזה מוצג בפרויקט שלכם ב- כדי לזהות את הלקוח.
מזינים את שם החבילה של אפליקציית Android. הערך הזה מוגדר במאפיין package של האלמנט <manifest> בקובץ המניפסט של האפליקציה.
מזינים את טביעת האצבע של אישור החתימה SHA-1 של הפצת האפליקציה.
- אם האפליקציה שלכם משתמשת בחתימת אפליקציות ב-Google Play, מעתיקים את טביעת האצבע של SHA-1 מדף חתימת האפליקציות ב-Play Console.
- אם אתם מנהלים את חנות המפתחות ואת מפתחות החתימה שלכם, אתם יכולים להשתמש בכלי keytool שכלול ב-Java כדי להדפיס את פרטי האישור בפורמט שנוח לקריאה. מעתיקים את הערך SHA1 בקטע Certificate fingerprints של הפלט של keytool. מידע נוסף זמין בקטע אימות הלקוח במאמרי העזרה בנושא ממשקי Google API ל-Android.
(אופציונלי) אימות הבעלות על אפליקציית Android.
לוחצים על יצירה.

iOS

בוחרים את סוג האפליקציה iOS.
מזינים שם ללקוח ב-OAuth. השם הזה מוצג בפרויקט שלכם ב- כדי לזהות את הלקוח.
מזינים את מזהה החבילה של האפליקציה. מזהה החבילה הוא הערך של המפתח CFBundleIdentifier בקובץ המשאבים של רשימת מאפייני המידע של האפליקציה (info.plist). הערך הזה מוצג בדרך כלל בחלונית General או בחלונית Signing & Capabilities של עורך הפרויקטים ב-Xcode. מזהה החבילה מוצג גם בקטע General Information (מידע כללי) בדף App Information (פרטי אפליקציה) של האפליקציה באתר App Store Connect של אפל.
חשוב לוודא שאתם משתמשים במזהה החבילה הנכון של האפליקציה, כי לא תוכלו לשנות אותו אם אתם משתמשים בתכונה App Check.
(אופציונלי)
אם האפליקציה פורסמה ב-App Store של אפל, מזינים את מזהה האפליקציה ב-App Store. מזהה החנות הוא מחרוזת מספרית שמופיעה בכל כתובת URL של Apple App Store.
1. פותחים את אפליקציית Apple App Store במכשיר iOS או iPadOS.
2. מחפשים את האפליקציה.
3. לוחצים על לחצן השיתוף (סמל של ריבוע וחץ למעלה).
4. בוחרים באפשרות העתקת הקישור.
5. מדביקים את הקישור בכלי לעריכת טקסט. מזהה האפליקציה ב-App Store הוא החלק האחרון בכתובת ה-URL.
  לדוגמה: https://apps.apple.com/app/google/id284815942
(אופציונלי)
מזינים את מזהה הצוות. מידע נוסף זמין במאמר בנושא איתור מזהה הצוות במסמכי התיעוד של חשבון Apple למפתחים.
הערה: אם מפעילים את App Check עבור הלקוח, חובה למלא את השדה Team ID (מזהה הצוות).
(אופציונלי)
מפעילים את App Check באפליקציית iOS. כשמפעילים את App Check, נעשה שימוש בשירות App Attest של Apple כדי לוודא שבקשות OAuth 2.0 שמקורן בלקוח OAuth הן אמיתיות ומגיעות מהאפליקציה שלכם. כך אפשר להפחית את הסיכון להתחזות לאפליקציה. מידע נוסף על הפעלת App Check באפליקציית iOS
לוחצים על יצירה.

UWP

בוחרים בסוג האפליקציה Universal Windows Platform.
מזינים שם ללקוח ב-OAuth. השם הזה מוצג בפרויקט שלכם ב- כדי לזהות את הלקוח.
מזינים את מזהה האפליקציה בחנות Microsoft Store, שמורכב מ-12 תווים. אפשר למצוא את הערך הזה במרכז השותפים של מיקרוסופט בדף זהות האפליקציה בקטע 'ניהול אפליקציות'.
לוחצים על יצירה.

באפליקציות UWP, סכמת ה-URI המותאמת אישית לא יכולה להיות ארוכה מ-39 תווים.

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

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

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

ב-YouTube Data API גרסה 3 נעשה שימוש בהיקפי ההרשאות הבאים:

היקף	תיאור
`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 API מופיעה רשימה מלאה של היקפי הרשאות שאפשר להשתמש בהם כדי לגשת אל Google APIs.

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

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

שלב 1: יצירת מאמת קוד ואתגר

‫Google תומכת בפרוטוקול Proof Key for Code Exchange (מפתח הוכחה להחלפת קוד, PKCE) כדי להפוך את תהליך ההתקנה של האפליקציה למאובטח יותר. לכל בקשת הרשאה נוצר מאמת קוד ייחודי, והערך שלו אחרי השינוי, שנקרא code_challenge, נשלח לשרת ההרשאות כדי לקבל את קוד ההרשאה.

יצירת מאמת הקוד

code_verifier הוא מחרוזת אקראית מוצפנת עם אנטרופיה גבוהה, שכוללת את התווים הלא שמורים [A-Z] / [a-z] / [0-9] / "-" / "." / "_" / "~", עם אורך מינימלי של 43 תווים ואורך מקסימלי של 128 תווים.

למאמת הקוד צריך להיות מספיק אנטרופיה כדי שיהיה לא מעשי לנחש את הערך.

יצירת אתגר קוד

יש שתי שיטות ליצירת אתגר קוד.

שיטות ליצירת אתגר קוד
‫S256 (מומלץ)	אתגר הקוד הוא גיבוב SHA256 של מאמת הקוד בקידוד Base64URL (ללא ריפוד). `code_challenge` = BASE64URL-ENCODE(SHA256(ASCII(`code_verifier`)))
plain	אתגר הקוד הוא אותו ערך כמו מאמת הקוד שנוצר למעלה. `code_challenge` = `code_verifier`

שלב 2: שליחת בקשה לשרת OAuth 2.0 של Google

כדי לקבל הרשאת משתמש, שולחים בקשה לשרת ההרשאות של Google בכתובת https://accounts.google.com/o/oauth2/v2/auth. נקודת הקצה הזו מטפלת בחיפוש של סשנים פעילים, מבצעת אימות של המשתמש ומקבלת את הסכמת המשתמש. אפשר לגשת לנקודת הקצה רק דרך SSL, והיא דוחה חיבורי HTTP (לא SSL).

שרת ההרשאות תומך בפרמטרים הבאים של מחרוזת השאילתה עבור אפליקציות מותקנות:

פרמטרים

client_id

חובה

מזהה הלקוח של האפליקציה. אפשר למצוא את הערך הזה ב .

redirect_uri

חובה

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

הערך חייב להיות זהה לאחד מכתובות ה-URI המורשות להפניה אוטומטית של לקוח OAuth 2.0, שהגדרתם ב- של הלקוח. אם הערך הזה לא תואם ל-URI מורשה, תקבלו שגיאת redirect_uri_mismatch.

בטבלה הבאה מוצג ערך הפרמטר redirect_uri המתאים לכל שיטה:

ערכים של redirect_uri

סכמת URI בהתאמה אישית

com.example.app:redirect_uri_path

או

com.googleusercontent.apps.123:redirect_uri_path

‫com.example.app הוא סימון ה-DNS ההפוך של דומיין שנמצא בשליטתכם. כדי שהסכימה המותאמת אישית תהיה תקינה, היא צריכה לכלול נקודה.
‫com.googleusercontent.apps.123 הוא סימון ה-DNS ההפוך של מזהה הלקוח.
‫redirect_uri_path הוא רכיב אופציונלי של הנתיב, כמו /oauth2redirect. שימו לב שהנתיב צריך להתחיל בקו נטוי יחיד, בניגוד לכתובות URL רגילות מסוג HTTP.

כתובת IP של Loopback

‫http://127.0.0.1:port או http://[::1]:port

מבצעים שאילתה בפלטפורמה כדי לאתר את כתובת ה-IP הרלוונטית של ה-loopback ומתחילים להאזין ל-HTTP ביציאה אקראית זמינה. מחליפים את port במספר היציאה בפועל שהאפליקציה מאזינה לו.

שימו לב שהתמיכה באפשרות ההפניה האוטומטית של כתובת ה-IP של ה-loopback באפליקציות לנייד הוצאה משימוש.

response_type

חובה

הפונקציה קובעת אם נקודת הקצה של Google OAuth 2.0 מחזירה קוד הרשאה.

מגדירים את ערך הפרמטר ל-code עבור אפליקציות מותקנות.

scope

חובה

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

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

ב-YouTube Data API גרסה 3 נעשה שימוש בהיקפי ההרשאות הבאים:

היקף	תיאור
`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 API מופיעה רשימה מלאה של היקפי הרשאות שאפשר להשתמש בהם כדי לגשת אל Google APIs.

code_challenge

מומלץ

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

code_challenge_method

מומלץ

מציין באיזו שיטה נעשה קידוד של code_verifier שישמש במהלך החלפת קוד ההרשאה. חובה להשתמש בפרמטר הזה עם הפרמטר code_challenge שמתואר למעלה. אם הערך של code_challenge_method לא מופיע בבקשה שכוללת code_challenge, ברירת המחדל היא plain. הערכים הנתמכים היחידים של הפרמטר הזה הם S256 או plain.

state

מומלץ

מציין ערך מחרוזת שהאפליקציה משתמשת בו כדי לשמור על מצב בין בקשת ההרשאה לבין התגובה של שרת ההרשאה. השרת מחזיר את הערך המדויק שאתם שולחים כצמד name=value במזהה של קטע כתובת ה-URL (#) של redirect_uri אחרי שהמשתמש מאשר או דוחה את בקשת הגישה של האפליקציה.

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

חשוב: לקוח OAuth חייב למנוע CSRF כפי שמצוין במפרט OAuth2 . אחת הדרכים לעשות זאת היא באמצעות הפרמטר state כדי לשמור על מצב בין בקשת ההרשאה לתגובה של שרת ההרשאה.

login_hint

אופציונלי

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

מגדירים את ערך הפרמטר לכתובת אימייל או למזהה sub, ששווה למזהה Google של המשתמש.

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

כתובות URL לדוגמה של הרשאות

בכרטיסיות שבהמשך מוצגות דוגמאות לכתובות URL של הרשאה לאפשרויות שונות של כתובות URI להפניה אוטומטית.

כל כתובת URL מבקשת גישה להיקף שמאפשר גישה לצפייה בחשבון YouTube של המשתמש.

כתובות ה-URL זהות, למעט הערך של הפרמטר redirect_uri. כתובות ה-URL כוללות גם את הפרמטרים הנדרשים response_type ו-client_id, וגם את הפרמטר האופציונלי state. כל כתובת URL מכילה מעברי שורה ורווחים כדי לשפר את הקריאות.

סכמת URI מותאמת אישית

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=com.example.app%3A/oauth2redirect&
 client_id=client_id

כתובת IP של Loopback

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
 response_type=code&
 state=security_token%3D138r5719ru3e1%26url%3Dhttps%3A%2F%2Foauth2.example.com%2Ftoken&
 redirect_uri=http%3A//127.0.0.1%3A9004&
 client_id=client_id

שלב 3: המשתמש מקבל בקשה להסכמה מ-Google

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

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

שגיאות

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

`admin_policy_enforced`

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

`disallowed_useragent`

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

Android

מפתחי Android עשויים להיתקל בהודעת השגיאה הזו כשהם פותחים בקשות הרשאה ב-android.webkit.WebView. במקום זאת, מפתחים צריכים להשתמש בספריות של Android כמו כניסה באמצעות חשבון Google ל-Android או AppAuth ל-Android של OpenID Foundation.

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

iOS

מפתחים של iOS ו-macOS עשויים להיתקל בשגיאה הזו כשהם פותחים בקשות הרשאה ב-WKWebView. במקום זאת, מפתחים צריכים להשתמש בספריות iOS כמו Google Sign-In for iOS או AppAuth for iOS של OpenID Foundation.

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

`org_internal`

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

`deleted_client`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

הפרמטר redirect_uri שמועבר בבקשת ההרשאה לא תואם לכתובת ה-URI המורשית להפניה אוטומטית עבור מזהה הלקוח של OAuth. בודקים את כתובות ה-URI המורשות להפניה אוטומטית ב- .

יכול להיות שהערך redirect_uri שהועבר לא תקין לסוג הלקוח.

הפרמטר redirect_uri עשוי להתייחס לתהליך OAuth out-of-band (OOB) שהוצא משימוש וכבר לא נתמך. כדי לעדכן את השילוב, אפשר לעיין במדריך להעברת נתונים.

`invalid_request`

משהו השתבש בבקשה ששלחת. יכולות להיות לכך כמה סיבות:

הפורמט של הבקשה לא תקין
בבקשה חסרים פרמטרים נדרשים
הבקשה משתמשת בשיטת הרשאה ש-Google לא תומכת בה. אימות ששילוב ה-OAuth משתמש בשיטת שילוב מומלצת
נעשה שימוש בסכימה מותאמת אישית עבור כתובת ה-URI של ההפניה האוטומטית : אם מופיעה הודעת השגיאה Custom URI scheme is not supported on Chrome apps או Custom URI scheme is not enabled for your Android client, המשמעות היא שאתם משתמשים בסכימת URI מותאמת אישית שלא נתמכת באפליקציות Chrome ומושבתת כברירת מחדל ב-Android. מידע נוסף על חלופות לסכימת URI מותאמת אישית

שלב 4: טיפול בתגובת השרת של OAuth 2.0

האופן שבו האפליקציה מקבלת את תגובת ההרשאה תלוי בסכימת ה-URI להפניה אוטומטית שבה היא משתמשת. לא משנה באיזו סכימה משתמשים, התשובה תכיל קוד הרשאה (code) או שגיאה (error). לדוגמה, error=access_denied מציין שהמשתמש דחה את הבקשה.

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

שלב 5: המרת קוד הרשאה לאסימוני רענון וגישה

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

שדות
`client_id`	מזהה הלקוח שהתקבל מ .
`client_secret`	סוד הלקוח שהתקבל מ- .
`code`	קוד ההרשאה שמוחזר מהבקשה הראשונית.
`code_verifier`	הקוד לאימות שיצרתם בשלב 1.
`grant_type`	כמו שמוגדר במפרט של OAuth 2.0, הערך של השדה הזה צריך להיות `authorization_code`.
`redirect_uri`	אחת מכתובות ה-URI להפניה אוטומטית שמופיעות בפרויקט ב- עבור `client_id` הנתון.

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

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

code=4/P7q7W91a-oMsCeLvIaQm6bTrgtp7&
client_id=your_client_id&
client_secret=your_client_secret&
redirect_uri=http://127.0.0.1:9004&
grant_type=authorization_code

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

התשובה מכילה את השדות הבאים:

שדות
`access_token`	האסימון שהאפליקציה שולחת כדי לאשר בקשת Google API.
`expires_in`	משך החיים שנותר של אסימון הגישה בשניות.
`id_token`	הערה: המאפיין הזה מוחזר רק אם הבקשה כוללת היקף זהות, כמו `openid`, `profile` או `email`. הערך הוא אסימון אינטרנט מסוג JSON ‏ (JWT) שמכיל מידע על זהות המשתמש בחתימה דיגיטלית.
`refresh_token`	טוקן שאפשר להשתמש בו כדי לקבל טוקן גישה חדש. תוקף הטוקנים לרענון הוא עד שהמשתמש מבטל את הגישה או עד שתוקף הטוקן לרענון פג. חשוב לזכור שאסימוני רענון תמיד מוחזרים עבור אפליקציות מותקנות.
`refresh_token_expires_in`	משך החיים שנותר לאסימון הרענון בשניות. הערך הזה מוגדר רק כשהמשתמש מעניק גישה מוגבלת בזמן.
`scope`	היקפי הגישה שניתנים על ידי `access_token` מוצגים כרשימה של מחרוזות שמופרדות ברווחים, והן תלויות רישיות.
`token_type`	סוג הטוקן שמוחזר. בשלב הזה, הערך של השדה הזה תמיד מוגדר ל-`Bearer`.

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

שלב 6: בדיקה של היקפי ההרשאות שהמשתמשים העניקו

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

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

מידע מפורט יותר זמין במאמר בנושא איך מטפלים בהרשאות גרנולריות.

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

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

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/youtube.force-ssl",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

קריאה לממשקי Google APIs

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

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

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

דוגמאות ל-HTTP GET

קריאה לנקודת הקצה youtube.channels (YouTube Data API) באמצעות כותרת ה-HTTP‏ Authorization: Bearer עשויה להיראות כך. שימו לב: צריך לציין טוקן גישה משלכם:

GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1
Host: www.googleapis.com
Authorization: Bearer access_token

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

GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

`curl` דוגמאות

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

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

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

curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true

רענון של טוקן גישה

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

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

שדות
`client_id`	מזהה הלקוח שהתקבל מ API Console.
`client_secret`	סוד הלקוח שהתקבל מ- API Console. (הערך `client_secret` לא רלוונטי לבקשות מלקוחות שרשומים כאפליקציות ל-Android, ל-iOS או ל-Chrome).
`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 יחד עם קוד שגיאה.

שיטות להפניה מחדש של אפליקציות

סכמת URI מותאמת אישית (Android, ‏ iOS, ‏ UWP)

סכימות URI בהתאמה אישית הן סוג של קישור עומק שמשתמש בסכימה מוגדרת בהתאמה אישית כדי לפתוח את האפליקציה.

חלופה לשימוש בסכימות URI בהתאמה אישית ב-Android

משתמשים בחלופה המומלצת שמעבירה את התגובה של OAuth 2.0 ישירות לאפליקציה, וכך לא צריך להשתמש ב-URI להפניה.

איך עוברים לספריית Android של Google Identity Services

אם אתם משתמשים בסכימה מותאמת אישית לשילוב OAuth ב-Android, תצטרכו לבצע את הפעולות הבאות כדי לעבור באופן מלא לשימוש בספריית Google Identity Services Android המומלצת:

מעדכנים את הקוד כך שישתמש בספריית Android של Google Identity Services.
משביתים את התמיכה בסכימה בהתאמה אישית במסוף Google Cloud.

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

בשלבים הבאים מוסבר איך לבצע מיגרציה לספריית Android של Google Identity Services:

מעדכנים את הקוד כך שישתמש בספריית Android של Google Identity Services:
1. בודקים את הקוד כדי לזהות את המקום שבו נשלחת בקשה לשרת OAuth 2.0 של Google. אם משתמשים בסכימה מותאמת אישית, הבקשה תיראה כך:
  ‫
```
  https://accounts.google.com/o/oauth2/v2/auth?
  scope=<SCOPES>&
  response_type=code&
  &state=<STATE>&
  redirect_uri=com.example.app:/oauth2redirect&
  client_id=<CLIENT_ID>
  
```
  ‫com.example.app:/oauth2redirect הוא ה-URI של ההפניה של הסכימה בהתאמה אישית בדוגמה שלמעלה. פרטים נוספים על הפורמט של הערך של סכימת ה-URI המותאמת אישית מופיעים בהגדרה של הפרמטר redirect_uri.
2. חשוב לשים לב לפרמטרים של הבקשה scope ו-client_id שצריך להגדיר ב-Google Sign-In SDK.
  הערה: אם אתם משתמשים בספרייה של צד שלישי, כדאי לעיין בקובץ ההגדרות של הספרייה כדי למצוא את הפרטים האלה.
3. כדי להגדיר את ה-SDK, צריך לפעול לפי ההוראות שבמאמר אישור גישה לנתוני משתמשים ב-Google אפשר לדלג על השלב הגדרת פרויקט במסוף Google Cloud כי נעשה שימוש חוזר ב-client_id שאוחזר בשלב הקודם.
4. פועלים לפי ההוראות שבקטע בקשת הרשאות שנדרשות לפעולות משתמש. התהליך כולל את השלבים הבאים:
  1. בקשת הרשאות מהמשתמש.
  2. משתמשים בשיטה getServerAuthCode כדי לאחזר קוד הרשאה להיקפי ההרשאות שאתם מבקשים.
  3. שולחים את קוד ההרשאה לשרת העורפי של האפליקציה כדי להחליף אותו באסימון גישה ורענון.
  4. משתמשים באסימון הגישה שאוחזר כדי לשלוח קריאות ל-Google APIs מטעם המשתמש.
  הערה: אם האפליקציה שלכם דורשת רק היקפי הרשאות לאימות, עליכם לפעול לפי ההוראות האלה במקום זאת כדי להשתמש בספריית Credential Manager המומלצת.
משביתים את התמיכה בסכימה מותאמת אישית ב-Google API Console:
1. עוברים לרשימה של פרטי כניסה של OAuth 2.0 ובוחרים את לקוח Android.
2. עוברים לקטע הגדרות מתקדמות, מבטלים את הסימון בתיבת הסימון הפעלת סכימת URI מותאמת אישית ולוחצים על שמירה כדי להשבית את התמיכה בסכימת URI מותאמת אישית.

הפעלת סכימת URI מותאמת אישית

אם החלופה המומלצת לא מתאימה לכם, אתם יכולים להפעיל סכימות URI מותאמות אישית ללקוח Android שלכם באמצעות ההוראות הבאות:

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

חלופה לשימוש בסכימות URI בהתאמה אישית באפליקציות Chrome

משתמשים ב-Chrome Identity API, שמספק את תגובת ה-OAuth 2.0 ישירות לאפליקציה, כך שלא צריך להשתמש בכתובת URI להפניה אוטומטית.

כתובת IP של Loopback (macOS, ‏ Linux, מחשב Windows)

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

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

שימוש מומלץ	אפליקציות ל-macOS, ל-Linux ול-Windows לשולחן העבודה (אבל לא Universal Windows Platform)
ערכי טופס	מגדירים את סוג האפליקציה בתור אפליקציה למחשב.

הערה: מידע נוסף על כתובת ה-IP של ה-loopback זמין בהגדרה של הפרמטר redirect_uri. אפשר גם להשתמש ב-localhost במקום בכתובת ה-IP של הלולאה החוזרת, אבל ההגדרה הזו עלולה לגרום לבעיות בחומות אש של לקוחות. רוב חומות האש מאפשרות תקשורת מסוג loopback, אבל לא כולן.

העתקה והדבקה ידניות (הוצא משימוש)

הגנה על האפליקציות

אימות הבעלות על האפליקציה (Android, ‏ Chrome)

אתם יכולים לאמת את הבעלות על האפליקציה כדי לצמצם את הסיכון להתחזות לאפליקציה.

Android

כדי להשלים את תהליך האימות, אפשר להשתמש בחשבון הפיתוח שלכם ב-Google Play אם יש לכם חשבון כזה והאפליקציה שלכם רשומה ב-Google Play Console. כדי שהאימות יתבצע בהצלחה, צריך לעמוד בדרישות הבאות:

צריכה להיות לכם אפליקציה רשומה ב-Google Play Console עם אותו שם חבילה וטביעת אצבע של אישור חתימה מסוג SHA-1 כמו לקוח Android OAuth שאתם משלימים את האימות שלו.
צריכה להיות לכם הרשאת אדמין לאפליקציה ב-Google Play Console. מידע נוסף על ניהול גישה ב-Google Play Console

בקטע Verify App Ownership (אימות בעלות על אפליקציה) בלקוח Android, לוחצים על הלחצן Verify Ownership (אימות בעלות) כדי להשלים את תהליך האימות.

אם האימות יצליח, תוצג הודעה לאישור ההצלחה של תהליך האימות. אחרת, תוצג הודעת שגיאה.

כדי לפתור בעיה באימות שנכשל, אפשר לנסות את הפעולות הבאות:

מוודאים שהאפליקציה שאתם מאמתים רשומה ב-Google Play Console.
מוודאים שיש לכם הרשאת אדמין לאפליקציה ב-Google Play Console.

Chrome

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

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

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

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

אם האימות יצליח, תוצג הודעה לאישור ההצלחה של תהליך האימות. אחרת, תוצג הודעת שגיאה.

כדי לפתור בעיה באימות שנכשל, אפשר לנסות את הפעולות הבאות:

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

בדיקת אפליקציות (iOS בלבד)

התכונה App Check עוזרת להגן על אפליקציות iOS מפני שימוש לא מורשה באמצעות שירות App Attest של Apple. השירות הזה מאמת שבקשות שנשלחות לנקודות הקצה של Google OAuth 2.0 מגיעות מהאפליקציות המקוריות שלכם. כך אפשר להפחית את הסיכון להתחזות לאפליקציה.

הפעלת App Check עבור לקוח iOS

כדי להפעיל בהצלחה את App Check בלקוח iOS, צריך לעמוד בדרישות הבאות:

צריך לציין מזהה צוות עבור לקוח iOS.
אסור להשתמש בתו כללי במזהה החבילה, כי הוא יכול להתייחס ליותר מאפליקציה אחת. כלומר, מזהה החבילה לא יכול לכלול את הסימן כוכבית (*).

כדי להפעיל את App Check, מעבירים את המתג Protect your OAuth client from abuse with Firebase App Check (הגנה על לקוח ה-OAuth מפני שימוש לרעה באמצעות Firebase App Check) בתצוגת העריכה של לקוח ה-iOS.

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

יכול להיות שיוצגו שגיאות שקשורות לתכונה App Check כשמפעילים את App Check באפליקציית iOS. כדי לתקן את השגיאות האלה, אפשר לנסות את הפעולות הבאות:

מוודאים שמזהה החבילה ומזהה הצוות שציינתם תקינים.
מוודאים שלא משתמשים בתו כללי לחיפוש במזהה החבילה.

אכיפת בדיקת אפליקציות בלקוח iOS

הפעלת App Check באפליקציה לא חוסמת אוטומטית בקשות לא מזוהות. כדי לאכוף את ההגנה הזו, צריך לעבור לתצוגת העריכה של לקוח iOS. בקטע Google Identity for iOS בצד שמאל של הדף, יופיעו מדדים של App Check. המדדים כוללים את הפרטים הבאים:

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

מומלץ לעיין במדדים האלה כדי להבין איך אכיפת השימוש ב-App Check תשפיע על המשתמשים.

כדי לאכוף את App Check, לוחצים על הלחצן ENFORCE (אכיפה) ומאשרים את הבחירה. אחרי שהאכיפה תופעל, כל הבקשות שלא אומתו מהלקוח שלכם יידחו.

הערה: אחרי שמפעילים את האכיפה, יכול להיות שיחלפו עד 15 דקות לפני שהשינויים ייכנסו לתוקף.

ביטול האכיפה של בדיקת האפליקציה בלקוח iOS

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

כדי לבטל את האכיפה של App Check בלקוח iOS, עוברים לתצוגת העריכה של לקוח iOS, לוחצים על הלחצן ביטול האכיפה ומאשרים את הבחירה.

הערה: אחרי שמבטלים את האכיפה של App Check, יכולות לחלוף עד 15 דקות עד שהשינויים ייכנסו לתוקף.

השבתת App Check עבור לקוח iOS

השבתת App Check באפליקציה תפסיק את כל המעקב והאכיפה של App Check. מומלץ לבטל את האכיפה של App Check כדי שתוכלו להמשיך לעקוב אחרי מדדים של הלקוח.

כדי להשבית את App Check בלקוח iOS, עוברים לתצוגת העריכה של לקוח iOS ומשביתים את לחצן ההפעלה/ההשבתה הגנה על לקוח OAuth מפני ניצול לרעה באמצעות Firebase App Check.

הערה: אחרי שמשביתים את App Check, יכולות לחלוף עד 15 דקות עד שהשינויים ייכנסו לתוקף.

גישה מבוססת-זמן

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

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

קריאה נוספת

השיטות המומלצות שמפורטות כאן מבוססות על השיטות המומלצות של IETF OAuth 2.0 for Native Apps.

הטמעה של ההגנה על כל החשבונות

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

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

Android

iOS

UWP

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

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

שלב 1: יצירת מאמת קוד ואתגר

יצירת מאמת הקוד

יצירת אתגר קוד

שלב 2: שליחת בקשה לשרת OAuth 2.0 של Google

כתובות URL לדוגמה של הרשאות

סכמת URI מותאמת אישית

כתובת IP של Loopback

שלב 3: המשתמש מקבל בקשה להסכמה מ-Google

שגיאות

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

deleted_client

invalid_grant

redirect_uri_mismatch

invalid_request

שלב 4: טיפול בתגובת השרת של OAuth 2.0

שלב 5: המרת קוד הרשאה לאסימוני רענון וגישה

שלב 6: בדיקה של היקפי ההרשאות שהמשתמשים העניקו

קריאה לממשקי Google APIs

דוגמאות ל-HTTP GET

curl דוגמאות

רענון של טוקן גישה

ביטול טוקן

שיטות להפניה מחדש של אפליקציות

סכמת URI מותאמת אישית (Android, ‏ iOS, ‏ UWP)

חלופה לשימוש בסכימות URI בהתאמה אישית ב-Android

איך עוברים לספריית Android של Google Identity Services

הפעלת סכימת URI מותאמת אישית

חלופה לשימוש בסכימות URI בהתאמה אישית באפליקציות Chrome

כתובת IP של Loopback (macOS, ‏ Linux, מחשב Windows)

העתקה והדבקה ידניות (הוצא משימוש)

הגנה על האפליקציות

אימות הבעלות על האפליקציה (Android, ‏ Chrome)

Android

Chrome

בדיקת אפליקציות (iOS בלבד)

הפעלת App Check עבור לקוח iOS

אכיפת בדיקת אפליקציות בלקוח iOS

ביטול האכיפה של בדיקת האפליקציה בלקוח iOS

השבתת App Check עבור לקוח iOS

גישה מבוססת-זמן

קריאה נוספת

הטמעה של ההגנה על כל החשבונות

OAuth 2.0 לאפליקציות לנייד ולמחשב

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`deleted_client`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` דוגמאות