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

Rowan Merewood

פורסם: 8 ביולי 2026, עודכן לאחרונה: 5 באוקטובר 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". האתר צריך לספק ערך חד-פעמי ייחודי שקשור לסשן כדי לאמת את שליחת הטופס.
  • מגדירים את autocomplete="email-verification-token". הדפדפן משתמש במאפיין הזה כדי לזהות את השדה שצריך למלא.

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

{
  "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

מאמתים את _email-verification רשומת ה-DNS של הדומיין של כתובת האימייל. לדוגמה, בשביל demo@gmail.com, מבצעים שאילתה ברשומה _email-verification.gmail.com TXT. עבור הספק הזה, השאילתה מחזירה את המיקום של ספק החשבון, כלומר 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.

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

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

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

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

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

אירוח נקודת קצה (endpoint) של .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"]
}

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

.well-known משאב נוסף בפורמט JSON שאולי כבר הטמעתם כחלק מ-Federated Credentials (FedCM) API. הקישור הזה מוביל לנקודת הקצה של החשבונות ולכתובת ה-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");

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

מכשיר issuance_endpoint מקבל בקשת application/x-www-form-urlencoded POST שכוללת את request_token.

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

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

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

  • שיטת המשלוח: 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, צריך לדווח על באג ברכיב:

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

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

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