[JWT]인증(authentication)에 보편적으로 사용되는 JWT에 대해서

web

jwt.io

1. 사용자 인증정보를 관리하는 두 가지

  • 세션 기반 인증

서버 기반 인증이라고 불리기도 한다. 과거부터 사용해오는 방법이며 이름에서 알 수 있듯이 유저가 서비스에 로그인을 하면 서버는 인증 정보를 계속해서 사용해야 하기 위해 메모리나 데이터 베이스에 저장하여 관리하는 방식이다. 세션 기반 방식은 정말 정말 널리 쓰이지만 크게 볼때 두 가지의 문제가 존재한다.

첫 번째, 서비스에 로그인 중인 유저가 많아지면 세션을 유지하기 위해 더 많은 메모리 / 데이터 베이스의 자원을 사용하게 됨으로 성능에 무리를 줄 수 있다. 두 번째, 서버의 확장이 어려워진다. 첫 번째 이유를 확장해 생각해볼때 분산 환경에서 세션을 사용하려면 분산된 서비스간에 세션의 정보가 동기화 되어야 함으로 구현의 복잡도가 매우 커질 것이다.

  • 토큰 기반 인증

HTTP의 두 가지 특성 - 무상태성 / 비연결성 - 에 따라 HTTP는 상태를 가지지 않는다. 그렇기 때문에 로그인한 상태를 파악하기 위해 세션 기반 인증을 사용하는 것인데, 이에 반해 토큰 기반 인증은 서버 측에서 상태를 유지하지 않고 로그인 시에 발급한 토큰을 통해 유저가 인증과정을 밟는 것이다. 서버의 구성이 분산되어 있더라도 유저는 동일한 토큰을 통해 서버에 요청할 수 있고, 서버는 데이터 베이스와 통신할 필요 없이 인증을 유지할 수 있어서 확장하기에 편해질 수 있다. 또한 모바일 어플리케이션에서 인증을 구현하기에 매우 편리하다는 장점이 있다.

2. 토큰 관리

  1. 브라우저 스토리지에 저장

유저가 로그인하면 서버는 응답정보에 토큰을 넣어 전달한다. 클라이언트는 브라우저의 localStorage나 sessionStorage에 저장하여 다음 번 요청때 요청 헤더에 토큰을 붙여 보낼 수 있다. 구현하기 매우 쉽지만 보안적으로는 큰 구멍이 존재하는데, 자바스크립트를 통해 웹 브라우저의 스토리지에 접근할 수 있기 때문이다.

  1. 쿠키에 저장

쿠키를 전송 수단으로써 사용한다. 서버 측에서 응답할때 쿠키 설정에 httpOnly 옵션을 활성화하면, 네트워크 통신 상에서만 해당 쿠키가 붙게 된다. 따라서, 자바스크립트가 브라우저를 통해 토큰 값을 사용할 수 없다. 그렇다고 보안상의 문제가 없는 것은 아니며 CSRF 공격의 위험성이 발생할 수 있다.

3. JWT란?

JWT는 Json Web Token의 약자로써 JSON 문자열로 이루어진 토큰을 의미한다. 토큰 기반 인증 기술 중 하나이며 다른 토큰들과는 다르게 토큰 그 자체가 의미를 가지는 Claim 기반의 토큰이다.

4. JWT의 구조

https://jwt.io/introduction/

Header / Payload / Signature - 세 개의 섹션으로 이루어져있다.

4-1. Header

JWT 웹 토큰의 헤더 정보

  • alg: 해시 알고리즘. 데이터 자체를 암호화 하는 것이 아니라 발급된 토큰을 검증하기 위해 사용한다.
  • typ: 토큰의 타입. JWT만 사용가능하다.
1
2
3
4
{
	"alg": "HS256",
	"typ": "JWT"
}

4-2. Payload

데이터가 저장되는 부분. 3가지의 Claim 데이터가 있다.

  • Reserved Claim
  • Public Claim
  • Private Claim : 사용자 정의 Claim으로써 아래와 같이 정보를 저장한다.
1
2
3
4
5
{
	"sub": "1234567890",
	"name": "John Doe",
	"admin": true
}

4-3. Signature

데이터의 무결성과 변조 방지를 위한 서명. Header와 Payload를 합친 후 Secret Key와 함께 Header에 명시한 알고리즘으로 해싱된 값이다.

1
2
3
4
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

4-4. 인증 과정

image

  1. 클라이언트가 로그인을 한다.
  2. 서버는 사용자의 정보를 확인 후 토큰을 생성하여
  3. 클라이언트에게 토큰을 전달한다.
  4. 로그인 후 모든 요청때, 헤더에 토큰 값을 붙여 전송한다.
  5. 토큰을 확인하여 유효한 토큰일 경우 요청을 처리한 뒤 응답한다.

4-5. 단점

  • Payload 부분에 데이터를 저장하기 때문에 데이터가 많아질 경우 토큰의 길이가 증가한다.
  • Payload의 데이터는 암호화가 아닌 base64로만 인코딩을 거친 값이다. 즉, 따로 암호화를 수행하거나 보안에 민감한 데이터를 포함하지 않아야만 한다.
  • 무상태(stateless)하기 때문에 한 번 생성한 토큰을 임의로 삭제할 수 없다. 꼭 토큰 만료시간을 설정하여 대비해야한다.

[참고]
https://jwt.io/introduction/
https://sanghaklee.tistory.com/47

Share