JSON 웹 토큰

서버에서 전자 서명된 토큰을 이용하면 인즈엥 따른 스케일 문제를 해결할 수 가 있습니다!

우리는 전자 서명된 토큰을 이용해 스케일 문제를 해결합니다.ㅎㅎ

그리고 이렇게 전자 서명된 토큰 중 하나가 JSON 웹 토큰 입니다.

이것이 JWT라고 합니다.

JWT는 오픈 스탠더드이고, JSON 형태로 된 토큰입니다.

토큰은 {header}.{payload}.{signature} 로 구성되어 있습니다.

각 파트의 필드가 무엇을 뜻할까요?

Header

• typ : Type을 줄인 말로 토큰의 타입을 의미
• alg : Algorith을 줄인 말로 토큰의 서명을 발행하는데 사용된 해시 알고리듬의 종류를 의미

Payload

• sub : Subject 를 줄인 말로 토큰의 주인을 의미, 애플리케이션에서는 사용자의 이메일이나 아이디로 토큰의 주인을 판별한다. sub는 ID처럼 유일한 식별자여야 합니다.
• iss : Issuer를 줄인 말로 토큰을 발행한 주체를 의미, 예를 들어 우리 애플리케이션이 이 토큰을 발행했다면 스터디_부트 , 페이스북이라면 페이스북 이 된다.
• iat : Issued at을 줄인 말로 토큰이 발행된 날짜와 시간을 의미한다.
• exp : expiration을 줄인 말로 토큰이 말료되는 시간을 의미한다.

Signature

• 토큰을 발핸한 주체 Issuer가 발행한 서명으로 토큰의 유효성 검사에 사용된다.

토큰 기반 인증에서 서버가 토큰을 생성한다고 했다. JWT도 토큰 기반 인증이므로 서버가 생성합니다.

다른 점은 서버가 헤더와 페이로드를 생성한 후 전자 서명을 한다는 점입니다.

이 과정은

JWT에서 전자 서명이란 {헤더}.{페이로드}와 시크릿키를 이용해 해시 함수에 돌린 암호 화한 결과값입니다.

시크릿키란 나만 알고 있는 문자열, 비밀번호 같은 것입니다.

너무 간단하지만 않으면 아무것이나 상관없답니다.

최초 로그인 시 서버는 사용자의 아이디와 비밀번호를 서버에 저장된 아이디와 비밀번호에 비교해 인증합니다.

만약 인증된 사용자인 경우 사용자의 정보를 이용해 {헤더}.{페이로드} 부분을 작성하고 ,

자신의 시크릿키로 {헤더}.{페이로드} 부분을 전자 서명합니다.

전자 서명의 결과로 나온 값을 {헤더}.{페이로드}.{서명} 으로 이어 붙이고 Base64로 인토딩한 후 반환합니다.

이후에 누군가 이 토큰으로 리소스 접근을 요청하면 서버는 일단 이 토큰을 Base5로 디코딩합니다.

디코딩해서 얻은 JSON을 {헤더}.{페이로드}와 {서명} 부분으로 나눕니다.

서버는 {헤더}.{페이로드}와 자신이 가지고 있는 Secret으로 전자 서명을 만든 후 방금 만든 전자 서명을 HTTP 요청이

가지고 온 {서명} 부분과 비교해 이 토큰의 유효성을 검사합니다.

서버가 방금 시크릿키를 이용해서 만든 전자 서명과 HTTP 요청의 {서명} 부분이 일치하면

토큰이 위조 되지 않았다는 뜻입니다.

누군가 헤더나 페이로드 부분을 변경했다면 서명이 일치하지 않기 때문입니다.

따라서 인증 서버에 토큰의 유효성에 대해 물어 볼 필요가 없어진겁니다.

이는 인증 서버에 부하를 일으키지 않는다는 뜻이고, 더 이상 인증 서버가 단일 장애점이 아니라는 뜻이기도 합니다.

누군가 토큰을 훔쳐가면 어떻게 될까요?

토큰을 훔쳐가면 당연히 해당 계정의 리소스에 접근할 수 있습니다. 
그렇기에 반드시 HTTPS를 통해 통신해야하는 겁니다.