JWT?
- 유저를 인증하고 식별하기 위한
토큰 기반 인증방식 - 인증에 필요한 정보들을 암호화시킨
JSON 형식의 토큰 - 세션과 달리 서버가 아닌
클라이언트 측에 저장된다.
- 헤더, 페이로드, 서명 3가지 구조를 갖는다.
누가 누구에게 발급했는지, 언제까지 유효한지, 사용자 정보 등이 포함되어 있음.
헤더: type, algorithm.
algo -> 3번 서명값과 일치 여부를 판단할 값을 만드는데 사용할 알고리즘이 저장됨. (HS256 ...)
서버는 사용자 요청에서 실어보낸 토큰의 1번 헤더, 2번 페이로드, 서버 비밀 값을 이 알고리즘에 넣고 돌려, 3번 서명 값과 일치하는지 확인 -> 인가하게 된다.
JWT의 장점?
- 인증에 필요한 모든 정보를 담고 있기 때문에 서버에 별도의 저장소가 없어도 된다.
- 모바일에서도 동작한다(
세션은 모바일 환경에서 힘들다)
-> Why?
-
토큰은 만들어서 클라이언트에 전달하는 방향으로 개발이 많이 진행되었기 때문에 전달만 잘 된다면 다양한 포맷(json, xml)에 구분없이, 그리고 상태와 상관없이 폭 넓게 사용이 될 수 있다. 이것이 모바일 생태계에 잘 맞는 인증 방법이었으며 아래의 이유들로 안쓸 이유가 없어졌다.
-
세션처럼 관리될
필요성이 없다.
즉, 웹과 정보 유지 방식이 다르다.
앱은 그 자체로 파일 시스템에 엑세스 할 수 있을 뿐만 아니라 내부 DB도 가질 수 있기 때문에 쿠키와 세션을 통해 통신할 필요가 없다.
서버에서 받은 유저 데이터는 따로 저장해두고 사용하면 되고, 로그아웃 하지 않는 이상 이 값은 지워지지 않는다. -
보안 수준이 웹과 다르다
웹은 경로가 주소에 공개되어 있고, 중간 탈취할 가능성을 고려하는게 맞다.
하지만 앱은 사용자와 1대 1 매칭되고, 정보 탈취 가능성이 상대적으로 낮기 때문에 세션 관리의 필요성이 낮다.
- 하지만 그렇다고 아예 보안을 설정하지 않을 순 없다.
1. 앱의 고유 해쉬값을 서버로 전달해서 저장해두거나,
2. 앱이 실제 마켓에서 받았는지 검증하는 방식을 이용한다.
- DB 조회 없이 인증/인가 과정이 가능하기 때문에, DB가 죽어도 서버도 같이 죽지 않을 수 있다.
단점?
- 이미 사용자에게 발급한 토큰을 뺏을 수도 없고 그 토큰으 발급 내역이나 정보를 서버에서 기록하거나 추적하고 있지 않기 때문에 통제가 안될 수 있다.
- 토큰이 탈취당하면 토큰을 무효화 할 방법이 없다.
보완 방법?
토큰을 두 개 주는 방식!
- 수명이 몇 시간이나 몇 분 이하로 짧은
access 토큰, - 2주 정도로 꽤 긴
refresh 토큰
사용자의 access 토큰이 수명을 다하면 사용자는 refresh 토큰을 서버로 보내고,
서버는 해당 토큰을 DB에 저장한 값과 대조 -> 맞다면 새 access 토큰을 발급한다.
그렇게 되면, 토큰이 탈취당해도 access token은 수명이 짧기 때문에 오래 쓸 수 없다. 또, DB에서 refresh 토큰을 지워 갱신이 안되도록 하면 차단이 가능하다
그러면, 저 Refresh 토큰만 서버에서 안전하게 관리된다면 안전하다.
Redis를 함께 사용하는 이유
Access Token 재발급을 위해 Redis 인메모리 저장소를 사용한다.
즉, Refresh Token 저장을 위해 인메모리 저장소로 Redis를 사용하는 것이다.
근데 왜 Redis 가 가장 적합한가?
- Redis의 장점은
I/O 가 빈번한 데이터를 저장할 때 사용하기 좋다.
그리고key-value 형태의 데이터 타입을 처리하는데 좋다고 한다.
동작 로직
Expiration time 철학
Access Token 은 서버에 저장되지 않고 토큰 자체로 검증/인증을 하는 토큰이기 때문에 만료시간을 짧게 가져가야 한다.
보통 30분 ~ 2시간으로 가져간다.
Refresh Token 은 반면에 접근에 대한 권한을 주는게 아니라 access token 재발급에만 관여하기 때문에 더 긴 만료시간을 가져가는 게 맞다.
보통 2주 ~ 3달로 가져간다.
