Auth0 Custom Domain 적용 (chrome의 third-party cookie 중단)

ding·2024년 12월 13일

Issue


프로젝트 개발 중 chrome에서 머지 않아 third-party cookies 공유가 불가능해질 것이라는 warning console이 떴다. 알고 보니 safari에서는 이미 로그인 상태에서 새로고침하면 로그인이 풀려버렸다.

Solution

Auth0 community에서 custom domain을 활용하라는 제안 발견!
ref: https://community.auth0.com/t/chrome-phasing-off-third-party-support-cookies/129006

  1. Auth0 Dashboard > Branding > Custom Domains에서 custom domain(auth.example.com) 설정 후 발급해주는 CNAME Content를 CNAME으로 등록했다.
    ref: https://auth0.com/docs/customize/custom-domains/auth0-managed-certificates
    이 때, status가 ready임을 확인하자!
  • 현재 DNS 설정
    • Azure에서 서버를 돌리고 있기 때문에 example.com의 Recordsets에서 도메인 관리
      • Azure에서 제공하는 name server 등록
      • auth.example.com → temp1.edge.tenants.jp.auth0.com (CNAME)
      • dev-pacs.example.com → temp2.azurestaticapps.net (CNAME)
  1. FE와 BE의 환경변수에 있는 AUTH0_DOMAIN 값도 auth.example.com으로 수정했다.
  2. Auth0 Dashboard > Applications > Settings > Application URIs에서 Allowed Callback URLs, Allowed Logout URLs, Allowed Web Origins에서 https://*.example.com을 설정했다. 개발 환경에서도 원활한 작동을 위해 localhost도 넣어주었다.

설정을 끝낸 후 Safari 개발환경(localhost:3000)에서 테스트해봤을 때에는 여전히 로그인이 풀렸다. 당연했다. localhost와 auth.example.com은 origin이 다르니까.
긴가민가한 마음으로 dev에 배포하고 나서 테스트하니 Safari에서 로그인이 풀리지 않았고, Chrome에서 warning console이 나오지 않았다. 성공~!

ref: https://auth0.com/docs/customize/custom-domains

브라우저가 쿠키의 1st-party/3rd-party 여부를 판단할 때, 어떤 기준으로 같은 도메인인지 여부를 판단할까?
'eTLD(effective Top-Level Domain)'개념을 활용한다.
auth.eample.com에서 eTLD = .com, eTLD+1 = example.com
dev-pacs.example.com에서 eTLD = .com, eTLD+1 = example.com
브라우저는 eTLD+1이 같으면 같은 도메인으로 인식한다.

0개의 댓글