ממשק ה-API לאימות כתובת אימייל הוא הצעה שמאפשרת לדפדפן לתקשר ישירות עם ספק האימייל כדי לאמת שהמשתמש הוא הבעלים של כתובת האימייל. המשתמשים מזינים את כתובת האימייל שלהם, שולחים את הטופס והאתר מאמת את אסימון האימות של האימייל החתום מהדפדפן מול הספק, בלי לשלוח אימייל או להפריע לתהליך של המשתמש.
בדרך כלל, כשאתרים אוספים כתובת אימייל במהלך הרשמה, כניסה, תשלום, הרשמה לניוזלטר או שחזור חשבון, הם מאשרים שהאדם ששולח את הטופס הוא הבעלים של הכתובת. שיטות האימות הקיימות מחייבות את המשתמשים לצאת מהאתר, לעבור לאפליקציה אחרת כדי לבדוק את תיבת הדואר הנכנס, להעתיק קוד OTP או ללחוץ על קישור אימות. השיבוש הזה מגדיל את שיעור הנטישה ואת שיעור ההפסקות של סשנים, גם אצל משתמשים אנושיים וגם אצל סוכנים אוטומטיים. למשתמשים יש לעיתים קרובות בעיות עם שיטות האימות הקיימות, כמו אימיילים שמתקבלים באיחור, קישורים שתוקפם פג או קודים לא מזוהים.
אימות כתובת האימייל פועל כשיפור הדרגתי לתהליך הקיים:
- ללא הפרעה: האימות מתבצע ברקע בזמן שהמשתמש ממלא את הטופס.
- אין צורך בזיהוי תכונות: האתרים מוסיפים לטפסים שלהם שדה להזנת כתובת אימייל ושדה להזנת טוקן מוסתר. אם הדפדפן או הספק לא תומכים באימות אימייל, או אם האימות נכשל, האתר חוזר לתהליך אישור האימייל שמוגדר כברירת מחדל.
- צמצום הסיכון לפישינג: אין קוד להעתקה או אפשרות לשלוח את המשתמש לאתר מזויף.
קישורים שימושיים
- Email Verification API ב-GitHub
- פרוטוקול לאימות אימייל ב-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.
מונחי מפתח
המונחים העיקריים שקשורים ל-Email Verification API הם:
- מאמת: האתר שאוסף את כתובת האימייל ורוצה לאמת אותה. הגורם המאמת נקרא גם Relying Party.
- ספק האימייל: השירות שמספק את כתובת האימייל של המשתמש, לדוגמה
gmail.com. - Issuer: השירות שמנהל את החשבון של כתובת האימייל של המשתמש, לדוגמה
accounts.google.com. המנפיק נקרא גם ספק הזהויות.
במקרים מסוימים, ספק האימייל והגורם המנפיק פועלים מאותו דומיין.
עם זאת, חשוב להבחין ביניהם כי ה-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-verificationjwks_uri. - אימות EVT והשלמה: הצד המסתמך מאמת את החתימה של המנפיק
EVTבאמצעות המפתח הציבורי של הספקJWKS. אם לא מתקבל טוקן או אם אחד משלבי האימות נכשל, האתר חוזר לתהליך אימות האימייל הקיים שלו.
בפעם הראשונה שמשתמש מאמת כתובת אימייל, Chrome מציג בקשת הרשאה (תיבת דו-שיח במחשב או גיליון תחתון ב-Android) לפני שהוא מבקש טוקן. אם ההרשאה ניתנת, היא נשמרת לכל כתובת אימייל בכל האתרים שמשתתפים בתכונה.
הגדרות Chrome
המשתמשים יכולים לנהל את כתובות האימייל המאומתות שלהם:
- במחשב, בקטע הגדרות > מילוי אוטומטי וסיסמאות > פרטים ליצירת קשר > אימייל מאומת (או פותחים את
chrome://settings/contactInfo) - ב-Android, בקטע הגדרות > כתובות ועוד > אימייל מאומת
המשתמשים יכולים להשבית לגמרי את התכונה או לנהל כתובות אימייל מאומתות ספציפיות.
שיקולים לגבי תרחישי שימוש
אימות כתובת אימייל הוא שיפור הדרגתי של התהליך הקיים, שמאפשר למשתמש לקבל קוד אימות חד-פעמי או ללחוץ על קישור בלי לצאת מהאתר. אתרים יכולים להוסיף את השדות של אימות כתובת האימייל לכל הטפסים הרלוונטיים, כמו טפסים של כניסה לחשבון, הרשמה לניוזלטר, יצירת חשבון ושחזור סיסמה. הפעלת EVP מתבצעת רק אם הדפדפן תומך בה. אם לא מתקבל קוד אחרי השליחה או אם אחד משלבי האימות נכשל, אפשר לחזור לתהליך אימות האימייל שמוגדר כברירת מחדל. זה גם אומר שאין זיהוי תכונות עבור ה-API; האתר המאמת מתייחס ל-EVT כאופציונלי, ומעבד אותו אם הוא קיים בבקשה.
אימות האימייל מאשר שלמשתמש יש סשן פעיל אצל הספק של כתובת האימייל שלו. האימות לא בודק אם האימייל הגיע למשתמש. יכול להיות שעדיין תרצו לשלוח אימיילים קיימים של קבלת פנים או של צירוף משתמשים, ואולי תרצו או תצטרכו לבקש מהמשתמש לבדוק את הגדרות הספאם שלו.