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

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

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

אסימוני גישה

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

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

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

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

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

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

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

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

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

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

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

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

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

אסימוני גישה לחשבון שירות

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

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

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

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

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

2. חתימה על מטען הייעודי (payload) באמצעות מפתח של חשבון השירות הרלוונטי. לקוחות יכולים לחתום על מטען הייעודי (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, אסימון JWT של חשבון שירות יכול לציין נקודת קצה ל-API במפתח aud:

{
  "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.googleapis.com/",
  "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

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

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

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

  • שעה אחת

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

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

טוקנים של גישת זהות לסוכנים

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

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 שלו. אסימון גישה של סוכן מאוגד תקף רק כשמשתמשים בו בחיבור TLS הדדי שאומת באמצעות אישור הלקוח X.509 שאליו האסימון קשור.

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

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

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

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

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

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

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

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

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

טוקנים שמעניקים טוקנים

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

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

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

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

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

ההבדלים בין טוקנים שמעניקים טוקנים הם:

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

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

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

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

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

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

• תוקף: לכל טוקן יש תוקף שונה, ומידת האפשרות לשנות אותו משתנה.

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

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

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

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

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

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

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

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

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

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

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

אסימוני JWT חיצוניים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• תוקף: יש הבדלים בתוקף של הטוקנים.

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

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

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

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

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

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

אסימונים מזהים של זהות הסוכן

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

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

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

אסימון מזהה של סוכן מפוענח נראה בערך כך, כש-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

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

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

טענות נכוֹנוּת (assertions) של שרת proxy לאימות זהויות (IAP) הן אסימוני אינטרנט מסוג JSON‏ (JWT) שמועברים על ידי IAP לאפליקציות אינטרנט שמוגנות על ידי IAP בכותרת בקשת ה-HTTP‏ x-goog-iap-jwt-assertion. טענות של 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

טענת IAP כוללת את השדות הבאים:

פרטים נוספים על טענות של הצהרת IAP זמינים במאמר בנושא אימות מטען ה-JWT.

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