[사내발표] Safari 애플 로그인 이슈 극복기(feat. firebase)

( 이 글은 사내에서 발표한 자료를 바탕으로 작성했습니다.  )

 

트리플 서비스를 100% 이용하고 싶을 때 필수로 거쳐야 하는 관문이 하나 있습니다. 바로 로그인인데요. 트리플에서는 5가지 방법(이메일, 카카오, 네이버, 페이스북, 애플)으로 로그인할 수 있고, 다양한 방식의 로그인을 쉽게 사용하도록 도와주는 firebase를 사용하고 있습니다. 이처럼 트리플에서는 firebase의 도움을 받아 다양한 로그인(이메일 / 비밀번호 기반 인증, ID 공급업체 인증, 전화번호 인증, 커스텀 인증 등)을 쉽고 빠르게 구현할 수 있었습니다.

 

firebase API Reference를 살펴보면 카카오와 네이버는 커스텀 인증(signInWithCustomToken)을 사용하고, 애플만 ID 공급업체 인증방식(signInWithRedirect)을 사용하고 있습니다. (작년까지는 페이스북도 signInWithRedirect를 사용했으나, 간헐적으로 redirect 정보가 유실되는 이슈가 생겨 현재는 여러 인증 제공업체 연결 방식(signInWithCredential)으로 변경되었습니다. (해당 PR)) 마지막으로 이메일 로그인은 firebase의 signInWithEmailAndPassword 메소드를 이용해서 로그인하는데, user가 입력한 email / password와 firebase Auth system에 저장되어있는 email / password를 비교하여 일치하면 unique user ID token을 내려주고, 일치하지 않으면 error object이나 예외를 반환하여 오류를 처리하는 과정을 거칩니다.

 

이제 본론으로 들어가 애플 로그인에 사용된 signInWithRedirect을 살펴볼까요? signInWithRedirect은 유저인증을 거치고 마지막에 트리플 도메인으로 돌아와 최종적으로 iframe을 사용하여 로그인을 합니다.(관련 테스트 코드) 이슈는 바로 여기서 생겼는데요. 제가 이번 위클리 주제를 이것으로 정한 이유도 iframe에서 기인했다고 해도 무방합니다.

 

유저가 사용하는 브라우저 대부분은 저마다의 보안정책이 적용되어있습니다. (Chrome은 로그인 이슈가 없어 논외로 정하겠습니다. 🙇🏾‍♂️) Safari - ITP(Intelligent Tracking Prevention), FireFox - ETP(Enhanced Tracking Prevention)는 공통적으로 Third-party cookie/iframe을 차단하여 cross-site tracking을 방지합니다. 이러한 보안정책 덕분에 유저들은 개인정보를 보호/강화할 수 있고, 광고주는 유저의 활동을 추적하기 어려워지고, 악성 소프트웨어(Malware) / 웹사이트(피싱, 암호화폐 등..) 접근을 차단하거나 특정 유형의 공격으로부터 보호할 수 있는 장점이 있습니다. (유저 입장에서는 너무 좋은 정책이죠~?)

 

signInWithRedirect 경우도 예외는 없었습니다. 조금 더 자세하게 설명하자면 iframe을 사용하여 최상위 프레임(top-level frame)은 사용자 인증을 처리하고 iframe에서 호스팅되는 애플리케이션은 자동으로 토큰을 가져와서 사용자가 로그인했음을 신뢰하는 방식(implicit flow)은 서드 파티 쿠키를 차단하는 브라우저(Safari, FireFox)에서는 이러한 매커니즘이 작동하지 않았던 것이죠.

 

A common pattern in web apps is to use an iframe to embed one app inside another: the top-level frame handles authenticating the user and the application hosted in the iframe can trust that the user is signed in, fetching tokens silently using the implicit flow.
However, there are a couple of caveats to this assumption irrespective of whether third-party cookies are enabled or blocked in the browser.
Silent token acquisition no longer works when third-party cookies are blocked - the application embedded in the iframe must switch to using popups to access the user's session as it can't navigate to the login page.
You can achieve single sign-on between iframed and parent apps with same-origin and cross-origin JavaScript script API access by passing a user (account) hint from the parent app to the iframed app.

 

다행히 firebase 문서에 third-party storage access를 block하는 경우 해결하기 위한 5가지 방법이 있었는데, 이 중 공수가 적게 드는 same-origin 방법(1번)을 사용하기로 했습니다.

 

기본적으로 signInWithRedirect를 사용할 때 firebase config에서 authDomain 값을 넣어줘야 하는데, 이전까지는 firebase 도메인(PROD 기준, soto-real.firebaseapp.com)으로 설정되어있던 주소를 트리플 도메인(triple.guide)으로 변경하였습니다. 이렇게 수정하면 앱(트리플 도메인)과 인증 iframe에서 같은 도메인을 사용하므로 써드파티 이슈를 해결할 수 있습니다.

기존 애플 로그인은 다음과 같이 로그인이 진행되었습니다.

 

 

수정된 애플 로그인 flow는 다음과 같습니다. (실제 flow와 유저 flow(쉽게 말하면 브라우저의 주소표시창)가 상이합니다.)

 

 

proxy를 구현하기 위해 보통이라면 nginx를 사용했을 터지만, auth-web에는 nginx를 사용하지 않으므로 Next.js에서 rewrites를 사용했습니다.

 

// next.config.js
  async rewrites() {
    return [
      {
        source: '/__/auth/:path*',
        destination: `https://${NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN}/__/auth/:path*`,
        basePath: false,
      }
    ]
  }

 

위 코드를 분석해보면, /__/auth/:path* 주소로 요청이 들어오면, https://${NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN}/__/auth/:path*로 보내달라는 의미인데, basePath가 false이므로 basePath인 /auth-web을 포함하지 않은 상태로 destination url을 masking 처리하여 user 입장에서는 destination url은 보이지 않게 됩니다.

// User flow
1. `https://triple.guide/auth-web` // 로그인 페이지
2. `https://triple.guide/__/auth/handler` // incoming request URL with basePath false
3. `https://appleid.apple.com/auth/authorize?...` // masking firebase URL

주소표시창에도 masking처리 된 destination url(soto-real.firebase...)은 보이지 않고 곧장 애플 도메인으로 이동하는 모습을 볼 수 있습니다.

 

 

여기까지 설정을 변경해주고 설레는 맘으로 테스트 해볼까요..?

 

 

404 Not Found error가 발생하네요?! 이유는 무엇일까요..? ${WEB_URL_BASE}/__/auth/handler?...로 요청이 들어오면 gateway가 어디로 forward 해줘야 할지 모르기 때문입니다. 이를 해결하기 위해 gateway를 담당하는 triple-web-gateway에서 /__ path는 /auth-web으로 forward하는 코드를 추가합니다.

// haproxy.cfg
backend triple-auth-web
  ...
  http-request replace-path (.*) /auth-web\1 unless { path_reg ^/(__)|(auth-web) }
  ...

  acl triple-auth-web path_beg /__/
  ...

 

여기까지하고 테스트를 다시 해볼까요..?

 

오.. 이제는 주소표시창이 애플 도메인까지 잘 넘어가네요..! 하지만 애플 도메인에서 redirect를 해줄 수 없다고 하는군요. 이제 애플 configuration에서 트리플 각 환경(Triple Dev, Triple Stage, Triple)에 알맞은 Website URLs를 추가해줍니다. 시작점이 트리플 도메인이었으니, redirect url도 트리플 도메인이어야겠죠?!

 

 

이제 관련 설정은 모두 끝난것 처럼 보이네요! 최종 테스트를 한번 진행해볼까요?!

모든 설정이 끝나고 제대로 동작하는군요..!

 

이렇게해서 Safari/FireFox 브라우저에서 애플 로그인 이슈를 해결하였습니다. 작성된 글을 보면 쉽게 해결한 것 같지만, 문제 해결 과정에 도달하기까지 꽤 오랜 시간과 시행착오가 많았습니다. (firebase-js-sdk에 해당 이슈가 올라와있지만 트리플 환경에 적합한 답변은 없었습니다. 😅) 또, 이번 기회에 놓고있던 safari webkit 문서도 많이 읽었네요.. 끝으로 중간에 이욜의 도움이 있었기 때문에 이 이슈를 해결 할 수 있었습니다. (늦은 시간까지 이슈를 해결하기 위해서 옆에서 조언해주신 이욜에게 감사를 표합니다. Thanks to eeyore! 🙏🏾🙇🏾‍♂️) 긴 글 읽어주셔서 감사합니다.

Reference

1. firebase - 비밀번호 인증
2. firebase - Apple 계정으로 로그인
3. firebase-js-sdk - issues #6716
4. firebase - 서드 파티 스토리지 액세스를 차단하는 브라우저에서 signInWithRedirect를 사용하기 위한 권장사항
5. DataDog - triple-web-gateway-dev
6. triple-auth-web - issues #270