인증 방식의 종류
서버가 클라이언트 인증을 확인하는 방법은 크게 3가지가 있다.
1. 쿠키
2. 세션
3. 토큰
쿠키
Key - value 형식으로 이루어져 클라이언트가 어떤 웹사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트 브라우저에 설치되는 기록 정보 파일이다.
각 사용자마다의 브라우저에 정보를 저장해 고유 정보 식별이 가능하다.
쿠키 인증 방식
- 브라우저가 서버에 요청을 보낸다.
- 서버는 클라이언트의 요청에 대한 응답을 작성할 때, 클라이언트 측에 저장하고 싶은 정보를 응답 헤더의 cookie에 담을 수 있다.
- 이후 해당 클라이언트는 요청을 보낼 때마다 매번 저장된 쿠키를 헤더에 담아 보낸다. 그 쿠키를 이용해 클라이언트가 누군지 식별한다 => 추천 알고리즘
쿠키 단점
- 보안에 취약하다
- 쿠키의 값을 그대로 보내기 때문에 유출/조작될 위험이 있다.
- 용량 제한이 있다.
- 웹 브라우저마다 쿠키의 지원형태가 달라 브라우저간 공유가 불가능하다.
- 네트워크의 부하가 심해진다.
세션
클라이언트의 정보를 서버측에 저장하고 관리한다. 서버의 메모리나, DB에 저장하기도 한다. 민감한 정보들은 보내지 않고, 서버에서 관리할 수 있다.
세션은 Key에 해당하는 ID와 이에 대응하는 Value로 이루어져 있다.
value에는 세션 생성 시간, 마지막 접근 시간 및 user가 저장한 속성등이 map 형태(Object) 로 저장된다.
세션 인증 방식
- 유저가 웹사이트에 로그인하면 세션이 서버에 저장된다. 이때, 세션을 식별하기 위한 Session ID를 기준으로 정보를 저장하게 된다.
- 서버에서 브라우저에 쿠키에다 Session Id를 저장한다.
- 쿠키에 정보가 담겨있기 때문에 브라우저는 해당 사이트에 모든 Request에 SessionId를 쿠키에 담아 전송한다.
- 서버는 클라이언트가 보낸 Session Id와 서버 메모리로 관리하고 있는 Session Id를 비교해 인증을 수행한다.
세션 단점
- 세션 ID 자체는 유의미한 정보는 아니다. 하지만 ID를 탈취당하면 클라이언트인 척 위장할 수 있다.
- 서버에서 세션 저장소를 사용하므로 요청이 많아지면 부하가 심해진다.
토큰
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 토큰을 부여한다. 이 토큰을 유일하며, 모든 요청의 헤더에 토큰을 실어서 보낸다. 서버에서는 이 토큰을 서버에서 제공한 토큰과 일치하는지 체크하여 처리하게 된다.
기존의 세션기반 인증은 파일이나 DB에 세션정보를 가지고 있어야 해서 조회할 때 많은 오버헤드가 발생한다.
토큰은 클라이언트에 저장되기 때문에 서버의 부담을 덜 수 있다. 토큰 자체에 데이터가 들어있어 클라이언트에서 받아 위조되었는지 판별만 하면 된다.
쿠키와 세션은 앱에 존재하지 않기 때문에 앱에서는 토큰을 사용해야한다
토큰의 인증 방식
- 클라이언트가 로그인을 시도한다
- 서버에서 토큰을 발급한다.
- 클라이언트는 토큰을 저장했다가 요청할때마다 헤더에 담아 전달한다.
- 서버는 토큰을 검증하고 응답한다. DB를 조회하지 않아도 누가 요청했는지 알 수 있다.
토큰의 단점
- 토큰 자체의 데이터가 길어, 인증 요청이 많아질수록 네트워크 부하가 생긴다.
- Payload 자체는 암호화되지 않아 중요한 정보는 담을 수 없다.
- 토큰을 탈취당하면 대처가 어렵다. (사용시간 제한 등의 방법..)
주경야독