Chrome 이메일 검증 실험 확대, 안드로이드 지원과 토큰·요청 헤더 변경

ARCH-B

ARCH-B

Chrome for Developers 기반 · 2026년 10월 13일 · 4분 분량

0

한눈에 보는 핵심요약

구글이 이메일 검증 오리진 트라이얼의 10월 변경 사항을 공개했다. Chrome 154부터 안드로이드와 제3자 실험 토큰을 지원하며, 검증 키 식별자와 요청 헤더 처리도 달라졌다. Chrome 156의 이메일 반환 규칙까지 함께 적용되는 만큼 사이트와 이메일 제공자의 역할을 구분한 점검이 필요하다.

  • 기능은 오리진 트라이얼 단계이며 Chrome 154부터 안드로이드로 확대됐다.
  • 토큰 검증과 발급 요청 검증은 사이트와 이메일 제공자가 각각 맡는다.
  • 제3자 실험 토큰은 발급자 도메인과 등록 오리진에 제한이 있다.
Chrome 이메일 검증 실험 확대, 안드로이드 지원과 토큰·요청 헤더 변경
이미지 제공: Chrome for Developers · 원출처 기사

정식 출시를 준비하는 진행 중 실험

구글의 10월 5일 안내는 이메일 검증 기능이 오리진 트라이얼 단계에서 계속 개선되고 있으며 정식 출시를 준비한다고 설명한다. 데스크톱 Chrome 150에서 시작한 실험은 Chrome 154부터 안드로이드 Chrome으로 확대됐다. 이메일 제공자에 사용자가 브라우저로 로그인해 있어야 한다는 조건은 유지된다. 이는 안드로이드 앱이 디지털 자격증명으로 검증된 이메일을 받는 별도 기능과 구분된다. 안드로이드 지원이라는 표현만 보고 모든 앱이나 이메일 계정에서 사용할 수 있다고 해석하면 안 된다.

사이트가 맡아야 할 검증 작업

검증 사이트의 공식 구현 문서는 이메일 입력과 함께 숨겨진 토큰 필드를 준비하고, 세션에 연결한 nonce를 제공하도록 한다. 폼 제출 뒤 서버는 서명 검증뿐 아니라 이메일, 사이트 오리진에 해당하는 audience, nonce와 유효 시간을 확인해야 한다. kid 키 식별자는 선택 사항이므로 토큰에 없다는 이유만으로 실패 처리하면 일부 제공자의 정상 토큰도 거절할 수 있다. 문서는 제공자의 JWKS에서 적절한 키를 찾아 서명을 검증하는 방법을 안내한다. 토큰을 읽어 이메일 값이 있다는 것과 발급자 및 현재 요청과의 연결을 검증하는 것은 다른 단계다.

발급자의 반환 값과 요청 문맥 변경

Chrome 156부터 발급자는 폼이 보낸 이메일 문자열을 그대로 토큰에 반환해야 하며, 다른 표기로 돌려주면 Chrome이 거절한다고 변경 안내는 밝힌다. 제공자 내부의 정규화된 주소를 노출하는 대신 요청자가 제출한 범위의 정보만 반환하려는 취지다. 발급 요청의 Sec-Fetch-Dest 값은 Chrome 154부터 emailverification에서 email-verification으로 바뀌었다. 전환 중에는 두 값을 허용하라는 안내도 있다. 다만 발급자 구현 문서는 세션 인증과 요청 서명, 본문 다이제스트 검증을 함께 요구한다. 이 헤더를 받아들였다는 사실만으로 인증 검사가 끝나지는 않는다.

SDK 배포 범위에도 조건이 붙는다

Chrome 154부터는 임베디드 스크립트나 인증 SDK 제공자가 제3자 오리진 트라이얼 토큰을 등록해 사용하는 방식도 지원한다. 이를 통해 스크립트를 포함한 사이트마다 별도 실험 토큰을 등록하는 부담을 줄일 수 있다. 그러나 등록 오리진과 이메일 발급자는 같은 사이트에 속해야 하며, 구글의 예시는 발급자 도메인에 맞춘 등록을 요구한다. 발급자와 다른 사이트의 등록이나 발급자 도메인 대신 하위 도메인으로 등록하는 구성은 지원되지 않는다고 명시한다. SDK가 배포됐다는 이유만으로 어느 도메인에서나 실험을 활성화할 수 있는 구조는 아니다.

ARCH.B 분석

실패 경로를 포함한 가입 경험 검토

ARCH.B가 주목하는 변화는 가입 화면의 편의성과 서버의 검증 책임이 동시에 늘어난다는 점이다. 사이트 팀은 토큰이 비었을 때와 들어왔지만 유효하지 않을 때를 구분해야 한다. 공식 문서는 브라우저·제공자 미지원 또는 사용자의 건너뛰기로 토큰이 비면 기존 OTP나 확인 링크 방식으로 돌아가도록 한다. 따라서 전환율 개선을 미리 단정하기보다, 검증 가능한 환경에서 절차가 줄고 지원되지 않는 환경에서도 가입을 마칠 수 있는지 확인하는 편이 타당하다. 안드로이드와 데스크톱, 로그인 세션 유무, 키 식별자 유무, 두 헤더 값과 이메일 표기 차이를 나눠 시험하면 실패 원인을 구체적으로 찾을 수 있다. 다른 브라우저의 동일 지원은 이번 Chrome 문서만으로 확정되지 않으므로 기존 확인 경로를 유지할 이유도 남는다. 특히 이메일 제공자 팀과 가입 사이트 팀이 같은 체크리스트만 공유해서는 문제를 놓칠 수 있다. 한쪽은 요청을 인증하고 입력 주소에 맞는 토큰을 발급해야 하며, 다른 쪽은 그 결과가 자기 사이트의 현재 가입 요청에 유효한지 판단해야 한다. 사용자에게는 하나의 확인 동작처럼 보여도 운영 책임은 나뉘므로, 오류 기록에서도 발급 실패와 검증 실패를 구별하면 수정할 위치가 명확해진다.

출처

Chrome for Developers의 원출처와 본문에 표시한 참고자료를 바탕으로 한국어로 재구성했습니다. ‘ARCH.B 분석’은 자료를 읽고 덧붙인 편집 해석입니다.

Email verification updates, October 2026 (새 창)

Share

Related

함께 읽기 좋은 글