WIL Date : 2022년 7월 둘째주
JWT란?
- 기본 구조 : Client -> API Server -> Database
- 회원 권한이 필요한 과정이면 C -> S -> D 로 가서 확인하는 과정을 계속 거쳐야함
- 이러한 전통적인 구조를 깨는 방식이 JWT
- DB에서 계속해서 권한을 확인하는 방식에서
- Client와 Server에서만 인증이 완료될 수 있게 하는 토큰
- JWT는 Client가 유저 데이터를 관리한다.
- 단 Client는 JWT를 볼 수는 있지만 수정할 수가 없음 (서버에서만 수정 가능)
JWT의 구조
- { Header }.{ payload }.{ Signature }
- jhbGci.tCXLKAj3or.fjasdfpje23 등으로 적혀있음
- 따로 암호화를 한 것은 아니고 데이터 전송하기 편하게 base64 포맷으로 변환만 한 것 (인코딩하면 원본을 볼 수 있음)
- base64 포맷한 데이터도 출처의 URL을 들어가보면 확인할 수 있다.
- 저 중에 있는 Signature 덕분에 클라이언트가 수정이 불가능
- Signature는 헤더와 페이로드의 정보를 SHA256으로 암호화를 진행
- 그러면 서버는 시그니쳐를 복호화해서 정보만 확인하면 되는 것
JWT의 단점
- Token Expiration Issue
- 토큰이 탈취당하면 손쓸 방법이 없음
- 그래서 JWT에서는 만료 기한을 정해둠
- 토큰의 탈취
- 만료기한을 정하면 토큰을 사용하지 못하게는 할 수 있음
- 그러나 그 안에 중요한 개인정보가 있다면 해커는 해당 정보를 볼 수 있음
JWT는 그러면 언제 사용할까?
- 인증 과정 전체를 JWT로 하는 곳은 거의 존재하지 않음
- 따라서 세션 관리를 원래대로 하되, JWT는 쿠키 정도의 역할만을 진행
JWT 한계점의 해결방법
- Server-Side (서버에서 암호화를 관리)
- 대칭키를 이용해 특정한 키를 알지 못하면 볼 수 없게 암호화를 하는 방법이 그 중 하나이다.
- 서버에서는 토큰의 정보를 확인할 수 있지만 유저에서는 토큰 정보를 확인하지 못하게 설정한다.
- Client-Side (클라이언트에서 암호화를 관리)
- 클라이언트에서 특정 키를 이용하여 암호화를 진행
- 그러나 특정 키 역시 탈취당하면 평문을 탈취당할 가능성이 있을 듯함 (주관적인 생각)
- 그러면 JWT를 탈취당해도 정보를 확인할 수 없음
- 대신 서버에서 암호화를 관리하는 것보다 서버의 부하, 속도 측면에서 우수
