세션, 토큰을 이용한 인증의 과정

 

쿠기로 로그인을 한다면

로그인

1. [C] 사용자가 입력한 ID,PW를 서버에 전송

2. [S] 사용자 정보가 맞다면 맞다는 응답 or 사용자 정보 응답

3. [C] 사용자 정보를 쿠키에 저장

 

사용자 정보가 필요한 요청

5. [C] 요청 헤더에 쿠키 추가

6. [S] 해당 쿠키로 사용자 정보 확인

7. [S] 사용자 정보로 요청 처리

 

위험 사항

쿠키 정보를 확인하는 것으로 사용자 정보를 확인할 수 있다.

추가 보안 로직이 없다면 쿠키를 탈취하는 것만으로도 사용자 정보가 필요한 요청에서 사용자를 흉내낼 수 있다.

 

세션으로 로그인을 한다면

로그인

1. [C] 사용자가 입력한 ID,PW를 서버에 전송한다.

2. [S] 사용자 정보가 맞다면 세션 생성, 서버에 저장 (SESSIONID  - INFO)

3. [S] Session Id 발급

4. [C] 발급받은 Session Id를 쿠키에 저장

 

사용자 정보가 필요한 요청

5. [C] 요청 헤더에 세션 쿠키 추가

6. [S] 세션 유효성 검증, 세션 Id에 해당하는 사용자 정보 확인

7. [S] 사용자 정보로 요청 처리

 

위험 사항

1. 서버의 메모리를 사용한다.

2. 추가 보안 로직이 없다면 세션Id를 훔치는 것으로 사용자 정보가 필요한 요청에서 사용자를 흉내낼 수 있다. (최초 세션 발급 시의 ip, user-agent를 기록하고, 비교하는 것으로 보안 강화)

3. 여러 was를 둘 경우 세션 관리의 어려움이 있다. (세션 동기화 문제)

4. 사용자간 세션 쿠키를 다루는 방식이 다를 수 있다. (웹/ 앱)

 

 

토큰(JWT)으로 로그인을 한다면

로그인

1. [C] 사용자가 입력한 ID,PW를 서버에 전송한다.

2. [S] 사용자 정보가 맞다면 (사용자 정보-시크릿키)를 포함한 토큰을 생성한다.

3. [C] 발급받은 토큰을 쿠키나 로컬스토리지에 저장 

 

사용자 정보가 필요한 요청

4. [C] 요청 헤더에 토큰 추가

5. [S] 토큰의 시크릿키(signiture)를 복호화하여 조작 여부, 유효기간을 확인한다.

6. [S] 유효한 토큰이라면 사용자 정보로 요청 처리

 

위험 사항

1. 토큰의 payLoad는 단순 base64 인코딩이므로 암호화가 들어가지 않는다. 중요 정보를 포함해선 안된다.

2. 토큰을 탈취하면 사용자 정보가 필요한 요청에서 사용자를 흉내낼 수 있다.

3. 서버에서 관리하는 세션과 달리, 해킹을 확인했을 떄도 해당 토큰의 유효성 여부를 서버에서 직접 제어할 수 없다. (유효기간을 짧게 설정해야한다.)

4. 토큰을 로컬 스토리지 또는 세션 스토리지에 저장하면 XSS 공격에 취약하다. Http Only 옵션의 쿠키를 이용한다.

 

** XSS와 Http Only 옵션

XSS는 웹 사이트에 스크립트를 숨기고 사용자가 이를 실행 시 사용자의 세션이나 쿠키 정보를 훔치는 해킹 행위이다. http Only 옵션 쿠키를 사용하는 것을, 자바스크립트에서 쿠키에 접근하는 것을 막아 XSS Cookie hijacking risk를 감소시킬 수 있다.