סוגי האסימונים

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

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

אסימוני גישה

טוקני גישה מאפשרים ללקוחות לבצע קריאות מאומתות לממשקי API של Cloud de Confiance by S3NS . ב-Cloud de Confiance by S3NS יש תמיכה בכמה סוגים שונים של טוקני גישה, עם המאפיינים המשותפים הבאים:

• הם מאמתים חשבון ראשי, שיכול להיות משתמש או עומס עבודה.

• הם מונפקים ללקוח ספציפי אחד.

• הם קצרי מועד ופגים אחרי כמה שעות לכל היותר.

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

טוקני גישה יכולים להיות שונים בדרכים הבאות:

• מנפיק: הגורם שמנפיק את האסימון.

• חשבון משתמש: סוג חשבון המשתמש שהאסימון יכול לאמת.

• הגבלות: ההגבלות שאפשר להטיל על הטוקן.

בטבלה הבאה מפורטים הסוגים השונים של טוקני גישה:

לסוגים השונים של טוקני הגישה יש גם מאפייני אבטחה שונים:

• פורמט: חלק מטוקני הגישה הם אטומים, כלומר הם בפורמט קנייני ואי אפשר לבדוק אותם. אסימונים אחרים מקודדים כ-JSON Web Token, והלקוח יכול לפענח אותם.
• משך החיים: משך החיים של הטוקנים שונה, וגם המידה שבה אפשר לשנות אותם.
• אפשרות ביטול: אפשר לבטל חלק מהאסימונים. אסימונים אחרים נשארים בתוקף עד שהם פגים.
• קישור: אפשר לקשר אסימונים מסוימים לפרטי כניסה נוספים, וכך להפוך אותם לאסימונים מקושרים.

בטבלה הבאה מפורטים ההבדלים בין סוגי טוקני הגישה.

טוקני גישה של חשבונות שירות

טוקני גישה של חשבונות שירות הם טוקנים למוכ"ז שמאמתים חשבון שירות. האסימונים אטומים.

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

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "service-account@example.s3ns.iam.gserviceaccount.com",
  "email_verified": "true",
  "access_type": "online"
}

אסימון של חשבון שירות כולל את השדות הבאים:

אי אפשר לבטל טוקני גישה של חשבונות שירות, והם נשארים בתוקף עד שהם פגים.

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

אסימוני JWT (‏JSON Web Tokens) של חשבון שירות

אסימוני JWT (‏JSON Web Tokens) של חשבון שירות הם אסימונים למוכ"ז שמאמתים חשבון שירות. טוקני גישה של חשבון שירות מונפקים על ידי שרת הרשאות, אבל אסימוני JWT של חשבון שירות יכולים להיות מונפקים על ידי הלקוח עצמו.

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

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

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

2. חותמים על המטען הייעודי באמצעות מפתח של חשבון השירות הרלוונטי. הלקוחות יכולים לחתום על המטען הייעודי (payload) אופליין באמצעות מפתח לחשבון שירות בניהול המשתמש, או אונליין באמצעות השיטה signJwt ומפתח לחשבון שירות בניהול Google. מידע נוסף מופיע במאמר יצירת JSON Web Token בחתימה עצמית.

דוגמה ל-JWT מפוענח של חשבון שירות, שבו SIGNATURE מוחלף בחתימה של האסימון:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/cloud-platform",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

במקום לציין היקף OAuth במפתח scope, אפשר לציין נקודת קצה ל-API במפתח aud של JWT של חשבון שירות:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.iam.gserviceaccount.com",
  "aud": "https://cloudresourcemanager.s3nsapis.fr/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

‫JWT של חשבון שירות כולל את השדות הבאים:

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

טוקני גישה מאוחדים

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

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

principal://iam.googleapis.com/locations/global/workforcePools/POOL/subject/raha@altostrat.com.

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

principal://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/POOL/subject/SUBJECT_ATTRIBUTE_VALUE

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

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

  • הזמן שנותר עד שתוקף הסשן של איחוד שירותי אימות הזהות של כוח העבודה יפוג

  • שעה אחת

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

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

טוקני גישה של Agent Identity

טוקני גישה של זהות נציג מאמתים נציג שהוקצתה לו זהות נציג, ומשתמשים במזהה חשבון משתמש שדומה לזה:

principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/us-central1/reasoningEngines/REASONING_ENGINE_ID

מזהה חשבון המשתמש מבוסס על מזהה SPIFFE של אישור הלקוח X.509 של הסוכן, אבל משתמש בקידומת principal:// במקום spiffe://.

הסוכן יכול לקבל אסימון גישה לזהות הסוכן משרת המטא-נתונים של Compute Engine. אם רוצים, הסוכן יכול לבקש שהאסימון יהיה מקושר לאישור הלקוח שלו ב-X.509. טוקן גישה מקושר של Agent Identity תקף רק כשמשתמשים בו בחיבור Mutual TLS (mTLS) שמאומת באמצעות אישור הלקוח X.509 שהטוקן מקושר אליו.

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

טוקנים של גבולות גישה לפרטי כניסה

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

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

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

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

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

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

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

טוקנים להענקת טוקנים

אסימונים להענקת אסימונים מאפשרים ללקוחות לקבל אסימונים חדשים או שונים, אולי במועד מאוחר יותר. ב- Cloud de Confiance by S3NS יש תמיכה בכמה סוגים שונים של אסימונים להענקת אסימונים, ולכולם יש את המאפיינים המשותפים הבאים:

• הם מייצגים אימות קודם.

• הם מאמתים ישות מורשית, שיכולה להיות Google Identity (משתמש או עומס עבודה) או זהות חיצונית.

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

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

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

• מנפיק: הגורם שמנפיק את האסימון.

• חשבון משתמש: סוג הזהות של חשבון המשתמש שהאסימון יכול לאמת.

• הגבלות: ההגבלות שאפשר להטיל על הטוקן.

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

לסוגים השונים של אסימונים להענקת אסימונים יש גם מאפייני אבטחה שונים:

• פורמט: חלק מהאסימונים אטומים. הלקוח יכול לפענח אסימונים אחרים.

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

• שימוש חוזר: בחלק מהאסימונים שמעניקים אסימונים אפשר להשתמש רק פעם אחת. אסימונים אחרים יכולים לשמש כמה פעמים.

• אפשרות ביטול: אפשר לבטל חלק מהאסימונים. אסימונים אחרים נשארים בתוקף עד שהם פגים.

• קישור: חלק מהאסימונים מקושרים לפרטי כניסה נוספים, מה שהופך אותם לאסימונים מקושרים. אסימונים אחרים לא מקושרים, ולכן הם טוקנים למוכ"ז.

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

טוקני רענון מאוחדים

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

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

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

קודי הרשאה מאוחדים

בדומה לקודי הרשאה, קודי הרשאה מאוחדים הם אסימונים אטומים לטווח קצר. הקודים מיועדים לשימוש רק במהלך אימות המשתמש כמתווך בין הלקוח לבין שרת ההרשאות של Cloud de Confiance by S3NS IAM.

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

אסימוני JSON Web Tokens חיצוניים

אסימוני JWT חיצוניים מונפקים על ידי ספק זהויות חיצוני, כמו Microsoft Entra ID, ‏Okta, ‏Kubernetes או GitHub. יכול להיות שהמבנה והתוכן שלהם יהיו שונים.

אם מגדירים את איחוד שירותי אימות הזהות של כוח העבודה או את איחוד שירותי אימות הזהות של עומסי העבודה, אפשר להגדיר יחסי אמון בין Cloud de Confiance by S3NS לבין ספק זהויות חיצוני. לאחר מכן, עומסי העבודה יכולים להשתמש באסימוני JWT חיצוניים כאסימונים להענקת אסימונים, כדי לקבל טוקני גישה מאוחדים.

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

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

בשני המקרים, המזהה של חשבון המשתמש נגזר מתביעה אחת או יותר של ה-JWT החיצוני.

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

תגובות או טענות נכוֹנוּת (assertions) חיצוניות של SAML

טענות נכוֹנוּת (assertions) חיצוניות של Security Assertion Markup Language (SAML) הן טענות נכוֹנוּת (assertions) של SAML 2.0 שמונפקות על ידי ספק זהויות חיצוני כמו Microsoft Entra ID,‏ Okta או Active Directory Federation Services. אפשר לצרף את טענות הנכוֹנוּת החיצוניות האלה של SAML לתגובת SAML 2.0 או להצפין אותן.

כמו עם אסימוני אינטרנט חיצוניים של JSON, אתם יכולים להגדיר את איחוד שירותי אימות הזהות של כוח העבודה או את איחוד זהויות של עומסי עבודה, כך שעומסי העבודה יוכלו להשתמש בתגובות או בטענות נכוֹנוּת (assertions) חיצוניות של SAML בתור אסימונים להענקת אסימונים, כדי לקבל טוקני גישה מאוחדים.

כדי שתהיה תאימות עם איחוד שירותי אימות הזהות של כוח העבודה או עם איחוד שירותי אימות הזהות של עומסי עבודה, טענות נכוֹנוּת (assertions) חיצוניות ב-SAML צריכות לעמוד בדרישות ספציפיות.

טוקן GetCallerIdentity של Amazon Web Services (AWS)

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

טוקנים של זהות

טוקנים של מזהים (ID) מאפשרים ללקוחות לזהות את המשתמש שאיתו הם יוצרים אינטראקציה. ב- Cloud de Confiance by S3NS יש תמיכה בכמה סוגים שונים של טוקנים של מזהים, ולכולם יש את המאפיינים המשותפים הבאים:

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

• הם מאמתים חשבון ראשי, שיכול להיות משתמש או עומס עבודה.

• הם מונפקים ללקוח ספציפי אחד.

• הם קצרי-מועד והתוקף שלהם פג אחרי שעה לכל היותר.

• אי אפשר לבטל אותם.

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

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

• אפשר להשתמש בהם כדי לאמת קריאות בין מיקרו-שירותים, או כדי לאמת באופן פרוגרמטי בשרת proxy לאימות זהויות (IAP).

אסימוני זהות יכולים להיות שונים בדרכים הבאות:

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

• מנפיק: הגורם שמנפיק את האסימון.

• חשבון משתמש: סוג הזהות של חשבון המשתמש שהאסימון יכול לאמת.

בטבלה הבאה מפורטים הסוגים השונים של אסימוני זהות.

לסוגים השונים של אסימוני הזהות יש גם מאפייני אבטחה שונים:

• פורמט: חלק מהאסימונים הם אסימוני אינטרנט מסוג JSON‏ (JWT), ואחרים משתמשים בפורמט XML.

• משך החיים: משך החיים של טוקנים שונה.

• קישור: אפשר לקשר אסימונים מסוימים לפרטי כניסה נוספים, וכך להפוך אותם לאסימונים מקושרים.

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

טוקנים של מזהי חשבונות שירות

אסימוני זיהוי של חשבון שירות הם אסימוני JWT (‏JSON Web Tokens) שמאמתים חשבון שירות.

בשונה מאסימוני JWT של חשבון שירות ומטענות נכונות (assertions) של אסימוני JWT של חשבון שירות, אסימוני מזהה של חשבון שירות לא נחתמים על ידי מפתח של חשבון שירות. במקום זאת, אסימוני המזהה של חשבון השירות נחתמים על ידי Google JSON Web Key Set‏ (JWKS).

אסימון מזהה מפוענח של חשבון שירות נראה כמו בדוגמה הבאה, כאשר SIGNATURE מוחלף בחתימה של האסימון:

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "aud": "example-audience",
  "azp": "112010400000000710080",
  "email": "service-account@example.s3ns.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1745365618,
  "iat": 1745362018,
  "iss": "https://accounts.google.com",
  "sub": "112010400000000710080"
}.SIGNATURE

אסימון מזהה של חשבון שירות כולל את השדות הבאים:

קבוצת ההצהרות המדויקת שנכללת בטוקן של מזהה תלויה באופן שבו הטוקן של המזהה מתבקש. לדוגמה, טוקנים של מזהים שמתבקשים על ידי שרת המטא-נתונים של Compute Engine יכולים לכלול הצהרות נוספות שמאשרות את הזהות של המכונה הווירטואלית. טוקנים של מזהה שביקשתם באמצעות IAM Credentials API יכולים להכיל את מזהה הארגון של הפרויקט של חשבון השירות.

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

טוקנים של מזהי Agent Identity

טוקנים של מזהה זהות הנציג הם מסמכי זיהוי שניתנים לאימות באמצעות SPIFFE‏ (JWT-SVID), והם מאמתים סוכן שהוקצתה לו Agent Identity.

סוכן יכול לקבל טוקן של מזהה משרת המטא-נתונים של Compute Engine. הסוכן יכול לבקש שהאסימון יהיה קשור לאישור הלקוח X.509 שלו. טוקן של מזהה מקושר של Agent Identity מכיל את טביעת האצבע של אישור הלקוח מסוג X.509 בהצהרה cnf.

בניגוד לאסימונים מזהים של משתמשים ואסימונים מזהים של חשבונות שירות, אסימונים מזהים של זהויות סוכנים לא חתומים על ידי Google JSON Web Key Set‏ (JWKS). במקום זאת, טוקנים של מזהים של זהויות של סוכנים נחתמים על ידי JWKS שספציפי למאגר זהויות של סוכנים.

טוקן של מזהה Agent Identity מפוענח נראה דומה לדוגמה הבאה, כאשר SIGNATURE מוחלף בחתימה של הטוקן:

{
  "alg": "RS256",
  "kid": "78ab40e4a0319f9ced58024f5bb66e6387d68066",
  "typ": "JWT"
}.{
  "iss": "https://sts.googleapis.com/v1/organizations/1234567890/locations/global/workloadIdentityPools/agents.global.org-1234567890.system.id.goog",
  "sub": "spiffe://agents.global.org-1234567890.system.id.goog/resources/aiplatform/projects/1234567890/locations/us-central1/reasoningEngines/987654321",
  "aud": ["https://example.com/"],
  "iat": 1775776191,
  "exp": 1775779791,
  "cnf": {
    "x5t#S256": "QTB5TSHeDxHrzDzcrrHU+/shhkfCnARcBEvMldp2uis"
  }
}.SIGNATURE

טוקן של מזהה Agent Identity כולל את השדות הבאים:

טענות נכונות (assertions) של שרת proxy לאימות זהויות (IAP)

טענות נכוֹנוּת (assertions) של שרת proxy לאימות זהויות (IAP) הן אסימוני JSON Web Token ‏(JWT) שמועברים על ידי IAP לאפליקציות אינטרנט שמוגנות על ידי IAP, בכותרת הבקשה x-goog-iap-jwt-assertion ב-HTTP. טענות נכונות (assertions) של IAP מאמתות משתמש וגם משמשות כהוכחה לכך שבקשה אושרה על ידי IAP.

• חשבונות משתמשים מנוהלים

• חשבונות פרטיים

• חשבונות שירות

• חשבונות משתמשים במאגר זהויות של כוח עבודה

טענת אימות מפוענחת של IAP נראית בערך כך, כאשר SIGNATURE מוחלף בחתימת האסימון:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "4BCyVw"
}.{
  "aud": "/projects/0000000000/global/backendServices/000000000000",
  "azp": "/projects/0000000000/global/backendServices/000000000000",
  "email": "user@example.com",
  "exp": 1745374290,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "iat": 1745373690,
  "identity_source": "WORKFORCE_IDENTITY",
  "iss": "https://cloud.google.com/iap",
  "sub": "sts.google.com:AAFTZ...Q",
  "workforce_identity": {
    "iam_principal": "principal://iam.googleapis.com/locations/global/workforcePools/example/subject/user-0000000000",
    "workforce_pool_name": "locations/global/workforcePools/example"
  }
}.SIGNATURE

טענת נכוֹנוּת (assertion) של IAP כוללת את השדות הבאים:

לפרטים נוספים על טענות נכוֹנוּת של טענת אימות ב-IAP, קראו את המאמר אימות המטען הייעודי (payload) של JWT.

טענות נכונות (assertions) של IAP תקפות למשך 10 דקות, ואי אפשר לבטל אותן.