JWT(Json Web Token) 인증 방식

JWT 기반 인증 (JSON Web Token)이란 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다.

JWT 기반 인증은 쿠키/세션 방식와 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별한다.

 

1. HTTP 특성

: HTTP는 인터넷 상에서 데이터를 주고 받기 위한 서버/클라이언트 모델을 따르는 프로토콜이다.

클라이언트가 서버에게 요청을 보내면서버는 응답을 보냄으로써 데이터를 교환한다.

HTTP는 비연결성과 무상태성이라는 특징을 가지고 있다.

HTTP는 요청에 대한 응답을 처리하게 되면 연결을 끊어버린다. 따라서 클라이언트에 대한 이전의 상태 정보 및 현재 통신의 상태가 남아 있지 않는다.

 

서버가 다수의 클라이언트와 연결을 계속 유지한다면, 이에 따른 자원 낭비가 심해진다.

비연결성 및 무상태성의 특징을 가진다면 불필요한 자원 낭비를 줄일 수 있다는 장점이 있다.

 

그러나 서버는 클라이언트를 식별 할 수 없다는 단점 또한 존재한다.

로그인을 하더라도 다음 요청에서는 해당 클라이언트를 기억하지 못해, 또 로그인을 해야 하는 문제가 발생한다.

브라우저에서 새로고침을 누를 때마다 로그인을 해야 한다면 매우 심각해질 것이다.

 

하지만 우리가 사용하는 웹 사이트들의 경우, 한 번 로그인 하면 로그인을 할 필요 없이 여러 사이트들의 기능을 사용 할 수 있다. 심지어는 로그인 유지가 되기도 한다.

이는 HTTP의 비연결성과 무상태성 특징을 보완한 기술인 Cookie와 Session 덕분이다.

 

2. Cookie

: 클라이언트가 어떠한 웹사이트를 방문 할 경우, 그 사이트가 사용하고 있는 서버를 통해 클라이언트의 브라우저에 설치

되는 작은 기록 정보 파일을 말하다.

단점

- 보안에 취약하다.

    - 요청 시 쿠키의 값을 그대로 보낸다.

    - 유출 및 조작 당할 위험이 존재한다.

- 쿠키에는 용량 제한이 있어 많은 정보를 담을 수 없다.

- 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 브라우저 간의 공유가 불가능하다.

- 쿠키의 사이즈가 커질수록 네트워크에 부하가 심해진다.

 

3. Cookie & Session 기반 인증

: 쿠키를 통해 클라이언트 로그인 상태를 유지 시킬 수 있지만, 쿠키가 유출 및 조작 당할 위험이 존재한다는 문제점이 있다. 개인 정보를 HTTP로 주고 받는 것은 위험하다.

 

세션은 비밀번호 등 클라이언트의 인정 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다.

 

장단점

 - 쿠키를 포함한 요청이 외부에 노출 되더라도 세션 ID 자체는 유의미한 개인정보를 담고 있지 않는다.

그러나 해커가 이를 중간에 탈취하여 클라이언트인 척 위장 할 수 있다는 한계가 있다.

- 각 사용자마다 고유한 세션 ID가 발급 되기 때문에 요청이 들어올 때마다 회원정보를 확인할 필요가 없다.

- 서버에서 세션 저장소를 사용하므로 요청이 많아지면 서버에 부하가 심해진다.

 

4. JWT

: JWT(Json Web Token)란 인증에 필요한 정보들을 암호화 시킨 토큰을 의미한다.

JWT 기반 인증은 쿠키/세션 방식와 유사하게 JWT 토큰(Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별함

 

구조

JWT는 .을 구분자로 나누어지는 세가지 문자열의 조합이다.

 

1) Header

: alg와 typ는 각각 정보를 암호화할 해싱 알고리즘 및 토큰의 타입을 지정한다.

2) Payload

: 토큰에 담을 정보를 지니고 있다. 주로 클라이언트의 고유 ID 값 및 유효기간 등이 포함되어 있는 영역이다.

key-value 형식으로 이루어진 한 쌍의 정보를 Clain이라고 한다.

3) Signature

: 인코딩된 Header와 Payload를 더한 뒤 비밀키를 해싱하여 생성한다.

Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작 할 수 있지만 Signature은 서버 측에서 관리하는 비밀키가 유출 되지 않는 이상 복호화 할 수 있다. 따라서 Signature은 토큰의 위변조 여부를 확인하는 데 사용된다.

인증 과정

1. 클라이언트 로그인 요청이 들어오면, 서버는 검증 후 클라이언트 고유 ID 등의 정보를 Payload에 담는다.

2. 암호화 할 비밀키를 사용해서 Access Token(JWT)을 발급한다.

3. 클라이언트는 전달받은 토큰을 저장해두고, 서버에 요청 할 때마다 토큰을 요청 헤더 Autorization에 포함시켜 함께 전달한다.

4. 서버는 토큰의 Signature를 비밀키로 복호화한 다음, 위변조 여부 및 유효기간 등을 확인한다.

5. 유효한 토큰이라면 요청에 응답한다.

 

장점

1. Header와 Payload를 가지고 Signature를 생성하므로 데이터 위변조를 막을 수 있다.

2. 인증 정보에 대한 별도의 저장소가 필요 없다.

3. JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증 되었음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다.

4. 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태가 된다.

5. 확장성이 우수하가.

6. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.

7. OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다.

8. 모바일 애플리케이션 환경에서도 잘 작동한다.

 

단점

1. 쿠키/세션과는 다르게 JWT는 토큰의 길이가 길어 인증 요청이 많아 질 수록 네트워크 부하가 심해진다.

2. Payload 자체는 암호화 되지 않기 때문에  유저의 중요한 정보를 담을 수 없다.

3. 토큰을 탈취 당하면 대처하기 어렵다.

4. 토큰은 한번 발급되면 유효기간이 만료 될 때까지 계속 사용이 가능하기 때문에 대처가 어렵다.

5. 특정 사용자의 접속을 강제로 만료하기 어렵지만, 쿠키/세션 기반 인증은 서버쪽에서 쉽게 세션을 삭제 할 수 있다.

 

5. 보안 전략

- 짧은 만료 기한 설정

- Sliding Session

- Refresh Token

 

6. 정리

출처

https://tecoble.techcourse.co.kr/post/2021-05-22-cookie-session-jwt/

인증 방식 : Cookie & Session vs JWT

 

관련 유튜브

https://www.youtube.com/watch?v=7abbNwuCXbg 

https://www.youtube.com/watch?v=THFmV5LPE6Y