세 번째 발걸음쿠키와 세션으로 이어지는 사용자를 확인한다

HTTP는 이전 요청의 로그인 상태를 본래부터 기억해 주지 않습니다. 웹 애플리케이션은 인증 결과를 다음 요청에 연결할 별도의 수단을 둡니다. 서버가 충분히 예측하기 어려운 세션 식별자를 만들고 서버 측 저장소에 사용자·권한 문맥·만료 조건을 연결하는 방식이 대표적입니다. 브라우저는 쿠키로 그 식별자를 보관했다가 정해진 조건에 맞는 요청에 보냅니다. 쿠키는 데이터를 담는 전달·저장 수단이고 세션은 요청들을 하나의 인증 상태에 연결하는 논리적 관계입니다.

Set-Cookie: __Host-sid=LAB_RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax
Cache-Control: no-store

Secure는 쿠키를 보안 연결에서 전송하도록 제한합니다. HttpOnly는 일반적인 페이지 스크립트가 쿠키 값을 직접 읽지 못하게 하지만, 그 페이지에서 시작된 요청에 쿠키가 자동으로 포함되는 것까지 막지는 않습니다. SameSite는 다른 사이트 문맥에서 쿠키를 보낼 조건을 제한하며 Strict·Lax·None의 차이가 있습니다. None에는 Secure가 필요합니다. 이 속성을 켰다고 교차 사이트 요청의 모든 부작용이 사라지는 것은 아니므로 상태 변경 요청에는 애플리케이션의 요청 의도 검증도 필요합니다.

Domain을 생략한 호스트 전용 쿠키는 발급한 호스트로 범위를 제한합니다. Path는 어느 요청 경로에 보낼지 정하지만 서로 적대적인 애플리케이션을 안전하게 격리하는 경계로 사용하지 않습니다. __Host- 접두사는 이를 지원하는 브라우저에서 Secure, Path=/, Domain 생략 조건을 요구해 범위를 더 엄격하게 표현합니다. 속성을 외우기보다 왜 다른 하위 도메인이나 불필요한 요청에 인증 증거를 전달하지 않아야 하는지 생각하면 선택이 분명해집니다.

로그인한 채 자리를 비운 당신의 브라우저를 다른 사람이 사용할 수 있습니다. 그래서 비밀번호 변경이나 결제수단 등록 전에는 등록된 인증기로 현재의 계정 제어를 다시 확인하도록 설계합니다. 이것이 재인증이며, 세션 쿠키가 남아 있다는 사실만으로 대신할 수 없습니다. SSO에서도 인증기관으로 화면을 다시 보낸 것만으로 끝나지 않습니다. 서비스는 마지막 인증 시점과 이번에 요구한 새 확인이 실제로 이루어졌는지 검증해야 합니다.

위험 기반 인증은 기기·접속 위치·행동 변화와 작업의 민감도를 보고 추가 확인 여부를 조정하는 방식입니다. 평소 기기에서 자료를 읽는 것과 새 기기에서 복구 수단을 바꾸는 요청을 다르게 볼 수 있습니다. 다만 새 IP가 곧 공격이라는 뜻은 아닙니다. 이동통신이나 여행으로도 신호가 달라지므로 여러 근거와 오탐을 함께 고려합니다. 기기 지문이나 위치는 위험 판단의 보조 신호이며, 그 자체가 비밀번호나 패스키를 대신하는 인증기는 아닙니다.

JWT는 헤더·클레임·서명 등의 구조로 토큰을 표현할 수 있는 형식입니다. 서명된 JWT의 내용은 보통 읽을 수 있으며 서명과 암호화는 다릅니다. 서버가 상태를 전혀 저장하지 않는 토큰 방식에서는 즉시 폐기와 권한 변경 반영이 더 어려울 수 있어 짧은 수명, 갱신·철회 설계 등을 선택합니다. 공개키 기반 검증이 가능하다는 장점만 보고 모든 세션을 JWT로 바꾸지 않습니다. 실제 처리에서는 허용한 알고리즘, 발급자, 수신자, 시각과 업무 문맥을 검증합니다.

브라우저의 동일 출처 정책은 한 출처의 스크립트가 다른 출처의 응답을 읽는 능력을 제한합니다. CORS는 서버가 허용한 출처에 이 읽기 범위를 열어 주는 프로토콜입니다. CORS가 설정되어 있다는 이유로 API 요청자의 신원이나 권한이 검증된 것은 아닙니다. 브라우저 밖 클라이언트에는 같은 보호 모델이 적용되지 않고, 어떤 요청은 응답을 읽지 못해도 전송 자체는 가능합니다. 세션과 인가, 요청 의도, 응답 읽기 정책을 구분한 뒤 방향 6의 공격·방어를 이어 읽습니다.

참고　[171] · [172] · [173] · [174] · [9] · [150]