בדיקת פרוטוקול לאימות אימייל באמצעות תקופת ניסיון

Rowan Merewood

תאריך פרסום: 8 ביולי 2026

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

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

הדגמה של בקשת משתמש בממשק ה-API לאימות כתובות אימייל
הדגמה של הנחיית משתמש ב-Email Verification API

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

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

תהליך אימות האימייל

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

מונחי מפתח

אלה מונחים מרכזיים שקשורים ל-Email Verification API:

  • המאמת: האתר שאוסף את כתובת האימייל ורוצה לאמת אותה. המאמת נקרא גם Relying Party.
  • ספק האימייל: השירות שמספק את כתובת האימייל של המשתמש, לדוגמה gmail.com.
  • ‫Issuer: השירות שמנהל את החשבון של כתובת האימייל של המשתמש, לדוגמה accounts.google.com. המנפיק נקרא גם ספק זהויות.

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

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

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

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

  • המשתמש צריך לבחור את כתובת האימייל שלו מהתפריט הנפתח של המילוי האוטומטי או ההשלמה האוטומטית.

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

    • אם המשתמש הוסיף את כתובת האימייל שלו באמצעות ההגדרה 'מילוי אוטומטי וסיסמאות' (chrome://settings/autofill) ב-Chrome, המערכת תציע אותה באמצעות המילוי האוטומטי.

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

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

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

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

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

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

  5. לאחר מכן, האתר המאמת בודק כל אחד מהפרטים האלה: כתובת האימייל הצפויה, ה-nonce והחתימות מהדפדפן ומהגורם המנפיק.

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

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

המשתמשים יכולים לנהל את כתובות האימייל המאומתות שלהם דרך הגדרות > מילוי אוטומטי וסיסמאות > פרטי איש קשר > כתובת אימייל מאומתת (או לפתוח את chrome://settings/contactInfo).

שיקולים לגבי תרחישי שימוש

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

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

הטמעה של אתר האימות

לפרטים נוספים, אפשר לעיין בסרטון ההדגמה של הקוד מקצה לקצה ולקרוא את שלבי האימות בהצעות לשימוש ב-Email Verification API וב-Email Verification Protocol.

הגדרת שדות בטופס

מוודאים שלשדות הטופס יש את המאפיינים הנכונים:

<input
  name="email-address"
  type="email"
  autocomplete="email">
<input
  type="hidden"
  name="token"
  nonce="rAnD0m-VaLuE"
  autocomplete="email-verification-token">

מגדירים את המאפיינים type ו-autocomplete של הקלט email כ-email כדי שהדפדפן יציע השלמה אוטומטית של כתובת האימייל.

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

  • מגדירים את type="hidden" כי השדה הזה לא דורש קלט מהמשתמש.
  • מגדירים את nonce="rAnD0m-VaLuE". האתר צריך לספק ערך חד-פעמי (nonce) ייחודי שקשור לסשן כדי לאמת את שליחת הטופס.
  • מגדירים את autocomplete="email-verification-token". הדפדפן משתמש במאפיין הזה כדי לזהות את השדה שצריך למלא.

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

אימות של EVT

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

  1. מנתחים את הטוקן.
  2. אימות הערכים הצפויים.
  3. אימות של שיוך המקשים.
  4. מאמתים את רשומת ה-DNS.
  5. לגלות את המנפיק ולאמת את החתימה של ה-EVT.

1. ניתוח הטוקן

הנתונים הגולמיים מטופס השליחה מכילים את ה-EVT ואת הטענות החתומות בטוקן רשת מבוסס JSON עם חשיפה סלקטיבית (SD-JWT+KB), מופרדים באמצעות טילדה (~). תצטרכו להפריד ביניהם ולפענח את הכותרות ואת המטען הייעודי (payload) של חתימה והצפנה של אובייקט ב-JavaScript‏ (JOSE) (לדוגמה, באמצעות jose ל-Node.js).

אם example.com מאמת את demo@gmail.com, המטען הייעודי מפוענח ודומה לדוגמה הבאה:

{
  "evtJwtDecodedPayload": {
    "cnf": {
      "jwk": {
        "crv": "Ed25519",
        "kty": "OKP",
        "x": "pUbLiCkEy123pUbLiCkEy123pUbLiCkEy123"
      }
    },
    "email": "demo@gmail.com",
    "email_verified": true,
    "iat": 1782911685,
    "iss": "https://accounts.google.com"
  },
  "kbJwtDecodedPayload": {
    "aud": "https://example.com",
    "iat": 1782911685,
    "nonce": "rAnDoM123rAnDoM123rAnDoM123rAnDoM123",
    "sd_hash": "hAsH456hAsH456hAsH456hAsH456hAsH456"
  }
}

2. אימות הערכים הצפויים

בודקים שהערכים הבסיסיים במטען הייעודי (payload) תואמים לערכים שסיפקתם:

  • מוודאים שההגדרה email_verified היא true.
  • מוודאים שכתובת האימייל email זהה לכתובת האימייל שצוינה בטופס.
  • מוודאים שהערך של nonce זהה לערך של ה-nonce שצוין בטופס.
  • מוודאים שהערך aud תואם למקור של האתר.
  • מוודאים שלרכיב iat יש חותמת זמן עדכנית יחסית, למשל אחרי שהטופס עבר עיבוד.

3. אימות של שיוך המקשים

הדפדפן יוצר מפתח זמני וחולף לעסקה כדי לאשר שהוא חתם על הטוקן. מחלקים את המפתח הזה מהתביעה cnf (אישור) ב-EVT ואז משתמשים בו כדי לאמת את ה-JWT שקשור למפתח.

לאחר מכן, מחשבים את הגיבוב הצפוי ומשווים אותו לטענת זכויות היוצרים sd_hash. בדוגמה הבאה ל-Node.js אפשר לראות איך לבצע את החישוב הזה:

const calculatedHash = createHash("sha256")
        .update(evtJwt + "~")
        .digest("base64url");

4. אימות רשומת DNS

מאמתים את רשומת ה-DNS _email-verification של הדומיין של כתובת האימייל. לדוגמה, כדי לראות את הרשומה TXT של demo@gmail.com, מריצים שאילתה על _email-verification.gmail.com. עבור הספק הזה, השאילתה מחזירה את המיקום של ספק החשבון, כלומר accounts.google.com.

$ dig +short TXT _email-verification.gmail.com
"iss=accounts.google.com"

5. איתור המנפיק ואימות החתימה של EVT

מוודאים שהמנפיק משרת את משאב /.well-known/email-verification, שמספק את נקודות הקצה להנפקת האסימון, את מפתח האינטרנט מסוג JSON ‏ (JWK) לאתר ואת אלגוריתמי החתימה הנתמכים.

$ curl https://accounts.google.com/.well-known/email-verification
{
  "issuance_endpoint": "https://accounts.google.com/gsi/email-verification/issue",
  "jwks_uri": "https://verifiablecredentials-pa.googleapis.com/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA"]
}

משתמשים ב-JWK כדי לאמת את ה-JWT של ה-EVT שחולץ מהטוקן. רוב הספריות של JOSE מספקות פונקציות לטיפול באימות הזה.

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

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

לפרטים נוספים, אפשר לעיין בקוד ההדגמה של ספק אימייל מדומה ובהצעות לEmail Verification API ולEmail Verification Protocol.

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

הגדרת גילוי המוסד המנפיק

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

הגדרת רשומת הפניה של DNS

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

פורמט הרשומה: _email-verification.<email-domain>

קובץ אזור לדוגמה:

_email-verification.example.com IN TXT "iss=accounts.issuer.example"

אירוח נקודת קצה של .well-known/email-verification

מארחים קובץ מטא-נתונים בפורמט JSON בדומיין של הגורם המנפיק בנתיב /.well-known/. בקובץ הזה מפורטות היכולות שלכם להנפקת אישורים והאלגוריתמים הקריפטוגרפיים לחתימה שהתשתית שלכם תומכת בהם.

נקודת קצה: https://<issuer-domain>/.well-known/email-verification

דוגמה לתגובה:

{
  "issuance_endpoint": "https://accounts.issuer.example/email-verification/issuance",
  "jwks_uri": "https://accounts.issuer.example/.well-known/vc-public-jwks",
  "signing_alg_values_supported": ["EdDSA", "ES256"]
}

אירוח נקודת קצה של .well-known/web-identity

משאב נוסף בפורמט JSON שאולי כבר הטמעתם כחלק מ-Federated Credentials (FedCM) API..well-known הקישור הזה מוביל לנקודת הקצה של החשבונות ולכתובת ה-URL להתחברות.

נקודת קצה: https://<domain>/.well-known/web-identity

דוגמה לתגובה:

{
  "accounts_endpoint": "https://accounts.issuer.example/accounts",
  "login_url": "https://accounts.issuer.example/login"
}

שימוש בנקודת קצה של חשבונות

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

נקודת קצה: כפי שמצוין ב-.well-known/web-identity

דוגמה לתגובה:

{
  "accounts": [
    {
      "id": "demo-example",
      "name": "Demo User",
      "email": "demo@example.com",
      "given_name": "Demo"
    }
  ]
}

שילוב עם Login Status API

המשתמש צריך להיות מחובר לספק בסשן פעיל, ואתם צריכים לשלוח אות לדפדפן באמצעות Login Status API.

כשמשתמש נכנס לחשבון או יוצא ממנו בהצלחה, צריך להציג את כותרת תגובת ה-HTTP התואמת:

Set-Login: logged-in
Set-Login: logged-out

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

navigator.login.setStatus("logged-in");
navigator.login.setStatus("logged-out");

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

הבקשה עם request_token נשלחת אל issuance_endpoint application/x-www-form-urlencoded POST.

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

1. אימות בקשת ההנפקה

ניתוח ואימות של מטענים ייעודיים (payloads) שמגיעים מהדפדפן:

  • שיטה: POST
  • אימות סשן: אימות קובצי ה-Cookie מאינטראקציה ישירה של המשתמש session/authentication שמועברים יחד עם הבקשה, כדי לוודא שקיים הקשר פעיל ומורשה של זהות.
  • אימות הפרמטר: חילוץ הפרמטר request_token (JWT חתום שנוצר על ידי הדפדפן). מוודאים שהיא מכילה את המפתח הציבורי הזמני הצפוי, את כתובת האימייל של היעד, את הקהל הנכון ואת חותמת הזמן התקינה.

האסימון המפוענח אמור להיראות כך:

{
  "decodedHeader": {
    "alg": "ES256",
    "typ": "JWT",
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "decodedPayload": {
    "iss": "https://accounts.issuer.example",
    "sub": "demo@example.com",
    "email": "demo@example.com",
    "iat": 1780272000,
    "exp": 1780272300
  },
  "signature": "SIGnatURE-123_SIGnatURE-123_SIGnatURE-123"
}

2. תשובה באמצעות אסימון

אחרי אימות מוצלח של הסשן ואסימון הבקשה, יוצרים JWT חתום של חשיפה סלקטיבית (SD-JWT) באמצעות מטען הייעודי (payload):

{
  "iss": "https://accounts.issuer.example",
  "iat": 1780272000,
  "exp": 1780272300,
  "cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "pUbLiCKeY123pUbLiCKeY123pUbLiCKeY123",
      "y": "pUbLiCKeY456pUbLiCKeY456pUbLiCKeY456"
    }
  },
  "email": "demo@example.com",
  "email_verified": true
}

חותמים על מטען הייעודי (payload) באמצעות המפתח הפרטי ואלגוריתם נתמך. לדוגמה, שימוש ב-jose ב-Node.js:

const evtJwt = await new SignJWT(evtPayload)
   .setProtectedHeader({
     alg: "EdDSA",
     kid: PRIVATE_KEY_JWK.kid, // Key ID corresponding to our JWKS keys
     typ: "evt+jwt", // Standard Token Type for EVTs
   })
   .sign(privateKey);

 // Standard SD-JWT compatibility requires appending a trailing tilde "~"
 // to separate the signed token from the key binding section.
 const issuanceToken = `${evtJwt}~`;

דוגמה לתגובה מוצלחת (HTTP 200):

{
  "issuance_token": "tOkEn123tOkEn123tOkEn123...~"
}

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

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

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

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

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

נפרסם עדכונים נוספים בבלוג כאן וברשימת התפוצה evp-announce@chromium.org ככל שהפיתוח יתקדם.