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

이메일 확인

이메일 인증 API는 브라우저가 이메일 제공업체와 직접 통신하여 사용자가 이메일 주소를 소유하고 있는지 확인할 수 있도록 하는 제안입니다. 사용자가 이메일을 입력하고 양식을 제출하면 사이트에서 이메일을 보내거나 사용자의 흐름을 중단하지 않고 브라우저에서 서명된 이메일 확인 토큰을 제공업체와 함께 확인합니다.

가입, 로그인, 결제, 뉴스레터 구독 또는 계정 복구 중에 이메일 주소를 수집할 때 사이트에서는 일반적으로 양식을 제출하는 사람이 주소를 관리하는지 확인합니다. 기존 확인 방법에서는 사용자가 사이트를 떠나 앱을 전환하여 받은편지함을 확인하고 OTP를 복사하거나 확인 링크를 클릭해야 합니다. 이러한 중단으로 인해 실제 사용자와 자동화된 에이전트 모두의 이탈률과 세션 포기율이 증가합니다. 사용자는 이메일 지연, 링크 만료, 인식되지 않는 코드와 같은 기존 인증 방법에서 불편함을 느끼는 경우가 많습니다.

이메일 인증은 기존 흐름을 점진적으로 개선하는 역할을 합니다.

중단 없음: 사용자가 양식을 작성하는 동안 백그라운드에서 인증이 진행됩니다.
기능 감지 불필요: 사이트에서 이메일 입력과 숨겨진 토큰 입력을 양식에 추가합니다. 브라우저 또는 제공업체에서 이메일 확인을 지원하지 않거나 확인에 실패하면 사이트가 기본 이메일 확인 흐름으로 대체됩니다.
피싱 위험 최소화: 복사할 코드가 없으며 사용자를 가짜 사이트로 보낼 기회가 없습니다.

유용한 링크

데모에서 흐름을 테스트할 수 있습니다.

발급자 데모: 모의 이메일 계정 및 로그인 세션을 제공합니다.
인증 도구 데모: 데모 이메일 또는 참여 중인 제공업체 이메일을 인증합니다.

오리진 트라이얼 고려사항

오리진 트라이얼은 의견을 수집하기 위한 실험이므로, 신뢰 당사자 또는 ID 제공업체로 참여하는 경우 의견이 중요합니다. 문제를 신고하려면 다음 GitHub 저장소를 사용하세요.

브라우저 이메일 인증 API: WICG/email-verification
이메일 인증 프로토콜: dickhardt/email-verification

Chrome 구현에서 버그가 발생하면 다음 구성요소에 문제를 신고하세요.

새 문제: Chromium > Blink > Identity > EVP

오리진 트라이얼 토큰을 포함하여 응답별로 오리진 트라이얼 기능을 제어합니다. 이렇게 하면 A/B 테스트 인구와 같은 특정 사용자 세그먼트로 기능을 제한할 수 있습니다. 또는 베타 테스트 또는 사전 체험 사용자 그룹이 있는 경우 해당 그룹에 대해 기능을 사용 설정해야 할 수 있습니다. 이 경우 토큰을 발급하거나 검증하기 전에 제공된 이메일 주소를 확인하세요.

오리진 트라이얼에는 출시 전에 기능을 사용하는 사이트를 최소화하기 위한 트래픽 한도도 있습니다. 발급자 API는 개발 중이며 Chrome UX 업데이트와 함께 하위 호환되지 않는 변경사항이 있을 수 있습니다.

개발이 진행됨에 따라 여기 블로그와 evp-announce@chromium.org 메일링 리스트에서 추가 업데이트를 확인하세요.

이메일 인증 흐름

다음 섹션에서는 이메일 확인 API를 사용할 때의 주요 용어와 프로토콜 단계를 설명합니다.

핵심 용어

이메일 인증 API의 주요 용어는 다음과 같습니다.

인증자: 이메일 주소를 수집하고 이를 확인하려는 사이트입니다. 인증 기관을 신뢰 당사자라고도 합니다.
이메일 제공업체: 사용자의 이메일 주소를 제공하는 서비스입니다(예: gmail.com).
발급자: 사용자 이메일의 계정을 관리하는 서비스입니다(예: accounts.google.com). 발급자는 ID 공급업체라고도 합니다.

경우에 따라 이메일 제공업체와 발급자가 동일한 도메인에서 운영됩니다. 하지만 이메일 인증 API는 인증 방법으로 ID 제공업체를 사용하여 브라우저의 활성 세션을 사용하므로 두 가지를 구분하는 것이 중요합니다. 예를 들어 example@gmail.com를 확인하려면 사용자가 동일한 브라우저에서 해당 계정으로 google.com에 로그인해야 합니다.

프로토콜 흐름

양식 표시: 신뢰 당사자는 <input type="email">와 autocomplete="email-verification-token"로 표시된 숨겨진 입력 및 인스턴스별 고유한 nonce가 포함된 HTML 양식을 제공합니다.
이메일 입력: 사용자가 자동 완성 제안을 선택하거나 입력 또는 붙여넣기를 하고 필드를 종료(blur)하면 브라우저가 백그라운드에서 인증을 트리거합니다.
검색 및 세션: 브라우저가 _email-verification.<email-domain>의 DNS TXT 레코드를 쿼리하여 제공자의 승인된 발급자 출처를 검색한 다음 발급자의 .well-known/web-identity 구성 및 FedCM 계정 엔드포인트를 사용하여 사용자에게 활성 세션이 있는지 확인합니다. 도메인에서 EVP 레코드를 게시하지 않거나 활성 세션이 없으면 브라우저에서 사용자에게 메시지를 표시하지 않고 인증을 중지합니다.
토큰 발급: 브라우저가 .well-known/email-verification에서 제공업체의 issuance_endpoint를 검색하고, 임시 키 쌍을 생성하고, 서명된 이메일 인증 토큰 (EVT)을 수신하기 위해 발급자의 퍼스트 파티 세션 쿠키와 타겟 이메일 주소를 사용하여 HTTP 메시지 서명 (RFC 9421)으로 HTTP POST 요청을 전송합니다.
키 바인딩 및 제출: 브라우저는 서명된 EVT을 신뢰 당사자 출처 및 키 바인딩 JWT (KB-JWT) 내의 양식 nonce에 바인딩합니다. 사용자가 양식을 제출하면 Chrome은 결합된 토큰 (<EVT>~<KB-JWT>)으로 숨겨진 입력을 채우고 이메일 제공업체에서 주소를 확인했음을 알리는 작은 알림을 표시합니다.
클레임 및 KB 검증: 신뢰 당사자 서버가 <EVT>~<KB-JWT> 토큰을 파싱하고, 예상 클레임 (email, email_verified, aud, nonce, iat, exp)을 검증하고, cnf.jwk의 임시 공개 키에 대해 키 바인딩 서명을 확인합니다.
DNS 및 공개 키: 신뢰 당사자는 _email-verification.<email-domain> DNS TXT 레코드를 쿼리하여 토큰의 iss 클레임과 일치하는지 확인한 다음 jwks_uri에서 발급자의 .well-known/email-verification 메타데이터와 공개 키를 가져옵니다.
EVT 확인 및 완료: 신뢰 당사자는 제공업체의 공개 JWKS를 사용하여 발급자의 EVT 서명을 확인합니다. 토큰이 수신되지 않거나 유효성 검사 단계가 실패하면 사이트가 기존 이메일 확인 프로세스로 대체됩니다.

사용자가 이메일 주소를 처음 인증할 때 Chrome은 토큰을 요청하기 전에 권한 메시지 (데스크톱의 경우 대화상자, Android의 경우 하단 시트)를 표시합니다. 이 권한이 부여되면 참여 사이트 전반에서 이메일 주소별로 기억됩니다.

크롬 설정

사용자는 다음과 같이 인증된 이메일을 관리할 수 있습니다.

데스크톱에서 설정 > 자동 완성 및 비밀번호 > 연락처 정보 > 인증된 이메일로 이동합니다 (또는 chrome://settings/contactInfo 열기).
Android의 경우 설정 > 주소 등 > 인증된 이메일

사용자는 이 기능을 완전히 사용 중지하거나 개별 인증된 이메일 주소를 관리할 수 있습니다.

사용 사례 고려사항

이메일 인증은 사용자가 OTP를 검색하거나 링크를 클릭하기 위해 사이트를 떠날 필요가 없도록 기존 흐름을 점진적으로 개선한 것입니다. 사이트는 로그인, 뉴스레터 가입, 계정 생성, 비밀번호 복구와 같은 모든 관련 양식에 이메일 인증 필드를 추가할 수 있습니다. EVP는 브라우저에서 지원하는 경우에만 트리거됩니다. 제출 시 코드를 수신하지 못하거나 유효성 검사 단계 중 하나가 실패하면 기본 이메일 확인 흐름으로 대체할 수 있습니다. 이는 API의 기능 감지가 없다는 의미이기도 합니다. 검증 도구 사이트에서는 EVT를 선택사항으로 취급하여 요청에 있는 경우 처리합니다.

이메일 인증은 사용자가 이메일 주소 제공업체와 활성 세션을 보유하고 있음을 확인합니다. 이메일이 사용자에게 도달했는지 확인하지는 않습니다. 기존 환영 또는 온보딩 이메일을 계속 보내고 싶을 수도 있고, 사용자에게 스팸 설정을 확인하라는 메시지를 표시하고 싶거나 표시해야 할 수도 있습니다.