[ jwt ] 로그인 - Json Web Token에 대해 알아보기

참고 사이트

• 나무를 심은사람님의 티스토리
• 후디님의 블로그
• 불타는 키보드님의 티스토리
• 푸르고 개발님의 티스토리

 

🔓 로그인 방식 이해

로그인은 크게 세션방식과 토큰 인증 방식으로 구분된다.

HTTP는 stateless한 특성을 가지며, 바로 직전의 상태 또한 저장이 되지 않는다.
그렇다고 우리는 서버에 요청할 때마다 호출할 때마다 로그인창을 열고 인증하지 않는다.

유저가 로그인을 성공하여 서버에 인증된 회원인 것이 확인되면 유저에게 세션 또는 토큰을 발급한다.

그럼 유저는 세션 또는 토큰을 로컬스토리지 또는 🍪Cookie로 가지고 있다가 서버에 요청할 때마다 세션 또는 토큰을 보낸다.

 

🔑 Session 방식

세션 방식은 사용자의 인증 정보가 서버의 세션 저장소에 저장하고, 사용자에게 저장된 세션 정보 식별자인 Session ID를 발급한다.

사용자의 Session ID는 브라우저에 Cookie 형태로 저장된다.

사용자는 서버에 요청할 때마다 HTTP Cookie 헤더에 Session ID를 함께 서버로 전송한다.

서버는 요청을 받고, Session ID에 해당하는 세션 정보가 세션 저장소에 존재하면 인증된 사용자로 판단한다.

 

🔑 Token 방식

토큰은 사용자의 인증 정보를 클라이언트가 로컬스토리지 또는 Cookie에 직접 들고 있는 방식이다.

대표적인 토큰인 jwt의 경우 디지털 서명이 존재해 토큰 내용의 위변조 여부를 판단하여 서버측이 확인할 수 있다.

토큰 기반 인증은 사용자가 가진 토큰을 HTTP의 Authorization(인가) 헤더에 실어 보낸다.
이 헤더를 요청 받은 서버는 토큰의 위변조 및 유효성을 확인하고 사용자를 인가한다.

 

🪙 Token이란

토큰은 해당 서버에서 인증한 🎫 출입증 이라고 생각하면 쉽습니다.

예를 들어, 캐리X안베이를 입장하면 각 개인마다의 바코드 팔찌(토큰)를 받습니다.
캐리X안베이 안에서 자유롭게 먹거리를 즐기기 위한 단계로는

1. 음식(데이터)을 주문(요청)
2. 바코드 팔찌(토큰)를 매점 직원(서버)에게 결제를 요청
3. 음식(데이터)를  받는다.

위와 같이 작성자는 이해하고 있다.

이때, 해당 바코드 팔찌를 통해 사용자는 캐리X안베이에서 컨텐츠를 자유롭게 이용할 수 있으며,
직원은 캐리X안베이에 정식 입장한 사람이라는 것을 확인하지만, 구매자의 정보는 자세히 모른다.

이처럼 인증된 값(바코드)만 제공하며, 보안적으로 인증/인가를 도와주는 라이브러리가 jwt이다.

 

---

😈 보안

🔑 Session

세션의 경우 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에 유리하다.
세션 ID가 해커에게 탈취된다해도, 서버측에서 해당 세션을 무효처리하면 된다.

 

🔑 Token

토큰의 경우 클라이언트가 인증 정보를 가지고 있다. 따라서 해커에게 탈취되면 해당 토큰이 만료되기 전까지 속수무책으로 피해를 입을 수 밖에 없다.

또한 jwt 특성상 토큰에 실린 payload가 별도로 암호화 되어있지 않아 누구나 내용을 확인할 수 있다. 따라서 토큰 인증 시, payload에 민감한 데이터를 실을 수 없다.

 

⚔️ XXS공격 / ⚔️ CSRF 공격

• XXS : JS를 삽입하여 정보 변경 및 탈취

XXS공격을 막기 위해서는 브라우저에서 접근 가능한 곳에 토큰을 두면 안된다.
브라우저에서 window.localStorage나 window.sessionStorage로 전역에 접근이 가능한 모든 곳에 토큰을 놓지 않는 것이 좋다.
따라서 RefreshToken은 Cookie에 httpOnly, secure 옵션을 붙여 서버만 접근 가능하도록 해야한다.

 

• CSRF : 해커가 게시물에 악성 코드를 넣어놓고 게시물에 이벤트가 발생할 때, 의도치 않은 이벤트가 발생하는

CSRF 공격을 막기 위해서는 AccessToken을 특정 요청을 통해 보낼 수 없게 만들어야한다.

 

 

🌏 Token의 보편화

최근에 모바일 앱이나 웹은 Token 방식을 채택한다.

그 이유는 아래와 같다.

 

🌐 확장성

일반적으로 웹 어플리케이션의 서버 확장 방식은 수평 확장을 사용한다. 즉, 한 대가 아닌 여러대의 서버가 요청을 처리한다.
이때 별도의 작업을 해주지 않는다면, 세션 인증 방식은 세션 불일치 문제를 겪게 된다.
이를 해결하기 위해 작업을 처리해주어야한다.

토큰의 경우 클라이언트가 인증 방식을 가지고 있으므로, 세션 불일치 문제로부터 자유롭다.
따라서 높은 확장성을 가지고 있다.

 

🪨 서버 부담

세션 인증 방식은 서비스가 데이터를 직접 저장하고 관리한다.
따라서 데이터의 양이 많아지면 서버의 부담이 증가한다.
하지만 토큰 인증 방식은 유저의 수가 얼마나 되던 서버의 부담이 증가하지 않는다.
따라서 서버의 부담으로 인해 토큰 기반 인증 방식이 더 유리하다.

 

인증 방식	Token	Session
보안성	-	WIN
외부 노출 시 대비	-	WIN
성능	-	WIN
비용	WIN	-
서버 부하 (효율성)	WIN	-
확장성	WIN	-

각자의 장단점을 가지고 있다.

Session은 사용자에게 좋다고 느껴지지만,

개인적으로 🏢기업은 💰이윤을 추구하는 집단이다보니 Token이 Session보다 유리한 것으로 생각해서 Token이 대세가 된 거 같다.

Token 방식을 잘 구현하면은 Session의 장점을 어느정도 커버가 가능하지만, Session은 대개 커버가 불가능하다고 본다.