앱을 오래 켜 둔 뒤 세션이 만료되면 다시 로그인하는 흐름이 있었다. 로그인 자체는 성공했지만 이전 화면으로 돌아오자 목록이 비어 있거나 만료 전 요청이 오류 팝업을 띄웠다. 화면 경로만 복구하고 그 화면이 의존하는 데이터와 구독은 복구하지 않았기 때문이다.
재로그인은 처음 로그인과 비슷하지만 이미 메모리에 남은 상태가 있다는 점이 달랐다.
복구 상태와 재조회 상태의 구분
사용자가 보고 있던 탭과 검색 조건은 복구할 수 있었다. 계좌 권한, 세션 연결, 거래 데이터는 새 세션에서 다시 검증해야 했다.
복구 가능 : 화면 경로, 비민감 UI 설정, 입력 중 임시 필터
재조회 : 권한, 계좌 목록, 서버 상태, 알림 구독
폐기 : 이전 요청 결과, 만료 토큰, 진행 중 주문
진행 중이던 중요한 작업은 자동 재실행하지 않고 결과를 확인하거나 사용자에게 다시 요청하도록 했다.
이전 세션 작업의 선행 중단
로그인 화면을 덮어 띄우기 전에 이전 세션의 취소 토큰을 종료하고 소켓과 주기 요청을 멈췄다. 재로그인 성공 후 새 세션 컨텍스트를 만든 뒤 구독을 다시 시작했다.
await oldSession.StopAsync();
var newSession = await auth.ReloginAsync();
await appState.InitializeForAsync(newSession);
await navigator.RestoreAsync(savedRoute);
순서를 명시하니 새 화면에 이전 응답이 들어오는 문제를 줄일 수 있었다.
복구 가능 상태의 화면 안내
저장해 둔 화면 경로가 새 권한에서 접근 불가능하거나 계좌가 사라졌을 수 있었다. 그 경우 억지로 같은 화면을 열지 않고 기본 화면으로 이동해 이유를 안내했다.
복구 중에는 마지막 화면의 민감한 데이터를 그대로 보여주지 않고 안전한 로딩 상태를 사용했다. 인증이 끝나기 전에 서버 데이터가 보이지 않게 했다.
현재 조건에 맞춘 상태 복구
처음에는 사용자가 있던 화면으로 돌아가면 친절한 복구라고 생각했다. 실제로는 새 세션의 사실을 기준으로 과거 의도를 다시 적용하는 과정이었다.
이 경험 뒤 재시도나 재로그인을 만들 때 이전 함수 호출을 반복하지 않는다. 무엇이 여전히 유효하고 무엇을 새로 확인해야 하는지를 나눈다. 복구의 핵심은 최대한 많이 되살리는 것보다 오래된 상태를 새 세션에 섞지 않는 데 있었다.
유사 문제 대응 기준
나중에 같은 증상을 다시 만나지 않으려고 문서에 적힌 기준으로 구현을 한 번 더 정리했다.
OWASP ASVS와 API Security 기준을 따라 다시 보면 화면에서 숨겼다는 사실은 권한 검사가 아니다. 계좌나 사용자 식별자를 클라이언트가 보내더라도 서버는 인증 주체가 그 객체에 접근할 수 있는지 매 요청에서 확인해야 한다.
클라이언트의 역할은 권한을 결정하는 것이 아니라 잘못된 조작을 줄이고, 거부 응답을 이전 데이터와 섞지 않으며, 민감한 정보를 로그나 저장소에 남기지 않는 데 가깝다.
다음에 재로그인 상태 복구 범위 같은 문제를 보면 아래 순서부터 확인하려고 한다.
- 익명·인증 중·인증됨·만료 상태
- 재시도 가능한 오류와 사용자 입력 필요 오류
- 토큰 폐기와 화면 초기화 순서
- 동시에 도착한 만료 응답의 단일 처리
식별자 형식을 어렵게 만들거나 메뉴를 감추는 방법은 서버의 객체 수준 권한 검사를 대체하지 못한다.
공식 참고 자료
- OWASP ASVS 4.0.3 — 인증·세션·접근제어의 서버 측 검증 기준
- OWASP API Security Top 10 2023 — 객체 수준 권한과 인증·자원 소비 경계