JWT (Json Web Token)

JWT = Json Web Token

제이슨으로 된 형태로 된 데이터를 네트워크를 통해서 
서로 다른 장치끼리 안전하게
전송하기 위해 설계됨

편지로 보면
봉투, 편지지, 서명

jwt는 편지와 똑같은 역할을 하는 도구

jwt에서는 내용을 payload라고 함
{
"sub": "1234556788",
"name": "john doe",
"email": "ckk9114@naver.com"
}

payload의 각 부분을 claim이라고 함
클레임은 주장이라고 함

왜 클레임이냐? 
받는 쪽에서 보내는 쪽의 내용을 곧이 곧대로 믿으면 안되기 때문에 클레임이라고 함
믿을 수 있게 해주는 것이 '서명'

서명만 있으면 이 내용의 무결성을 단박에 알아 볼 수 있습니다.

signature 
에) b^\xcgsds\xsd\ssds\ssd!\sds

서명을 하는 여러가지 방법이 존재
JWt는 서명 방법을 강제하지 않음
이걸 적기 위해 헤더가 존재
헤더에 어떤 알고리즘을 썼고 어떤 타입인지 명시  
header 
{
"alg": "HS256",
"typ": "JWT"
}

네트워크로 정보를 그냥 보내면 여러가지 문제가 생긴다
이걸 방지 하기 위해서 Base64 인코딩을 해서 
그리고 마침표로 다들 연결시킨다
그렇게 만들어진 모두 연결된 텍스트가 jwt가 됩니다

위 내용이 jwt가 만들어지는 과정

------------------------------
jwt 의 핵심은 '서명'

서명과 내용을 상대에게 줘서 올바른 내용이었다고 판단하게 한다

서명을 하기 위해서는 우선 비밀번호가 있어야한다
secret key라고 함

내용이 있어야함 페이로드
hmac 서명 생성기(서명을 만드는 함수(기계))

secret key + payload
       \              /  
           hmac
             ⬇️
            서명

    상대에게 payload, hmac header, 서명을 전달 후 잊으면 됨


<<활용 분야>>

인증 Authentication. (가장 많이 쓰임)

정보 공유 Information Exchange

권한 부여 Authorization

단일 로그인 Single Sign-On

---
인증 의 종류

1. 쿠키 기반의 인증 cookie

2. Jwt 기반 인증

-----------------------------------------------------------------------
1. 쿠키 베이스 세션 메니지먼트 (session)
cookie-based session management

브라우저.     서버.      디비
 ㄴ--->
로그인 시도     ㄴ-------->
               있는 회원인지, 유저 조회.  유저가 있다면 
                      ㅣ abc123이라는 임시 비밀번호 발급한걸 기록
                      ㅣ                         이 값을 session id 라고함
                      ㅣ [세션 테이블]
                      ㅣ [session id  l user_id]
                      ㅣ [abc123           23. ]
                        <---------
                       session_id:abc123
<------------
 cookie: abc123

브라우저에 저장되고 다음에 접속할때마다 서버로 전송됨

-------------->
cookie: abc123
수정요청 시 같이 보냄
                  --------->
                  cookie: abc123
                  세션 아이디 조회
                  테이블 보니 있는 것 확인
                  <---------
                  allow access
<---------
allow access

서버에 접속할때 마다 사용자 확인해야함
사용자가 다른 장치로 접속할때마다 세션 아이디를 새로 발급해줘야함
: 데이터 베이스 혹사 주의

-----------------------------------------------------------------------
JWT Authentication (토큰 방식)

브라우저.     서버.      디비
 ㄴ--->
로그인 시도     ㄴ-------->
                      있는 회원인지, 유저 조회. 
                     앱서버에서 
                     payload + secret key 3esdfs566778..
{
"sub": "1234556788",
"name": "john doe",
"email": "ckk9114@naver.com"
}
페이로드와 시크릿 키를 서명 알고리즘에 입력해서
'서명'을 만듬
dfdfdsofko434343@#@$%$/dsdfsdfsfds
헤더에 뭘 썼는지 기입
header 
{
"alg": "HS256",
"typ": "JWT"
}
⬇️
\ base64로 인코딩 \
헤더 
dsofkjsdfdsjkfdslfs234
페이로드
fgdflkgdf3453436/2342
서명
ffdsfde4546!@@!23f
3개는 점으로 연결
=> jwt
<-------------
     jwt
브라우저로 jwt 값 전달
이 값은 인증 직후에 서버가 발행한 것
이 jwt를 가지고 있다는 것은 로그인 한적이 있는 사람이라는 증표!
받은 클라이언트는
쿠키나 로컬 스토리지와 같은 곳에 저장
jwt 를 base64로 디코딩하면
원래의 데이터로 되돌릴 수 있음!

jwt 첫번째 장점: jwt는 메시지를 담는 수단이기 때문에,애플리케이션이 필요한 정보를 payload에 담기 좋음
이 정보를 가져오기 위해서 서버에 다시 접속하지 않아도 되기 때문에 서버 부담을 완화

-------------->
     jwt

               받은걸 base64로 디코딩
               브라우저가 전달한 헤더와 페이로드 시크릿 키로 서명을 해봄
               브라우저에서 온 서명과 일치하면 이사람은 이전에 앱서버가 로그인 해준 사람이 틀림없다
               이 서명을 만들 수 있는 것은 이 우주에서 이 비밀키를 가지고 있는 사람밖에 없기 때문
               서명이 맞는지 보고
<-----------------
   allow access


jwt를 사용하면 로그인할때만 한번만 데이터베이스에 접속하고
그 일후 확인 과정에서는 데이터베이스에는 접속할 필요가 없다
세션 테이블이 필요 없다. jwt 토큰만으로 인증이 끝나기 때문에
데이터 베이스 접속을 안하기 때문에 서버의 부담을 획기적으로 줄일 수 있다

토큰을 직접 만들어 볼 수 있는 사이트
jwt.io

헤더 base 64 . +
payload base 64. +
password(secret key)를 alg로 서명한 값