[Security] JWT

JWT 인증 (Authentication)

 

세션 기반 인증

세션 저장소(서버, 데이터 베이스)에 인증된 유저의 정보를 세션형식으로 담는 방식

 

특징

• 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리한다.
• 생성된 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
• 세션 ID만 클라이언트 쪽에서 사용하므로 상대적으로 적은 네트워크 트래픽을 사용한다.
• 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.
• 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.
• 세션 데이터가 많아지면 질수록 서버의 부담이 가중될 수 있다.
• SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식이다.

---

토큰 기반 인증

인증된 사용자의 정보를 토큰에 저장하고, 접근 권한을 부여해 특정 리소스에만 접근이 가능하게 하는 방식이다.

토큰 : 유저정보를 암호화 - 웹클라이언트가 보관

 

특징

• 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.
• 생성된 토큰을 헤더에 포함시켜 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
• 토큰내에 인증된 사용자 정보 등을 포함하고 있으므로 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다.
• 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.
• 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.
• 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이 되므로 민감한 정보는 토큰에 포함시키지 말아야 한다.
• 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화 시킬 수 없다.
• CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식입니다.

---

 

JWT (Json Web Token)

JWT는 일반적으로 액세스 토큰(Access Token)과 리프레시 토큰(Refresh Token)을 사용자의 자격 증명에 이용한다.

 

특징

• Access Token에는 비교적 짧은 유효 기간 을 주어 탈취 되더라도 오랫 동안 사용할 수 없도록 하는 것이 권장된다.
• Refresh Token은 Access Token의 유효 기간이 만료되었을 때, 재발급 받을 수 있게 해준다. 유효기간이 더 길다.
• JWT는 Header, Payload, Signature의 구조로 이루어진다.
• Base64로 인코딩되는 Payload는 손쉽게 디코딩이 가능하므로 민감한 정보는 포함하지 않아야 한다.

구조

1. header

이것이 어떤 종류의 토큰인지(지금의 경우엔 JWT), 어떤 알고리즘으로 Sign할지 정의한다. 

JSON 포맷 형태로 정의해야한다.

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

이렇게 생성된 JSON객체를 base64 방식으로 인코딩하면된다.

 

2. payload

서버에서 사용할 수 있는 사용자의 정보가 담겨있다.

어떤 정보에 접근 가능한지에 대한 권한, 사용자의 이름 등 필요한 데이터를 담을 수 있다.

Payload는 Signature를 통해 유효성이 검증될 정보이긴 하지만, 민감한 정보는 담지 않는 것이 좋다.

{
  "sub": "someInformation",
  "name": "phillip",
  "iat": 151623391
}

첫 번째 부분과 마찬가지로, 위 JSON 객체를 base64로 인코딩하면 된다.

 

3. signature

base64로 인코딩된 첫 번째, 그리고 두 번째 부분이 완성되었다면,

Signature에서는 원하는 비밀 키(Secret Key)와 Header에서 지정한 알고리즘을 사용하여 

Header와 Payload에 대해서 단방향 암호화를 수행한다.

 

이렇게 암호화 된 메시지는 토큰의 위변조 유무를 검증하는데 사용된다.

 

예를 들어, 만약 HMAC SHA256 알고리즘(암호화 방법 중 하나)을 사용한다면 Signature는 아래와 같은 방식으로 생성된다.

HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);

---

 

토큰 기반 인증 절차

1. 클라이언트가 서버에 아이디/비밀번호를 담아 로그인 요청을 보낸다.
2. 서버에 아이디/비밀번호가 일치하는지 확인하고, 클라이언트에게 보낼 암호화 된 토큰을 생성한다.
   • Access Token과 Refresh Token을 모두 생성한다.
     • 토큰에 담길 정보(Payload)는 사용자를 식별할 정보, 사용자의 권한 정보 등이 될 수 있다.
     • Refresh Token 이용해 새로운 Access Token을 생성할 것이므로 두 종류의 토큰이 같은 정보를 담을 필요는 없다.
3. 토큰을 클라이언트에게 전송, 클라이언트는 토큰을 저장한다.
   • 저장하는 위치는 Local Storage, Session Storage, Cookie 등이 있다.
4. 클라이언트가 HTTP Header(Authorization Header) 또는 쿠키에 토큰을 담아 request를 전송한다.
   • Bearer authentication을 이용한다.
5. 서버는 토큰을 검증하여 유효한 토큰으로 판단이 될 경우, 클라이언트의 요청을 처리한 후 응답을 보내준다.

---

 

 

JWT의 장점과 단점

 

장점

1. 상태를 유지하지 않고(Stateless), 확장에 용이한(Scalable) 애플리케이션을 구현하기 용이하다.

= 서버는 클라이언트 정보를 저장할 필요가 없고, 클라이언트는 request 전송 시 토큰을 헤더에 포함시키면 된다.

 

2. 클라이언트가 request 전송할 때 마다 자격 증명 정보를 전송할 필요가 없다.

= 토큰이 만료되기 전까지는 한 번의 인증만 수행하면 된다.

 

3. 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이하다.

= 자격 증명 정보를 직접 관리하지 않고 Github,Google,Kakao 등 다른 플랫폼을 통해 인증하는 것이 가능하다.

 

4. 권한 부여에 용이하다.

= 토큰의 Payload(내용물) 안에 해당 사용자의 권한 정보를 포함하는 것이 용이하다.

 

단점

1. Payload는 디코딩이 용이하다.

= base64로 인코딩 되기 때문에 토큰을 탈취하여 디코딩하면 정보를 확인할 수 있다.

따라서 민감한 정보를 담아선 안된다.

 

2. 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.

= request 마다 토큰을 함께 전송하기 때문에 네트워크에 부하를 줄 수 있다.

 

3. 토큰은 자동으로 삭제되지 않는다.

= 반드시 만료시간을 추가해줘야한다.탈취될 경우를 대비하여 만료시간을 짧게 설정해야한다.