서버 인증 | 세션/쿠키 | JWT 토큰

 

1. 왜 서버 인증을 해야할까?

사용자 a가 로그인을 해서 a만의 리뷰를 쓰고 저장한다.  사용자 b도 로그인을 해서 b만의 리뷰를 쓰고 저장한다.
웹을 사용하는 사용자도 다르고 사용자마다의 정보도 모두 다르다. 그래서 서버는 a와 b가 로그인을 한다고 요청을 보냈을 때 누가 로그인을 하는지 정확히 알아야 한다. 만약 a가 로그인을 하였는데 b의 정보가 노출된다면 개인정보 유출의 문제가 일어날 수 있다. 따라서 클라이언트측에서 자신이 누구인지를 서버에게 알리고 서버는 그것을 알아차리고 사용자가 누구인지 어떤 정보인지를 파악하여 데이터를 전달한다.

 

---

2. 세션/쿠키 방식과 JWT토큰 방식.

인증방식에는 세션쿠키 방식과 jwt 토큰 인증방식이 있다.

 

 

2-1.  세션/쿠키 방식

세션 쿠키 방식의 순서를 요약해보자면 이렇다.
1. 사용자가 로그인을 한다.
2. 서버에서 로그인 정보를 읽어 사용자를 확인한 후에 사용자의 고유한 id 값을 부여하여 세션저장소에 저장하고 연결되는 세션 id를 저장한다.
3. 사용자는 서버에서 그 세션 id를 받아 쿠키에 저장한 후 인증이 필요한 요청마다 쿠키를 실어 보낸다.
4. 서버에서는 그 쿠키를 받아서 가지고 있던 세션 id 와 대조를 한 후 맞는 정보를 가져온다.
5. 인증이 완료되고 서버는 사용자에 맞는 데이터를 보내준다.

 

세션/쿠키 장단점

장점: 쿠키는 세션을 열기 위한 열쇠이므로 쿠키가 노출되더라도 쿠키에는 실제 사용자 정보가 들어있지았다. 따라서 http 주소값 방식으로  / 뒤에 보이는 것보다 안전하다. 

단점: 쿠키를 훔쳐와서 http 요청을 보내면 해당 사용자인 줄 알고 열쇠로 문을 열어버릴 수 있다.
해결책 -> 훔쳐가도 정보를 읽기 힘들게 한다, 유효시간을 준다.

 

 

---

 

2-2. JWT 토큰 방식

Jwt 토큰을 요약해본다면 이렇다.

토큰 만들기
Header : 암호화 할 방식, 타입이 들어감.
Payload : 서버에서 보낼 데이터가 들어감.
일반적으로 유저의 고유 id값, 유효기간이 들어간다.
Verify signature: 인코딩된 header, payload, secret key를  더한 후 서명된다.

Jwt 토큰 인증방식 순서
1. 사용자가 로그인을 한다.
2. 서버에서 로그인 정보를 읽어 사용자를 확인한 후에 사용자의 고유한 id 값을 부여하여 payload 에 넣는다.
3. Jwt 토큰의 유효기간을 정한다.
4. 암호화할 secret key를 이용해 access token을 발급한다.
5. 사용자는 access token을 받아 저장한 후 인증이 필요한 요청마다 토큰을 실어 보낸다.
6. 서버에서는 verify signiture를 secret key로 디코드(되돌리기)해서 조작, 유효기간을 확인한다.
7. 검증이 완료되면 payload를 디코드해서 사용자 id에 맞는 데이터를 가져온다.

 

세션/쿠키 와 JWT 토큰의 차이점

세션/쿠키 방식은 사용자의 정보를 서버의 세션저장소에 넣는다.
jwt는 사용자의 정보를 토큰 안에 넣는다.

 

JWT 토큰의 장단점

장점
1. 세션/쿠키 방식은 세션저장소 관리가 필요하지만 jwt는 발급한 후 암호화 된 것을 검증만 하면 되기 때문에 세션저장소 관리가 필요 없다.
2. 토큰을 기반으로 하는 다른 인증시스템에도 접근이 가능하다. 페이스북, 구글 로그인 등 모두 토큰 인증 방식이다. 

단점: 
세션/쿠키에서 쿠키가 노출되거나 잘못 사용될 경우 세션 id를 삭제해버리면 된다. 그러나 토큰은 유효기간이 만료될 때까지 사용이 가능하기 때문에 유효기간 전이라면 내 개인정보는 계속 노출상태로 있는 것이다.

해결책 : Access token의 유효기간을 짧게하고 refresh token이라는 새로운 토큰을 발급한다.

 

 

 

 

 

참고

https://tansfil.tistory.com/58?category=255594 서버 인증에 대해 잘 정리되어 있는 글.