로그인에 사용된 기술적 요소들 - Hot-stock/backend GitHub Wiki

1. 로그인 요청 (POST /api/v0/auth/login)

토큰 관리 방식

JWT를 사용하여 서버에서 별도의 토큰 저장이 필요하지 않지만, 보안 강화를 위해 몇 가지 추가적인 조치를 취한다.

Access Token:
로그인 성공 시 발급되며, 클라이언트가 서버와 통신할 때 사용된다. HTTP 헤더에 포함되어 전송된다.
Refresh Token & Session ID 관리:
- Refresh Token과 Session ID는 Redis에 저장된다.
- 보안을 강화하기 위해 두 값을 HttpOnly 쿠키에 저장하여 클라이언트에서 직접 접근할 수 없도록 한다.
보안 강화 및 블랙리스트 기법:
Refresh Token이 탈취된 경우에도 Session ID와 결합하여 탈취 여부를 검증할 수 있다. 만약 Access Token이 만료되기 전에 Refresh Token으로 갱신 요청이 들어오면, 이는 의심스러운 행동으로 간주하고 **모든 토큰을 무효화(폐기)**할 수 있다. 이를 통해 Refresh Token의 탈취에 대한 보안성을 강화하는 블랙리스트 기법을 적용할 수 있다.

2. 로그아웃 요청 (POST /api/v0/auth/logout)

토큰 무효화 방식: 쿠키에 설정된 모든 token 값들을 max-age=0으로 변경하고, Redis에 저장된 session id를 삭제함으로써 더이상 사용 불가능하게 만든다.

3. 재갱신 요청 (POST /api/v0/auth/refresh)

트레일링 토큰 기법:
트레일링 토큰 기법은 리프레시 토큰과 액세스 토큰을 매번 재갱신 요청 시 새로운 값으로 갱신하는 방식입니다. 이 방식은 리프레시 토큰이 한 번 사용된 후 더 이상 재사용되지 않도록 무효화하여, 리프레시 토큰의 탈취 위험을 줄이는 보안 강화 기법입니다.
- 동작 방식:
  1. 클라이언트가 만료된 액세스 토큰을 갱신하기 위해 리프레시 토큰을 사용해 재갱신 요청을 보냅니다.
  2. 서버는 요청이 유효한 경우 새로운 액세스 토큰과 새로운 리프레시 토큰을 발급합니다.
  3. 기존 리프레시 토큰은 무효화되며, 더 이상 사용할 수 없게 됩니다.
  4. 클라이언트는 새로운 리프레시 토큰을 저장하고 이후 요청에 사용합니다.

4. 동시성 처리

둘 중에 한명은 만료됨?

5. 쿠키 설정 값들 설명

쿠키에는 다양한 설정 값이 있으며, 이를 통해 보안성과 기능을 강화할 수 있습니다. 대표적인 쿠키 설정 값은 다음과 같습니다:

max-age:
쿠키의 유효 시간을 설정하는 속성입니다. max-age는 초 단위로 설정되며, 지정된 시간이 지나면 쿠키가 자동으로 만료됩니다. 예를 들어, max-age=3600으로 설정하면 쿠키는 1시간 후에 만료됩니다. 유효 시간이 지나면 쿠키는 자동으로 삭제됩니다.
secure:
쿠키를 오직 HTTPS 연결을 통해서만 전송하도록 하는 속성입니다. secure 설정이 되어 있으면, 안전하지 않은 HTTP 연결에서는 쿠키가 전송되지 않습니다. 이를 통해 네트워크 상에서 쿠키가 탈취되는 것을 방지할 수 있습니다. 따라서 보안이 중요한 정보(예: 인증 토큰)는 반드시 secure 속성과 함께 사용해야 합니다.
HttpOnly:
자바스크립트에서 쿠키에 접근할 수 없도록 하는 속성입니다. HttpOnly 설정이 되어 있으면, XSS(크로스 사이트 스크립팅) 공격에 의한 쿠키 탈취를 방지할 수 있습니다. 이 속성은 특히 세션 쿠키나 민감한 정보를 다룰 때 중요한 보안 설정입니다.
path:
쿠키가 특정 경로에 대해 유효하게 작동하도록 설정할 수 있는 속성입니다. path 속성은 쿠키가 적용될 URI 경로를 지정하며, 해당 경로 또는 하위 경로에만 쿠키가 전송됩니다. 예를 들어, path=/admin으로 설정된 쿠키는 /admin과 그 하위 경로에서만 전송됩니다. 이를 통해 쿠키의 범위를 제한할 수 있습니다.
domain:
쿠키가 전송될 도메인을 지정하는 속성입니다. domain을 설정하지 않으면 기본적으로 현재 도메인에만 쿠키가 전송됩니다. 하지만 특정 서브도메인이나 다른 도메인에서도 쿠키를 사용하려면 이 값을 설정할 수 있습니다.
SameSite:
쿠키가 크로스사이트 요청에서 전송되지 않도록 방지하는 속성입니다. SameSite 속성은 Strict, Lax, None 값으로 설정할 수 있으며, 이 속성을 통해 CSRF(크로스사이트 요청 위조) 공격을 방지할 수 있습니다. Strict로 설정하면 같은 사이트 내에서만 쿠키가 전송되며, Lax는 일부 크로스사이트 요청을 허용하지만, 기본적으로 CSRF 공격을 방지합니다.

이러한 설정 값들은 쿠키의 보안성과 유효성, 그리고 사용 범위를 결정하는 중요한 요소입니다. 면접에서 쿠키 설정에 대한 질문을 받을 경우, 각 속성의 목적과 사용하는 이유에 대해 설명하는 것이 좋습니다.

6. 쿠키 vs 세션

쿠키:
쿠키는 클라이언트 브라우저에 저장되는 작은 데이터 파일이다. 서버와의 통신 시, 쿠키는 HTTP 요청 헤더에 포함되어 전송되기 때문에 클라이언트와 서버 간의 상태를 유지할 수 있다. 하지만 쿠키의 크기가 커지면 매번 전송되는 페이로드가 증가하여 네트워크 통신 성능에 영향을 미칠 수 있다. 또한, 쿠키는 클라이언트 측에 저장되므로 상대적으로 보안에 취약하다.
세션:
세션은 서버에서 관리되며, 서버가 사용자의 상태 정보를 저장하고 클라이언트는 세션 ID만 보유한다. 클라이언트는 서버에 세션 ID를 전송하여 상태를 확인하고, 실제 데이터는 서버에서 관리되므로 보안성이 더 높다. 세션은 일정 시간 후 만료되며, 사용자가 로그아웃하거나 브라우저를 닫을 경우 세션이 종료될 수 있다.
보안 차이:
쿠키는 클라이언트에 저장되므로 데이터 탈취나 변조의 위험이 있지만, 세션은 서버에서 관리되기 때문에 보안성이 더 높다. 특히 중요한 정보나 인증 데이터를 다룰 때는 세션이 더 안전한 방법으로 간주된다.
네트워크 성능 차이:
쿠키는 클라이언트와 서버 간 통신 시 매번 헤더에 포함되어 전송되므로, 쿠키의 양이 많아질수록 네트워크 트래픽이 증가하여 성능이 저하될 수 있다. 반면, 세션은 서버에서 상태를 유지하므로 클라이언트 측 데이터 전송이 최소화된다.