Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

이메일 인증 업데이트(2026년 8월)

Rowan Merewood

게시일: 2026년 8월 13일, 최종 업데이트: 2026년 10월 5일

이메일 인증 오리진 트라이얼은 Chrome 150에서 시작되었습니다. 보내주신 의견을 바탕으로 여러 가지 수정사항과 개선사항을 적용했습니다. 이 게시물에서는 변경사항과 사이트 또는 서비스에서 취해야 할 조치를 간략하게 설명합니다.

먼저 이메일 인증 기능에 대해 간략히 살펴보겠습니다 (자세한 내용은 이전 공지사항 참고). 사이트의 일반적인 패턴은 사용자가 가입, 로그인, 계정 복구 등의 과정에서 이메일 주소를 입력한 다음 이메일로 이동하여 매직 링크를 클릭하거나 OTP를 획득해야 하는 것입니다. 이메일 인증은 브라우저에서 직접 제공업체와 이메일 주소를 인증하여 이보다 점진적으로 개선된 기능을 제공합니다. 그러면 사이트에서 이메일 제공업체로 확인할 수 있는 토큰을 브라우저로부터 수신하여 해당 이메일 전송을 완전히 건너뜁니다.

사용자 대상 업데이트

사용자 인터페이스 또는 사용자 대상 동작의 변경사항

이메일 입력

이전에는 사용자가 자동 완성 또는 자동 입력을 사용하여 이메일 주소를 입력해야 했습니다. 이제 사용자가 input 요소를 종료하면 (예: 입력 또는 붙여넣기) change 이벤트와 마찬가지로 필드에 이메일 주소를 입력하는 즉시 확인 프로세스가 트리거됩니다. 즉, 이메일 주소를 입력하면 이메일 인증이 효과적으로 트리거되어야 합니다.

진행 상태 표시기

Chrome 152 이상에서는 인증 프로세스의 진행률 표시기도 테스트하고 있습니다. 인증 프로세스는 빠르지만 프로세스가 완료되기 전에 사용자가 양식을 제출할 수도 있습니다. 진행률 표시기는 확인하는 동안 스피너를 표시하고 완료되면 입력 필드의 인라인 끝 (LTR 언어의 경우 오른쪽)에 체크표시를 표시합니다.

이로 인해 문제가 발생하거나 예상치 못한 동작이 표시되면 버그를 신고하세요.

데스크톱 전용

이메일 인증은 데스크톱에서만 사용할 수 있으며 Chrome 152까지만 지원됩니다. Android 지원도 적극적으로 검토하고 있으며 향후 업데이트를 제공할 예정입니다.

인증자 업데이트

이메일을 수집하고 인증하는 사이트의 변경사항

토큰 검증

이메일 인증 토큰은 JSON 웹 토큰의 선택적 공개 (SD-JWT) 형식으로 제공됩니다. 원시 형식은 다음과 같습니다. 발급기관 서명 JWT가 0개 이상의 공개 정보로 이어지고 물결표로 구분된 각 구성요소와 함께 키 바인딩 JWT로 끝납니다.

<Issuer-signed JWT>~<Disclosure.1>~<Disclosure.2>~...~<Disclosure.N>~<Key Binding JWT>

현재 형태의 이메일 인증 토큰은 공개 정보가 포함되지 않은 발급자 서명 JWT와 키 바인딩 JWT만 반환합니다. 원래 블로그 게시물과 데모의 첫 번째 반복에서는 토큰을 두 개로 분할하고 두 개의 JWT를 파싱했습니다. 이는 취약하며 향후 선택적 공개가 추가되면 중단됩니다.

현재 제안의 이 기능을 사용하는 대신 플랫폼용 라이브러리를 사용하여 사양에 따라 SD-JWT 토큰을 올바르게 파싱하도록 구현해야 합니다. 예를 들어 이제 데모 인증 코드는 @sd-jwt/core를 사용하여 토큰을 파싱하고 키 바인딩 (대상, nonce, 해시)을 검증한 다음 jose를 사용하여 발급자의 EVT와 브라우저의 키 바인딩 JWT의 서명을 검증합니다.

서드 파티 오리진 트라이얼

8월부터 이메일 인증에는 서드 파티 오리진 트라이얼이 지원되지 않습니다. 서드 파티 오리진 트라이얼을 사용하면 서드 파티 오리진이 포함된 사이트(예: 교차 출처 JavaScript 종속 항목)에서 트라이얼 기능을 사용 설정할 수 있습니다. 이 문제가 사용 사례에서 우선순위가 높다면 추적 버그에 댓글을 달거나 팔로우하세요.

대소문자를 구분하지 않는 이메일 비교

이메일 제공업체는 양식에 demo.user@example.com이 제공된 경우에도 대문자가 포함된 표준 이메일 주소(예: Demo.User@example.com)를 반환할 수 있습니다. 수신된 이메일 주소와 대소문자를 구분하지 않는 비교를 수행해야 합니다. 설정 페이지에서 동일한 이메일 주소의 대소문자 변형이 표시될 수 있는 버그도 수정되었습니다.

제공업체 업데이트

이메일 제공업체 변경사항

발급 요청의 HTTP 메시지 서명

Chrome 153에서는 HTTP 메시지 서명과 함께 application/json 형식의 email만 전송하는 발급 요청이 도입됩니다.

Chrome 152 이하: 발급 엔드포인트는 본문에 request_token이 포함된 application/x-www-form-urlencoded POST 요청을 수신합니다.
Chrome 153 이상: 콘텐츠 유형이 Signature, Signature-Input, Signature-Key 헤더와 email 키만 포함하는 본문이 있는 application/json로 변경됩니다.

현재 트래픽 수준과 테스트 목표에 따라 다음 중 하나를 선택할 수 있습니다.

두 형식을 모두 지원하고 콘텐츠 유형에 따라 전환합니다. 8월 말에 Chrome 153이 안정화 버전에 도달하면 트래픽을 평가하여 기존 기능을 삭제할 수 있습니다.
새 형식으로 전환하면 이전 버전의 Chrome 사용자의 인증이 실패합니다.

데모 코드의 발급 엔드포인트가 structured-headers 및 http-message-sig를 사용하여 두 흐름을 모두 처리하도록 업데이트되었습니다.

전체 요청 형식:

POST /email-verification/issuance HTTP/1.1
Host: provider.example
Accept: application/json
Content-Digest: sha-256=:aBc123aBc123aBc123aBc123aBc123=:
Content-Type: application/json
Signature: sig=:+dEf567dEf567/dEf567dEf567dEf567/dEf567==:
Signature-Input: sig=("@method" "@authority" "@path" "content-digest" "signature-key");created=1786455840
Signature-Key: sig=hwk;crv="Ed25519";kty="OKP";x="gHi890_gHi890_gHi890"

{email: "demo@example.com"}

응답 형식은 application/json 본문의 issuance_token로 동일하게 유지됩니다.

WICG/email-verification 및 dickhardt/email-verification 제안 저장소에서 추가 의견을 읽고 제출할 수 있습니다. 지금까지 커뮤니티의 반응은 매우 유용했으며, 앞으로도 업데이트와 개선이 계속될 것으로 예상됩니다.