Computer Science

[JWT] JSON Web Token의 구조, 장점, 한계

연_우리 2022. 2. 3. 22:28
반응형

목차

     

     

     

    JWT을 알아보기 전 사전지식

     

    Cookie와 Session, 그리고 Token

    목차 HTTP의 특징 HTTP는 비연결성(Connectionless)과 무상태(Stateless)라는 특징이 있다. 클라이언트는 서버에게 Request를 보내면서 서버와 연결되는데 이때 서버가 클라이언트에게 Response하면서 맺었던

    lotuus.tistory.com

     

    정보보안의 3대 요소(기밀성, 무결성, 가용성)와 RSA 암호화 방식

    정보보안의 3대 요소 기밀성 Confidentiality : 허가받은 자만 정보에 접근할 수 있다. 무결성 Integrity : 허가받은 자만 변경해야한다. 가용성 Availability : 허가받은 자면 정보를 사용할 수 있어야 한다.

    lotuus.tistory.com

     

     

    JWT : Json Web Token

    JWT는 Token방식을 이용하여 서버가 SessionDB를 가지지 않고, 클라이언트가 인증정보를 관리하게 할 수 있다.

    클라이언트가 로그인하면, 서버가 클라이언트에게 "인증OK"되었다는 의미로 토큰을 발급해준다.

     

    클라이언트에게 인증정보를 주게되면? 클라이언트가 수정도 할 수 있을 것!

    클라이언트가 인증정보를 수정하게되면 서버는 이 토큰이 안전한 토큰인지 어떻게 구별할 수 있을까??

     

     

     

    JWT 구조

    참고 : https://jwt.io/#debugger-io

     

    JWT는 { xxxxxxx . yyyyyyy . zzzzzzz } 이런 구조로 이루어져있다.

     

    📌 주의!! Header와 Payload는 암호화 되어있지 않다!!! 

    따라서 Payload에는 절대 개인정보를 추가하면 안된다.

    구분 명칭 역할 형태
    xxxxxxx Header 알고리즘과 토큰 타입을 나타낸다 {
      "alg": "HS256",   // signature를 어떤 알고리즘으로 암호화할지
      "typ": "JWT"      // 어떤 타입인지
    }
    yyyyyyy Payload 실제 보관할 데이터를 JSON형식으로 나타낸다 {
      "sub": "1234567890",
      "name": "John Doe",
      "iat": 1516239022
    }
    zzzzzzz Signature 데이터가 수정되었는지를 판단한다 HMACSHA256(
      base64UrlEncode( header ) + "." +
      base64UrlEncode( payload ),
       secret key      // 정보들로 해시값 생성
    )

     * base64Url : 인코딩 & 디코딩이 가능한 알고리즘 (일종의 암호화)

     * HMACSHA256 : HMAC + SHA256

     * HMAC : 암호화된 해시값(SHA256)과 암호화 키를 가지는 메시지 인증 코드

     * SHA256 : 복호화 불가능한 해시값

     

     

    유저가 서버로 토큰을 보내면 서버에서는

    1. 유저가 보내준 Header와 Payload + 서버의 secret key를 조합하여 Signature를 만든다

    2. 유저가 보내준 Signature와 1번을 비교한다

    3. 만약 값이 같지 않다면? 조작된 데이터!!

     

    JWT의 Signature 덕분에 클라이언트가 토큰을 수정해도 서버가 받은 토큰이 안전한지 구별해낼 수 있다.

     

     

     

     

    JWT의 장점

    기존의 세션방식에서는 트래픽이 늘어날수록 서버가 SessionDB를 증설해야했다.

    또한, SessionId를 찾으려고 이리저리 헤매고 다녀야했었는데 JWT를 사용하면 그럴일이 없다.

     

    JWT는 더이상 SessionDB가 필요없다. 유저한테 받은 Signature를 검증만 해주면된다. 

     

     

     

    JWT의 한계

    1. A 서비스는 1곳에서만 로그인을 하게끔 하려한다.

       (PC에 로그인하면 Mobile이 로그아웃되고, Mobile에 로그인하면 PC가 로그아웃되게)

       서버는 토큰을 저장하지 않는다. 요청받은 토큰에 대해서만 처리하기때문에

       token값만을 가지고 기존에 로그인이 되어있는지에 대해서는 알수가없다!!

     

    2. 😀유저가 A 서비스에 로그인하여 유저의 정보를 요청하였다.

        그런데 중간에서 😈해커가 정보를 가로채버렸다! 😈해커가 가진 정보를 못쓰게 만들어야하는데

        서버는 토큰을 저장하지 않는다. 요청받은 토큰에 대해서만 처리하기때문에

        같은 😀유저의 정보로 접속하면 진짜 😀유저가 접속한것인지, 😈해커가 접속한것인지 알 수 있는 방법이 없다.

        토큰이 유출되어버리면 만료시킬 방법이 없다!!

     

     

     

     

     

    결론

    JWT의 사용 목적은 "암호화"가 아닌 "무결성"에 있다.

    즉, "이거 내가 보낸 토큰 맞아! 다른사람이 수정안했어" 하고 데이터의 위조를 보장해주는 역할이 핵심이다.

     

     

     

     

    반응형
    • 네이버 블러그 공유하기
    • 페이스북 공유하기
    • 트위터 공유하기
    • 구글 플러스 공유하기
    • 카카오톡 공유하기