[spring security] JWT 기본 지식

🌏기본 개념

---

JWT( JSON Web Token)는 웹에서 정보를 안전하게 전송하기 위한 표준 방법 중 하나 이다.
이러한 JWT 는 사용자에 대한 인증, 인가에 많이 사용된다.

그럼 여기서 말하는 인증, 인가란 무엇일까?

 

🌏인증 인가

---

• 인증
  • 인증이란, 우리가 서비스에서 사용하는 로그인과 같다고 생각하면 된다.
  • 사용자가 신원을 확인하는 과정을 말한다.
  • 로그인을 진행하게 되었을 때, ID 와 Password 를 이용하게 되면서 사용자에 대하여 인증을 하는 과정을 가지게 된다.
  • 쉽게 말해 인증이란, "누구인가?" 에 대한 과정을 처리하는 것이라 생각하면 된다.
• 인가
  • 인가는 인증 받은 사용자가 어떤 서비스, 자원에 접근이 가능한가 를 확인하는 것이다.
  • 인가는 인증 후에 이루어지며, 로그인을 통해 인증 받은 사용자는 특정 작업을 수행 할 수 있는 것을 나타낸다.
  • 쉽게 말해 인가란, "무엇을 할 수 있는가?" 라는 질문에 답 할 수 있다.

여기서 설명하는 JWT 는 인증과 인가에 많이 사용된다. 우리는 처음 로그인을 실행하게 되었을 때, 아이디와 비밀 번호를 확인하여 JWT 를 주게 되고, 부여한 JWT 토큰을 기반으로 인가를 확인하여 서비스에 접근을 허용하게 된다.

🌏JWT 의 구조

---

JWT는 Base64로 인코딩된 JSON 객체로 이루어져 있으며, 세 부분으로 구성된다.
세 부분은 헤더(Header), 페이로드(Payload), 서명(Signature) 이다.
아래에 있는 사이트에 접속하게 된다면, JWT 의 예를 확인할 수 있다.

 

• JWT 공식 사이트
  https://jwt.io/

JWT.IO

 

지금부터 설명하는 헤더, 페이로드, 서명은 꼭 알아야 하는 개념 및 구조이다. 이러한 이유는 차후에 사용하게 될 스프링 시큐리티에서 직접 사용되는 개념이기 때문이다.

• 헤더(Header)

  • 헤더는 JWT의 정보를 포함한다. 일반적으로 헤더에는 두 가지 정보가 포함된다: 토큰의 유형 및 사용된 해시 알고리즘이 두 가지를 포함한다.
  • 헤더는 Base64로 인코딩되어 있다. 그러므로 실제로는 사람이 읽기 어렵다. 하지만 Base64로 디코딩 한다면, 다시 읽을 수 있다.
  • JWT 는 헤더와 페이로드는 Base64로 인코딩 되어있기 때문에, 디코딩하면 원래의 JSON 형식으로 표현된 데이터를 얻을 수 있다.

• 페이로드(Payload)

  • 페이로드는 실제로 전달되는 데이터를 포함한다.
  • 페이로드는 클레임(claim)이라고 불리는 키-값 쌍으로 구성되어 있으며. 클레임에는 세 종류가 있다.
    • 등록된 클레임(Registered claims): 특정 의미를 가진 클레임으로, 예를 들어 발급자(iss), 만료 시간(exp) 등이 포함될 수 있다. (시큐리티에도 기본적으로 있다.)
    • 공개 클레임(Public claims): 클라이언트와 서버가 사전에 협의하여 사용되는 클레임이다.
    • 비공개 클레임(Private claims): 사용자 정의 클레임으로, 클라이언트와 서버 간에 공유되는 정보를 포함할 수 있다.
      (참고로 나는 아직 공개 클레임과 비공개 클레임이 크게 뭔 차인지 명확하게 잘 모르겠다.. 둘 다 개인적으로 정의해서 사용하는 걸로는 알고 있다.)

• 서명(Signature)

  • 서명 부분은 Base64로 인코딩된 데이터다.
  • 서명은 헤더와 페이로드를 결합한 후, 특정 비밀 키를 사용하여 해싱 된 값 이다.
  • 서명은 디코딩하면 일반적으로 읽을 수 없는 바이너리 데이터가 된다.
  • 서명은 검증을 위한 것이므로 원래의 데이터를 확인하는 데 사용되는 것이 주된 목적이다.
  • 서명은 헤더와 페이로드를 조합하여 생성되는 문자열이다. 이는 JWT의 유효성을 확인하는 데 사용됩니다.
  • 이 서명은 JWT를 수신한 서버에서 다시 계산하여 유효성을 확인한다.
  • 서명은 헤더에서 지정된 해시 알고리즘을 사용하여 생성된다. 예를 들어, HS256 알고리즘이 지정된 경우 HMAC SHA-256 해싱 알고리즘을 사용하여 서명이 된다.
  • 쉽게 말해서 우리가 가지고 있는 JWT 가 맞는지 확인하는 부분이다.

JWT의 VERIFY SIGNATURE 단계에서는 다음과 같은 과정이 진행된다

1. 헤더와 페이로드를 조합하여 서명을 생성합니다.
2. 서버는 이전에 사용된 동일한 키를 사용하여 토큰을 발급한 서버와 동일한 서명을 생성합니다.
3. 서버는 클라이언트로부터 전송된 JWT의 서명을 추출합니다.
4. 추출된 서명과 서버가 생성한 서명을 비교하여 일치하는지 확인합니다.
5. 일치하는 경우, 토큰의 유효성이 검증되었으며, 클라이언트의 요청을 수행할 수 있습니다.

 

🌏JWT 사용 이유

---

그럼 우리는 왜 JWT 를 사용할까?
그냥 쿠키, 세션 사용해서 하면 되는 거 아니야? 뭐 하러 이런 거를 만들어서 고생하지? 라는 생각을 할 수 있다.

 

가장 큰 이유로는 세션은 우리의 정보를 서버에 저장하게 되면서 Stateful(상태유지) 를 하게 된다. 이런 점에 있어, 서버와 긴밀하게 연관 되면서, 서버의 리소스(자원)를 사용하게 되면서 많은 접속을 해야하는 서버에서는 조금 부담스러운 방법이라 할 수 있다.

 

하지만 JWT 는 티켓을 확인하듯이 토큰의 내용만 확인하면 되기 때문에 Stateless(무상태) 한 특성을 가지고 있다. 하지만, accessToken 이나 refreshToken 을 사용하게 된다면 refreshToken 을 서버에서 저장하게 되면서 세션과 비슷하지만 좀 더 약한? 관계를 가지게 되는 차이가 존재한다. (accessToken, refreshToken 에 대한 개념은 추후에 설명하겠다.)

아무튼 이런 식으로 나는 JWT 를 정리해 보았다.