HTTP BASIC, 쿠키, 세션, JWT 인증 이해하기

사용자 인증 방식은 인터넷의 발전과 해당 시대의 어플리케이션 구조와 인프라에 따라 발전했다.
크게 4개의 방식으로 이를 구분해서 조사했다.
HTTP BASIC, COOKIE, SESSION, JWT가 그것이다.

1. HTTP BASIC 인증

HTTP BASIC 인증은 1990년대 초반 등장한 구시대적일 수 있는 인증방식이다.
요청마다 아이디와 비밀번호를 Authorization 헤더에 담아 보내는 방식이다.

BASIC 인증 방식의 가장 큰 장점은 간단함이다.
사용자 ID와 비밀번호 외에 별도의 인증 정보를 요구하지 않는다.

그러나 암호화 되지않은 BASE64로 인코딩 되어 보안이 보장되지 않는다.
보안이 보장되게 하려면 HTTPS로 통신해야만 한다.
또한 사용자의 권한을 세세하게 설정하려면 추가 구현이 필요하다.

인증 흐름은 다음과 같다.

1. 사용자가 보호된 페이지에 접근한다.
2. 서버가 `401 Unauthorized`와 `WWW-Authenticate` 헤더로 인증을 요구한다.
3. 브라우저가 기본 로그인 창을 띄운다.
4. 사용자가 아이디와 비밀번호를 입력한다.
5. 이후 요청마다 브라우저가 `Authorization` 헤더를 함께 보낸다.

---

2. COOKIE 기반 인증

COOKIE 방식 인증은 1994년에 Netscape 브라우저에서 사용되기 시작했다.
HTTP는 요청과 응답이 끝나면 이전 요청을 자동으로 기억하지 않기에 서버는 사용자의 클라이언트에 값을 저장하는 방법을 고안한것이다.
COOKIE와 'Set-Cookie' 헤더를 다루는 RFC 2109는 1997년에 발표되었고
이후 2011년에 RFC 6265가 현재 웹에서 널리 쓰이는 쿠키 동작을 정리했다.

인증 흐름은 다음과 같다.

1. 사용자가 보호된 페이지에 접근한다.
2. 서버가 로그인 페이지로 리다이렉트하거나 401 Unauthorized를 응답한다.
3. 사용자의 아이디와 비밀번호를 입력받아 서버에서 로그인 값을 검증한다.
4. 인증에 성공하면 서버가 인증에 필요한 값을 쿠키에 담아 응답한다.
5. 브라우저가 Set-Cookie 헤더를 보고 쿠키를 저장한다.
6. 이후 같은 서버로 요청할 때마다 브라우저가 Cookie 헤더를 자동으로 함께 보낸다.
7. 서버는 요청에 포함된 쿠키 값을 확인해 사용자를 식별하거나 인증 상태를 판단한다.
8. 쿠키가 유효하면 보호된 페이지나 데이터를 응답한다.
9. 로그아웃하면 서버가 쿠키를 만료시키는 Set-Cookie 헤더를 내려준다.

하지만 쿠키에 사용자 정보를 그대로 담으면 위험하다.
쿠키를 사용하니 편리했으나 CSRF(Cross-Site Request Forgery) 공격 문제가 발생했다.

예를 들어 사용자가 로그인된 상태에서 공격자가 만든 페이지에 접속했다고 가정하자.
그 페이지가 사용자의 은행 사이트나 관리자 사이트로 요청을 보내면, 브라우저는 조건에 따라 해당 사이트의 쿠키를 자동으로 붙일 수 있다.
서버가 이 요청을 정상 사용자 요청으로 믿으면 문제가 발생한다.

---

3. SESSION 기반 인증

인증 정보를 사용자 클라이언트에서 갖고있는 COOKIE 방식이 문제가 되어 인증키(sessionId)를 사용자 클라이언트에 저장하고
인증 정보는 서버에 저장하는 SESSION 방식이 1990년대 중후반 이후 동적 웹 애플리케이션과 함께 널리 쓰이게 되었다.

흐름은 다음과 같다.

1. 사용자가 아이디와 비밀번호로 로그인한다.
2. 서버가 인증에 성공하면 세션 저장소에 사용자 정보를 저장한다.
3. 서버가 `sessionId`를 쿠키로 내려준다.
4. 브라우저는 이후 요청마다 `sessionId` 쿠키를 보낸다.
5. 서버는 `sessionId`로 세션 저장소를 조회해 사용자를 식별한다.

세션이라고 다른 헤더를 쓰는것이 아닌 COOKIE 헤더를 그대로 사용한다.
다만 정보를 클라이언트 저장 인지, 서버 저장 인지가 달라진 것 뿐이다.

---

4. JWT 인증

웹 서비스의 형태가 모바일로 확장되기 시작한 2010년대 부터는 보안은 물론 서버 부하에도 무리 없을 JWT인증을 고안하게 된다.
서버 렌더링 중심에서 여러 API서버가 함께 동작하는 구조가 되었기 때문에 이러한 환경에서는 중앙 세션 저장소를
모든 요청마다 조회하는 방식이 부담이 될 수 있고, 여러 서비스가 같은 인증 정보를 검증해야 하는 경우가 많아졌다.
JWT는 OAuth, 모바일 API 환경과 함께 인증정보를 서명된 토큰으로 담아 전달하게 된다.
JWT는 2015년에 RFC 7519로 표준화되었다.

인증 흐름은 다음과 같다.

1. 사용자가 id/password로 로그인 요청을 보낸다.
2. 서버는 전달받은 사용자 정보를 검증한다.
3. 인증에 성공하면 서버는 사용자 식별 정보와 권한 정보를 담아 JWT를 생성한다.
4. 서버는 생성한 JWT를 클라이언트에 전달한다.
5. 클라이언트는 이후 요청마다 JWT(Authorization: Bearer <token>형태)를 함께 보낸다.
6. 서버는 요청에 포함된 JWT를 꺼낸다.
7. 서버는 JWT의 서명, 만료 시간, 위변조 여부를 검증한다.
8. 검증에 성공하면 JWT 안의 사용자 정보와 권한을 읽어 인증 객체를 만든다.
9. 서버는 해당 사용자를 인증된 사용자로 간주하고 요청을 처리한다.
10. 검증에 실패하면 서버는 401 Unauthorized를 응답한다.
11. JWT가 만료되면 클라이언트는 다시 로그인하거나, Refresh Token이 있다면 새 Access Token을 발급받는다.

---

5. 인증 방식 결정시 주의사항

인증 방식을 채택할 때 나중에 등장한 방식이 안전하다는 오해를 사기도 한다.
그러나 나중에 등장한 방식이 항상 더 안전하거나 더 좋은 것은 아니다.

예를 들어, JWT가 세션을 대체하는 정답이라기보다 서비스 구조가 달라지면서 선택지가 늘어난 것에 가깝다.
보안 관점에서는 각 방식이 어떤 공격에 약하고 탈취되었을 때 어떻게 피해를 줄일 수 있는지가 더 중요하다.

---

6. 요약

쿠키, 세션, JWT는 같은 층위의 개념이 아니다.
하지만 보안 관점에서는 모두 "사용자의 권한을 증명하는 값"을 어떻게 보호할 것인가로 연결된다.

• 쿠키는 HTTP에서 상태를 유지하기 위해 먼저 사용된 저장 및 전달 수단이다.
• 세션은 민감한 인증 상태를 서버에 두기 위해 쿠키 위에 만들어진 방식이다.
• JWT는 SPA, 모바일, 분산 API 환경에서 토큰 자체 검증을 쉽게 하기 위해 많이 쓰이게 된 방식이다.
• 쿠키는 자동 전송 특성 때문에 CSRF를 고려해야 한다.
• 세션은 서버에서 즉시 무효화하기 쉬워 권한 회수에 강하다.
• JWT는 탈취되면 만료 전까지 유효할 수 있으므로 짧은 만료와 폐기 전략이 필요하다.
• localStorage는 XSS에 취약하고, HttpOnly 쿠키는 CSRF 방어가 필요하다.
• Refresh Token은 Access Token보다 더 엄격하게 관리해야 한다.

결국 인증 보안의 핵심은 방식 이름이 아니라 피해를 줄이는 설계다.
토큰이 탈취될 가능성을 전제로 두고, 짧은 수명, 안전한 저장 위치, 서버 측 무효화, XSS와 CSRF 방어를 함께 준비해야 한다.