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

איך משתפים לקוחות OAuth

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

סקירה כללית

שיתוף של לקוחות OAuth בין פרויקטים מאפשר להשתמש בלקוח OAuth אחד בהתאמה אישית לכמה אפליקציות שמוגנות באמצעות שרת proxy לאימות זהויות (IAP), במקום ליצור לקוח OAuth חדש לכל אפליקציה. הגישה הזו מפשטת את הניהול, במיוחד לארגונים עם הרבה אפליקציות.

כשמגדירים את IAP, אפשר להשתמש באחד משני סוגים של לקוחות OAuth:

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

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

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

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

לפני שמתחילים

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

גישה פרוגרמטית

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

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

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

gcloud

מכינים קובץ הגדרות עם מזהי הלקוחות ב-OAuth:

cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

מחילים את ההגדרות באמצעות הפקודה gcloud iap settings set:

gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

פקודות לדוגמה:

# Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

כאשר:

‫SETTINGS_FILENAME: קובץ ה-YAML שהכנתם.
‫ORGANIZATION: מזהה הארגון
‫FOLDER: מזהה התיקייה
‫PROJECT: מזהה הפרויקט
‫RESOURCE_TYPE: סוג המשאב של IAP (‏app-engine,‏ iap_web,‏ compute,‏ organization או folder)
‫SERVICE: שם השירות (אופציונלי לסוגי המשאבים compute או app-engine)
‫VERSION: שם הגרסה (לא רלוונטי ל-compute, אופציונלי ל-app-engine)

API

מכינים קובץ JSON של הגדרות:

cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

משיגים את שם המשאב:

gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

מעדכנים את ההגדרות באמצעות שם המשאב:
```
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
```
כאשר:
- ‫ORGANIZATION: מזהה הארגון
- ‫FOLDER: מזהה התיקייה
- ‫PROJECT: מזהה הפרויקט
- ‫RESOURCE_TYPE: סוג המשאב של IAP (‏app-engine,‏ iap_web,‏ compute,‏ organization או folder)
- ‫SERVICE: שם השירות (אופציונלי לסוגי המשאבים compute או app-engine)
- ‫VERSION: שם הגרסה (לא רלוונטי ל-compute, אופציונלי ל-app-engine)

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

גישה לדפדפן

כדי לאפשר ל-IAP להשתמש במזהה הלקוח ובסוד הלקוח באמצעות מסוףGoogle Cloud , צריך לבצע את ההוראות הבאות:

הסיכונים

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

נקודת כשל בודדת

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

כדי לנהל את הסיכון התפעולי הזה בצורה יעילה:

להטמיע אמצעי בקרת גישה מתאימים כדי למנוע שינויים או מחיקה בטעות
הגבלת הגישה ללקוחות OAuth באמצעות הרשאות clientauthconfig.clients.*
להשתמש ביומני הביקורת שלGoogle Cloud כדי לעקוב אחרי פעילויות ניהוליות שקשורות ללקוחות OAuth.

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

דליפות של סודות לקוח

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

כדי לצמצם את הסיכון הזה:

להגן על סודות לקוח כמו סיסמאות, ואף פעם לא לאחסן אותם כטקסט פשוט
הטמעת ניהול מאובטח של פרטי כניסה באמצעות Secret Manager
מעקב אחרי הגישה למשאבי IAP באמצעות Cloud Audit Logging
סוד לקוח שדלף משפיע רק על האימות, ולא על ההרשאה לגשת למשאבים. אם אתם חושדים שהסוד שלכם דלף, אפסו אותו מיד.

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

שיקולים לגבי היקף ההרשאות

כשמשתפים לקוחות OAuth, כל האפליקציות משתמשות באותם היקפי הרשאות. ב-IAP, היקפי ההרשאות היחידים שנדרשים הם openid ו-email. השיקול הזה כשלעצמו לא מהווה סיכון משמעותי, אבל חשוב להבין:

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

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