웹 앱 세션 관리: 쿠키 vs JWT vs 리프레시 토큰

세션 관리는 실제로 무엇을 하는가

세션은 누군가 로그인한 후 앱이 한 가지 질문에 답하는 방식입니다: "지금 당신은 누구인가?" 그 답이 신뢰할 수 있으면 앱은 사용자가 무엇을 볼 수 있고, 무엇을 변경할 수 있으며, 어떤 동작을 차단해야 할지 결정합니다.

"로그인 상태 유지"도 사실은 보안상의 선택입니다. 사용자의 신원 유효 기간을 얼마나 길게 둘지, 신원을 증명하는 정보가 어디에 저장될지, 그 증명 정보가 복사되면 어떤 일이 일어날지를 결정하는 것입니다.

대부분의 웹 앱 구성은 세 가지 구성 요소에 의존합니다:

• 쿠키 기반 서버 세션: 브라우저가 쿠키를 저장하고 서버가 각 요청마다 세션을 조회합니다.
• JWT 액세스 토큰: 클라이언트가 서명된 토큰을 보내면 서버는 데이터베이스 조회 없이 검증할 수 있습니다.
• 리프레시 토큰: 짧은 수명의 액세스 토큰을 새로 발급받을 때 사용하는 더 오래 지속되는 자격 증명입니다.

이것들은 서로 경쟁하는 "스타일"이라기보다 동일한 트레이드오프를 다루는 다양한 방법입니다: 속도 대 제어, 단순성 대 유연성, "지금 바로 무효화할 수 있는가?" 대 "스스로 만료되는가?" 같은 기준입니다.

유용한 평가 방법은 이렇습니다: 공격자가 앱이 신원을 증명하는 것(쿠키나 토큰)을 훔치면 무엇을 할 수 있고 얼마나 오래 할 수 있는가? 즉각적인 서버 측 제어가 필요할 때는 쿠키 세션이 유리한 경우가 많습니다(강제 로그아웃이나 즉시 잠금 등). JWT는 여러 서비스 간에 상태 없이 검증해야 할 때 적합하지만 즉시 철회가 필요하면 번거로워집니다.

어떤 한 가지 방법이 모든 상황에서 이기는 것은 아닙니다. 올바른 접근법은 위협 모델, 로그아웃 요구 사항의 엄격성, 그리고 팀이 현실적으로 유지할 수 있는 복잡성 수준에 달려 있습니다.

정답을 바꾸는 위협 모델들

좋은 세션 설계는 "최고의" 토큰 유형에 덜 의존하고, 실제로 어떤 공격을 견뎌야 하는지에 더 의존합니다.

공격자가 브라우저 저장소(예: localStorage)에서 데이터를 훔친다면, 페이지 JavaScript가 읽을 수 있는 JWT 액세스 토큰은 쉽게 탈취됩니다. 반면에 쿠키는 다릅니다: HttpOnly로 설정된 경우 일반 페이지 코드에서 읽을 수 없어서 단순한 "토큰 훔치기" 공격을 어렵게 만듭니다. 하지만 기기를 가진 사람이 직접 접근할 수 있거나(분실 노트북, 악성코드, 공유 컴퓨터) 브라우저 프로필에서 쿠키를 복사할 수는 있습니다.

XSS(공격자 코드가 페이지에서 실행되는 상황)는 모든 것을 바꿉니다. XSS가 있다면 공격자는 아무것도 훔치지 않고도 피해자의 이미 로그인된 세션을 사용해 조작을 할 수 있습니다. HttpOnly 쿠키는 세션 비밀을 읽지 못하게 막아주지만, 공격자가 페이지에서 요청을 실행하는 것을 막지는 않습니다.

CSRF(다른 사이트가 원치 않는 동작을 트리거하는 공격)는 주로 브라우저가 자동으로 쿠키를 붙여 보내는 쿠키 기반 세션을 위협합니다. 쿠키에 의존한다면 명확한 CSRF 방어가 필요합니다: 의도적인 SameSite 설정, 안티-CSRF 토큰, 상태 변경 요청의 신중한 처리 등이 필요합니다. 반면 Authorization 헤더로 보내는 JWT는 전통적 CSRF에 덜 취약하지만, JavaScript가 읽을 수 있는 곳에 저장하면 XSS에 노출됩니다.

재사용 공격(탈취된 자격 증명 재사용)은 서버 측 세션이 강한 면모를 보이는 곳입니다: 세션 ID를 즉시 무효화할 수 있습니다. 짧은 수명의 JWT는 재사용 가능한 시간을 줄이지만, 토큰이 유효한 동안에는 재사용을 막지 못합니다.

공유 기기나 분실된 휴대폰은 "로그아웃"을 실제 위협 모델로 만듭니다. 보통의 결정은 이런 질문으로 귀결됩니다: 사용자가 다른 기기에서 강제 로그아웃할 수 있는가, 얼마나 빨리 적용되어야 하는가, 리프레시 토큰이 탈취되면 어떤 일이 일어나는가, "기억하기(remember me)" 세션을 허용하는가? 많은 팀은 직원 접근을 고객 접근보다 더 엄격하게 다루기 때문에 타임아웃과 무효화 기대치가 달라집니다.

쿠키 세션: 어떻게 동작하고 무엇을 보호하는가

쿠키 기반 세션은 고전적인 구성입니다. 로그인 후 서버는 세션 레코드(종종 ID와 사용자 ID, 생성 시간, 만료 등 필드)를 생성합니다. 브라우저는 세션 ID만 쿠키에 저장합니다. 각 요청에서 브라우저는 그 쿠키를 보내고 서버는 세션을 조회해 사용자가 누구인지 결정합니다.

큰 보안 이점은 제어입니다. 세션은 매번 서버에서 검증됩니다. 누군가를 강제로 로그아웃해야 한다면 서버 측 세션 레코드를 삭제하거나 비활성화하면 즉시 작동이 중단됩니다. 사용자가 쿠키를 여전히 가지고 있어도 서버의 거부가 실제로 로그아웃을 강제합니다.

많은 보호는 쿠키 설정에서 옵니다:

• HttpOnly: JavaScript가 쿠키를 읽지 못하게 합니다.
• Secure: HTTPS에서만 쿠키를 전송합니다.
• SameSite: 브라우저가 크로스사이트 요청에 쿠키를 보낼 때를 제한합니다.

세션 상태를 어디에 저장하느냐가 확장성에 영향을 미칩니다. 앱 메모리에 세션을 유지하면 단순하지만 여러 서버를 운영하거나 자주 재시작하면 문제가 생깁니다. 데이터베이스는 내구성에 좋고, 많은 활성 세션에 대해 빠른 조회가 필요하면 Redis가 일반적입니다. 핵심은 동일합니다: 서버는 각 요청에서 세션을 찾고 검증할 수 있어야 합니다.

쿠키 세션은 관리자 대시보드나 직원 포털처럼 엄격한 로그아웃 동작이 필요한 경우에 적합합니다. 직원이 퇴사하면 서버 측 세션을 비활성화하면 토큰 만료를 기다리지 않고 접근이 즉시 차단됩니다.

JWT 액세스 토큰: 강점과 위험한 부분

JWT(JSON Web Token)는 사용자에 대한 몇 가지 클레임(사용자 ID, 역할, 테넌트 등)과 만료 시간을 담은 서명된 문자열입니다. API는 서명과 만료를 로컬에서 검증하고 데이터베이스 호출 없이 요청을 인증합니다.

이 때문에 JWT는 API 우선 제품, 모바일 앱, 여러 서비스가 동일한 신원을 검증해야 하는 시스템에서 인기가 있습니다. 여러 백엔드 인스턴스가 있을 때 각각이 같은 토큰을 검증해 동일한 답을 얻을 수 있습니다.

강점

JWT 액세스 토큰은 검증이 빠르고 API 호출 간에 전달하기 쉽습니다. 프런트엔드가 많은 엔드포인트를 호출할 때 짧은 수명의 액세스 토큰은 흐름을 단순하게 유지해 줍니다: 서명을 검증하고 사용자 ID를 읽고 계속 진행하면 됩니다.

예: 고객 포털이 "송장 목록 보기"와 "프로필 업데이트"를 별도 서비스에 요청한다고 합시다. JWT는 고객 ID와 customer 같은 역할을 담아 각 서비스가 세션 조회 없이 요청을 권한부여할 수 있게 합니다.

위험한 부분

가장 큰 트레이드오프는 무효화(revocation)입니다. 토큰이 1시간 동안 유효하면 사용자가 "로그아웃"을 눌렀거나 관리자가 계정을 비활성화해도, 서버에 추가적인 검사 없이 그 1시간 동안은 일반적으로 어디에서나 유효합니다. 이를 해결하려면 추가적인 서버 측 체크가 필요합니다.

JWT는 흔한 방식으로 유출됩니다. 일반적인 실패 지점으로는 localStorage( XSS가 읽을 수 있음), 브라우저 메모리(악성 확장 프로그램), 로그와 에러 리포트, 헤더를 캡처하는 프록시나 분석 도구, 지원 채팅이나 스크린샷에 복사된 토큰 등이 있습니다.

이 때문에 JWT 액세스 토큰은 "영구 로그인"용이 아니라 단기간 접근용으로 더 적합합니다. 토큰 안에 민감한 개인 정보를 넣지 말고, 만료 시간을 짧게 유지하고, 탈취된 토큰은 만료될 때까지 유효하다고 가정하세요.

리프레시 토큰: JWT 구성으로 실무 가능한 시스템 만들기

JWT 액세스 토큰은 짧게 쓰도록 설계되었습니다. 이는 안전에는 좋지만 현실적 문제를 일으킵니다: 사용자가 몇 분마다 다시 로그인해야 하면 안 됩니다. 리프레시 토큰은 액세스 토큰이 만료됐을 때 앱이 조용히 새 액세스 토큰을 받게 해줍니다.

리프레시 토큰을 어디에 저장하느냐는 액세스 토큰보다 더 중요합니다. 브라우저 기반 웹 앱에서는 기본적으로 HttpOnly, Secure 쿠키에 저장하는 것이 가장 안전한 선택입니다. 로컬 스토리지는 구현이 쉽지만 XSS 버그가 있는 경우 훔치기 쉽습니다. 위협 모델에 XSS가 포함된다면 장기적 비밀을 JavaScript가 접근 가능한 저장소에 두지 마세요.

회전(rotation)은 리프레시 토큰을 실무에서 쓸 수 있게 하는 핵심입니다. 몇 주 동안 같은 리프레시 토큰을 쓰는 대신, 사용할 때마다 교체합니다: 클라이언트가 리프레시 토큰 A를 제시하면 서버는 새 액세스 토큰과 리프레시 토큰 B를 발급하고 A는 무효화됩니다.

단순한 회전 설정은 보통 몇 가지 규칙을 따릅니다:

• 액세스 토큰은 짧게 유지(분 단위, 시간 단위 아님).
• 리프레시 토큰은 서버 측에 상태와 마지막 사용 시간을 저장.
• 리프레시 시마다 회전하고 이전 토큰을 무효화.
• 가능하면 리프레시 토큰을 기기나 브라우저에 바인딩.
• 남용 조사를 위해 리프레시 이벤트를 로깅.

재사용 탐지는 핵심 경보입니다. 리프레시 토큰 A가 이미 교환되었는데 나중에 다시 보이면 복사된 것으로 간주하세요. 일반적인 대응은 세션 전체(대개 사용자에 대한 모든 세션)를 폐기하고 새로 로그인하도록 요구하는 것입니다. 어떤 사본이 실제인지 알 수 없기 때문입니다.

로그아웃에 관해서는 서버가 시행할 수 있는 무언가가 필요합니다. 보통 리프레시 토큰을 무효로 표시하는 세션 테이블(또는 폐기 목록)이 필요합니다. 액세스 토큰은 만료될 때까지 계속 작동할 수 있지만, 액세스 토큰 수명을 짧게 유지하면 그 창을 작게 만들 수 있습니다.

로그아웃 요구사항과 실제로 강제할 수 있는 것

로그아웃은 정의하기 전까지 간단해 보입니다. 보통 두 가지 요청이 섞입니다: "이 기기에서 로그아웃"(한 브라우저나 휴대폰)과 "모든 기기에서 로그아웃"(모든 활성 세션).

타이밍 문제도 있습니다. "즉시 로그아웃"은 앱이 지금 바로 자격 증명을 받아들이지 않는 것을 의미합니다. "만료 후 로그아웃"은 현재 세션이나 토큰이 자연스럽게 만료될 때 받아들이지 않는 것을 의미합니다.

쿠키 기반 세션에서는 즉시 로그아웃이 간단합니다. 서버가 세션을 소유하므로 클라이언트의 쿠키를 삭제하고 서버 측 세션 레코드를 무효화하면 됩니다. 누군가 쿠키 값을 미리 복사했다 해도 서버의 거부가 실제로 로그아웃을 강제합니다.

JWT 전용 인증(상태 없는 액세스 토큰만 있고 서버 조회가 전혀 없는 경우)에서는 진정한 즉시 로그아웃을 보장할 수 없습니다. 탈취된 JWT는 만료될 때까지 유효하기 때문에 서버가 "이 토큰이 무효화되었는가?"를 확인할 곳이 없습니다. 블랙리스트(denylist)를 추가할 수 있지만, 그러면 상태를 유지하고 확인해야 하므로 원래의 단순성이 사라집니다.

현실적인 패턴은 액세스 토큰을 짧게 유지하고 로그아웃을 리프레시 토큰으로 강제하는 것입니다. 액세스 토큰은 몇 분 동안 허용되지만 세션을 유지시키는 것은 리프레시 토큰입니다. 노트북이 도난당하면 리프레시 토큰 패밀리를 무효화하면 향후 접근을 빠르게 끊을 수 있습니다.

사용자에게 현실적으로 약속할 수 있는 것들:

• 이 기기에서 로그아웃: 해당 세션 또는 리프레시 토큰을 폐기하고 로컬 쿠키나 저장소를 삭제합니다.
• 모든 기기에서 로그아웃: 해당 계정의 모든 세션 또는 모든 리프레시 토큰 패밀리를 폐기합니다.
• "즉시" 효과: 서버 세션에서는 보장되며, 액세스 토큰에서는 만료될 때까지 최선의 노력을 하는 수준입니다.
• 강제 로그아웃 이벤트: 비밀번호 변경, 계정 비활성화, 역할 하향 조정 등.

비밀번호 변경이나 계정 비활성화 같은 경우에는 "사용자가 로그아웃할 것"에 기대지 마세요. 계정 단위의 세션 버전(또는 ‘token valid after’ 타임스탬프)을 저장하세요. 각 리프레시(그리고 경우에 따라 각 요청) 시 비교합니다. 값이 바뀌었으면 거부하고 다시 로그인하도록 요구하세요.

단계별: 앱에 맞는 세션 방식 선택하기

세션 설계를 단순하게 유지하려면 먼저 규칙을 정하고 그다음에 메커니즘을 선택하세요. 대부분의 문제는 팀이 유행이라서 JWT나 쿠키를 선택하는 경우에 발생합니다. 위험과 로그아웃 요구 사항에 맞는 선택을 해야 합니다.

먼저 사용자가 로그인하는 모든 장소를 목록화하세요. 브라우저 앱은 네이티브 모바일 앱, 내부 관리자 도구, 파트너 통합과 다르게 동작합니다. 각각은 안전하게 저장할 수 있는 방식, 로그인 갱신 방법, 로그아웃의 의미를 바꿉니다.

대부분 팀에 유효한 실용적 순서:

1. 클라이언트 목록 작성: 웹, iOS/Android, 내부 도구, 제3자 액세스.
2. 기본 위협 모델 선택: XSS, CSRF, 도난 기기 등.
3. 로그아웃이 무엇을 보장해야 하는지 결정: 이 기기, 모든 기기, 관리자 강제 로그아웃 등.
4. 기본 패턴 선택: 쿠키 기반 세션(서버가 기억) 또는 액세스 토큰 + 리프레시 토큰.
5. 타임아웃과 대응 규칙 설정: 유휴 대 절대 만료, 의심스러운 재사용 시 조치.

그다음 시스템이 실제로 어떤 약속을 하는지 문서화하세요. 예: "웹 세션은 유휴 30분 또는 절대 7일 후 만료됩니다. 관리자는 60초 이내에 강제 로그아웃할 수 있습니다. 분실 전화기는 원격으로 비활성화할 수 있습니다." 이런 문장들이 사용하는 라이브러리보다 더 중요합니다.

마지막으로 패턴에 맞는 모니터링을 추가하세요. 토큰 기반 설정에서는 리프레시 토큰 재사용 탐지가 강력한 신호입니다(같은 리프레시 토큰이 두 번 사용됨). 이를 탈취로 간주하고 세션 패밀리를 폐기하고 사용자에게 알리세요.

계정 탈취로 이어지는 흔한 실수들

대부분의 계정 탈취는 "영리한 해킹"이 아닙니다. 예측 가능한 세션 실수에서 오는 단순한 성공 사례입니다. 좋은 세션 처리는 공격자에게 자격 증명을 훔치거나 재사용할 쉬운 방법을 제공하지 않는 것입니다.

흔한 함정 중 하나는 액세스 토큰을 localStorage에 넣고 XSS가 없기를 바라는 것입니다. 페이지에서 어떤 스크립트든(문제가 있는 의존성, 주입된 위젯, 저장된 댓글 등) 실행되면 localStorage를 읽어 토큰을 밖으로 보낼 수 있습니다. HttpOnly 플래그를 켠 쿠키는 JavaScript가 읽지 못하기 때문에 이 위험을 줄여줍니다.

또 다른 함정은 리프레시 토큰 없이 JWT를 장기간 사용해 리프레시를 피하려는 것 입니다. 7일짜리 액세스 토큰은 7일 동안 재사용 가능 창을 제공합니다. 짧은 액세스 토큰과 잘 관리된 리프레시 토큰 조합이 더 안전합니다. 특히 리프레시를 차단할 수 있을 때 그렇습니다.

쿠키는 또 다른 실수 함정을 가집니다: CSRF 방어를 잊는 것. 쿠키 세션을 사용하고 상태 변경 요청을 CSRF 방어 없이 받으면 악성 사이트가 로그인된 브라우저를 속여 정상 요청을 보내게 할 수 있습니다.

사건 조사에서 자주 보이는 다른 실수들:

• 리프레시 토큰이 전혀 회전하지 않거나, 회전은 되지만 재사용을 탐지하지 못함.
• 여러 로그인 방법(쿠키 세션과 베어러 토큰)을 지원하는데 서버의 "어느 것이 우선인지" 규칙이 불명확함.
• 토큰이 로그(브라우저 콘솔, 분석 이벤트, 서버 요청 로그)에 남아 복사되고 보존됨.

구체적 예: 지원 담당자가 "디버그 로그"를 티켓에 붙여넣습니다. 로그에 Authorization 헤더가 포함되어 있다면 티켓 접근 권한이 있는 누구나 그 토큰을 재생해 담당자처럼 행동할 수 있습니다. 토큰을 비밀번호처럼 다루세요: 출력하지 말고, 저장하지 말고, 짧게 유지하세요.

배포 전에 빠르게 점검할 사항

대부분의 세션 버그는 화려한 암호화 문제가 아닙니다. 하나의 누락된 플래그, 너무 오래 사는 토큰, 또는 재인증이 필요했던 하나의 엔드포인트에서 옵니다.

배포 전에 훔친 쿠키나 토큰으로 공격자가 무엇을 할 수 있는지 중심으로 짧게 점검하세요. 전체 인증 설정을 다시 쓰지 않고도 보안을 빠르게 개선할 수 있는 방법입니다.

출시 전 체크리스트

스테이징에서 이 점검을 하고 프로덕션 설정에서도 다시 확인하세요:

• 액세스 토큰을 짧게 유지(분 단위)하고, API가 실제로 만료 후 거부하는지 확인.
• 리프레시 토큰을 비밀번호처럼 다루기: 가능하면 JavaScript가 읽을 수 없는 곳에 저장, 리프레시 엔드포인트로만 전송, 사용 후 회전.
• 쿠키를 인증에 사용한다면 플래그 확인: HttpOnly 켜짐, Secure 켜짐, SameSite 의도적으로 설정. 쿠키 범위(domain과 path)가 필요 이상으로 넓지 않은지도 확인.
• 쿠키로 인증하는 요청의 경우 CSRF 방어 추가하고 상태 변경 엔드포인트가 CSRF 신호 없이 실패하는지 확인.
• 폐기가 실질적으로 작동하는지 확인: 비밀번호 재설정이나 계정 비활성화 후 기존 세션이 빠르게 작동 중단되는지(서버 세션 삭제, 리프레시 토큰 무효화, 또는 "세션 버전" 체크).

그다음 로그아웃 약속을 테스트하세요. "로그아웃"은 종종 "로컬 세션 제거"를 의미하지만 사용자는 더 많은 것을 기대합니다.

실용적 테스트: 노트북과 휴대폰에서 로그인한 뒤 비밀번호를 변경하세요. 노트북은 다음 요청에서 강제로 로그아웃되어야지 몇 시간 후가 되어야 하는 것이 아닙니다. "모든 기기에서 로그아웃"과 기기 목록을 제공한다면 각 기기가 취소할 수 있는 별개의 세션 또는 리프레시 토큰 레코드에 매핑되는지 확인하세요.

예시: 직원 계정과 강제 로그아웃이 필요한 고객 포털

작은 기업을 상상해 보세요. 웹 고객 포털(고객이 송장 확인, 티켓 열기)과 현장 직원용 모바일 앱(작업, 메모, 사진)이 있습니다. 직원들은 때때로 신호가 없는 지하에서 일하므로 앱은 어느 정도 오프라인 상태에서도 작동해야 합니다. 관리자들은 큰 빨간 버튼을 원합니다: 태블릿 분실이나 계약자 퇴사 시 강제 로그아웃을 할 수 있어야 합니다.

여기에 세 가지 흔한 위협을 추가합니다: 차량의 공유 태블릿(누군가 로그아웃을 잊음), 피싱(직원이 가짜 페이지에 자격 증명 입력), 포털의 가끔 발생하는 XSS 버그(브라우저에서 스크립트가 실행되어 훔칠 수 있는 것을 훔치려 함).

여기서는 짧은 수명의 액세스 토큰 + 회전하는 리프레시 토큰과 서버 측 폐기가 실무적으로 적합합니다. 빠른 API 호출과 오프라인 내성(off-line tolerance)을 주면서도 관리자가 세션을 끊을 수 있게 합니다.

구성 예시:

• 액세스 토큰 수명: 5~15분.
• 리프레시 토큰 회전: 갱신할 때마다 새 리프레시 토큰을 발급하고 이전 토큰은 무효화.
• 리프레시 토큰 안전하게 저장: 웹에서는 HttpOnly, Secure 쿠키에; 모바일에서는 OS의 보안 저장소에.
• 리프레시 토큰 서버 측 추적: 토큰 레코드(사용자, 기기, 발급 시간, 마지막 사용, 폐기 플래그)를 저장. 회전된 토큰이 재사용되면 도난으로 간주하고 체인을 폐기.

강제 로그아웃은 시행 가능해집니다: 관리자가 해당 기기(또는 사용자의 모든 기기)에 대한 리프레시 토큰 레코드를 폐기하면 됩니다. 도난된 기기는 현재 액세스 토큰이 만료될 때까지 계속 사용할 수 있지만 새 토큰을 얻을 수는 없습니다. 따라서 완전한 접근 차단까지의 최대 시간은 액세스 토큰 수명이 됩니다.

분실 기기에 대해서는 규칙을 평이한 언어로 정의하세요: "10분 이내에 앱이 동기화를 중단하고 다시 로그인해야 합니다." 오프라인 작업은 기기에서 남아 있어도 다음 온라인 동기화는 로그인이 필요할 때까지 실패해야 합니다.

다음 단계: 구현, 테스트, 유지 관리하기 쉽게 만들기

"로그아웃"이 의미하는 바를 제품 언어로 적어두세요. 예: "이 기기에서 로그아웃하면 해당 기기에서의 접근이 제거됩니다.", "모든 기기에서 로그아웃하면 1분 이내에 모든 기기가 강제 로그아웃됩니다.", "비밀번호 변경 시 다른 세션은 로그아웃됩니다." 이런 약속들이 서버 측 세션 상태, 폐기 목록, 또는 짧은 수명 토큰 중 무엇이 필요한지를 결정합니다.

그 약속들을 작은 테스트 계획으로 바꾸세요. 토큰과 세션 버그는 정상 흐름 데모에서는 잘 보이지 않다가 실제 상황(절전 모드, 끊긴 네트워크, 다중 기기)에서 실패합니다.

실용적 테스트 체크리스트

다음과 같은 혼란스러운 경우를 커버하는 테스트를 실행하세요:

• 만료: 액세스 토큰이나 세션이 만료되면 접근이 중단되는가?
• 폐기: "모든 기기에서 로그아웃" 후에 이전 자격 증명이 다음 요청에서 실패하는가?
• 회전: 리프레시 토큰 회전이 새 리프레시 토큰을 발급하고 이전 것을 무효화하는가?
• 재사용 탐지: 오래된 리프레시 토큰을 재생하면 락다운이 발생하는가?
• 다중 기기: "현재 기기만" 대 "모든 기기" 규칙이 강제되고 UI가 일치하는가?

테스트 후 팀과 함께 간단한 공격 리허설을 하세요. 세 가지 시나리오를 골라 종단간으로 점검합니다: 토큰을 읽을 수 있는 XSS 버그, 쿠키 세션을 노린 CSRF 시도, 활성 세션이 있는 분실 전화기. 설계가 약속과 일치하는지 확인하세요.

빠르게 진행해야 한다면 커스텀 커넥터 코드를 줄이세요. AppMaster (appmaster.io)은 생성된, 실무용 백엔드와 웹/네이티브 앱을 제공해 만료, 회전, 강제 로그아웃 같은 규칙을 클라이언트 간에 일관되게 유지하는 데 도움이 되는 한 옵션입니다.

출시 후 추적 검토를 일정에 넣으세요. 실제 지원 티켓과 사고를 사용해 타임아웃, 세션 제한, "모든 기기에서 로그아웃" 동작을 조정하고 같은 체크리스트를 다시 실행해 수정이 조용히 후퇴하지 않도록 하세요.