JSON Web Token (JWT)

Session & Cookie

쿠키 🍪

• 웹 브라우저와 요청, 응답을 주고 받을 때 사용하는 데이터 조각
• 쿠키는 도메인에 제한적이며 유효 기간이 정해져있다.
• Auth 외에도 다양한 방식으로 활용이 가능하다

세션 (Session)

• stateless한 HTTP 특징을 보완하기 위한 방법
• 세션 DB를 이용해서 유저의 정보를 기억하며 Session ID라고 하는 랜덤한 key를 쿠키에 담아서 Auth에 활용
• 쿠키를 사용해서 Session ID를 주고 받는 것이다.

JWT

• Cookie는 웹 브라우저에만 존재하는 것으로, 다양한 장치들과 공통적으로 사용할 수 있는 방식이 필요하다.
  이러한 방식으로 널리 사용되는 방법 중 하나가 바로 Token Auth, 그중에서도 JWT 방식이 많이 사용된다.
• JWT는 일정한 규칙을 가지고 있으며 간단한 서명을 더한 문자열로 토큰 자체에 유저에 대한 간단한 정보가 들어가 있는 형태다.
• JWT 방식으로 Auth를 처리하면 Session DB나 인증을 위한 여러가지 로직 처리가 필요 없다.

처리 방식

1. 클라이언트가 ID/PW를 서버로 보냄
2. 서버에서 ID/PW를 검증하고 유효하다면 일정한 형식으로 서명 처리된 Token을 응답
3. 이후 클라이언트는 모든 요청 헤더에 토큰을 담아 서버로 요청을 전송
4. 서버는 해당 토큰의 유효성을 검증하고 유저의 신원과 권한을 확인 후 요청을 처리

Session과 차이점

• 서버에 세션 데이터베이스가 존재하지 않으며 데이터베이스가 필요하지 않음
• 토큰 자체가 하나의 인증 데이터
• 서버는 토큰이 유효한지만 검증하여 처리한다.

장/단점

• 서버에서 관리하는 데이터가 없으므로 복잡한 처리 로직이 필요하지 않음
  그렇다 보니 일방적으로 로그인을 무효화 하는 등의 처리가 불가능해진다. (세션 테이블 X)
  ➖ 모든 기기 로그아웃, 현재 접속 유지 관리 등
  ➕ 세션이나 DB 없이 유저를 인증하는 것이 가능
  ➖ Token 자체가 데이터를 담고 있는 정보이므로 탈취 당할 시 보안이 취약하다.
  ( 만료 기한을 짧게 잡아 만약 탈취 당해도 짧은 시간 안에 유효하지 않은 토큰의 형태가 됨 )

구조

• . 을 기준으로 HEADER, PAYLOAD, VERIFY SIGATURE 세 부분으로 나누어 구성된다.

Refresh Token

• Access Token이 만료되었을 때 새로 Access Token을 발급 받기 위한 Token
• Acces Token보다 긴 유효 기간을 가지게 된다.
• 주로 사용자의 기기에 저장해두고 사용되며 만약 Refresh Token까지 만료되었다면 다시 인증(로그인)이 필요해진다.
• Refresh Token의 탈취를 보완하기 위해 DB 리소스를 사용하는 다양한 방식도 존재함 -> BlackList 등

ORM

건너뛴다.