토큰 기반 인증 방식 (JWT: JSON Web Token)
💡 JWT 토큰이란
- JWT 토큰은 토큰 기반 인증 방식으로, 헤더, 페이로드, 시그니처 세 가지 구성요소가 있습니다.
- JWT 토큰 동작을 살펴보면 클라이언트가 서버에 인증/인가가 필요한 도메인에 요청이 들어오면 서버는 사용자 정보 검증 후 토큰 생성 (Access, Refresh 둘 다) 후 클라이언트에게 유효한 토큰을 발급합니다. 이 후 요청부터는 클라이언트는 HTTP 헤더에 토큰을 담아 서버에 요청을 보냅니다. 서버는 헤더에 존재하는 토큰을 해독한 후 요청 처리에 응답합니다.
- 헤더: 토큰 저장
- 페이로드: 사용자를 식별할 수 있는 정보, 권한 등 저장
💡 토큰 기반 인증 방식과 서버 기반 인증 방식의 차이점
- 서버 기반 인증 방식은 서버에 세션을 저장하기 때문에 사용자의 수가 많아지면 서버의 부하가 높아지는 단점이 있습니다.
- 그러나 토큰 기반 인증 방식은 요청 들어온 토큰만 검증하면 되므로 부하가 적고 확장성이 좋습니다.
💡 JWT 토큰의 단점
- JWT 토큰의 단점은 토큰을 강제로 만료시킬 수 없다는 점입니다. 그렇기 때문에 Refresh 토큰과 Access 토큰을 함께 사용합니다.
- Access 토큰의 만료시간은 짧게, Refresh 토큰의 만료시간은 길게 지정하여 Access 토큰이 만료되면 Refresh 토큰을 이용하여 사용자에게 다시 로그인을 요청합니다.
서버 기반 인증 방식
💡 cookie와 session에 대해 설명
- 세션과 쿠키는 http 비연결성을 해결하기 위해 사용자 정보를 저장하는 역할을 합니다.
- 세션은 서버에 저장되어 안전합니다. 하지만 세션만을 사용하게 되면 서버에 부하가 발생하게 됩니다.
- 쿠키는 클라이언트 저장소에 저장되어 세션보다 보안성이 낮지만 서버에 부하를 주지 않아 자주 사용됩니다.
💡 Session 동작 순서를 설명
- 클라이언트가 로그인을 하고, 성공하면 서버가 사용자 세션을 만들고 메모리나 DB에 저장합니다. 그리고 서버가 클라이언트에게 세션 아이디를 보내고 클라이언트의 브라우저에 세션 아이디만 쿠키에 저장하게 합니다.
💡 cookie를 쓰는 이유를 설명
- 세션을 많이 사용하면 서버에 부하가 가기 때문에 쿠키를 사용합니다.
💡 세션 인증방식 단점
- 세션 데이터가 서버의 메모리에 저장되므로 확장 시 모든 서버가 접근할 수 있도록 별도의 중앙 세션 관리 시스템이 필요합니다.
- 중앙 세션 관리 시스템이 장애가 일어나면 전체 시스템에 문제가 생깁니다.
💡 쿠키 인증방식 해결방안
- Secure 옵션 : HTTPS로 통신하는 경우에만 웹브라우저가 쿠키를 서버로 전송한다. XSS 문제를 완화시킬 수 있다.
- HttpOnly 옵션 : document.cookie를 이용해서 쿠키에 접속하는 것을 막는다.
- CSURF 라이브러리 : 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격인, CSRF(Cross Site Request Forgery 사이트 간 요청 위조)를 예방할 수 있다
