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

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

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

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

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

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

חלופות

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

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

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

מומלץ להשתמש בספריות ובדוגמאות הבאות כדי להטמיע את התהליך של OAuth 2.0 שמתואר במסמך הזה:

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

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

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

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

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

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

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

לוחצים על Create credentials (יצירת פרטי כניסה) > OAuth client ID (מזהה לקוח OAuth).
בקטעים הבאים מתוארים סוגי הלקוחות שנתמכים בשרת ההרשאות של Google. בוחרים את סוג הלקוח המומלץ לאפליקציה, נותנים שם ללקוח ה-OAuth ומגדירים את שאר השדות בטופס בהתאם.

Android

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

iOS

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

UWP

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

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

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

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

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

במסמך היקפי הרשאות API של OAuth 2.0 מופיעה רשימה מלאה של ההיקפים שבהם אפשר להשתמש כדי לגשת לממשקי 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 (מומלץ)	אתגר הקוד הוא גיבוב SHA-256 של מאמת הקוד בקידוד 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 הרלוונטית של הלולאה החוזרת ומפעילים מאזין HTTP ביציאה אקראית שזמינה. מחליפים את port במספר היציאה בפועל שאליו האפליקציה מקשיבה.

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

response_type

חובה

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

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

scope

חובה

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

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

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

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

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

login_hint

אופציונלי

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

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

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

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

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

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

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

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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 של לולאה חוזרת

https://accounts.google.com/o/oauth2/v2/auth?
 scope=email%20profile&
 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. במאמר העזרה שליטה בגישה של אפליקציות של צד שלישי ואפליקציות פנימיות לנתונים ב-Google Workspace מוסבר איך אדמין יכול להגביל את הגישה לכל ההיקפים או להיקפים רגישים ומוגבלים, עד שתוענק גישה מפורשת למזהה הלקוח של OAuth.

`disallowed_useragent`

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

Android

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

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

iOS

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

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

`org_internal`

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

`invalid_grant`

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

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

`redirect_uri_mismatch`

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

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

הפרמטר redirect_uri עשוי להתייחס לתהליך OAuth מחוץ למסגרת (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`	אסימון שאפשר להשתמש בו כדי לקבל אסימון גישה חדש. אסימוני הרענון בתוקף עד שהמשתמש מבטל את הגישה. חשוב לזכור שתמיד מוחזרים אסימוני רענון לאפליקציות מותקנות.
`scope`	היקפי הגישה שמוענקים על ידי `access_token` מפורטים כרשימה של מחרוזות תלויות-אותיות רישיות שמפרידות ביניהן רווחים.
`token_type`	סוג הטוקן שהוחזר. בשלב זה, הערך של השדה הזה תמיד מוגדר ל-`Bearer`.

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

{
  "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
  "expires_in": 3920,
  "token_type": "Bearer",
  "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
  "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
}

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

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

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

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

  {
    "access_token": "1/fFAGRNJru1FTz70BzhT3Zg",
    "expires_in": 3920,
    "token_type": "Bearer",
    "scope": "https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/calendar.readonly",
    "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI"
  }

קריאה ל-Google APIs

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

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

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

שדות
`client_id`	מזהה הלקוח שהתקבל מ- .
`client_secret`	סוד הלקוח שהתקבל מ- . (ה-`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 https://www.googleapis.com/auth/calendar.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

להשתמש ב-Google Sign-In for Android SDK, שמעביר את התגובה של OAuth 2.0 ישירות לאפליקציה, וכך מבטל את הצורך ב-URI להפניה אוטומטית.

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

מעדכנים את הקוד כך שישתמש ב-Google Sign-In SDK.
משביתים את התמיכה בסכימה בהתאמה אישית במסוף Google API.

כדי לעבור ל-Google Sign-In Android SDK:

מעדכנים את הקוד כך שישתמש ב-Android SDK של Google Sign-In:
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, שנדרשים להגדרת ה-SDK של Google Sign-In.
  הערה: אם אתם משתמשים בספרייה של צד שלישי, תוכלו למצוא את המידע הזה בקובץ התצורה של הספרייה.
3. כדי להגדיר את ה-SDK, פועלים לפי ההוראות במאמר תחילת השילוב של כניסה באמצעות חשבון Google באפליקציה ל-Android. אפשר לדלג על השלב קבלת מזהה הלקוח של OAuth 2.0 בשרת הקצה, כי אפשר להשתמש שוב ב-client_id שאוחזר מהשלב הקודם.
4. פועלים לפי ההוראות במאמר הפעלת גישה ל-API בצד השרת. מחזור החיים של התקלה כולל את השלבים הבאים:
  1. משתמשים בשיטה getServerAuthCode כדי לאחזר קוד אימות להיקפי הגישה שבהם מבקשים הרשאה.
  2. שולחים את קוד האימות לקצה העורפי של האפליקציה כדי להמיר אותו לטוקן גישה וטוקן רענון.
  3. משתמשים באסימון הגישה שאוחזר כדי לבצע קריאות ל-Google APIs מטעם המשתמש.
  הערה: אם לא נדרשת לאפליקציה גישה אופליין, צריך לפעול לפי ההוראות האלה כדי לבקש גישה ל-API מצד הלקוח.
משביתים את התמיכה בסכימה מותאמת אישית במסוף Google API:
1. עוברים לרשימת פרטי הכניסה של OAuth 2.0 ובוחרים את לקוח Android.
2. עוברים לקטע Advanced Settings, מבטלים את הסימון בתיבה Enable Custom URI Scheme ולוחצים על Save כדי להשבית את התמיכה בסכימת URI בהתאמה אישית.

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

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

עוברים לרשימת פרטי הכניסה של OAuth 2.0 ובוחרים את לקוח Android.
עוברים לקטע Advanced Settings (הגדרות מתקדמות), מסמנים את התיבה Enable Custom URI Scheme (הפעלת סכימת URI מותאמת אישית) ולוחצים על Save (שמירה) כדי להפעיל תמיכה בסכימת URI מותאמת אישית.

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

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

כתובת IP של לולאה חוזרת (macOS, ‏ Linux, ‏ Windows במחשב)

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

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

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

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

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

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

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

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

Android

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

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

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

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

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

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

Chrome

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מקורות מידע נוספים

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

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

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

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

שגיאות

admin_policy_enforced

disallowed_useragent

Android

iOS

org_internal

invalid_grant

redirect_uri_mismatch

invalid_request

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

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

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

קריאה ל-Google APIs

דוגמאות לבקשות HTTP GET

curl דוגמאות

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

ביטול טוקן

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

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

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

איך עוברים ל-Google Sign-In for Android SDK

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

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

כתובת IP של לולאה חוזרת (macOS, ‏ Linux, ‏ Windows במחשב)

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

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

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

Android

Chrome

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

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

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

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

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

מקורות מידע נוספים

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

`admin_policy_enforced`

`disallowed_useragent`

`org_internal`

`invalid_grant`

`redirect_uri_mismatch`

`invalid_request`

`curl` דוגמאות