[웹 공부] 인증(2) JWT (JSON Web Token)

lheun·2022년 9월 8일
0

웹 공부

목록 보기
3/4
post-thumbnail

🚩 인증 방식

서버가 클라이언트를 식별하고 정보를 유지하기 위해 사용하는 인증 방식에는 쿠키, 세션 그리고 토큰이 있다

✅ 쿠키(cookie)와 세션(session) 간단 정리

사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다

  • 단점
    • 보안에 취약하다
    • 쿠키 용량 제한이 있다
    • 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저간 공유가 불가능하다
    • 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다

2. 세션 (session)

세션은 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다

  • 단점
    • 해커가 세션ID를 탈취하여 클라이언트인척 위장할 수 있다는 한계가 존재한다
    • 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다

✅ 토큰 (token) 방식

클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 토큰을 부여한다

요청을 보낼 때, 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다

  • 세션 기반 인증과는 달리 토큰 자체에 데이터가 들어있기 때문에 클라이언트에서 받아 위조되었는지 판별만 하면 된다

🚩 JWT (JSON Web Token)

⏹ JWT (JSON Web Token)란

인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다

  • JWT 기반 인증은 쿠키/세션 방식과 유사하게 JWT 토큰 (Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다

🚩 JWT 구조

JWT는 . 을 구분자로 나누어지는 세 가지 문자열 Header, Payload, Signature의 조합이다

  • ( https://jwt.io/ 에서 JWT 구조와 관련하여 자세히 살펴볼 수 있다 )

✅ HEADER : ALGORITHM & TOKEN TYPE

  • JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨있다
    • alg : 서명 암호화 알고리즘 (ex: HMAC SHA256, RSA)
    • typ : 토큰 유형

✅ PAYLOAD : DATA

  • 토큰에 담을 정보(Claim)를 지니고 있다
    • key-value 형식으로 이루어진 한 쌍의 정보를 Claim이라고 칭한다
  • 주로 클라이언트의 고유 ID 값 및 유효 기간 등 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있는 영역이다

  • 페이로드는 정해진 데이터 타입은 없지만, 대표적으로 Registered claims, Public claims, Private claims 세 가지로 나뉜다

    • Registed claims : 미리 정의된 클레임
      iss (Issuer)_토큰 발급자
      sub (Subject)_토큰 제목, 토큰에서 사용자에 대한 식별값이 됨
      aud (Audience) : 토큰 대상자
      exp (Expiration Time)_토큰 만료 시간
      nbf (Not Before)_토큰 활성 날짜 (이 날짜 이전의 토큰은 활성화 되지 않음을 보장)
      iat (Issued At)_토큰 발급 시간
      jti (JWT Id)_JWT 토큰 식별자 (issuer가 여러명일 때 이를 구분하기 위한 값)
    • Public claims : 사용자가 정의할 수 있는 클레임 공개용 정보 전달을 위해 사용
      (공개 클레임들은 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 하고, 충돌을 방지하기 위해서 클레임 이름을 URI 형식으로 한다)
      https://velog.io/@lheun : true
    • Private claims : 해당하는 당사자들 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임 외부에 공개되도 상관없지만 해당 유저를 특정할 수 있는 정보들을 담는다
      username : lheun
  • 꼭 모두 포함해야하는 것이 아니고, 상황에 따라 해당 서버가 가져야할 인증 체계에 따라 사용하면 된다

    • 중요한 것은 PAYLOAD에 민감한 정보를 담지않는 것이다
    • HEADERPAYLOAD는 json이 디코딩되어있을 뿐이지 특별한 암호화가 걸려있는 것이 아니기 때문에 누구나 jwt를 가지고 디코딩을 한다면 header나 payload에 담긴 값을 알 수 있다

✅ VERIFY SIGNATURE

  • 시그니처에서 사용하는 알고리즘은 헤더에서 정의한 알고리즘 방식(alg)을 활용한다
  • SIGNATURE인코딩된 HEADER와 PAYLOAD를 더한 뒤, 서버가 갖고 있는 유일한 key 값을 합친 것을 헤더에서 정의한 알고리즘으로 해싱하여 생성한다

  • HEADER와 PAYLOAD는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만,
  • SIGNATURE는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다
    • 따라서 SIGNATURE토큰의 위변조 여부를 확인하는데 사용된다

🚩 JWT (토큰 기반 인증) 동작 방식

토큰 기반 시스템의 구현 방식은 시스템마다 크고작은 차이가 있겠지만, 대략적으로 보면 다음과 같다

  • 클라이언트가 로그인을 요청하면 서버에서 회원인지 확인한다
  • 계정 정보가 확인되면 HEADER, PAYLOAD, SIGNATURE를 정의한다
    • HEADER, PAYLOAD, SIGNATURE 를 각각 Base64로 한 번 더 암호화하여 JWT를 생성하고 이를 쿠키에 담아 클라이언트에게 발급한다
    • (토큰 유효기간 설정)
  • 클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장한다 (쿠키나 다른 곳에 저장할 수도 있음)

  • 클라이언트가 서버에 요청할 때 Authorization header에 Access Token을 담아서 보낸다

  • 서버는 클라이언트가 Header에 담아서 보낸 JWT가 자신의 서버에서 발행한 토큰인지 일치 여부를 확인하여 일치한다면 인증을 통과시켜주고 아니라면 통과시키지 않으면 된다
    • 인증이 통과되면 PAYLOAD에 들어있는 유저의 정보들을 select해서 클라이언트에 돌려준다
  • 클라이언트가 서버에 요청을 했는데, 만일 액세스 토큰의 시간이 만료되면 클라이언트는 리프래시 토큰을 이용해서 서버로부터 새로운 엑세스 토큰을 발급 받는다

🚩 JWT 장단점

⏹ 토큰 인증 방식이 신뢰성을 가지는 이유

서버는 토큰 안에 들어있는 정보가 무엇인지 아는게 중요한 것이 아니라 해당 토큰이 유효한 토큰인지 확인하는 것이 중요하다

  • 클라이언트로부터 받은 JWT의 Header, Payload를 서버의 key값을 이용해 시그니처를 다시 만들고 이를 비교하며 일치했을 경우 인증을 통과시킨다

ex) User JWT : 🔴(Header) + 🟡(Payload) + 🟠(Signature)

  • 다른 유저가 PAYLOAD를 임의로 수정 🟡 ➡ 🔵
  • 수정한 토큰을 서버에 요청을 보내면 서버는 유효성 검사 시행
    • 유저 JWT: 🔴(Header) + 🔵(Payload) + 🟠(Signature)
      서버에서 검증 후 생성한 JWT: 🔴(Header) + 🔵(Payload) + 🟣(Signature)

      ( Signature 불일치 )
  • 대조 결과가 일치하지 않아 유저의 정보가 임의로 조작되었음을 알 수 있다

✅ JWT 장점

  • Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다
  • 인증 정보에 대한 별도의 저장소가 필요없다
    • (I/O 처리 필요 없음)
  • JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다

  • 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 된다

  • 확장성이 우수하다

  • 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다 (쿠키와의 차이)

  • OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다

  • 모바일 어플리케이션 환경에서도 잘 동작한다 (모바일은 세션 사용 불가능)

  • JWT 토큰은 DB조회를 줄일 수 있다 (DB조회를 안해도 된다)
    • Payload에 유저이름과 유저등급 을 같이 두고 보내도록 설정하면
    • 서버에서는 유저이름을 가지고 DB를 조회해서 유저 등급을 얻지않아도 바로 원하는 정보를 취할수 있다

✅ JWT 단점

  • 쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다

  • Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다 (비밀번호 등)

  • 토큰을 탈취당하면 대처하기 어렵다
    • 토큰은 한 번 발급되면 유효기간이 만료될 때까지 계속 사용이 가능하다
  • 특정 사용자의 접속을 강제로 만료하기 어렵다
    • 쿠키/세션 기반 인증은 서버 단에서 쉽게 삭제할 수 있지만 토큰 불가능하다

⭐ 최종 정리

JWT의 넓은 범용성, 무결성 보장, 필요한 값을 자체 포함할 수 있는 성질 때문에 많은 곳에서 JWT를 사용하고 있다

이전의 Session 방식이나 Cookie방식의 인가(Authenticate)를 사용하든 JWT를 사용하든 각각 장단점은 존재한다

장점단점
쿠키(Cookie) & 세션(Session)Cookie만 사용하는 방식보다 보안 향상
서버 쪽에서 Session 통제 가능
네트워크 부하 낮음
세션 저장소 사용으로 인한 서버 부하
JWT인증을 위한 별도의 저장소가 필요 없음
별도의 I/O 작업 없는 빠른 인증 처리
확장성이 우수함
토큰의 길이가 늘어날수록 네트워크 부하
특정 토큰을 강제로 만료시키기 어려움

👏 Reference

[WEB] 📚 JWT 토큰 인증 이란? - 💯 이해하기 쉽게 정리

쿠키, 세션, 토큰(JWT) 몰라도 괜찮겠어?

JWT(Json Web Token) 인증방식

인증 방식 : Cookie & Session vs JWT

[JWT] JSON Web Token 소개 및 구조

JWT를 소개합니다.

profile
🛫

0개의 댓글