[Auth] - Jwt 토큰 인증, 세션(서버) 방식 인증 개념

-Topic-
1. 토큰 인증, 세션(서버)인증 개념
2. Jwt 개념

 

---

 

Why 

웹 애플리케이션은 [ 회원 / 비회원 ], [ 회원 등급 기준] , [ 일반 사용자 / 관리자 ] 등의 특정 인증 사용자에게만 페이지 접근이 가능하도록 하는 등의 권한 제어가 필요한 경우가 많다. 이 때, 어떻게 접근자A 가 어떤 상태를 갖는지 확인하는 인증 방법이 필요하고, 주로 사용되는 방식으로 사용자 세션 기반 인증과 토큰 인증 방식이 있다.

 

🔗세션(서버) 기반 인증 - stateful

세션 방식의 주요 특징은 사용자가 로그인 시 세션ID를 생성하고 사용자 브라우저에 저장 및 서버의 DB에 저장하고, 사용자가 권한이 필요한 기능을 실행할 때, 브라우저에 저장된 세션 ID가 포함된 요청을 서버에 보내게 되면 DB에 해당 세션 정보가 있는지 확인하는 방식이다.

 

➡️서버에 세션의 상태를 저장하기 때문에 stateful 한 방식이다.

 

세션 기반 인증의 장점

• 세션 무효화
  • 특정 세션ID가 비정상적으로 이용또는 탈취 됨을 확인했을 경우, 서버에서 해당 데이터를 삭제 하는 방법으로 해당 세션을 막을 수 있다.

 

세션 기반 인증의 단점

• 성능 문제
  • 사용자 세션 인증이 필요할 때마다 DB 에 해당 세션 ID가 있는지 확인이 필요하므로 성능이 저하될 수 있다.

 

세션 기반 인증으로 불리는 방식은, 사용자 Session Storage 뿐만 아니라 Cookie 등, 브라우저에 저장될 수 있으며, 주로 HttpOnly Cookie 를 사용한다.

 

☑️브라우저 저장 위치의 차이

	Storage( Local / Session Storage )	Cookie
접근 방식	클라이언트 측 자바스크립트를 통해 직접 접근 가능	서버와 클라이언트 간 자동 전송
보안	Secure, HttpOnly, SameSite 등 지원 불가 ➡️ XSS 공격에 취약	HttpOnly 지원 XSS 및 CSRF 방지 옵션 제공
자동 전송	수동으로 데이터 전송 필요 ➡️필요할 때만 전송 가능	모든 HTTP 요청 시 자동 전송
데이터 용량	일반적으로 5MB 이상 지원	약 4KB 제한
구현 용이성	자바스크립트로 간단히 구현 가능	서버와 클라이언트 모두 설정 필요

 

♦️HttpOnly Cookie?

일반 쿠키는 클라이언트 측 JavaScript 로 접근이 가능하여 XSS 공격에  취약한 반면, HttpOnly 쿠키는 JavaScript 로 접근할 수 없기 때문에 XSS 공격으로부터 보호된다.

 

 

🎟️토큰 기반 인증 - stateless

웹에서 Token 은 어떤 작업을 수행할 수 있는 권한을 나타내는 객체이다. Token을 보유한 사용자가 어떠한 특정 인증 매커지즘을 걸쳐 권한을 부여 받을 수 있도록 하는 토큰을 Bearer Token이라하며, 인증 매커니즘을 통해 이 토큰을 소유하는 것 자체가 권한을 가지는 것을 의미하므로 이용권 처럼 작동하게 된다.

 

세션(서버) 인증 방식은 서버단의 DB에서 사용자 세션 ID 상태를 관리하는 stateful 방식이지만, 토큰 기반 인증은 클라이언트 단에서 보낸다면, 서버단에서 별도로 DB에서 세션ID에 관련된 상태를 관리할 필요 없이 요청에 포함된 토큰이 올바른 토큰인지만 확인하여 요청 응답 값을 반환해주는 stateless 인증 방식이다.

 

 

토큰 기반 인증의 장점

• 성능 향상
  
  • 서버에서 별도로 상태관리를 하지 않는 stateless 방식 이므로, 토큰이 유효한 토큰인지만 확인하면 되므로 처리가 빠르다.

 

토큰 기반 인증의 단점

• 토큰에 대한 제어권이 없다
  
  • 토큰이 탈취당한 것을 확인했을때, 그 즉시 만료시키거나 토큰의 유효성을 제어할 수 없다.

 

세션 기반 인증 + 토큰 기반 인증

 

세션 기반 인증 방식과 토큰 기반 인증 방식은 함께 사용되는 것이 권장된다. 

Token을 Access Token, Refresh Token 으로 나누어서 관리 하는 방법으로 AccessToken 은 별도로 서버에서 저장하지 않는 토큰 방식 인증 방식을 적용하고 5분 ~ 10 분 사이의 짧은 만료 기한을 두어 Refresh Token을 통해 AccessToken을 재발급 할 수 있도록 해준다. Refresh Token은 DB에 저장해서 AccessToken 재발급 요청이 들어오면 세션 인증 방식으로 Refresh Token 이 DB에 존재하는지 유효성을 검사한 뒤, AccessToken을 재발급하는 방식이다.

 

 

 

 

JWT

 

일반 Token과 Claim Token, JWT 를 순서대로 배우면 조금 더 이해가 쉬운 느낌이다.

 

🎫 Token

먼저 기본적인 Token 은 단순한 문자열 형태로, 위변조를 막기 위해 임의의 문자열로 구성된 문자열로 구성되고, 추가적인 정보나 메타 데이터를 포함하지 않는다. 일반적인 API 키와 같이 사용자 정보나 권한을 포함하지 않는 단순한 Token 이다.

 

📄Claim Token

정보를 포함하지 못하는 기본적인 토큰에서 진보된 방식으로, 만료 시간, 사용자의 권한 과 같은 사용자에 대한 메타데이터 정보를 헤더, 페이로드(클레임), 시그니쳐로 나누어 구조화하여 Token에 정보를 저장할 수 있도록 설계한 구조를 클레임(Claim) 토큰 방식이라고 한다. 구체적으로 사용자 정보 저장에 대한 방식보다, 사용자 정보를 저장할 수 있도록 하는 토큰 유형의 인터페이스 인 샘이다.

 

📜JSON Web Token

클레임 토큰의 구체적인 구현 방식으로, 헤더, 페이로드, 시그니쳐가 Json 의 형식으로 존재하는 '이 토큰'을 통해 클라이언트가 서버에 요청을 할 경우 시그니쳐+헤더의 정보를 통해 서명 검증 후 페이로드를 JSON 형태로 파싱하여 클레임을 사용할 수 있게 하는 구조를 JWT 토큰 이라고 한다.

• ✅이외에도 Bearer 토큰의 인증 요건으로 Base64Url 인코딩, 무결성 검증, 유효 기간 설정, 적절한 시그니쳐 알고리즘 사용 등의 요건도 있다

 

https://jwt.io/

♦️JWT 라이브러리는 언어별로 여러가지 있고, 제공하는 알고리즘도 라이브러리 별로 상이하다. jwt.io 의 library 탭에서 비교해볼 수 있다.

 

 

 

 

 

 

 

 

 

 

 

 

 

---

[Reference]

Token

Token - Wikipedia

 

토큰 유형  |  Authentication  |  Google Cloud