[10] JWT 토큰인증에 대해서.. ( 쿠키 / 세션 / 토큰 ) - Access Token, Refresh Token

들어가기 전에...

보통 서버에서 클라이언트 인증을 확인하는 방식은 쿠키 / 세션 / 토큰으로 나누어진다.

이 세 가지를 알아보고 JWT를 다뤄보겠다.

---

1. Cookie / Session / Token 

1-1. Cookie 인증

: 쿠키는 Key-Value 형식의 문자열 덩어리이다.

다시 말해, 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일을 말하는 것이다.

 

※ Cookie 방식의 단점

- 보안에 취약함 (★결정적인 단점임!!)

- 용량에 제한이 있어서 많은 정보를 담을 수가 없음

- 브라우저 간 공유가 불가능함

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

 

1-2. Session 인증

: 보안에 취약한 쿠키의 단점 때문에 세션의 경우에는 클라이언트의 민감한 정보(비밀번호 등등)를 브라우저가 아닌 서버측에 저장하고 관리한다. 서버의 로컬 파일이나 데이터베이스에 저장하기도 한다.

 

"세션 = Key(세션ID) + Value"로 구성되어있다. 

 

※ Session 방식의 단점

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

- 서버 요청이 많아지면 서버에 과부하가 걸린다.

 

1-3. Token 인증

: 토큰 기반 인증 시스템은 클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 '토큰'을 부여한다. 이 토큰은 유일하며 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 심어서 보낸다. 그러면 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다.

 

서버기반 vs 토큰기반

- 서버기반 : 서버의 세션을 사용해 사용자 인증을 하는 방법으로 서버측(서버 램 or 데이터베이스)에서 사용자의 인증정보를 관리하는 것을 의미

이는 사용자가 증가하면 성능에 문제가 생길 수 있으며... 확장성이 어렵다는 단점이 있다...

 

- 토큰기반 : 서버기반의 단점을 극복하기 위해서 토큰 기반 인증 시스템이 나왔다.

 

1-4. Token 인증 방식

1) 사용자가 아이디와 비밀번호로 로그인을 한다.

2) 서버 측에서 사용자(클라이언트)에게 유일한 토큰을 발급한다.

3) 사용자는 서버 측에서 전달받은 토큰을 쿠키나 스토리지에 저장해 두고, 서버에 요청을 할 때마다 해당 토큰을 HTTP 요청 헤더에 포함시켜서 전달한다.

4) 서버는 전달받은 토큰을 검증하고 요청에 응답한다.

 

※ Token 방식의 단점

- 쿠키/세션과 다르게 토큰 자체의 데이터 길이가 김 -> 인증 요청이 많을 수록 네트워크가 과부하걸림

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

- 토큰을 탈취 당하면 대처하기 어려움

---

2. JWT ( JSON Web Token ) 란 무엇인가..??

: JWT란 인증에 필요한 정보들을 함호화시킨 JSON 토큰을 의미한다. 그리고 JWT 기반 인증은 JWT 토큰 (Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식이다.

사용자가 JWT 를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.

 

2-2. JWT 구조

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

[ . 을 기준으로 좌측부터 Header, Payload, Signature ]

 

- 헤더 (Header)

: JWT 에서 사용할 타입과 해시 알고리즘의 종류 담겨져있다.

{
	"alg" : "HS256", // 서명 암호화 알고리즘
	"typ" : "JWT" // 토큰 유형
}

 

- 정보 (Payload)

: 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨있다.

 

- 서명 (Signature)

: Header, Payload 를 Base64 URL-safe Encode 를 한 이후 Header 에 명시된 해시함수를 적용하고, 개인키(Private Key)로 서명한 전자서명이 담겨있다.

 

2-3. JWT 장단점

	장점	단점
Cookie & Session	Cookie만 사용하는 방식보다 보안 향상 서버 쪽에서  Session 통제 기능 네트워크 부하 낮음	세션 저장소 사용으로 인한 서버 부하
JWT	인증을 위한 별도의 저장소가 필요없음 별도의 I/O 작업 없는 빠른 인증 처리 확장성이 우수함	토큰의 길이가 늘어날수록 네트워크 부하 특정 토큰을 강제로 만료시키기 어려움

 

BUT 이 JWT도 제 3자에게 토큰 탈취의 위험성이 있기 때문에 Access Token과 Refresh Token 으로 인증하는 방식을 현업에선 취한다. ▼▼▼▼

---

3. JWT의 Access Token / Refresh Token

- Access Token : 접근에 관여하는 토큰

클라이언트가 갖고있는 실제로 유저의 정보가 담긴 토큰으로, 클라이언트에서 요청이 오면 서버에서 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행

 

- Refresh Token : 재발급에 관여하는 토큰

새로운 Access Token을 발급해주기 위해 사용하는 토큰으로 짧은 수명을 가지는 Access Token에게 새로운 토큰을 발급해주기 위해 사용. 해당 토큰은 보통 데이터베이스에 유저 정보와 같이 기록

 

3-2. Refresh Token 인증 과정

1) 사용자가 ID , PW를 통해 로그인

2) 서버에서는 회원 DB에서 값을 비교

3~4)로그인이 완료되면 Access Token, Refresh Token을 발급한다. 이때 회원DB에도 Refresh Token을 저장해둔다.

5) 사용자는 Refresh Token은 안전한 저장소에 저장 후, Access Token을 헤더에 실어 요청을 보낸다.

6~7) Access Token을 검증하여 이에 맞는 데이터를 보낸다.

8) 시간이 지나 Access Token이 만료됐다.

9) 사용자는 이전과 동일하게 Access Token을 헤더에 실어 요청을 보낸다.

10~11) 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보낸다.

---

JWT 정리 끝~