개요
원래는 JWT에 대해서 공부하고 포스팅하려 했는데, 토큰을 공부하다보니 쿠키, 세션, 캐시가 계속 눈에 밟혀서 깊게는 아니더라도 좀 파고들어 봐야겠다고 생각했다. 인증과 인가의 방식들에 대해서 살펴보고자 한다.
참고 글
정말 감사합니다.....ㅎ
- 상태정보를 유지하는 기술
쿠키
- key-value 형식의 문자열
- 웹서비스 유저들의 효율적이고 안전한 웹 사용을 위한 것이다.
- 쿠키는 유저가 웹사이트 접속시 접속자의 개인장치에 다운로드되고 브라우저에 저장되는 작은 텍스트 파일이다.
- 웹사이트(서버)는 쿠키를 통해 접속자임을 인식하고, 접속자의 설정 정보, 과거 사이트 이용내역의 일부 데이터를 서버에 저장한다.
세션쿠키
- 브라우저를 닫으면 자동 삭제
지속적 쿠키
- 수동으로 삭제하기 전까지 오랫동안 컴퓨터에 저장
Cookie 인증 방식
출처 : Dev Scroll
- 클라이언트(브라우저)가 서버에 요청을 보낸다.
- 서버는 요청에 대한 응답을 보낼 때, 클라이언트에 저장할 정보를 응답 헤더의 Set-Cookie에 담아 보낸다.
- 이후에 클라이언트는 어떤 요청을 보내든지, 쿠키를 요청 헤더의 Cookie에 담아 보낸다.
서버는 쿠키의 정보를 기반으로 요청의 클라이언트가 누구인지 식별한다.
Cookie의 단점
- 보안에 취약
요청시 쿠키의 값을 그대로 보내어 유출 및 조작을 당할 수 있다. - 쿠키는 용량 제한이 있다.
- 브라우저마다 쿠키의 형태가 달라 서로 다른 브라우저간 공유가 안된다.
- 쿠키가 커질수록 네트워크에 부하가 심해진다.
Session
- '일정한 시간'동안 한 사용자로부터 오는 요청들을 하나의 상태로 보고 그 상태(인증된 상태, 로그인된 상태?)를 일정하게 유지시키는 기술
- 일정한 시간 :
사용자가 웹 서버에 접속한 시점 ~ 웹 브라우저 종료로 연결이 끊기는 시점 - 쿠키의 보안 이슈 때문에, 세션은 클라이언트의 민감한 정보들을 클라이언트가 아닌 서버에 저장하고 관리한다.
- 메모리(책상), 로컬 파일(서랍), DB(창고)
Session의 인증 방식
출처 : Dev Scroll
- 유저가 로그인하면 세션이 서버에 저장된다.
- 서버에서 브라우저에 쿠키에다가 Session Id를 저장한다.
- 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 대한 모든 Request에 Session Id를 쿠키에 담아 전송한다.
- 서버는 클라이언트가 보낸 Session Id 와 서버 메모리로 관리하고 있는 Session Id를 비교하여 인증을 수행한다.
Session의 단점
- 세션 ID를 탈취당하면 탈취한 사람이 해당 클라이언트로 위장할 수도 있다.
- 서버에 세션을 저장하기 때문에 요청이 많아지면 서버에 부하가 심해진다.
Token
- 클라이언트가 서버에 접속시 서버에서 클라이언트에게 토큰을 발급한다.
- 이후에 클라이언트가 보내는 요청에는 항상 토큰을 함께 보낸다.
- 서버는 이 토큰이 서버에서 발급한 토큰이 맞는지 체크한다.
- 토큰은 클라이언트에 저장되기 때문에 세션 방식보다 서버를 편하게 할 수 있다.
- 토큰 방식은 앱과 서버의 통신에서 가장 많이 사용된다.
웹은 쿠키, 세션이 있지만 앱은 없기 때문
Token 인증 방식
출처 : Dev Scroll
1. 사용자가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.
3. 클라이언트는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 서HTTP 요청 헤더에 포함시켜 전달한다.
4. 서버는 전달받은 토큰을 검증하고 요청에 응답한다.
토큰에는 요청한 사람의 정보가 담겨있기에 서버는 DB를 조회하지 않고 누가 요청하는지 알 수 있다.
Token의 단점
- 토큰 자체의 길이가 길어서 인증요청이 많아질수록 네트워크의 부하가 심해질 수도 있다.
- Payload자체는 암호화가 되지 않아서 사용자의 중요한 정보는 담을 수 없다.
- 토큰은 위조 방지에는 강하지만 탈취당했을 때는 대처가 어렵다.
마무리
JWT에 대해서 공부하려다보니 어쩌다 쿠키, 세션도 모두 봤다.
다음 글에는 JWT를 파봐야겠다.
BackEnd Developer