목차
JWT 의 등장
•
웹시장의 규모가 커지면서 웹 서비스가 핸들링 해야하는 규모 또한 커졌습니다.
•
또한 로그인 횟수 등이 유저에게 큰 불편함을 주었고, 이는 결국 유저 이탈 등의 비용적 손해로 직결되었습니다.
◦
서비스 인식 / 재방문 감소
원활한 서비스 운영을 위한 (= 수익, 비용) 발전 과정에서 나온 대안입니다!
JWT
•
JWT 는 우리가 담고싶은 정보(유저id, 권한, 인증 등)와 만료 정보가 있습니다.
•
때문에 DB에 저장하고 읽고 비교하는 로드가 사라졌습니다.
◦
단순히 특정 알고리즘 과 Key 로 토큰을 열어 어떤 유저인지, 만료 되었는지 체크할 수 있습니다.
•
하지만 기존 Token 때와 마찬가지로 일정 기간이 지나면 만료가 되어 유저가 재로그인 해야하는 이슈는 여전했습니다.
◦
JWT 만료 기간을 무한대로 늘리면 탈취, 유출 되었을 때 위험성이 커집니다.
◦
반대로 만료기간을 작게하면 유저의 로그인 주기가 짧아지게 됩니다.
인증서버와 자원서버
웹시장의 발전으로 더욱 많은, 다양한 서비스를 제공하게 되었습니다.
•
서버가 다중화 되어 로드를 분산수행합니다.
◦
같은 기능의 서버를 로드밸런싱을 통해 다중 제공 합니다.
◦
MSA 를 통해 서비스를 작은 단위의 여러 서비스로 제공합니다.
하지만 모든 서버와 MSA 들이 JWT 를 발행할 줄 알아야 할까요? 
•
요즘에는 유저 인증에 관여하는 인증 서버와 로직을 수행하는 자원 서버로 분리합니다.
•
또한 외부 인증서버를 활용하여 인증서버 역할을 위임하고, RESTful API 개발에만 몰두 합니다. (+ 안정성)
◦
카카오 로그인
◦
네이버 로그인
◦
구글 로그인
◦
AWS Cognito
Refresh Token 의 등장
JWT 만료 기간을 짧게 줄이고, 유저가 로그인을 인지하지 못하게 하자!
•
AccessToken = 30 초, 5 분 ~ 60 분, 1 일
•
RefreshToken = 30 일
◦
Access Token 기한은 서비스 중요도에 따라, 알고리즘 별 해킹 시간이 다르니 이 또한 고려해야 합니다.
◦
Refresh Token 의 등장으로 인해 Access Token 의 만료 시간이 짧더라도 유저는 이를 인식하지 못합니다.
Refresh Token 이 탈취 되면?
1. 인증서버
- RT 발행 및 저장(DB)
- AT 발행
2. 클라이언트
- RT 저장(Store)
- AT 저장(Store)
3. 자원서버
- 클라이언트 요청 Header 에서 AT 검증하여 응답
4. 클라이언트
- AT 만료 시(401)
- 인증서버에게 RT 로 AT 재발급요청
5. 인증서버
- 재발급 요청한 RT 및 DB에 저장된 발급자 정보를 통해 유효한지 검증 후 AT 재발급
Markdown
복사
•
Access Token 탈취 당하면 만료 전까지 (30분 등) 마음대로 사용 가능하겠지만
Refresh Token 를 탈취 하더라도 이는 인증서버에서 검증하는거라 더 수준높은 보안을 적용할 수 있습니다.
•
예시 어제 집에서 디스코드 사용하다 오늘 스타벅스에서 디스코드를 키면 Access Token 이 만료되었으니 Refresh Token 로 재발급 요청을 하라고 합니다. 하지만 해당 Refresh Token 는 집 ip 로 발행된거라 스타벅스 ip 에서는 Refresh Token 못쓰니 재로그인을 해야 합니다.
•
예시 구글 로그인의 경우 RT 유효성 뿐만이 아니라 허용된 디바이스 목록에 있어야만 로그인이 가능합니다. 허용된 디바이스 에서 새 디바이스를 허용해야 합니다.