Json Web Token
토큰 기반 인증 방식
절대로 민감한 정보가 들어가면 안된다.
누구나 디코딩 해서 풀어볼 수 있기 때문에
jwt는 암호화된 문자열이다 (X)
세 가지 구조로 구성된다.
헤더(Header), 페이로드(Payload), 서명(Verify Signature)
이 세 가지 부분이 . 으로 구분되어 하나의 문자열로 결합
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ0b2tlbl90eXBlIjoiYWNjZXNzIiwiZXhwIjoxNzI5OTQ0ODM3LCJpYXQiOjE3Mjk4NTg0MzcsImp0aSI6IjAzMmY2ODBhOWM2YjQ3YTI5NmZlZmJmNWFlZDM0MWRhIiwidXNlcl9pZCI6NX0.KAbexUZYojekapQ6UX_N9PedshIo1iyPEg-0QN-62cA
#Header.Payload.Signature헤더(Header)
토큰 타입"typ":"JWT", 서명에 사용된 해싱 알고리즘 정보"alg":"HS256"
페이로드(Payload)
- 토근 발급자, 토큰 대상자, 토큰 만료 시점exp (expiration),활성날짜, 발급 시점iat (issued at) 등등
여러 데이터가 담겨있는 부분 - 이곳에 서비스가 유저 정보를 담아서 인증
- 누구나 풀어볼 수 있기 때문에 민감한 정보를 담지않고 최소의 정보만 저장
- user의 pk 값 등
- 각각의 데이터는 Claim이라고도 하며 Key-Value 형태로 구성
서명(Verify Signature)
토큰의 무결성 검증을 위한 부분
헤더와 페이로드를 결합한 후 서버의 비밀 키(secret key)로 서명을 생성합니다. 이 서명 덕분에 토큰이 위조되지 않았음을 확인할 수 있습니다.
토큰 vs 세션
가장 큰 차이
토큰은 세션 db가 서버에 존재하지 않는다.
== 문자열로 유저를 인증을 끝냄
->토큰 자체 == 인증 데이터
장점
토큰은 토큰자체에 유저정보가 들어있기 때문에 세션 db가 필요하지 않고 그래서 로직이 간단하다.
(세션이나 db없이 문자열로 유저를 인증하는 것이 가능하다.)
서버에서 유저의 id/pw맞는지 검증을하고 맞다면 토큰:문자열(서명포함)을 클라이언트에게 주고 이 다음부터는 클라이언트가 요청(예:crud)을 보낼때마다 헤더부분에(요청request에는 헤더(Authorization,바디의 Content-Type)와 바디(실제 데이터)가 있다) 토큰을 넣어 함께 보낸다. 서버는 토큰을 보고 토큰의 유효성 검증, 유저의 신원과 권한을 확인하고 요청을 처리(응답)어떤 유저인지 바로 판별을 할 수 있고 응답을 줄수 있다.
단점
세션 db가 없으므로서 생기는 것들
- 중복 로그인 체크가 안된다
- 모든 기기에서 로그아웃 하시겠습니까? 안됨
- 현재 접속 유저 관리 안됨
토큰이 탈취당하면 끝(보안 취약)
- 내 토큰을 누가 가져가는 순간 쟤가 내가 됨
그 래 서
고민한게
---->Token의 유효시간을 짧게 잡는다.
탈취 당해도 금방 만료 되게끔
access token : acces할때 사용하는 토큰 (모든 요청에 넣어서 보냄), 유효기간이 굉장히 짧다(중간에 탈취당해도 만료시켜서 유효하지 않게 만든다)
refresh token : access token이 만료되었을 때 새로운 access token을 받을 수 있는 token, 유효기간이 긴 토큰, 사용자의 기기(내장되어 있는 스토리지)에 저장해둔다.
저장해놨던 refresh token을 던져서 새로운 access token을 받아서 그 다음부터 이 access token을 다시 가지고 요청을 보낸다.
refresh token도 만료돼면?
클라이언트가 다시 로그인 처리
(로그인을 자주 해줘야 하는 앱/로그인 유지가 오래 되는 앱-refresh token기간이 엄청 긴 것)
->액세스 토큰을 계속 발급 받을 수 있는 리프레시 토큰의 기간이 길어서 리프레시 토큰 유효기간만큼 로그인이 유지되는 것
부연설명
리프레시 토큰 유효기간이 한 달이라면, 그 한 달 동안은 액세스 토큰이 만료될 때마다 새로운 액세스 토큰을 계속 발급받을 수 있습니다. 결과적으론 한달동안 로그인 상태가 유지됨
