로그인 인증 방식 (JWT & 세션)

JWT (JSON Web Token)

인증에 필요한 정보들을 암호화시킨 JSON 토큰

JWT 기반 인증은 JWT 토큰 (Access Token)을 HTTP 헤더에 실어 서버가 클라이언트를 식별하는 방식

 

 

JWT 구조

• 암호화 알고리즘을 담은 Header
• 사용될 데이터 정보를 담고 있는 Payload
• 서명 Signature

 

장점

• Header와 Payload로 서명을 생성하므로 데이터의 위변조를 막을 수 있음
• 인증 정보에 대한 별도의 저장소가 필요없음 (DB 조회 필요 X)

 

 

---

JWT를 이용한 인증 과정

1. 사용자 로그인 (인증 요청)
2. JWT, Access Token, Refresh Token 발급 (서버)
3. Access Token을 Header에 담아 API 요청 (클라이언트)
4. Access Token에 문제 없으면 정보 응답 (서버)

➕ 클라이언트 → 서버 요청 시, Access Token의 시간이 만료되면 클라이언트는 Refresh Token을 이용해서 Access Token을 재발급 받음

 

 

---

Token

JWT도 제3자에게 토큰 탈취의 위험성이 있기 때문에, 그대로 사용하는 것이 아닌 Access Token, Refresh Token으로 이중으로 나누어 인증하는 방식을 현업에서 취함

 

 

Access Token

• 30분 ~ 1시간 (짧은 유효 기간, 탈취 위험 때문)
• 클라이언트가 갖고 있는 실제 유저 정보가 담긴 토큰
• 클라이언트에서 요청이 오면 서버에서 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행

 

Refresh Token

• 1 ~ 2주
• 새로운 Access Token을 발급해주기 위해 사용하는 토큰
• 보통 데이터베이스에 유저 정보와 같이 기록

 

 

---

세션 인증 로그인

1. 클라이언트가 로그인을 위해 인증 정보를 서버에 전송
2. 서버는 메모리에 사용자를 저장하고, 세션 아이디를 쿠키로 전달
3. 클라이언트는 쿠키에 저장된 세션 아이디를 이용하여 요청을 보냄
4. 서버는 일치하는 세션 아이디를 메모리에서 검색한 후, 응답을 보냄

 

 

---

JWT와 세션 인증의 차이

⭐가장 큰 차이점은 서버에 인증 정보를 전달하는지 여부⭐

• JWT는 서버 저장 X → 클라이언트의 요청마다 인증을 위해 DB를 탐색하는 과정이 필요하지 않고, 저장공간도 필요하지 않음
• 세션의 경우, 모든 인증 정보를 서버에서 관리하기 때문에 보안 측면에서 조금 더 유리. 설령 세션 ID를 해커에게 탈취된다고 하더라고, 서버 측에서 해당 세션을 무효 처리 가능
• BUT 토큰은 강제 만료 처리할 수 없으며, 클라이언트가 모든 인증 정보를 가지고 있음. 그러므로 토큰 탈취되면 피해 O
• 그럼에도 JWT 방식은 높은 확장성을 가져 최근 많이 사용됨
  • 세션 → 서버의 수평적 확장 (어려움)
  • JWT → Payload 추가 (쉬움)