[Network]JWT(JSON Web Token)

지난 글에선 세션 인증 방식과 토큰 인증 방식을 비교했다.

 

2022.09.23 - [Development/Network] - [Network]세션 기반 인증 vs. 토큰 기반 인증

[Network]세션 기반 인증 vs. 토큰 기반 인증

이번 글에서는 토큰 기반 인증 방식의 표준인 JWT에 대해 알아보자.

 

JWT(JSON Web Token)

 

JWT(JSON Web Token)는 이름 그대로 JSON으로 만들어진 웹 토큰을 말한다.

 

조금 구체적으로는 데이터를 안전하면서도 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식이라 할 수 있다.

 

작업은 JSON으로 이루어진 정보를 인코딩한 뒤에 인코딩 된 토큰 정보를 비밀 키(Secret Key)로 서명(Sign)해서

 

웹 토큰으로 사용하는 식으로 진행된다.

 

공식 홈페이지에 들어가보면 인코딩 및 디코딩을 해볼 수 있다.

 

https://jwt.io/

JWT.IO

 

Access Token, Refresh Token

 

지난 글에서 토큰에 대해 설명할 때, 토큰은 만료가 될 때까지 무효화시킬 수 없다고 했었다.

 

추가로 보안을 위해 만료시간을 짧게 주는 대신 Refresh Token을 발급하는 방법을 사용한다고 했는데,

 

JWT의 종류도 이와 같이 두 가지가 된다.

 

사용자가 처음으로 인증 요청을 하면 서버는 위의 두 가지 토큰을 모두 발급한다.

 

그중 Access Token은 흔히 토큰이라고 하면 떠올리는 것과 같이, 특정 리소스에 대한 권한 부여에 사용된다.

 

즉, 권한 부여에는 Access Token만 있으면 된다는 뜻이다.

 

하지만 위에 말했던 대로 보안을 위해 Access Token의 만료 시간을 짧게 주는 것이 좋은데,

 

이때 새로운 Access Token을 발급하기 위해 사용되는 것이 Refresh Token이다.

 

 

위 그림처럼 Access Token이 만료되면 유효기간이 긴 Refresh Token을 사용해 새로운 Access Token을 발급받는다.

 

하지만 이 과정에서 Refresh Token까지 탈취당하면 큰 문제가 생기기 때문에,

 

사용자의 편의보다 보안을 더 중요시 해야 하는 앱에서는 Refresh Token 자체를 사용하지 않기도 한다.

 

추가로 Refresh Token은 새로운 Access Token 발급에만 사용되므로 두 토큰이 같은 정보를 담을 필요는 없다.

 

Structure

 

JWT는 위와 같이 세 부분으로 나뉜다.

 

헤더에는 Sign할 알고리즘 방식과("alg") 생성할 토큰의 타입("typ")을 JSON으로 담는다.

 

페이로드에는 사용자 정보와 권한 정보 등 필요한 정보가 JSON으로 담기지만, 민감한 정보는 담지 않는다.

 

시그니처에서는 Base64로 인코딩한 헤더와 페이로드의 정보를 가져와

 

원하는 비밀키와 헤더에서 지정한 알고리즘을 결합해 단방향 암호화를 진행한다.

 

이렇게 암호화된 메시지는 토큰의 자격을 증명하는 데 사용된다.

 

Workflow

 

JWT는 예를 들면 아래와 같은 상황에서 쓰인다.

 

• A 앱에서 Gmail과 연동해 이메일을 읽어와야 한다.
• 사용자가 인증 서버에 로그인 정보를 제공하고 JWT를 발급받는다.
• A 앱이 JWT를 이용해 사용자의 이메일을 읽어온다.

이처럼 Gmail과 아무 상관없는 앱이라도 JWT를 이용해 이메일에 접근할 수 있게 된다.

 

사실 JWT 기반 인증 절차는 일반적인 토큰 기반 인증 방식과 차이가 없다.

 

그래도 그림을 보면서 절차를 되짚어 보자.

 

사용자가 보낸 인증 정보를 확인한 후 JWT(Access Token + Refresh Token)를 발급하고

 

클라이언트는 토큰을 저장(Local Storage, Session Store, Cookie)한다.

 

이후 요청의 헤더 혹은 쿠키에 토큰을 담아 전송하면 서버는 토큰을 검증한 뒤 적절한 응답을 보내는 식이다.

 

Pros and Cons

 

마지막으로 JWT의 장점과 단점을 간략하게 알아보자.

 

읽어보면 알겠지만 그대로 토큰 기반 인증 방식의 장단점이 되기도 한다.

 

Pros

 

• 상태를 유지하지 않으며(Stateless), 확장성이 좋은(Scalable) 앱을 구현하기 편하다.
  
  
  • 서버는 토큰의 검증여부만 판단한다.
  • 클라이언트의 정보가 서버에 저장되지 않기 때문에 부하가 덜 걸린다.
  • 여러 대의 서버를 이용한 서비스라도 하나의 토큰으로 인증이 가능하다.
• 클라이언트가 요청마다 인증 정보를 전송할 필요가 없다.
  
  
  • 처음 한 번의 인증 후 토큰을 만료 전까지 사용할 수 있다.
• 인증 시스템의 분리가 편리하다.
  
  
  • 자격 증명 정보를 직접 관리하지 않기 때문에 Google 등 다른 플랫폼의 자격 증명 정보로 인증이 가능하다.
  • 토큰 생성용 서버를 따로 만들거나 다른 회사에 토큰 관련 작업을 맡기기 쉽다.
• 권한 부여가 편리하다.
  
  
  • 토큰의 페이로드 안에 권한 정보를 포함할 수 있다.

 

Cons

 

• 페이로드의 디코딩(복호화)이 간단하다.
  
  
  • 페이로드는 base64로 인코딩 되기 때문에 토큰으로부터 데이터를 확인하기가 용이하다.
• 토큰의 정보가 많아지면(길이가 길어지면) 네트워크에 부하가 간다.
• 토큰은 자동으로 삭제되지 않으므로 반드시 적절한 만료 시간을 설정해야 한다.

 

Summary

 

• JWT는 Access Token과 Refresh Token으로 나뉜다.
• Access Token은 자격 증명에 사용되며 짧은 만료기한을 부여하는 것이 좋다.
• 만료된 Access Token은 Refresh Token으로 다시 발급 받는다.
• JWT는 Header.Payload.Signature로 이루어진다.
• Payload는 Base64로 인코딩 돼 디코딩이 쉽기 때문에 민감한 정보는 담지 않아야 한다.
• 토큰이 길어지면 네트워크에 부하가 가므로 너무 많은 정보를 담지 않아야 한다.