diff --git a/network/kkw/JWT.md b/network/kkw/JWT.md
new file mode 100644
index 0000000..4fc9a5e
--- /dev/null
+++ b/network/kkw/JWT.md
@@ -0,0 +1,85 @@
+## JWT
+
+### Json Web Token
+
+- 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준
+- Payload는 Claim과 assert를 처리하는 JSON을 보관하고 있다
+- 토큰은 공개/비공개 키를 사용하여 서명된다
+
+### 구조
+
+- Header
+
+```JSON
+  {
+    "alg" : "HS256",
+    "typ" : "JWT"
+  }
+```
+
+- 서명 생성을 위해 어느 알고리즘을 사용할지를 식별
+- 주로 HS256이나 RS256 알고리즘을 사용한다
+- Payload
+
+```JSON
+  {
+    "sub": "1234567890",
+    "name": "KIM KYUNG WON",
+    "admin": true,
+    "iat": 1516239022
+  }
+```
+
+- 일련의 클레임들을 포함, 표준 필드인 7개의 등록 필드와 사용자 지정 클레임이 들어간다.
+- 등록 클레임
+  - iss : 토큰 발급자
+  - sub : 토큰 제목
+  - aud : 토큰 대상자
+  - exp : 토큰의 만료 시간
+  - nbf : Not before, 토큰의 활성 날짜
+  - iat : 토큰이 발급된 시간
+  - jti : jwt의 고유식별자
+- 공개 클레임
+  - JWT 를 사용하는 사람들에 의해 정의된 클레임
+    - 참고 : https://www.iana.org/assignments/jwt/jwt.xhtml
+  - 공개 클레임은 서로 충돌이 방지된 이름을 가지고 있어야 하므로 URI 형태로 짓는다.
+- 비공개 클레임
+
+  - 서버와 클라이언트간에 협의하에 사용되는 클레임
+
+- Signature
+
+```JSON
+HMACSHA256(
+  base64UrlEncode(header) + "." +
+  base64UrlEncode(payload),
+  your-secret-key
+) secret base64 encoded
+```
+
+- 서명은 위에서 만든 Header와 Payload의 값을 각 BASE64로 인코딩하고, 그 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 해싱하고, 이 값을 다시 BASE64로 인코딩하여 생성한다.
+
+- Header와 Payload는 Base64로 인코딩 되었을 뿐 암호화는 Signature에만 적용되어있다.
+- 즉 개발자는 HTTPS와 같은 시스템 수준의 암호화를 통해서 외부 노출 차단을 막고, 데이터의 신뢰성 평가를 암호화 토큰을 통해서 보장한다.
+
+### 장단점
+
+- 장점
+  - 별도의 인증 저장소가 필요없음
+  - 토큰의 신뢰성을 확인하는데 네트워크 연결이 따로 필요하지 않음 (독립적임)
+  - REST 서비스고 제공 가능
+  - 수평 스케일이 용이
+  - URL 파라미터와 헤더로 사용이 가능
+  - 내장된 만료
+  - 트래픽에 대한 부담이 낮음
+  - 디버깅 및 관리가 용이
+- 단점
+  - 필드가 많아지면 토큰이 커질 수 있음
+  - 모든 요청에 보내질 수 있으므로 신경을 써줘야함
+  - 토큰이 탈취되더라도 막을 수 없음
+    - JWT 헤더만으로 중요한 유효성을 확인하지 말 것
+
+### 주 사용처
+
+- 회원 인증
+- 정보 교류 : JWT에 서명이 담겨있기에 중간에 보낸 이가 바뀌진 않았는지 정보가 바뀌진 않았는지 검증이 가능