ממשק ה-API לאימות כתובת אימייל הוא הצעה שמאפשרת לדפדפן לתקשר ישירות עם ספק האימייל כדי לאמת שהמשתמש הוא הבעלים של כתובת האימייל. המשתמשים מזינים את כתובת האימייל שלהם, שולחים את הטופס והאתר מאמת את אסימון האימות של האימייל החתום מהדפדפן מול הספק, בלי לשלוח אימייל או להפריע לתהליך של המשתמש.
כשאתם אוספים כתובת אימייל במהלך הרשמה, כניסה, תשלום, הרשמה לניוזלטר או שחזור חשבון, האתרים בדרך כלל מאשרים שהאדם ששולח את הטופס שולט בכתובת. בשיטות האימות הקיימות, המשתמשים צריכים לצאת מהאתר, לעבור לאפליקציה אחרת כדי לבדוק את תיבת הדואר הנכנס, להעתיק סיסמה חד-פעמית או ללחוץ על קישור לאימות. השיבוש הזה מגדיל את שיעור הנטישה של משתמשים אנושיים ושל סוכנים אוטומטיים. הרבה פעמים המשתמשים נתקלים בבעיות בשיטות האימות הקיימות, כמו אימיילים שמתעכבים, קישורים שפג תוקפם או קודים לא מזוהים.
אימות אימייל פועל כשיפור הדרגתי (progressive enhancement) לתהליך הקיים:
- בלי הפרעות: האימות מתבצע ברקע בזמן שהמשתמש ממלא את הטופס.
- לא נדרש זיהוי תכונות: האתרים מוסיפים לטפסים שלהם שדה להזנת כתובת אימייל ושדה להזנת טוקן מוסתר. אם הדפדפן או הספק לא תומכים באימות כתובת אימייל, או אם האימות נכשל, האתר חוזר לתהליך אישור האימייל שמוגדר כברירת מחדל.
- מזעור הסיכונים לפישינג: בלי צורך בקוד להעתיק או הזדמנות לשלוח את המשתמש לאתר מזויף.
קישורים שימושיים
- מפרט Email Verification API (WICG) (מאגר ב-GitHub)
- טיוטת אינטרנט של פרוטוקול אימות אימייל (IETF) (מאגר GitHub)
- אימות אימייל בסטטוס הפלטפורמה של Chrome
- הרשמה לגרסת מקור לניסיון של אימות אימייל
אתם יכולים לבדוק את התהליך בהדגמה:
- הדגמה של מנפיק: מספקת חשבון אימייל מדומה וסשן מחובר.
- אימות הדגמה: מאמתים את כתובת האימייל להדגמה או כל כתובת אימייל של ספק שמשתתף בתוכנית.
שיקולים לגבי גרסת מקור לניסיון
גרסאות מקור לניסיון הן ניסויים לאיסוף משוב, ולכן המשוב שלכם הוא קריטי אם אתם משתתפים כגורם מסתמך או כספק זהויות. כדי לדווח על בעיות, אפשר להשתמש במאגרי GitHub הבאים:
- Browser Email Verification API: WICG/email-verification
- פרוטוקול לאימות אימייל: dickhardt/email-verification
אם נתקלתם בבאגים בהטמעה של Chrome, אתם יכולים לדווח על הבעיה ברכיב הבא:
אתם שולטים בפונקציונליות של גרסת מקור לניסיון על בסיס כל תגובה, על ידי הכללה של הטוקן של גרסת מקור לניסיון. כך אתם יכולים להגביל את התכונה לפלח ספציפי של משתמשים, כמו אוכלוסיית בדיקת A/B. לחלופין, אם יש לכם קבוצת משתמשים לבדיקת בטא או לגרסת טרום-השקה מוקדמת, יכול להיות שתרצו או תצטרכו להפעיל את התכונה בשבילם. במקרה כזה, צריך לבדוק את כתובת האימייל שסופקה לפני הנפקת הטוקן או אימותו.
בנוסף, יש לגרסאות מקור לניסיון מגבלות תנועה כדי לצמצם את מספר האתרים שמסתמכים על התכונה לפני ההשקה שלה. ממשק ה-API של המנפיק נמצא בפיתוח, וצפויים שינויים שלא תואמים לדורות קודמים, וגם עדכונים לחוויית המשתמש ב-Chrome.
ככל שהפיתוח יתקדם, נפרסם עדכונים נוספים בבלוג הזה וברשימת התפוצה evp-announce@chromium.org.
תהליך אימות האימייל
בקטעים הבאים מוסברים המונחים העיקריים והשלבים בפרוטוקול כשמשתמשים ב-Email Verification API.
מונחי מפתח
מונחי מפתח ל-API של אימות אימייל:
- הגורם המאמת: האתר שאוסף את כתובת האימייל ורוצה לאמת אותה. הגורם המאמת נקרא גם Relying Party.
- ספק אימייל: השירות שמספק את כתובת האימייל של המשתמש, לדוגמה
gmail.com. - Issuer: השירות שמנהל את החשבון של כתובת האימייל של המשתמש, לדוגמה
accounts.google.com. המנפיק נקרא גם ספק הזהויות.
במקרים מסוימים, ספק האימייל והגורם המנפיק פועלים מאותו דומיין.
עם זאת, חשוב להבחין ביניהם כי Email Verification API משתמש בסשן הפעיל בדפדפן עם ספק הזהויות כשיטת האימות. לדוגמה, כדי לאמת את example@gmail.com, המשתמש צריך להיכנס אל google.com באמצעות החשבון הזה באותו דפדפן.
תהליך הפרוטוקול
- הצגת הטופס: הצד המסתמך מציג טופס HTML שמכיל
<input type="email">וקלט מוסתר שמסומן ב-autocomplete="email-verification-token"וב-nonceייחודי לכל מופע. - הזנת אימייל: כשהמשתמש מזין כתובת אימייל – על ידי בחירה בהצעה למילוי אוטומטי או על ידי הקלדה או הדבקה ויציאה מהשדה (
blur) – הדפדפן מפעיל אימות ברקע. - גילוי וסשן: הדפדפן שולח שאילתה לרשומת ה-DNS TXT של
_email-verification.<email-domain>כדי לגלות את מקור הנפקת ההרשאה של הספק, ואז בודק אם למשתמש יש סשן פעיל באמצעות ההגדרה של.well-known/web-identityונקודות הקצה של חשבונות FedCM. אם הדומיין לא מפרסם רשומת EVP או שלא קיים סשן פעיל, הדפדפן מפסיק את האימות בלי להציג למשתמש בקשה. - הנפקת אסימון: הדפדפן מגלה את הספק
issuance_endpointמתוך.well-known/email-verification, יוצר צמד מפתחות זמני ושולח בקשת HTTPPOSTבאמצעות חתימות HTTP על הודעות (RFC 9421) עם קובצי ה-Cookie של הסשן של הצד הראשון של המנפיק וכתובת האימייל של היעד כדי לקבל אסימון אימות אימייל חתום (EVT). - קישור מפתחות ושליחה: הדפדפן מקשר את ה-
EVTהחתום למקור של הצד המסתמך ולטופסnonceבתוך JWT לקישור מפתחות (KB-JWT), ומציג התראה קטנה שמודיעה למשתמש שספק האימייל שלו אימת את הכתובת שלו. כשהמשתמש שולח את הטופס, Chrome מאכלס את הקלט המוסתר בטוקן המשולב (<EVT>~<KB-JWT>). - אימות הטענות ו-KB: שרת הצד המסתמך מנתח את אסימון
<EVT>~<KB-JWT>, מאמת את הטענות הצפויות (email,email_verified,aud,nonce,iatו-exp) ומאמת את חתימת הקישור של המפתח מול המפתח הציבורי הזמני ב-cnf.jwk. - DNS ומפתחות ציבוריים: הצד המסתמך שולח שאילתה לרשומת ה-TXT ב-DNS של
_email-verification.<email-domain>כדי לוודא שהיא תואמת להצהרהissשל האסימון, ואז מאחזר את המטא-נתונים והמפתחות הציבוריים של המנפיק מ-.well-known/email-verificationב-jwks_uri. - אימות ה-EVT והשלמת התהליך: הצד המסתמך מאמת את החתימה של המנפיק
EVTבאמצעות המפתח הציבורי של הספקJWKS. אם לא מתקבל טוקן או אם אחד משלבי האימות נכשל, האתר חוזר לתהליך אישור האימייל הקיים שלו.
בפעם הראשונה שמשתמש מאמת כתובת אימייל, Chrome מציג בקשת הרשאה (תיבת דו-שיח במחשב או גיליון תחתון ב-Android) לפני שהוא מבקש טוקן. אם ההרשאה ניתנת, היא נשמרת לכל כתובת אימייל באתרים המשתתפים.
הגדרות Chrome
המשתמשים יכולים לנהל את כתובות האימייל המאומתות שלהם:
- במחשב, בקטע הגדרות > מילוי אוטומטי וסיסמאות > פרטים ליצירת קשר > אימייל מאומת (או פותחים את
chrome://settings/contactInfo) - ב-Android, בקטע הגדרות > כתובות ופרטים נוספים > כתובת אימייל מאומתת
המשתמשים יכולים להשבית את התכונה לגמרי או לנהל כתובות אימייל מאומתות ספציפיות.
שיקולים לגבי תרחישי שימוש
אימות אימייל הוא שיפור הדרגתי (progressive enhancement) לתהליך הקיים, שמונע את הצורך של המשתמשים לצאת מהאתר כדי לאחזר סיסמה חד-פעמית או ללחוץ על קישור. אתרים יכולים להוסיף את השדות של אימות כתובת האימייל לכל הטפסים הרלוונטיים, כמו טפסים של כניסה לחשבון, הרשמה לניוזלטר, יצירת חשבון ושחזור סיסמה. EVP מופעל רק אם הדפדפן תומך בו. אם לא מתקבל קוד אחרי השליחה או אם אחד משלבי האימות נכשל, אפשר לחזור לתהליך ברירת המחדל של אישור האימייל. זה גם אומר שאין זיהוי תכונות ל-API. אתר האימות מתייחס ל-EVT כאופציונלי, ומעבד אותו אם הוא נמצא בבקשה.
אימות אימייל מאשר שלמשתמש יש סשן פעיל אצל ספק כתובת האימייל שלו. האימות לא בודק אם האימייל הגיע למשתמש. יכול להיות שעדיין תרצו לשלוח אימיילים קיימים של קבלת פנים או של צירוף משתמשים, ואולי תרצו או תצטרכו לבקש מהמשתמש לבדוק את הגדרות הספאם שלו.