Aktualizacje dotyczące potwierdzania adresu e-mail, październik 2026 r.

Rowan Merewood

Opublikowano: 5 października 2026 r.

W ramach testu origin weryfikacji adresu e-mail wprowadziliśmy kolejne zmiany na podstawie Waszych opinii. Nie przewidujemy dalszych zmian powodujących niezgodność i przygotowujemy się do udostępnienia tej funkcji. Udostępniliśmy też nową sekcję dokumentacji dotyczącą weryfikacji adresu e-mail, która zawiera osobne sekcje dla weryfikatorów i wydawców.

Wersja próbna origin weryfikacji adresu e-mail rozpoczęła się w Chrome 150 na komputerach. Na podstawie opinii deweloperów i testów w całym ekosystemie nadal udoskonalamy wdrożenie. Ten post zawiera informacje o aktualizacjach w Chrome 154, w tym o obsłudze Androida, testach origin innych firm, obsłudze wykrywania kluczy podczas weryfikacji tokena i aktualizacji nagłówka dla dostawców poczty e-mail.

Aktualizacje widoczne dla użytkowników

zmiany interfejsu lub zachowania widocznego dla użytkownika;

Obsługa Chrome na Androida

Od wersji 154 Chrome na Androida obsługuje potwierdzanie adresu e-mail. Weryfikatorzy ani dostawcy nie muszą wprowadzać żadnych zmian, ponieważ interfejs API ani protokół pozostają bez zmian. Obowiązują te same wymagania wstępne, w tym wymóg zalogowania się użytkownika w przeglądarce u dostawcy poczty e-mail.

Użytkownicy mogą uzyskać dostęp do swoich ustawień w sekcji Ustawienia > Adresy i inne informacje > Zweryfikowany adres e-mail.

Aktualizacje dotyczące weryfikatora

Zmiany w przypadku witryn, które zbierają i weryfikują adresy e-mail.

Testy pochodzenia zewnętrznego

Od Chrome w wersji 154 testy pochodzenia innych firm są obsługiwane w przypadku weryfikacji adresu e-mail (zobacz problem 534377131). Jeśli udostępniasz osadzony skrypt lub pakiet SDK do obsługi tożsamości, możesz zarejestrować się, aby otrzymać token próbny podmiotu zewnętrznego, i wstrzyknąć go do stron, na których znajduje się Twój skrypt. Witryny, które osadzają Twój skrypt, nie muszą rejestrować osobnych tokenów testowania origin.

Jest jednak ważny warunek: osoba rejestrująca testowanie origin i wydawca muszą być powiązani z tą samą witryną. W szczególności źródło zarejestrowane w okresie próbnym musi być zgodne z domeną wystawcy.

Obsługiwana konfiguracja:

  • Domena wystawcy: issuer.example
  • Rejestrujący OT: https://issuer.example
  • Źródło JavaScript: https://issuer.example (lub https://app.issuer.example z dopasowywaniem subdomen)

Nieobsługiwane konfiguracje:

  • Abonent subdomeny: domena wydawcy to issuer.example, ale abonent OT to https://app.issuer.example.
  • Abonent w wielu witrynach: domena wydawcy to issuer.example, ale abonent OT to https://different.example.

Obsługa opcjonalnego parametru kid w EVT

Podczas weryfikacji tokena weryfikacji adresu e-mail (EVT) serwer pobiera zestaw kluczy internetowych JSON (JWKS) dostawcy, aby zweryfikować podpis kryptograficzny wystawcy. Klucze mogą opcjonalnie zawierać kid identyfikator klucza, który również może być opcjonalnie uwzględniony w tokenie JWT, aby wskazywać, którego klucza użyto do podpisania tokena. Jeśli token nie zawiera roszczenia kid (np. w przypadku Gmaila), iteruj klucze, aby znaleźć właściwy. Dokumentacja i wersja demonstracyjna zawierają kod, który to umożliwia.

Zwracanie roszczenia email w dokładnie takiej postaci, w jakiej zostało ono przesłane.

Od Chrome 156 adres e-mail w tokenie będzie zwracany dokładnie tak, jak został podany w formularzu (zobacz problem 549217427). Wcześniej wydawcy mogli zwracać kanoniczny adres e-mail konta (np. zwracać First.Last@example.com, gdy przesłany formularz zawierał first.last@example.com). Pamiętaj, że zawsze warto używać porównania zwracanego adresu e-mail bez uwzględniania wielkości liter, więc nie powinno to być zmiana powodująca problemy.

Aktualizacje dostawców

Zmiany dla dostawców poczty e-mail.

Zwracanie roszczenia email w dokładnie takiej postaci, w jakiej zostało ono przesłane.

Wymagania po stronie dostawcy są bardziej rygorystyczne: jeśli dostawca nie zwróci e-maila w dokładnie takiej samej postaci, w jakiej został on podany, Chrome odrzuci token. Dzięki temu unikniesz ujawnienia większej ilości danych niż w przypadku wysłania e-maila z potwierdzeniem. Sprawdź, czy przychodzący e-mail pasuje do zalogowanego użytkownika w taki sam sposób, w jaki obsługujesz dostarczanie e-maili.

Zmieniam nazwę Sec-Fetch-Dest na email-verification

Od Chrome 154 nagłówek Sec-Fetch-Dest wysyłany w żądaniach wydania tokena został zaktualizowany i zawiera myślnik:

  • Chrome 154 lub nowszy: Sec-Fetch-Dest: email-verification
  • Chrome 153: Sec-Fetch-Dest: emailverification

Ta zmiana ujednolica identyfikator miejsca docelowego pobierania z konwencjami nazewnictwa platformy internetowej (patrz problem 546618576).

Jeśli punkt końcowy wydawania weryfikuje nagłówek Sec-Fetch-Dest (zalecane w celu ochrony przed CSRF i niezamierzonymi kontekstami żądań), zaktualizuj sprawdzanie, aby akceptować email-verification. Aby uniknąć zakłócenia działania podczas wdrażania przeglądarek, w okresie przejściowym akceptuj obie wartości.

Zasoby i opinie