🔄 iOS에서 네이티브와 WebView 세션 동기화

읽는 데 15분

2024년 2월 16일

우선순위 1: (거의) 모든 디지털 비즈니스 아이디어의 기반은 사용자 식별과 구매/구독을 통한 서비스 제공입니다. 이 둘은 대부분 애플리케이션의 기본 로직이자 비즈니스 성공의 핵심입니다.

National Media & Tech는 JSON Web Token, OAuth 2.0, HTTP 쿠키를 바탕으로 한 웹 중심의 세션 관리 방식을 사용합니다.

이 글은 주로 웹 기반인 세션 관리를 iOS에 적용할 때의 도전과제를 다룹니다.

글 구성에 헷갈리지 마세요: 먼저 기본을 설명하고, 우리의 오디세이를 들려준 뒤, 최종적으로 작동하는 해법으로 이끕니다. 그러니 부디 계속 읽으며 우리의 시행착오를 피하세요…

The Basics: JWT, OAuth and HTTP Cookies

JSON Web Token

JSON Web Token(JWT)은 정보를 JSON 객체로 안전하게 전송하기 위한 표준(RFC 7519)입니다. 무결성 검증과 신뢰를 위해 디지털 서명을 사용할 수 있습니다. 서명은 HMAC을 통한 시크릿 또는 RSA/ECDSA 공개/개인키 쌍으로 수행합니다. JWT는 기밀성을 위해 암호화할 수도 있지만, 여기서는 헤더와 페이로드 전체를 서명하여 클레임의 무결성을 보장하는 “서명된 토큰”에 초점을 둡니다.

JWT는 특히 두 가지 시나리오에서 유용합니다:

권한 부여(Authorization): 사용자가 로그인한 뒤 각 요청에 JWT를 포함해, 권한 있는 라우트/서비스/리소스에 접근합니다. 가볍고 도메인 간 사용이 쉬워 SSO(Single Sign-On)에 적합합니다.
정보 교환(Information Exchange): JWT는 디지털 서명을 통해 발신자의 “신원”과 “권한(Entitlements)”을 보장하고, 서명에 헤더와 페이로드가 포함되므로 데이터의 무결성을 확인합니다.

요약하면, JWT는 디지털 서명을 활용해 데이터의 무결성과 진위성을 보장하면서 인증과 안전한 정보 교환을 위한 간결하고 유연한 방법을 제공합니다.

참고로 Google Firebase Authentication도 같은 접근을 사용합니다.

OAuth 2.0

OAuth 2.0은 애플리케이션이 Facebook, GitHub, Google 같은 HTTP 서비스의 사용자 계정에 제한된 접근 권한을 얻도록 하는 인가 프레임워크입니다. 사용자 인증은 해당 서비스에 위임하고, 서드파티 앱이 사용자 계정에 접근하도록 허용합니다. “액세스 토큰”은 수명이 짧아 사용자 대신 API 요청을 인가하는 데 쓰이고, “리프레시 토큰”은 수명이 길어 사용자가 다시 로그인할 필요 없이 새로운 액세스 토큰을 발급받는 데 사용됩니다.

HTTP Cookies

쿠키는 목적에 따라 여러 종류가 있습니다.

영속 쿠키(persistent cookie)는 지정된 만료일/기간까지 브라우저에 데이터를 저장합니다. 세션 종료 시 삭제되는 세션 쿠키와 달리 여러 세션에 걸쳐 유지됩니다. 사용자가 관련 웹사이트를 다시 방문하거나 광고 등으로 다른 사이트에서 해당 리소스를 볼 때마다 서버로 정보를 전송합니다. 덕분에 유저를 장기간 추적하거나, 방문 간 로그인 상태를 유지해 반복 로그인 입력을 줄이는 데 유용합니다.

HTTP 쿠키를 HTTP 헤더로 주고받는 방식은 브라우저 기반 웹 세션 관리의 사실상 표준이며, 브라우저가 쿠키 하우스키핑을 맡습니다.

Session Synchronization

네이티브 앱의 USP

웹에서는 모든 것이 브라우저 기반이지만, 앱을 네이티브로 구현하면 크게 세 가지 이점이 있습니다:

성능(Performance): 네이티브 앱은 일반적으로 WebView 앱보다 빠르고 반응성이 좋습니다. 플랫폼 하드웨어에 최적화되어 애니메이션이 부드럽고 로딩이 빠르며 전체 경험이 매끄럽습니다.
사용자 경험(UX): 네이티브 iOS 앱은 iOS HIG를 따르므로 직관적이고 익숙한 경험을 제공합니다. iOS 제스처와 상호작용을 온전히 활용합니다.
디바이스 기능 접근: 카메라, GPS, 가속도계, 푸시 알림 등 하드웨어와 iOS 기능에 완전 접근할 수 있어, 디바이스의 잠재력을 십분 활용하는 인터랙티브한 앱을 만들 수 있습니다.

PWA나 Flutter 같은 멀티플랫폼 도구로 유사 기능을 구현할 수 있어도, iPhone에서 최적의 사용자 경험을 구현하려면 네이티브가 여전히 우월합니다.

네이티브 세션 처리

세션은 네이티브 호출로 시작하되, 세션 정보를 담은 모든 쿠키를 잊지 말고 주고받아야 합니다.

swift
let session = URLSession.shared
if let url = URL(string: "https://example.com") {

    var request = URLRequest(url: url)
    request.httpMethod = "GET"

    let task = session.dataTask(with: request) { data, response, error in
        if let error = error {
            print("Error: \(error.localizedDescription)")
            return
        }
    }

    task.resume()
}

핵심 포인트

자동 쿠키 관리: 기본 URLSession 구성에서는 iOS가 쿠키를 자동으로 처리합니다. 응답에서 받은 쿠키 저장, 동일 서버 요청 시 쿠키 자동 전송 등이 포함됩니다.
수동 쿠키 처리 불필요: 자동 모드에서는 요청에 쿠키를 수동으로 추가하거나 응답에서 쿠키를 직접 저장할 필요가 없습니다. 시스템이 HTTPCookieStorage를 통해 이를 처리합니다.
세션 구성: URLSession.shared나 URLSessionConfiguration.default로 만든 세션은 자동 쿠키 처리를 제공합니다. 커스텀 구성을 만들 경우, 직접 쿠키를 관리하려는 의도가 아니라면 자동 쿠키 처리를 비활성화하지 마세요.

쿠키를 WKWebView로… 그리고 다시 되돌리기?

이제 HTTPCookieStorage에 저장된 세션 정보를 WKWebView의 WKCookieStore로 넘겨야 합니다.

기본적으로 HTTPCookieStorage에 저장된 쿠키는 WKWebView의 WKCookieStore와 자동 공유되지 않으며, 그 반대도 마찬가지입니다. 이것은 WebKit의 프로세스 분리 아키텍처로 WebView가 앱과 다른 프로세스에서 동작하기 때문입니다. 성능/보안을 높여주는 설계지만, 그만큼 WebView와 앱의 HTTP 요청 간 쿠키 공유가 간단하지 않습니다.

WKWebView의 쿠키 저장소에 쿠키를 삽입하려면 쿠키를 순회하며 setCookie로 추가하세요. setCookie는 비동기이므로, 모든 쿠키 설정 후 작업(예: 웹 요청 로드)이 필요하면 await로 완료를 기다립니다.

swift
for cookie in cookies {
    await webView.configuration.websiteDataStore.httpCookieStore.setCookie(cookie)
}

// 모든 쿠키 설정 후 로드
if let url = URL(string: "https://example.com") {
    let request = URLRequest(url: url)
    webView.load(request)
}

좋아요 — 그런데 백그라운드의 네이티브 호출로 쿠키가 업데이트되면 어떻게 되죠?

이 경우 쿠키를 다시 전달하고, 실행 중인 웹 컨텍스트가 쿠키를 재읽도록 WKWebView를 리로드해야 합니다.

가능은 해 보이는데, 만약 WebView 스스로 쿠키를 업데이트하면요(예: 자바스크립트나 네비게이션 중 서버의 set-cookie)?

음… 좋은 지적입니다! 그러면 WKHTTPCookieStoreObserver로 WKHTTPCookieStore 변경을 구독하여, 변경분을 네이티브 호출이 사용하는 HTTPCookieStorage에 다시 동기화해야 합니다.

swift
func copyCookiesToSharedStorage(from cookieStore: WKHTTPCookieStore) async {
    let cookies = await cookieStore.getAllCookiesAsync()
    for cookie in cookies {
        HTTPCookieStorage.shared.setCookie(cookie)
    }
}

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

HTTPCookieStorage와 WKHTTPCookieStore의 완전 동기화(Mermaid)

쿠키 저장소의 단일 진실 공급원(Single Source of Truth)

잠깐만요. 뭔가 잘못된 느낌이 드네요.

순서가 거꾸로였던 건 아닐까요!

단일 진실 공급원이 있어야 하고, 커스텀 동기화를 하면 동시에 호출될 때 경쟁 상태가 생길 수도 있습니다…

WKHTTPCookieStore를 단일 진실 공급원으로 쓰면, WebView 내에서 일어나는 모든 변경을 네이티브 호출에서 접근할 수 있고, 반대로 네이티브 호출도 WKHTTPCookieStore에 직접 쓰면 그 변경이 곧바로 WebView에 반영됩니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

WKHTTPCookieStore를 단일 진실 공급원으로(Mermaid)

네이티브 요청은 항상 WKHTTPCookieStore를 읽고 쓴다 이제 WKHTTPCookieStore를 단일 진실 공급원으로 만들면 모든 WKWebView에 쿠키가 자동 제공됩니다. 다만 네이티브 요청 시에는 쿠키를 명시적으로 설정하고, 결과 쿠키를 다시 WKWebsiteDataStore에 써준 뒤 리로드하여 모든 WKWebView에서 이용 가능하게 해야 합니다.

swift
WKWebsiteDataStore.default().httpCookieStore.getAllCookies { cookies in
    for cookie in cookies {
        HTTPCookieStorage.shared.setCookie(cookie)
    }

    if let url = URL(string: "https://example.com") {
        var request = URLRequest(url: url)

        let task = session.dataTask(with: request) { data, response, error in
            if let error = error {
                print("Request error: \(error)")
                return
            }
            guard let httpResponse = response as? HTTPURLResponse else {
                print("Invalid response")
                return
            }
            if let headerFields = httpResponse.allHeaderFields as? [String: String], let url = response?.url {
                let cookies = HTTPCookie.cookies(withResponseHeaderFields: headerFields, for: url)
                for cookie in cookies {
                    DispatchQueue.main.async {
                        WKWebsiteDataStore.default().httpCookieStore.setCookie(cookie) {
                            // 완료 핸들러
                        }
                    }
                }
            }
        }
        task.resume()
    }
}

사이드 노트

설명한 접근은 네이티브 요청과 WKWebView에는 잘 작동하지만, SFSafariController나 Safari에는 적합하지 않습니다. Safari 뷰의 컨텍스트는 앱과 완전히 격리되어 있어 쿠키를 전달할 수 없기 때문입니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

Mermaid

WKWebsiteDataStore의 주의점

비동기 로드

WKWebsiteDataStore는 WebKit의 일부로, 쿠키/캐시/로컬 스토리지 등 웹사이트 데이터를 관리합니다. 앱 생명주기 초반, 예를 들어 applicationDidLoad 시점에 WKWebsiteDataStore를 조회하면 비어 보일 수 있습니다. 이유는 다음과 같습니다.

비동기 데이터 로딩: 웹사이트 데이터(쿠키/캐시 등)를 WKWebsiteDataStore로 불러오는 과정은 “비동기”입니다. 앱 로드시 즉시 내용을 확인하면 로딩이 아직 끝나지 않았을 수 있습니다.
데이터 스토어 초기화: WKWebsiteDataStore가 applicationDidLoad 시점에 완전히 초기화되지 않았을 수 있습니다. 앱이 웹 컨텐츠를 어떻게 초기화/접근하는지에 따라 다릅니다.
아직 데이터 없음: 새로 설치한 앱이거나 WKWebView가 아직 아무 컨텐츠도 로드하지 않았다면, WKWebsiteDataStore는 당연히 비어 보입니다.
기본 데이터 스토어 사용: 기본 WKWebsiteDataStore를 접근한다면 앱 내 WKWebView에서 로드한 웹 컨텐츠의 데이터가 들어갑니다. 다만 타이밍/초기화 상태에 따라 가용 데이터가 달라 보일 수 있습니다.

위 비동기 문제를 피하기 위해, 쿠키를 직접 읽는 대신 fetchDataRecords(ofTypes:completionHandler:)를 사용했습니다. 직접 접근하면 종종 빈 것으로 보고되곤 했기 때문입니다.

swift
let dataStore = WKWebsiteDataStore.default()
let dataTypes = Set([WKWebsiteDataTypeCookies])

dataStore.fetchDataRecords(ofTypes: dataTypes) { records in
    for record in records {
        print("\(record.displayName) has the following cookies:")
        for cookie in record.cookies {
            print(cookie)
        }
    }
}

격리된 쿠키 & 세션 쿠키

WKWebView — 각 WKWebView 인스턴스는 기본 영속 스토어를 공유하거나, 비영속 스토어(시크릿/사파리의 개인정보 보호 모드와 유사)를 사용하거나, 특정 ID로 영속 스토어를 구성해 데이터를 공유할 수 있습니다. 자세한 내용은 WKWebsiteDataStore 클래스를 참고하세요.

받아보기: Paul Hackenberger의 글을 메일로

Medium에 무료 가입하고 이 필자의 업데이트를 받아보세요.

세션 쿠키(쿠키 객체의 isSessionOnly가 true)는 단일 프로세스에만 국한되며 공유되지 않습니다. 세션 쿠키는 만료일이 없는 것으로 브라우저가 식별합니다.

잠재적 레이스 컨디션

세션을 동기화하려고 최선을 다했어도, 여전히 세션이 손상되는 레이스 컨디션을 겪을 수 있습니다.

네이티브 앱이 세션 갱신을 시작하는 동안, WebView도 자체 갱신을 수행해 네이티브 세션을 무효화하거나 그 반대의 상황이 생길 수 있습니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

동일 세션에 대한 WebView와 네이티브의 세션 처리 간 레이스 컨디션(Mermaid)

이제 WKWebViewDataStorage의 열핵(thermonuclear) 문제

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

열핵 폭발

네이티브 요청을 가장 잘 통제할 수 있다는 점과 결합하여 WKWebViewDataStorage를 단일 진실 공급원으로 삼는 것은 아주 좋은 결정처럼 보였습니다만…

기본 WKWebView 구성(기본 영속성 사용)임에도, WKWebViewDataStorage가 무작위로 쿠키를 잃어버려 사용자가 로그아웃되는 문제가 발생합니다!!!

우회책: 쿠키를 위한 네이티브 영속 계층

우리는 우회책으로 두 번째 네이티브 안전망을 도입했습니다. WKWebSiteDataStorage가 쿠키를 잃어버린 경우에도, 네이티브로 세션을 복구해 다시 WKWebSiteDataStorage에 쿠키를 전달할 수 있도록 항상 대비합니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

네이티브 영속 쿠키 계층(Mermaid)

보기엔 좋아요 — 하지만 HTTPCookie도, 그 속성들도 Codable을 준수하지 않죠…

모든 알려진 쿠키 속성을 저장하는 Codable 래퍼를 만들 수는 있지만, HTTPCookiePropertyKey가 할당되지 않은 속성(예: HttpOnly)도 있어 중요한 속성을 놓칠 수 있습니다.

HTTPCookie의 속성은 다음과 같이 정의됩니다:

[HTTPCookiePropertyKey: Any]?

여기서 HTTPCookiePropertyKey는 String 별칭이지만, Any는 무엇이든 될 수 있습니다. 이제 타입 안정성 문제가 생깁니다.

Any를 사용하면 딕셔너리에 저장된 값의 타입 정보가 사라집니다. 사용자 기본(UserDefaults)에서 값을 읽어올 때 실제 타입을 알기 어렵습니다. 적절한 타입 안전성이 없으면, 예기치 않은 타입으로 인해 런타임 에러가 발생할 수 있습니다.

다행히 NSKeyedArchiver는 우리가 쿠키 속성에서 마주치는 타입들을 지원합니다. 타입 안전성에 대한 불확실성이 조금 남긴 하지만, 실무에서는 충분히 동작했습니다.

그 전에 JSONSerialization을 시도했는데, 타입 예외로 실패했어요…

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

직렬화 메서드가 지원하는 데이터 타입들(Gemini)

Summary

모든 문제의 뿌리는 사실상 두 개의 독립 클라이언트 — 앱과 앱 안의 WebView 컨텍스트 — 가 동일한 세션을 공유한다는 점입니다.

설상가상으로 WKWebView가 무작위로 쿠키를 잃어버리기도 합니다!

세션 동기화는 생각보다 훨씬 어려웠고, 여기 제시한 해법에도 불구하고 네이티브와 WKWebView가 동시에 쿠키를 읽고/쓰는 순간 레이스 컨디션이 발생할 수 있는 경우가 “많습니다”. 게다가 WKWebView가 쿠키를 잃는 대참사가 일어나기도 하죠!

iOS는 WKWebView 동작을 매우 제한적으로만 제어하게 해 주므로, 향후 개선을 지켜보려 합니다.

과거 UIWebView는 앱 레벨 쿠키 저장소(HTTPCookieStorage)를 NSURLSession/NSURLConnection 같은 네트워크 API와 공유했기에 훨씬 다루기 쉬웠습니다.

WKHTTPCookieStore가 이렇게 다르게 동작해 관리가 훨씬 어려운 이유는 여러 가지가 있겠지만, 추가 보안을 위해 WebView를 네이티브 요청의 민감한 데이터로부터 샌드박스 처리하거나, WKWebView의 내부 구조상 기본 전체 자동 동기화가 불가능하기 때문일 수 있습니다.

OLX Group Acting iOS Staff Engineer Ivan Lisovyi의 피드백

저도 OLX iOS 앱에서 다양한 인증 관련 문제를 몇 달 동안 고쳤습니다. 앱이 아무것도 하지 않았는데도 주기적으로 쿠키가 지워지는 문제도 있었죠. 우연의 일치네요! 😅

TL;DR: 글 말미에 지적하셨듯 쿠키는 신뢰하기 어렵고, WKWebView가 무언가 해 주기를 전제로 한 로직은 취약합니다. 그래서 저희는 결국 인증 플로를 거의 처음부터 다시 썼습니다. 이 문제에 좋은 해결책이 있는지는 잘 모르겠네요.

Future Options

옵션 A: 세션 복제 및 격리

우리가 직면한 기본 문제는 네이티브 앱과 앱 내부 WebView가 실질적으로 독립 클라이언트처럼 행동한다는 점입니다.

네이티브와 WebView의 두 세션 처리를 동기화하려 애쓰기보다, “세션 프록시”를 사용해 각 클라이언트용 세션을 복제·격리하는 방법을 고려할 수 있습니다.

네이티브 앱이 URL을 열어야 할 때, 직접 접근하는 대신 현재 세션 쿠키와 대상 URL을 세션 프록시에 전달합니다.
세션 프록시는 세션을 복제해 WebView 세션을 네이티브 세션으로부터 격리한 뒤, 복제된 세션이 설정된 상태로 대상 페이지로 리다이렉트합니다.
WebView를 닫으면, WebView 사용 중 발생했을 수 있는 변경을 반영하기 위해 네이티브 세션을 갱신합니다.

그게 말이 돼요? 모든 웹 요청을 프록시로 리다이렉트해야 하고, 그런 프록시가 필요하다니 너무 과한데요!

맞는 말씀입니다… 그래도 옵션의 하나이긴 했죠…

옵션 B: 세션 제어를 네이티브 앱에 위임

우리 내부 세션 관리에서는 WebView 안에서 자바스크립트로 세션을 갱신할 수 있습니다.

WebView 내부의 갱신 호출과 네이티브 호출 간 레이스 컨디션을 피하고, 네이티브 영속 계층으로 WKWebViewDataStorage의 쿠키 유실을 방지하기 위해, 세션 관리의 제어권을 네이티브 앱으로 넘길 수 있습니다.

즉, WebView 안에서 실행되는 웹 페이지가 컨텍스트를 인지해 WKScriptMessageHandlerWithReply로 네이티브 앱에 세션 갱신을 요청하도록 합니다.

네이티브 앱은 WebView 스크립트로부터 트리거되어 세션 갱신을 수행하고, WebView가 네비게이션을 실행하기 “이전”에 갱신된 세션 쿠키를 WebView의 세션 저장소에 써 넣습니다. 네비게이션은 HTTP 헤더로 쿠키를 변경할 수도 있으니까요.

Paul, 잠깐만요…

그냥 쿠키만 복사하면, 삭제된 쿠키는 놓치잖아요. 스토어에서 복사하면 삭제 정보는 얻지 못하니까요!

젠장! 맞아요!

그래서 네이티브 요청 후에는 응답의 set-cookie 헤더를 파싱해 HTTPCookie로 만들고, 과거 날짜 만료 설정 등으로 표현된 “삭제” 정보까지 포함된 HTTPCookie들을 WKCookieStore에 전달해야 합니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

자바스크립트가 트리거하고 네이티브가 제어하는 세션/리프레시(Mermaid)

거기에 더해, 사람(혹은 SDK) 실수까지 더욱 안전히 막으려면 리프레시 토큰을 아예 WebView에 전달하지 않는 방법도 있습니다. 이렇게 하면 WebView가 네이티브 세션을 망가뜨릴 수 없습니다.

마지막으로, 앱에 통합된 다른 SDK가 HTTPCookieStorage나 WKCookieStore의 공유 스토리지를 건드릴지 확신할 수 없으니, WKWebView의 개인 브라우징과 네이티브 호출의 ephemeral 구성을 사용해 공유 저장소로부터 격리합니다.

이건 너희에겐 통하겠지만, 우리에겐 아닐 수도!

그럴 수도 있죠. 그 경우엔 여러분 환경에 맞는 맞춤 해법을 찾아야 합니다…

어느 쪽을 고르시겠어요?

즐거우셨길!

네이티브와 WebView 세션을 동기화하는 방법에 관한 이 글이 도움이 되었길 바랍니다. 질문이 있거나(더 좋게는) 더 지속 가능한 해법을 찾으셨다면 꼭 연락 주세요!

Input from our Android Crew

iOS도 힘들었지만, Android에서도 마냥 쉬운 일은 아니었습니다…

구현이 한때 매우 어려웠습니다(지금은 덜하지만 과거엔 그랬죠)
모바일과 웹 사이의 결합도가 매우 높아집니다
CookieManager의 API가 매우 제한적입니다. 예: 오프라인 로그아웃을 하고 싶어도 쿠키 삭제 API가 없어 불가
현재 가장 큰 문제: 토큰 리프레시를 네이티브와 웹 두 컴포넌트가 담당해 동시에 여러 번 리프레시되어 세션이 손상될 수 있음
Android의 Chromium 브라우저에도 이슈가 있습니다…

Android는 앱을 시작할 때, 이전 앱 프로세스가 실제로 종료됐는지 보장할 수 없습니다. 노력하긴 하고 Android 11+에선 더 노력하지만, 커널에서 인터럽트 불가 수면(uninterruptible sleep)이나 무한 루프에 빠진 스레드(대개 디바이스 드라이버 버그로 인해)라는 한 가지 경우는 해결할 수 없습니다. 그 스레드는 SIGKILL로도 종료되지 않으므로, 그 스레드가 속한 프로세스는 영원히 남아 열려 있는 파일 디스크립터와 해당 자문 잠금(advisory locks)을 계속 붙잡고 있게 됩니다. :(

이는 일반적으로 매우 드물지만, 균등하게 분포되어 있진 않습니다. 스레드를 멈추게 하는 버그는 디바이스/OS 빌드에 따라 달라서, “평균적” 사용자에게는 결코 일어나지 않더라도, 해당 버그가 있는 디바이스를 쓰는 불운한 사용자(그리고 그 사용자들을 가진 불운한 앱 개발자)에게는 더 나쁜 상태일 수 있습니다. 또한 어떤 앱은 특정 상황에서 이 버그를 “유발”하기도 하여, 그 앱에겐 특히 안 좋을 수 있습니다.

읽는 데 15분

2024년 2월 16일

National Media & Tech는 JSON Web Token, OAuth 2.0, HTTP 쿠키를 바탕으로 한 웹 중심의 세션 관리 방식을 사용합니다.

이 글은 주로 웹 기반인 세션 관리를 iOS에 적용할 때의 도전과제를 다룹니다.

글 구성에 헷갈리지 마세요: 먼저 기본을 설명하고, 우리의 오디세이를 들려준 뒤, 최종적으로 작동하는 해법으로 이끕니다. 그러니 부디 계속 읽으며 우리의 시행착오를 피하세요…

The Basics: JWT, OAuth and HTTP Cookies

JSON Web Token

JWT는 특히 두 가지 시나리오에서 유용합니다:

권한 부여(Authorization): 사용자가 로그인한 뒤 각 요청에 JWT를 포함해, 권한 있는 라우트/서비스/리소스에 접근합니다. 가볍고 도메인 간 사용이 쉬워 SSO(Single Sign-On)에 적합합니다.
정보 교환(Information Exchange): JWT는 디지털 서명을 통해 발신자의 “신원”과 “권한(Entitlements)”을 보장하고, 서명에 헤더와 페이로드가 포함되므로 데이터의 무결성을 확인합니다.

요약하면, JWT는 디지털 서명을 활용해 데이터의 무결성과 진위성을 보장하면서 인증과 안전한 정보 교환을 위한 간결하고 유연한 방법을 제공합니다.

참고로 Google Firebase Authentication도 같은 접근을 사용합니다.

OAuth 2.0

HTTP Cookies

쿠키는 목적에 따라 여러 종류가 있습니다.

HTTP 쿠키를 HTTP 헤더로 주고받는 방식은 브라우저 기반 웹 세션 관리의 사실상 표준이며, 브라우저가 쿠키 하우스키핑을 맡습니다.

Session Synchronization

네이티브 앱의 USP

웹에서는 모든 것이 브라우저 기반이지만, 앱을 네이티브로 구현하면 크게 세 가지 이점이 있습니다:

성능(Performance): 네이티브 앱은 일반적으로 WebView 앱보다 빠르고 반응성이 좋습니다. 플랫폼 하드웨어에 최적화되어 애니메이션이 부드럽고 로딩이 빠르며 전체 경험이 매끄럽습니다.
사용자 경험(UX): 네이티브 iOS 앱은 iOS HIG를 따르므로 직관적이고 익숙한 경험을 제공합니다. iOS 제스처와 상호작용을 온전히 활용합니다.
디바이스 기능 접근: 카메라, GPS, 가속도계, 푸시 알림 등 하드웨어와 iOS 기능에 완전 접근할 수 있어, 디바이스의 잠재력을 십분 활용하는 인터랙티브한 앱을 만들 수 있습니다.

PWA나 Flutter 같은 멀티플랫폼 도구로 유사 기능을 구현할 수 있어도, iPhone에서 최적의 사용자 경험을 구현하려면 네이티브가 여전히 우월합니다.

네이티브 세션 처리

세션은 네이티브 호출로 시작하되, 세션 정보를 담은 모든 쿠키를 잊지 말고 주고받아야 합니다.

swift
let session = URLSession.shared
if let url = URL(string: "https://example.com") {

    var request = URLRequest(url: url)
    request.httpMethod = "GET"

    let task = session.dataTask(with: request) { data, response, error in
        if let error = error {
            print("Error: \(error.localizedDescription)")
            return
        }
    }

    task.resume()
}

핵심 포인트

자동 쿠키 관리: 기본 URLSession 구성에서는 iOS가 쿠키를 자동으로 처리합니다. 응답에서 받은 쿠키 저장, 동일 서버 요청 시 쿠키 자동 전송 등이 포함됩니다.
수동 쿠키 처리 불필요: 자동 모드에서는 요청에 쿠키를 수동으로 추가하거나 응답에서 쿠키를 직접 저장할 필요가 없습니다. 시스템이 HTTPCookieStorage를 통해 이를 처리합니다.
세션 구성: URLSession.shared나 URLSessionConfiguration.default로 만든 세션은 자동 쿠키 처리를 제공합니다. 커스텀 구성을 만들 경우, 직접 쿠키를 관리하려는 의도가 아니라면 자동 쿠키 처리를 비활성화하지 마세요.

쿠키를 WKWebView로… 그리고 다시 되돌리기?

이제 HTTPCookieStorage에 저장된 세션 정보를 WKWebView의 WKCookieStore로 넘겨야 합니다.

swift
for cookie in cookies {
    await webView.configuration.websiteDataStore.httpCookieStore.setCookie(cookie)
}

// 모든 쿠키 설정 후 로드
if let url = URL(string: "https://example.com") {
    let request = URLRequest(url: url)
    webView.load(request)
}

좋아요 — 그런데 백그라운드의 네이티브 호출로 쿠키가 업데이트되면 어떻게 되죠?

이 경우 쿠키를 다시 전달하고, 실행 중인 웹 컨텍스트가 쿠키를 재읽도록 WKWebView를 리로드해야 합니다.

가능은 해 보이는데, 만약 WebView 스스로 쿠키를 업데이트하면요(예: 자바스크립트나 네비게이션 중 서버의 set-cookie)?

swift
func copyCookiesToSharedStorage(from cookieStore: WKHTTPCookieStore) async {
    let cookies = await cookieStore.getAllCookiesAsync()
    for cookie in cookies {
        HTTPCookieStorage.shared.setCookie(cookie)
    }
}

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

HTTPCookieStorage와 WKHTTPCookieStore의 완전 동기화(Mermaid)

쿠키 저장소의 단일 진실 공급원(Single Source of Truth)

잠깐만요. 뭔가 잘못된 느낌이 드네요.

순서가 거꾸로였던 건 아닐까요!

단일 진실 공급원이 있어야 하고, 커스텀 동기화를 하면 동시에 호출될 때 경쟁 상태가 생길 수도 있습니다…

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

WKHTTPCookieStore를 단일 진실 공급원으로(Mermaid)

swift
WKWebsiteDataStore.default().httpCookieStore.getAllCookies { cookies in
    for cookie in cookies {
        HTTPCookieStorage.shared.setCookie(cookie)
    }

    if let url = URL(string: "https://example.com") {
        var request = URLRequest(url: url)

        let task = session.dataTask(with: request) { data, response, error in
            if let error = error {
                print("Request error: \(error)")
                return
            }
            guard let httpResponse = response as? HTTPURLResponse else {
                print("Invalid response")
                return
            }
            if let headerFields = httpResponse.allHeaderFields as? [String: String], let url = response?.url {
                let cookies = HTTPCookie.cookies(withResponseHeaderFields: headerFields, for: url)
                for cookie in cookies {
                    DispatchQueue.main.async {
                        WKWebsiteDataStore.default().httpCookieStore.setCookie(cookie) {
                            // 완료 핸들러
                        }
                    }
                }
            }
        }
        task.resume()
    }
}

사이드 노트

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

Mermaid

WKWebsiteDataStore의 주의점

비동기 로드

비동기 데이터 로딩: 웹사이트 데이터(쿠키/캐시 등)를 WKWebsiteDataStore로 불러오는 과정은 “비동기”입니다. 앱 로드시 즉시 내용을 확인하면 로딩이 아직 끝나지 않았을 수 있습니다.
데이터 스토어 초기화: WKWebsiteDataStore가 applicationDidLoad 시점에 완전히 초기화되지 않았을 수 있습니다. 앱이 웹 컨텐츠를 어떻게 초기화/접근하는지에 따라 다릅니다.
아직 데이터 없음: 새로 설치한 앱이거나 WKWebView가 아직 아무 컨텐츠도 로드하지 않았다면, WKWebsiteDataStore는 당연히 비어 보입니다.
기본 데이터 스토어 사용: 기본 WKWebsiteDataStore를 접근한다면 앱 내 WKWebView에서 로드한 웹 컨텐츠의 데이터가 들어갑니다. 다만 타이밍/초기화 상태에 따라 가용 데이터가 달라 보일 수 있습니다.

swift
let dataStore = WKWebsiteDataStore.default()
let dataTypes = Set([WKWebsiteDataTypeCookies])

dataStore.fetchDataRecords(ofTypes: dataTypes) { records in
    for record in records {
        print("\(record.displayName) has the following cookies:")
        for cookie in record.cookies {
            print(cookie)
        }
    }
}

격리된 쿠키 & 세션 쿠키

받아보기: Paul Hackenberger의 글을 메일로

Medium에 무료 가입하고 이 필자의 업데이트를 받아보세요.

잠재적 레이스 컨디션

세션을 동기화하려고 최선을 다했어도, 여전히 세션이 손상되는 레이스 컨디션을 겪을 수 있습니다.

네이티브 앱이 세션 갱신을 시작하는 동안, WebView도 자체 갱신을 수행해 네이티브 세션을 무효화하거나 그 반대의 상황이 생길 수 있습니다.

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

동일 세션에 대한 WebView와 네이티브의 세션 처리 간 레이스 컨디션(Mermaid)

이제 WKWebViewDataStorage의 열핵(thermonuclear) 문제

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

열핵 폭발

네이티브 요청을 가장 잘 통제할 수 있다는 점과 결합하여 WKWebViewDataStorage를 단일 진실 공급원으로 삼는 것은 아주 좋은 결정처럼 보였습니다만…

기본 WKWebView 구성(기본 영속성 사용)임에도, WKWebViewDataStorage가 무작위로 쿠키를 잃어버려 사용자가 로그아웃되는 문제가 발생합니다!!!

우회책: 쿠키를 위한 네이티브 영속 계층

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

네이티브 영속 쿠키 계층(Mermaid)

보기엔 좋아요 — 하지만 HTTPCookie도, 그 속성들도 Codable을 준수하지 않죠…

HTTPCookie의 속성은 다음과 같이 정의됩니다:

[HTTPCookiePropertyKey: Any]?

여기서 HTTPCookiePropertyKey는 String 별칭이지만, Any는 무엇이든 될 수 있습니다. 이제 타입 안정성 문제가 생깁니다.

그 전에 JSONSerialization을 시도했는데, 타입 예외로 실패했어요…

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

직렬화 메서드가 지원하는 데이터 타입들(Gemini)

Summary

모든 문제의 뿌리는 사실상 두 개의 독립 클라이언트 — 앱과 앱 안의 WebView 컨텍스트 — 가 동일한 세션을 공유한다는 점입니다.

설상가상으로 WKWebView가 무작위로 쿠키를 잃어버리기도 합니다!

iOS는 WKWebView 동작을 매우 제한적으로만 제어하게 해 주므로, 향후 개선을 지켜보려 합니다.

과거 UIWebView는 앱 레벨 쿠키 저장소(HTTPCookieStorage)를 NSURLSession/NSURLConnection 같은 네트워크 API와 공유했기에 훨씬 다루기 쉬웠습니다.

OLX Group Acting iOS Staff Engineer Ivan Lisovyi의 피드백

저도 OLX iOS 앱에서 다양한 인증 관련 문제를 몇 달 동안 고쳤습니다. 앱이 아무것도 하지 않았는데도 주기적으로 쿠키가 지워지는 문제도 있었죠. 우연의 일치네요! 😅

TL;DR: 글 말미에 지적하셨듯 쿠키는 신뢰하기 어렵고, WKWebView가 무언가 해 주기를 전제로 한 로직은 취약합니다. 그래서 저희는 결국 인증 플로를 거의 처음부터 다시 썼습니다. 이 문제에 좋은 해결책이 있는지는 잘 모르겠네요.

Future Options

옵션 A: 세션 복제 및 격리

우리가 직면한 기본 문제는 네이티브 앱과 앱 내부 WebView가 실질적으로 독립 클라이언트처럼 행동한다는 점입니다.

네이티브 앱이 URL을 열어야 할 때, 직접 접근하는 대신 현재 세션 쿠키와 대상 URL을 세션 프록시에 전달합니다.
세션 프록시는 세션을 복제해 WebView 세션을 네이티브 세션으로부터 격리한 뒤, 복제된 세션이 설정된 상태로 대상 페이지로 리다이렉트합니다.
WebView를 닫으면, WebView 사용 중 발생했을 수 있는 변경을 반영하기 위해 네이티브 세션을 갱신합니다.

그게 말이 돼요? 모든 웹 요청을 프록시로 리다이렉트해야 하고, 그런 프록시가 필요하다니 너무 과한데요!

맞는 말씀입니다… 그래도 옵션의 하나이긴 했죠…

옵션 B: 세션 제어를 네이티브 앱에 위임

우리 내부 세션 관리에서는 WebView 안에서 자바스크립트로 세션을 갱신할 수 있습니다.

즉, WebView 안에서 실행되는 웹 페이지가 컨텍스트를 인지해 WKScriptMessageHandlerWithReply로 네이티브 앱에 세션 갱신을 요청하도록 합니다.

Paul, 잠깐만요…

그냥 쿠키만 복사하면, 삭제된 쿠키는 놓치잖아요. 스토어에서 복사하면 삭제 정보는 얻지 못하니까요!

젠장! 맞아요!

엔터를 누르거나 클릭하여 이미지를 전체 크기로 보기

자바스크립트가 트리거하고 네이티브가 제어하는 세션/리프레시(Mermaid)

이건 너희에겐 통하겠지만, 우리에겐 아닐 수도!

그럴 수도 있죠. 그 경우엔 여러분 환경에 맞는 맞춤 해법을 찾아야 합니다…

어느 쪽을 고르시겠어요?

즐거우셨길!

Input from our Android Crew

iOS도 힘들었지만, Android에서도 마냥 쉬운 일은 아니었습니다…

구현이 한때 매우 어려웠습니다(지금은 덜하지만 과거엔 그랬죠)
모바일과 웹 사이의 결합도가 매우 높아집니다
CookieManager의 API가 매우 제한적입니다. 예: 오프라인 로그아웃을 하고 싶어도 쿠키 삭제 API가 없어 불가
현재 가장 큰 문제: 토큰 리프레시를 네이티브와 웹 두 컴포넌트가 담당해 동시에 여러 번 리프레시되어 세션이 손상될 수 있음
Android의 Chromium 브라우저에도 이슈가 있습니다…

Android는 앱을 시작할 때, 이전 앱 프로세스가 실제로 종료됐는지 보장할 수 없습니다. 노력하긴 하고 Android 11+에선 더 노력하지만, 커널에서 인터럽트 불가 수면(uninterruptible sleep)이나 무한 루프에 빠진 스레드(대개 디바이스 드라이버 버그로 인해)라는 한 가지 경우는 해결할 수 없습니다. 그 스레드는 SIGKILL로도 종료되지 않으므로, 그 스레드가 속한 프로세스는 영원히 남아 열려 있는 파일 디스크립터와 해당 자문 잠금(advisory locks)을 계속 붙잡고 있게 됩니다. :(

이는 일반적으로 매우 드물지만, 균등하게 분포되어 있진 않습니다. 스레드를 멈추게 하는 버그는 디바이스/OS 빌드에 따라 달라서, “평균적” 사용자에게는 결코 일어나지 않더라도, 해당 버그가 있는 디바이스를 쓰는 불운한 사용자(그리고 그 사용자들을 가진 불운한 앱 개발자)에게는 더 나쁜 상태일 수 있습니다. 또한 어떤 앱은 특정 상황에서 이 버그를 “유발”하기도 하여, 그 앱에겐 특히 안 좋을 수 있습니다.