JWT(JSON Web Token) 정리

💡 서버(세션) 기반의 인증 시스템

서버(세션)기반의 인증 시스템이란?

서버 기반의 인증 방식으로, 서버 측에서 사용자들의 정보를 기억하는 방식.
사용자들의 정보를 기억하기 위해서는 세션을 유지해야 하는데, 메모리나 디스크 또는 데이터베이스 등을 통해 관리한다.

stateful 서버

클라이언트로부터 요청을 받으면, 클라이언트의 상태를 계속해서 유지하고 이 정보를 서비스에 이용한다.
예를 들어 사용자가 로그인을 하면, 세션에 사용자 정보를 저장해두고 서비스를 제공할 때 사용한다.

흐름

문제점

1. 메모리 과부하

사용자가 인증을 할 때, 서버는 이러한 정보를 저장해야 하고 이를 세션(Session)이라고 부른다.
세션을 메모리나 데이터베이스에 저장하는데, 로그인 중인 사용자가 늘어날 경우에는 서버의 RAM에 부하가 걸리거나 데이터베이스에 무리를 줄 수 있다

 

2. 확장성

사용자가 늘어나게 되면 더 많은 트래픽을 처리하기 위해 서버를 확장해야 한다.
세션을 사용시, 세션을 분산시키는 시스템을 설계해야 하지만 그 과정이 매우 어렵고 복잡하다.

 

3. CORS(Cross-Origin Resource Sharing)

세션을 관리할 때 자주 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어있기 때문에 쿠키를 여러 도메인에서 관리하는 것은 번거롭다.

💡 토큰 기반의 인증 시스템

토큰 기반 인증 시스템이란?

인증받은 사용자들에게 토큰을 발급하고, 서버에 요청을 할 때 헤더에 토큰을 함께 보내도록 하여 유효성 검사를 하는 방법.

stateless 구조

사용자의 인증정보를 서버나 세션에 유지하지 않고, 클라이언트 측에서 들어오는 요청만으로 작업을 처리한다.

흐름

1. 사용자가 아이디와 비밀번호로 로그인을 한다.
2. 서버 측에서 해당 정보를 검증한다.
3. 정보가 정확하다면, 서버 측에서 사용자에게 signed 토큰을 발급한다.
4. 클라이언트 측에서 전달받은 토큰을 저장해두고, 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달한다.(Http 요청 헤더에 토큰을 포함)
5. 서버는 토큰을 검증하고, 요청에 응답한다.

장점

1. 무상태성(Stateless) & 확장성(Scalability)
   토큰은 클라이언트 측에 저장되기 때문에 서버는 완전히 Stateless하며, 클라이언트와 서버의 연결고리가 없기 때문에 확장하기에 매우 적합하다.
   만약 사용자 정보가 서버 측 세션에 저장된 경우에 서버를 확장하여 분산처리 한다면, 해당 사용자는 처음 로그인 했었던 서버에만 요청을 받도록 설정을 해주어야 한다.
   하지만 토큰을 사용한다면 어떠한 서버로 요청이 와도 상관이 없다.
2. 확장성(Extensibility)
   시스템의 확장성을 의미하는 Scalability와 달리 Extensibility는 로그인 정보가 사용되는 분야의 확정을 의미한다. 토큰 기반의 인증 시스템에서는 토큰에 선택적인 권한만 부여하여 발급할 수 있으며 OAuth의 경우 Facebook, Google 등과 같은 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.
3. 여러 플랫폼 및 도메인
   서버 기반 인증 시스템의 문제점 중 하나인 CORS를 해결할 수 있다.
   토큰을 사용한다면 어떤 디바이스, 어떤 도메인에서도 토큰의 유효성 검사를 진행한 후에 요청을 처리할 수 있다.

💡 JWT(JSON Web Token)

JWT 이란?

• Json 포맷을 이용하여 데이터를 저장하는 Claim 기반의 웹 토큰이다.
• 토큰 자체에 정보가 저장되는 Self-Contained 방식으로 정보를 안전하게 전달한다.
• 주로 회원 인증이나 정보 전달에 사용된다.

로직

• 애플리케이션이 실행될 때, JWT를 static 변수와 로컬 스토리지에 저장한다.

static 변수에 저장되는 이유는 HTTP 통신을 할 때마다 JWT를 HTTP 헤더에 담아서 보내야 하는데, 이를 로컬 스토리지에서 계속 불러오면 오버헤드가 발생하기 때문이다.

• 클라이언트에서 JWT를 포함해 요청을 보내면 서버는 허가된 JWT인지를 검사한다. 또한 로그아웃을 할 경우 로컬 스토리지에 저장된 JWT 데이터를 제거한다. (실제 서비스의 경우에는 로그아웃 시, 사용했던 토큰을 blacklist라는 DB 테이블에 넣어 해당 토큰의 접근을 막는 작업을 해주어야 한다.)

JWT 구조

• Header, Payload, Signature의 3부분으로 이루어진다.
• JSON 형태인 각 부분은 Base64Url로 인코딩 되어 표현된다.
• 토큰의 각 부분은 .을 구분자로 사용한다.

Header(헤더)

• typ과 alg 두 가지 정보로 구성된다. alg는 헤더(Header)를 암호화 하는 것이 아니고, Signature를 해싱하기 위한 알고리즘을 지정하는 것이다.
• typ: 토큰의 타입을 지정.
• alg: 알고리즘 방식을 지정하며, 서명(Signature) 및 토큰 검증에 사용

{
    "alg": "HS256",
    "typ": JWT
}

Payload(페이로드)

토큰에서 사용할 정보의 조각들인 클레임(Claim)이 담겨 있다.

Claim의 경우 총 3가지로 나뉜다.

• Registered Claim(등록된 클레임)
  미리 정해져있는 키로 구성된 데이터들로 각 키에 해당하는 데이터는 선택적으로 사용할 수 있다.

iss(토큰 발급자), sub(토큰 제목, unique한 값을 사용), aud(토큰 대상), exp(토큰 만료시간, NumericDate 형식), nbf(토큰 활성화 시간, 이 날이 지나기 전의 토큰은 활성화 되지 않음), iat(토큰 발급시간, 토큰 발급 이후의 경과 시간을 알 수 있음), jti(토큰 고유 식별자, 중복 방지를 위해 사용하며 일회용 토큰(Access Token) 등에 사용)

• Public Claim(공개 클레임)
  사용자 정의 클레임으로 공개용 정보를 위해 사용한다. 충돌 방지를 위해서 URI 포맷을 사용한다.

ex)
{
    "https://yeeeh.tistory.com": true
}

• Private Claim(비공개 클레임)
  사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다.
  공개 클레임과는 다르게 일반적인 Key:Value 구조를 사용하므로 충돌 가능성이 존재하여 사용에 유의해야 한다.
  사용자 인증에 사용되는 토큰의 경우 사용자 특정을 위한 실질적인 정보로 구성된다.
  Header와 같이 암호화가 진행되지 않는다.

ex)
{
    "token_type": access
}

Signature(서명)

서명(Signature)은 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드이다.

생성 절차

1. 헤더(Header)와 페이로드(Payload)의 값을 각각 BASE64Url로 인코딩한다.
2. 인코딩한 값을 비밀 키를 이용해 헤더(Header)에서 정의한 알고리즘으로 해싱을 한다.
3. 이 값을 다시 BASE64Url로 인코딩하여 생성한다.
4. 생성된 토큰은 HTTP 통신을 할 때, Authorization이라는 key의 value로 사용된다. 일반적으로 value에는 Bearer이 앞에 붙여진다.

{
    "Authorization" : "Bearer {생성된 토큰 값}",
}

JWT 장단점

장점

• Self-Contained 의 특성에 따라서 별도의 인증 저장소를 필요로 하지 않는다.
• MSA 환경에서 중앙 집중식 인증 서버와 DB에 의존하지 않는 인증 및 인가 방법을 제공한다.
• 유효성 검사 과정에서 IO 또는 네트워크 액세스를 필요로 하지 않고 최신 웹 서버 HW에서 확장이 용이하다.
• 트래픽 대한 부담이 낮음
• REST 서비스로 제공 가능

단점 및 고려사항

• 토큰 길이: 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다.
• Payload 인코딩: 중요한 부분인 Payload 파트가 암호화되지 않기 때문에 추가적인 암호화 방안을 고려하거나, Payload에 중요한 데이터를 넣지 않고 운영해야 한다.
• Stateless: 토큰 자체에서 상태를 관리하지 않기때문에 토큰 만료와 관련된 데이터를 필수로 사용해야 한다.

Access Token, Refresh Token

Access Token 만을 통한 인증 방식은 제 3자에게 탈취당할 경우 보안에 취약하다는 문제점이 있다.
Access Token의 유효기간을 짧게 하고, Refresh Token의 유효기간을 길게하는 방식을 이용한다.

• 예시

1. 처음에 로그인을 할 때, 서버는 로그인 성공과 함께 클라이언트에게 Access Token과 Refresh Token을 동시에 발급한다.

2. 서버는 데이터베이스에 Refresh Token을 저장하고, 클라이언트는 Access Token과 Refresh Token을 저장하고, 요청을 할때마다 두 토큰을 헤더에 담아서 보낸다.

사용자가 인증이 필요한 API에 접근하고자 하면, 가장 먼저 토큰을 검사한다.
이때, 토큰을 검사함과 동시에 각 경우에 대해서 토큰의 유효기간을 확인하여 재발급 여부를 결정한다.

case1 : access token과 refresh token 모두 만료
→ 에러 발생 (재 로그인하여 둘다 새로 발급)
case2 : access token은 만료, refresh token은 유효
→ refresh token을 검증하여 access token 재발급
case3 : access token은 유효, refresh token은 만료
→ access token을 검증하여 refresh token 재발급
case4 : accesss token과 refresh token 모두가 유효
→ 정상 처리

3. 로그아웃을 하면 Acces Token과 Refresh Token을 모두 만료시킨다.