Server ) JWT ( Json Web Token ) 정의, 구성, 특징 - EEYatHo iOS

 

JWT 정의

---

- JSON Web Token )

- JSON 데이터를, URL-safe BASE64 인코딩과( URL로 사용될 수 있는 문자열로 구성 ), 특정 암호화 알고리즘으로 전자 서명된 문자열.

- 정보전달 및 권한인가를 위해 사용하는 토큰.

 

 

 

JWT 구성

---

- 3가지 파트로 나누어져 있으며 ( header, payload, signature ), 마침표(.)를 구분점으로 이어져 있음

 

 

 

1. header

---

토큰의 타입과, signature에서 사용하는 암호화 알고리즘

두 데이터를 JSON으로 만들고, URL-safe BASE64 인코딩하면 완성

header에 필요한 데이터 = { "alg": "HS256", "typ": "JWT" }

=> 인코딩 

=> eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

 

header = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

 

 

 

2. payload

---

전달할 데이터

payload에 들어있는 키 값 한쌍을 클레임(claim) 이라고 부름

( 클레임 종류를 registerd, public, private로 나누기도 하는데, 이름과 달리 private도 똑같은 수준으로 공개되고, 굳이 나눈 것에 대한 실효성은 잘 모르겠네.. )

 

전달할 데이터를 JSON으로 만들고, URL-safe BASE64 인코딩하면 완성

필요한 데이터 : { "sub": "1234567890", "name": "John Doe", "iat": 1516239022" }

=> 인코딩

=> eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

 

payload = eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

 

 

 

3. signature

---

토큰의 유효성을 검증할 때 사용하는 서명

header과 payload를 URL-safe BASE64 인코딩 후,

마침표(.)로 이어준 뒤,

서버에서 정한 암호화 알고리즘에 따라, 서버에서 생성한 비밀키를 이요해 암호화 한 후,

또 URL-safe BASE64 인코딩을 하면 완성

 

 

header + "." + payload = 

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

 

=> 암호화

=> XbPfbIHMI6arZ3Y922BhjWgQzWXcXNrz0ogtVhfEd2o

=> 인코딩

=> PcmVIPbcZl9j7qFzXRAeSyhtuBnHQNMuLHsaG5l804A

 

signature = PcmVIPbcZl9j7qFzXRAeSyhtuBnHQNMuLHsaG5l804A

 

 

 

JWT = 

header + "." + payload + "." + signature = eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.PcmVIPbcZl9j7qFzXRAeSyhtuBnHQNMuLHsaG5l804A

 

 

 

JWT 특징

---

• 토큰의 유효성 정보를 토큰 스스로 들고있기에, 세션처럼 서버 중앙 관리가 필요없음
  => 세션을 대체한 인증수단으로 자리잡음
  
  
• 네트워크 통신시 마다 헤더에 토큰을 넣어주기 때문에, 크기를 작게 해야함
• 한번 발급한 토큰은 수정, 삭제가 불가능. ( 만료될 뿐 )
• header, payload는 디코딩하면 해석할 수 있기 때문에, 노출되면 안되는 정보는 넣지않습니다.
  
  => 여기서 의문. 그렇다면 왜 굳이 동일한 정보를 평문(header, payload)과 암호문(signature)으로 같이 전달하지? 그냥 다 암호문만 전달하면 안되나..?
  
  => 저렇게 전달 함으로써, 수정을 방지할 수 있음. 평문과 암호문 두가지를 같은 의미를 가지게 임의로 수정할 수 없기 때문.
        + 데이터가 평문에 있으니, 클라이언트에서 디버그하기 좋은점도 있는듯?