JWT(토큰기반 인증)
Json Web Token
Json 포멧으로 사용자 속성을 저장하는 웹 토큰
🧊세션 기반 자격증명
- 서버에 세션을 저장함으로 서버의 부담 가중(메모리, 엑세스 과정, 세션 관리 작업)
- 상대적으로 적은 네트워크 트래픽(세션ID만 저장)
- 서버가 직접 관리함으로 보안성 측면에서 상대적으로 유리
- request 상태 유지가 필요, 세션 불일치 가능성 관련 확장성이 떨어짐
주고 받는 과정은 쉽지만 관리는 힘들다,
힘든만큼 보안이 견고하지만 그만큼 확장성이 떨어진다
🧊토큰 기반 자격증명
- 클라이언트 정보를 저장하지 않아 서버 부담이 적어짐
- 상대적으로 많은 네트워크 트래픽(토큰이 길어질수록 request시 부하가 증가)
- 서버가 직접 관리하지 않아 보안성 측면에서 상대적으로 불리
- 어느 서버나 생성 가능하며 하나의 토큰으로 여러 서버에서 인증 가능(확장성)
주고 받는 과정은 힘들지만 관리는 편하다,
간편한 만큼 보안이 떨어지지만 그만큼 확장성에 유리하다
추가적인 토큰기반 특징
- CSR방식에 적합
- 토큰 만료 설정이 추가적으로 필요
- 암호화된 토큰, 암호화 상태로 사용 - 단, 디코딩이 용이함으로 민감정보에 주의
- 권한부여가 용이(payload에 권한정보가 저장됨)
- Github, Google 등의 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능
Stateless(무상태성)
클라이언트와 서버의 연결이 끝난 순간 상태 정보를 유지하지 않는 속성
상태 유지가 필요하다면 통신할 때마다 인증 절차가 필요
무상태성의 번거로움을 줄이기 위해 위해 쿠키와 세션을 사용
🧊JWT의 종류
액세스 토큰(Access Token)
권한 부여에 사용
리프레시 토큰(Refresh Token)
Access Token 갱신에 사용
🧊JWT의 구조
모든 파트는 JSON 포맷 형태로 저장된다
Header
- 토큰 타입
- 암호화 알고리즘
Payload
- 유저 정보(식별자)
- 권한 정보
- 기타 필요한 정보(만료일자 등)
Claims : 페이로드에 포함되는 각각의 정보의 조각
Signature
- base64인코팅된 각각의 Header, Payload를 salt추가 후 암호화한 값
🧊토큰 기반 인증 절차
- Username, Password로 로그인 요청
- DB 확인 후 암호화된 JWT Token 제공(Access&fresh)
- 로컬스토리지, 쿠키, 리액트 스테이트 등에 저장
- 헤더에 토큰을 담아 요청
- 토큰 검증을 통한 요청처리(Bearer 인증 타입을 이용)
갭린이 리나