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

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

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

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

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

אסימוני גישה

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

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

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

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

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

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

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

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

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

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

סוג הטוקן מנפיק חשבונות משתמשים הגבלות
טוקן גישה של משתמש שרת ההרשאות של Google
  • משתמש (חשבון מנוהל)
  • משתמש (חשבון פרטי)
 היקף הרשאות OAuth
טוקן גישה לחשבון שירות
  • שרת ההרשאות של Google
  • Google Cloud שרת הרשאות IAM
 חשבון שירות היקף הרשאות OAuth
אסימון של הענקת גישה ברמת הדומיין שרת ההרשאות של Google משתמש (חשבון מנוהל) היקף הרשאות OAuth
אסימון JWT‏ (JSON Web Token) של חשבון שירות לקוח חשבון שירות היקף הרשאות OAuth או API
אסימון גישה מאוחד Google Cloud שרת הרשאות IAM
  • פרינציפל במאגר זהויות של כוח עבודה
  • פרינציפל במאגר זהויות של עומסי עבודה
 היקף הרשאות OAuth
טוקן גישה לזהות הסוכן Google Cloud שרת הרשאות IAM הזהות של הישות המורשית של הסוכן היקף הרשאות OAuth
אסימון של גבול גישה לפרטי כניסה Google Cloud שרת הרשאות IAM
  • משתמש (חשבון מנוהל)
  • משתמש (חשבון פרטי)
  • חשבון שירות
 אובייקטים ספציפיים ב-Cloud Storage
טוקן של גבול גישה לפרטי כניסה שהונפק על ידי הלקוח לקוח חשבון שירות אובייקטים ספציפיים ב-Cloud Storage

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

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

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

סוג הטוקן פורמט ניתן לבדיקה כל התאריכים ניתן לביטול קישור
טוקן גישה של משתמש אטום כן שעה אחת כן
טוקן גישה לחשבון שירות אטום כן ‫5 דקות עד 12 שעות לא
טוקן של הענקת גישה ברמת הדומיין אטום כן שעה אחת לא
אסימון JWT (‏JSON Web Token) של חשבון שירות JWT לא רלוונטי 5 דקות עד שעה לא
טוקן גישה מאוחד אטום לא אסימוני גישה מאוחדים לא
טוקן גישה לזהות הסוכן אטום לא טוקנים של גישה לזהות הסוכן לא אישור לקוח X.509
טוקן של גבול גישה לפרטי כניסה אטום לא מידע נוסף על אסימונים של גבולות גישה לפרטי כניסה לא
טוקן של גבול גישה לפרטי כניסה שהונפק על ידי הלקוח אטום לא לא רלוונטי לא

טוקנים של גישה של משתמשים

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

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

curl "https://oauth2.googleapis.com/tokeninfo?access_token=ACCESS_TOKEN"

הפלט של הפקודה אמור להיראות כך:

{
  "azp": "0000000000.apps.googleusercontent.com",
  "aud": "0000000000.apps.googleusercontent.com",
  "sub": "00000000000000000000",
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "user@example.com",
  "email_verified": "true"
}

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

שדה שם תיאור
aud קהל

לקוח ה-OAuth שאליו משויך הטוקן הזה, שמזוהה באמצעות מזהה הלקוח ב-OAuth.

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

azp צד מורשה לקוח ה-OAuth שביקש את הטוקן, שמזוהה באמצעות מזהה הלקוח שלו ב-OAuth.
email כתובת אימייל ראשית

כתובת האימייל הראשית של המשתמש.

השדה הזה מופיע רק אם האסימון כולל את ההיקף https://www.googleapis.com/auth/userinfo.email.

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

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

המזהה הזה זהה למזהה שמוצג ב- Directory API.

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

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

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

אסימוני גישה של חשבונות שירות הם אסימונים למוכ"ז שמאמתים חשבון שירות. האסימונים הם אטומים ואפשר לבדוק אותם באמצעות https://oauth2.googleapis.com/tokeninfo API.

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

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

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

שדה שם תיאור
aud קהל חשבון השירות שאליו משויך האסימון, ששווה ל-authorized party.
azp צד מורשה חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו.
email כתובת אימייל ראשית

כתובת האימייל של חשבון השירות.

השדה הזה מופיע רק אם האסימון כולל את ההיקף https://www.googleapis.com/auth/userinfo.email.

exp תאריך תפוגה תאריך התפוגה של האסימון, בפורמט חותמת זמן של מערכת Unix.

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

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

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

אסימוני הענקת גישה ברמת הדומיין הם אסימונים למוכ"ז שמאמתים משתמש ומאשרים לחשבון שירות לפעול בשם המשתמש. האסימונים הם אטומים ואפשר לבדוק אותם באמצעות https://oauth2.googleapis.com/tokeninfo API.

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

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744688957",
  "expires_in": "3540",
  "email": "user@example.com",
  "email_verified": "true",
  "access_type": "offline"
}

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

שדה שם תיאור
aud קהל חשבון השירות שאליו משויך האסימון, ששווה לצד המורשה.
azp צד מורשה חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו.
email כתובת אימייל ראשית

כתובת האימייל הראשית של המשתמש שמתחזים אליו.

השדה הזה מופיע רק אם האסימון כולל את ההיקף https://www.googleapis.com/auth/userinfo.email.

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

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

אסימוני 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.iam.gserviceaccount.com",
  "sub": "service-account@example.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.iam.gserviceaccount.com",
  "sub": "service-account@example.iam.gserviceaccount.com",
  "aud": "https://cloudresourcemanager.googleapis.com/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

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

שדה שם תיאור
aud קהל נקודות קצה של API שהלקוח יכול לגשת אליהן. ההגדרה הזו תקפה רק אם לא צוין scope.
exp תאריך תפוגה תאריך התפוגה של האסימון, בפורמט חותמת זמן של מערכת Unix.
iat זמן הבעיה הזמן שבו הונפק האסימון, בפורמט של חותמת זמן של מערכת Unix.
iss מנפיק הגורם שהנפיק את האסימון, שהוא חשבון השירות עצמו.
scope היקפי ההרשאות של OAuth קבוצת ממשקי ה-API שהלקוח מורשה לגשת אליהם, שמזוהים על ידי היקף הרשאות OAuth. ההגדרה הזו תקפה רק אם לא צוינה מדיניות aud.
sub נושא חשבון המשתמש המאומת, שהוא חשבון השירות עצמו.

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

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

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

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

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

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

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

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

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

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

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

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

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

סוג הטוקן מנפיק סוג טוקן הגישה שנפדה חשבונות משתמשים הגבלות
טוקן רענון שרת ההרשאות של Google טוקן גישה של משתמש
  • משתמש (חשבון מנוהל)
  • משתמש (חשבון פרטי)
 היקף הרשאות OAuth
קוד הרשאה שרת ההרשאות של Google טוקן גישה של משתמש
  • משתמש (חשבון מנוהל)
  • משתמש (חשבון פרטי)
 היקף הרשאות OAuth
טוקן רענון מאוחד Google Cloud שרת הרשאות IAM טוקן גישה מאוחד פרינציפל במאגר זהויות של כוח עבודה היקף הרשאות OAuth
קוד הרשאה מאוחד Google Cloud שרת הרשאות IAM טוקן גישה מאוחד פרינציפל במאגר זהויות של כוח עבודה היקף הרשאות OAuth
טענת זהות של אסימון אינטרנט מסוג JSON של חשבון שירות לקוח
  • טוקן של הענקת גישה ברמת הדומיין
  • טוקן גישה לחשבון שירות
  • משתמש (חשבון מנוהל)
  • חשבון שירות
 היקף הרשאות OAuth
אסימון רשת מבוסס JSON חיצוני ספק זהויות חיצוני טוקן גישה מאוחד גורם חיצוני ללא
טענת נכוֹנוּת (assertion) או תגובה חיצונית של SAML ספק זהויות חיצוני טוקן גישה מאוחד גורם חיצוני ללא
אסימון של Amazon Web Services ‏ (AWS) GetCallerIdentity ספק זהויות חיצוני טוקן גישה מאוחד גורם חיצוני ללא

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

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

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

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

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

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

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

סוג הטוקן פורמט כל התאריכים ניתן לביטול רב-שימושי קישור
טוקן רענון אטום משתנה, ראו אסימוני רענון כן כן פרטי כניסה של לקוח OAuth
קוד הרשאה אטום 10 דקות לא לא פרטי כניסה של לקוח OAuth
טוקן רענון מאוחד אטום משתנה, ראו אסימוני רענון מאוחדים לא כן פרטי כניסה של לקוח OAuth
קוד הרשאה מאוחד אטום 10 דקות לא לא פרטי כניסה של לקוח OAuth
טענת זהות של אסימון JWT (‏JSON Web Token) של חשבון שירות JWT 5 דקות עד שעה לא כן
אסימון חיצוני או אסימון חיצוני מסוג JSON Web Token JWT תלוי בספק הזהויות תלוי בספק הזהויות כן
טענת נכונות או תגובה חיצונית של SAML SAML תלוי בספק הזהויות תלוי בספק הזהויות כן
טוקן של Amazon Web Services ‏ (AWS) GetCallerIdentity בלוב טקסט תלוי בספק הזהויות תלוי בספק הזהויות כן

אסימוני רענון

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

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

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

קודי הרשאה

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

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

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

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

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

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

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

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

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

טענות (assertions) של אסימוני JWT (‏JSON Web Token) של חשבון שירות

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

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

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

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

שדה ‏JWT של חשבון שירות טענת JWT של חשבון שירות
aud ‫Google Cloud API, מושמט אם מצוין scope חייב להיות https://oauth2.googleapis.com/token
exp תאריך תפוגה תאריך תפוגה
iat זמן הבעיה זמן הבעיה
iss כתובת האימייל של חשבון השירות כתובת האימייל של חשבון השירות
scope היקפי הרשאות OAuth, לא מצוינים אם מציינים את aud היקפי ההרשאות של OAuth
sub כתובת האימייל של חשבון השירות כתובת האימייל של חשבון משתמש להענקת גישה ברמת הדומיין, מושמטת אחרת

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

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

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

אם מגדירים איחוד שירותי אימות הזהות של כוח עבודה או איחוד של Workload Identity, אפשר ליצור יחסי אמון בין Google Cloud לבין ספק זהויות חיצוני. עומסי עבודה יכולים להשתמש באסימוני 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‏ולטענות נכוֹנוּת (assertions) של SAML‏, אפשר להגדיר את איחוד שירותי אימות הזהות של כוח עבודה או את איחוד שירותי אימות הזהות של עומסי עבודה כך שעומסי עבודה יוכלו להשתמש בבלובים האלה של טקסט כאסימון להענקת אסימונים כדי לקבל אסימוני גישה מאוחדים.

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

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

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

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

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

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

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

סוג הטוקן מנפיק קהל חשבון משתמש
אסימון מזהה משתמש שרת ההרשאות של Google לקוח OAuth/OIDC
  • משתמש (משתמש מנוהל)
  • משתמש (חשבון פרטי)
אסימון מזהה של חשבון שירות Google Cloud שרת הרשאות IAM חופשיים לבחור כל קהל חשבון שירות
אסימון מזהה של זהות הסוכן Google Cloud שרת הרשאות IAM חופשיים לבחור כל קהל זהות הסוכן
טענת שרת proxy לאימות זהויות (IAP) IAP
  • בק-אנד
  • אפליקציית App Engine
  • משתמש (חשבון מנוהל)
  • משתמש (חשבון פרטי)
  • פרינציפל במאגר זהויות של כוח עבודה
טענת נכוֹנוּת (assertion) של SAML שרת ההרשאות של Google אפליקציית SAML משתמש (חשבון מנוהל)

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

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

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

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

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

סוג הטוקן פורמט כל התאריכים קישור
אסימון מזהה משתמש JWT שעה אחת
אסימון מזהה של חשבון שירות JWT שעה אחת
אסימון מזהה של זהות הסוכן JWT שעה אחת אישור לקוח X.509
טענת שרת proxy לאימות זהויות (IAP) JWT 10 דקות
טענת נכוֹנוּת (assertion) של SAML XML 10 דקות

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

אסימונים מזהים של משתמשים הם אסימוני JWT (‏JSON Web Tokens) שמאמתים משתמש. לקוחות יכולים לקבל אסימון מזהה של משתמש על ידי הפעלת תהליך אימות OIDC.

אסימוני User ID חתומים באמצעות Google JSON Web Key Set‏ (JWKS). קובץ ה-JWKS של Google הוא משאב גלובלי, ואותם מפתחות חתימה משמשים לסוגים שונים של משתמשים, כולל:

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

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

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

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

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "iss": "https://accounts.google.com",
  "azp": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "aud": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "sub": "12345678901234567890",
  "at_hash": "y0LZEe-ervzRNSxn4R-t9w",
  "name": "Example user",
  "picture": "https://lh3.googleusercontent.com/a/...",
  "given_name": "Example",
  "family_name": "User",
  "hd": "example.com",
  "iat": 1745361695,
  "exp": 1745365295
}.SIGNATURE

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

שדה שם תיאור
aud קהל

לקוח ה-OAuth שאליו משויך הטוקן הזה, שמזוהה באמצעות מזהה הלקוח ב-OAuth.

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

azp צד מורשה לקוח ה-OAuth שביצע את תהליך האימות של OIDC, מזוהה על ידי מזהה לקוח ה-OAuth שלו.
exp תאריך תפוגה תאריך התפוגה של האסימון, בפורמט חותמת זמן של מערכת Unix.
hd דומיין מתארח

הדומיין הראשי של חשבון Cloud Identity או Google Workspace של המשתמש.

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

iss מנפיק הישות שהנפיקה את האסימון. הערך תמיד יהיה https://accounts.google.com.
sub נושא

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

המזהה הזה זהה למזהה שמוצג ב- Directory API.

הקבוצה המדויקת של ההצהרות שכלולות בטוקן מזהה תלויה בפרמטר scope בבקשת האימות.

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

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

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

אסימונים מזהים של חשבון שירות הם אסימוני 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.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1745365618,
  "iat": 1745362018,
  "iss": "https://accounts.google.com",
  "sub": "112010400000000710080"
}.SIGNATURE

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

שדה שם תיאור
aud קהל מזהה של הצד שאליו האסימון הזה מיועד. הערך יכול להיבחר באופן חופשי על ידי מי שמבקש את האסימון.
azp צד מורשה חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו.
exp תאריך תפוגה תאריך התפוגה של האסימון, בפורמט חותמת זמן של מערכת Unix.
iss מנפיק הנפקן של האסימון, תמיד מוגדר כ-https://accounts.google.com.
sub נושא חשבון השירות שביקש את האסימון, שמזוהה באמצעות המזהה הייחודי שלו.

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

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

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

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

אסימוני הזהות של הסוכן הם מסמכי זהות ניתנים לאימות של 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

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

שדה שם תיאור
aud קהל מזהה של הצד שאליו האסימון הזה מיועד. הערך יכול להיבחר על ידי מי שמבקש את הטוקן.
exp תאריך תפוגה תאריך התפוגה של האסימון, בפורמט חותמת זמן של מערכת Unix.
iss מנפיק הנפקן של האסימון, שהוא מאגר הזהויות של הסוכן בארגון או בפרויקט שמכילים את הסוכן.
sub נושא מזהה ה-SPIFFE של הסוכן.
cnf.x5t#S256 אישור טביעת האצבע של אישור הלקוח X.509 שהאסימון משויך אליו. ההצהרה ריקה אם הטוקן לא מאוגד.

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

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

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

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

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

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

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

אחרי פענוח, טענת ה-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": 1745362883,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "hd": "example.com",
  "iat": 1745362283,
  "identity_source": "GOOGLE",
  "iss": "https://cloud.google.com/iap",
  "sub": "accounts.google.com:112010400000000710080"
}.SIGNATURE

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

{
  "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 כוללת את השדות הבאים:

שדה שם תיאור
aud קהל שירות הקצה העורפי, אפליקציית App Engine או שירות Cloud Run שאליהם מיועדת טענת ה-IAP.
iss מנפיק המנפיק של הטוקן, תמיד מוגדר כ-https://cloud.google.com/iap
sub נושא

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

אם IAP מוגדר לשימוש בזהויות של Google, המזהה הזה שווה למזהה שמוצג ב- Directory API.

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

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

טענות נכוֹנוּת (assertions) של SAML

טענות נכונות (assertions) של Security Assertion Markup Language ‏(SAML) מאמתות חשבון משתמש מנוהל ומאשרות לו גישה לאפליקציית SAML בהתאמה אישית. טענות נכונות של SAML מונפקות ונחתמות על ידי Cloud Identity, ואפשר להשתמש בהן רק כדי לאמת חשבונות משתמשים מנוהלים.

בניגוד לאסימוני זהות שנחתמים באמצעות מפתח גלובלי, טענות הנכונות (assertions) של SAML נחתמות באמצעות מפתח שספציפי לחשבון Cloud Identity או לחשבון Google Workspace.

טענת נכוֹנוּת (assertion) של תגובת SAML מפוענחת נראית כך:

<saml2:Assertion
  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="..."
  IssueInstant="2025-04-23T22:47:20.881Z"
  Version="2.0">
  <saml2:Issuer>
    https://accounts.google.com/o/saml2?idpid=C0123456789
  </saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
  <saml2:Subject>
    <saml2:NameID
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
        user@example.com
    </saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData
        NotOnOrAfter="2025-04-23T22:52:20.881Z"
        Recipient="https://app.example.com/"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>

  <saml2:Conditions
    NotBefore="2025-04-23T22:42:20.881Z"
    NotOnOrAfter="2025-04-23T22:52:20.881Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>example-app</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>

  <saml2:AuthnStatement
    AuthnInstant="2025-04-23T22:46:44.000Z"
    SessionIndex="...">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
      </saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
</saml2:Assertion>

הצהרת SAML כוללת את השדות הבאים:

שדה שם תיאור
Audience קהל מזהה הישות של אפליקציית SAML.
Issuer מנפיק הנפקן של האסימון, ספציפי לחשבון Cloud Identity או לחשבון Google Workspace.
NameID נושא הגורם המאומת. הפורמט של המזהה תלוי בהגדרות של אפליקציית SAML.

הקבוצה המדויקת של המאפיינים שנכללים בטענת הנכוֹנוּת (assertion) של SAML תלויה בהגדרות של אפליקציית SAML.

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