0817_세션과 토큰에 대하여

로그인시 중요한 세션과 토큰에 대해 알아보자!

1. 인증과 인가에 대해서 알아야 세션, 토큰에 이해가 잘됨!

• 인증(Authentication)이란 : 우리가 알고있는 로그인. DB에서 로그인 할때 사용하는 id, pw 가 사용자가 입력한 데이터와 일치하는지 확인하는 것. 인증만 되서 되는게 아니라, 로그인을 반드시 해야만 할 수있는 활동 예를들어 인스타그램 포스팅하기, 비공개인 친구의 포스팅 확인 하기 등을 할때 매번 로그인을 계속 할 수는 없다. 로그인의 과정은 복잡하다. 유저가 로그인을 하기 위해 입력한 id, pw 를 db에 저장되어있는 id, pw(비밀번호는 또 해시값 등을 통해서 암호화된 pw 일테니 알고리즘으로 복호화 해서 입력값과 일치여부를 비교해야 함) 그리고 매번 필요할 때마다 아이디와 비밀번호가 전송된다면 중간에 갈취될 위험성도 있다.
• 인가(Authorization) : 한번 로그인을 완료 한 유저가 로그인을 반드시 한 후에 할 수 있는 활동을 시도할때, 내가 로그인 완료 된 유저라는 것을 확인하고 허가해주는것

2. 그래서 인가를 좀더 쉽게 하기 위해 세션이라는 개념이 생김

• 세션(session) : 로그인을 성공하면 비행기 티켓처럼 반은 브라우저의 쿠키에 저장하고, 나머지 반은 메모리(경우에 따라 db가 될 수도 있음)에 저장한다. 세션아이디를 사용해서, 특정 사용자가 계속 로그인이 되어있음을 인가 해주는 이 상태를 ‘세션’이라고 함. 단점이 있다. 사용자가 동시에 많이 접속하는 경우 서버에 과부하가 올 수 있다. 그리고 서버를 부팅해야 하는 경우 이용중이던 유저가 모두 로그인을 다시 해야한다. 그렇다고 표 반쪽을 하드에다 저장하는건 무리다. 만약에 규모가 있는 서비스라 여러개의 서버를 돌리는 경우, 1번 서버에서 로그인 하면 3번 서버에서 진행되는 활동은 못할 수도 있으니까. 그렇다고 일정한 서버에만 요청하도록 프로그래밍 하는것도 어렵다.

• 그래서 고안된 것이 jwt(Json web token) 토큰이란, 로그인을 한 유저에게 토큰을 준다. 반 찢어 주는게 아니라 그냥 다 준다. 서버는 로그인 할떄 무언가 기억하지 않는다. 토큰은 3가지로 구성된다. header / payload / signature base64 로 디코딩 하면 json 형식으로 여러 정보가 들어가있다. 누가 발급했는지, 언제까지 유효한지, 서비스가 사용자에게 공개하기로 한 내용 등등이 들어가 있다.

  

  하지만 이 정보를 모두 공개하면 정보를 멋대로 조작하거나 악용할 수 있음. 그래서1번 헤더와 3번 서명으로 이것을 방지한다. 3번에서 사용되는 서명값을 암호화 하는 알고리즘이 1번 헤더에 저장됨. 그리고 ‘서버에 감춰놓은 비밀값’ 이 암호화 알고리즘에 필요함. 암호화 알고리즘이란, 한쪽 방향으로는 계산이 되도 반대 방향으로는 불가능 해서 서버에 감춰놓은 비밀값을 모르면 디코딩이 불가능하다 = 조작 불가능 서버는 요청에 토큰이 실려오면, 1,2 번의 값을 서버의 비밀값이랑 함꼐 돌려봐서 계산된 값이 3번과 동일한지 확인한다. 동일하지 않으면 조작된 값이라 판단 해서 거부된다. 서버는 특별한 것을 기억할 필요 없이 비밀값만 가지고 있고, 요청들어올때마다 토큰을 스캔해서 사용자를 걸러낼 수 있다. 때문에 시간에 따라 변경되는 어떤 상태를 가지고 있지 않음(stateless하다) 반면에 세션은 stateful 하다.

3. jwt 가 절대적인 것은 아니다.

이미 발급된 토큰을 뺏을 수가 없다. 토큰이 해킹당했다는 것을 인지해도 할 수 있는것이 아무것도 없다. 그래서 jwt 만으로 인가를 구현하지 않고 refresh token, access token 을 발급한다.

access token 의 유효시간을 짧게 해서, 유효기간이 다 되면 데이터 베이스에 저장된 refresh token 을 확인해서 맞다면 새로운 access token 을 발급해준다. refresh token 만 안전하게 관리된다면 중간에 만약 access token 이 탈취되더라도 유효시간 내 밖에 사용하지 못함. 하지만! 탈취된 사실을 안 즉시 어떠한 조치를 취할 수는 없다. 정답은 없으니 내 서비스의 상황에 따라 맞게 설계하면 되겠다.