인증 (Authentication) : 쉽게 말하면 로그인, 클라이언트가 특정 서비스에 일정 권한이 주어졌는지 아이디와 패스워드를 통해 인증을 받는 것
인가 (Authorization) : 서비스에서 사용자가 인증을 받았을 때만 할 수 있는 활동을 시도할 때 인증 유무를 통해 허가해 주는 것 (ex. 페이스북에서 내 친구 타임라인에 글을 올리는 행동)
Session의 취약점
- 서버가 꺼져버릴 경우 메모리에 있는 세션이 날아간다. -> 세션에 있었던 멤버들이 전부 로그아웃이 되어 다시 로그인을 해야한다.
- 서버를 여러 대를 둘 경우 구현이 까다로움. (ex. 1번 서버에서 로그인, 3번 서버에서 인가가 필요한 서비스를 받는 경우에 3번 서버에는 사용자의 정보가 세션에 저장되어 있지 않음.)
- 공용 db 또는 레디스 MemCached 같은 메모리형 데이터베이스 서버에 세션을 저장하는 방법으로 어느 정도 해결되나, 이 역시 1번과 같은 이슈를 가지고 있음.
JWT 토큰
- Encoded
- Decoded
JWT 취약점
- Stateless한게 단점. jwt의 토큰의 정보를 서버에 저장하지 않으므로, 누군가 이 토큰을 탈취한 경우에 토큰을 무효화 할 방법이 없음.
- 예를 들면 PC에서 로그인한 사용자가 모바일로 또 로그인을 하면기존 로그인을 해제하고 로그인 하겠냐는 알림이 뜨지만 jwt에서는 이 방식이 어렵다.
완벽하지 않은 해결 방법
- 유효 기간이 짧은 access 토큰, 유효 기간이 긴 refresh 토큰을 브라우저에 보내고 refresh 토큰의 값을 DB에 저장한다.
- 브라우저의 access 토큰의 수명이 다할 시 브라우저는 refresh 토큰을 서버에 보내고, 서버는 보낸 토큰이 저장된 refresh 토큰과 일치하는지 확인하여 맞다면 새 access 토큰을 보낸다.
- refresh 토큰만 안전하게 관리되면 access 토큰이 만료될 때마다 다시 로그인을 할 필요가 없음. 또한 중간에 access 토큰이 탈취되어도 refresh 토큰을 DB에서 지워 토큰 갱신을 안되게 할 수 있다. 하지만 그 짧은 시간에는 Jwt의 취약점과 동일한 상황이 발생할 수 있다.