웹 사용자 인증방식 [ 쿠키 , 세션 , 토큰 ]

우리가 웹에서 서버와 통신할때는 http라는 통신 프로토콜을 이용하여 통신합니다.

인증방식의 존재이유부터 설명하자면 이 http는 보통 지속적이지 않습니다.

그래서 서버에 요청이 들어올때마다 사용자에 대한 정보가 없다면 서버측은 누가 보낸 요청인지 알 수가 없음

ex) 서버입장에선 페이지 넘버, 목록번호 등 만 포함하여 서버에 요청한다면 얘가 누군데 요청하는거야? 하고 알 수가 없고 거절할 것

 

보안이 중요한 케이스로 병원의 환자정보를 열람하는 시스템을 들어갔다 하면,

클라이언트가 서버에 요청을 할때마다 인증여부를 포함해주지 않는다면 / 서버는 요청한 클라이언트가 인증된 사용자인지 알 수가 없습니다.

이것을 서버가 사용자를 식별하지 못하는 무상태(Stateless) 라고 하고,

http 통신의 이 특징때문에 매번 인증절차를 밟을 수 밖에 없어요. 

ex) 페이지 넘버, 환자번호 등 만 포함하여 서버에 요청한다면 쉽게 환자정보를 주지 않겠죠.

(반면 http 통신이 지속적이지 않아서 그만큼 서버의 부담이 줄어들긴 합니다.)

 

그래서 사용자를 인증해주기 위해 여러 기법이 생겼고,

그 중 쿠키, 세션, 토큰에 대한 포스팅입니다.

 

 

---

 

1. 쿠키

 

클라이언트의 로컬에 저장되는 키와 값이 들어있는 파일입니다.

서버측에서 http response header에 set-cookie 속성을 이용하여 클라이언트에게 쿠키를 제공합니다.

그 후 클라이언트 측에서는 쿠키를 이용하여 무언가를 하거나,

서버에 요청할 시 http requeset header에 cookie가 담겨 서버측에서 사용자를 인식할 수 있다.

 

 

2. 세션

 

쿠키와는 달리 서버의 저장소를 이용합니다.

만약 쿠키만으로 인증한다면 로그인시의 계정정보가 http요청에 고스란히 담겨 있어 보안상의 문제가 있습니다.

허나 세션방식에서는 쿠키를 이용하여 유저가 사이트에 접근했을 시 유저의 session-id만을 생성하여 클라이언트 측에 담아주고,

서버쪽으로 요청이 들어왔을시 session-id(쿠키) 값을 받아 사용자를 인식 및 인증할 수 있습니다.

쿠키와는 달리 서버측에 데이터가 저장되니 보안상에서 더 안전함

 

 

2.5 쿠키&세션

 

그럼 세션이 더 좋아보이는데 쿠키를 사용하면 안되겠네용?

=> X

해당이유로는

    1. 만료기한

    쿠키는 만료기한 조정 가능

    세션도 만료기한 조정 가능 but 브라우저를 닫을 시 사라짐

    2. 서버부담

    세션은 서버의 자원을 이용하기에 그만큼 서버속도가 느려질 수 있다.

각 방식을 알맞는 케이스에 사용하면 됨

 

 

3. 토큰(JWT)

 

토큰은 먼저 로그인을 하여 클라이언트가 서버측에 인증을 요구하고,

인증완료 후 서버가 클라이언트 측에 토큰을 전달해준다.

그 후 클라이언트는 토큰을 http header 등에 저장하여 서버측에 요청을 할 때마다 이 토큰을 같이 실어주면 끝.

서버는 토큰을 확인후 해당 요청을 수행한다.

 

1. MSA구조에서는 각 서버마다 세션을 동기화하거나, 각각 구현해야할 수 있음

2. 세션구조는 서버에 부담이 갈 수 있음

위 이유로 토큰을 많이 채택하는 추세

 

허나 클라이언트에 사용자 정보들을 저장하다보니

패스워드와 같은 중요정보는 담으면 안되고,

트래픽이 늘어난다는 단점이 있음

 

토큰탈취의 대처법으로는

짧은 유지기간과 refresh token 기법을 사용함

유효기간을 짧게 하는 대신에 자주 재발급시키자는 의도인데,

기존 인증 토큰(access token 이라 함)외에 유효기간이 긴 refresh token을 새로 두어

access token이 만료되었다면 이 refresh token을 이용해 access token을 재발급 받음

 

하지만 이것도 완벽하지않음

데이터베이스, 기타 수단 등을 이용해 refresh token을 관리하더라도

탈취당한다면 access token이 만료될때까지 손볼수없단점과,

refresh token을 서버에서 관리하면할수록 세션의 단점이 이어져옴