JSON Web Token의 줄임말로, 토큰 기반 인증 시스템에서 사용되는 암호화 방식이다.
토큰 기반 인증 시스템 ?
기존의 서버 기반 인증 시스템은 서버 측에서 유저들의 정보를 기억하고 있어야 했다.
세션을 이용해서 유저의 인증 기록을 저장하는데, 이는 서버의 과부하를 초래하고, 서버의 과부하를 해결하기 위해 서버를 확장하는 것도 어렵게 만들었다. 이러한 문제점을 해결하기 위해 나온 인증 시스템이 바로 토큰 기반 인증 시스템이다.
위 그림을 보면 토큰 기반 인증 시스템의 로직을 간단하게 이해할 수 있을 것이다!
클라이언트에서 서버로 로그인 요청을 하게 되면, 해당 API가 실행이 될텐데, 이때 본인이 맞는지 DB에서 확인을 거친 후에 accessToken과 refreshToken을 발급한다.
accessToken ? refreshToken ?
간단하게 이야기하면 로그인 증표라고 생각하면 될 것 같다. 로그인을 한 후에만 이용 가능한 서비스가 있을 것이다. 예를 들면, 내 정보 조회, 결제 등!
이런 서비스를 이용하기 위해서 본인임을 인증해야 하는데, 이때마다 매번 로그인을 통해 인증하는건 번거로운 일이다.그래서 나온 개념이다. 한번 로그인을 하게 되면, 토큰을 발급해주는데 이 토큰을 통해 본인임을 인가 받을 수 있다.
그럼 둘의 차이는 무엇일까?
바로 만료 기간과 어디에 저장이 되는지에 따라 차이가 있다.
accessToken은 대게 만료 기간이 짧고, 변수에 저장되어 쓰인다. 반면, refreshToken은 만료 기간이 길고 쿠키에 저장된다.더 자세한건 다음 블로깅을 통해 설명하기로 .🫠.
이때 이 토큰 값을 JWT를 통해 암호화하고 암호화된 토큰을 이용해서 토큰을 새로 발급하기도 하고, 인가를 처리하기도 한다!
그럼 JWT의 구성을 알아보자
위의 사진에서 암호화된 내용을 보면 .
2개가 찍혀있는 것을 볼 수 있을텐데, 이를 기준으로 3가지의 내용으로 구성되어 있다.
Header는 토큰의 타입과 해싱 알고리즘이라는 두 가지 정보를 담고 있다
{"alg":"HS256","typ":"JWT"}
보통 해싱 알고리즘은 HS256
을 사용하지만 HS512
을 이용해 토큰을 더 길게 만들수도 있다.
Payload에는 토큰에 담을 정보가 들어가며, 담는 정보의 한 조각은 name/value의 한 쌍으로 이루어진 Claim이라고 부른다. Claim은 Registered, Public, Private의 세 분류로 나누어져 있으며 Registered Claim은 토큰 발급자, 토큰 제목, 토큰 만료시간, 토큰 발급 시간 등 토큰에 대한 정보를 담기 위해 이미 이름이 정해진 Claim이다.
JWT의 마지막 부분은 서명으로, Header의 인코딩 값과 Payload의 인코딩 값을 합친 후 주어진 비밀키로 해싱하여 생성한다.
참고자료 및 출처:https://jwt.io/