JWT 인증 과정 및 특징

JWT 인증 과정

1. 클라이언트는 로그인을 요청한다.
2. 로그인 성공 시 서버는 Header, Payload, Secret Key를 이용하여 Signature를 생성하고, 이를 Base64로 인코딩하여 JWT를 발급한다. 발급된 JWT는 통상적으로 Cookie에 담아 클라이언트에게 전달된다.
3. 클라이언트는 발급받은 JWT를 저장하고, 서버에 요청 시 Authorization Header에 JWT를 담아 전송한다. (일반적으로 "Bearer [JWT]" 형식)
4. 서버는 수신한 JWT의 유효성을 검사한다. 이는 JWT 만료 여부 및 위변조 여부(Signature 검증)를 포함한다. 유효성 검사를 통과하면 인증된 사용자로 간주하고 요청을 처리한다.

JWT 유효성 검사 상세

악의적 사용자 B가 정상 사용자 A의 JWT를 탈취하여 임의 수정 시, 서버는 다음과 같이 변조 여부를 확인한다.

1. 클라이언트로부터 JWT를 수신한다.
2. JWT의 Header와 Payload를 추출한다.
3. 서버에 보관된 Secret Key를 이용하여 추출한 Header와 Payload로 새로운 Signature를 생성한다.
4. 클라이언트로부터 받은 JWT의 Signature와 새로 생성한 Signature를 비교한다.
5. 두 Signature가 불일치하면 해당 JWT는 위변조된 것으로 판단하고 인증을 거부한다.

JWT 장단점

JWT 장점:

• Signature를 통한 토큰 위변조 방지로 서버 보안성을 향상시킨다.
• 토큰 자체에 사용자 정보 및 검증 정보가 포함되어 서버는 별도의 저장소를 관리할 필요가 없다.
• 서버는 토큰 유효성 검증만 수행하므로 상태 유지가 불필요하여 서버 수평 확장에 용이하다.
• Cookie 사용 불가 환경(모바일 앱 등)에서도 인증 및 인가를 적용할 수 있다.
• 매 요청 시 데이터베이스 조회를 통한 인증이 불필요하여 서버 자원을 절약한다.

JWT 단점:

• Payload는 암호화되지 않고 Base64로 인코딩되므로 민감 정보 포함은 지양해야 한다.
• 토큰 길이가 길어 요청 증가 시 네트워크 트래픽에 부담을 줄 수 있다.
• 클라이언트 측에서 토큰을 관리하므로 탈취 시 즉각적인 무효화가 어렵다. 통상적으로 짧은 만료 시간을 설정하여 위험을 줄인다.

Token 유형

• Access Token: 사용자 인증 후 서버가 발급하는 사용자 정보 포함 토큰이다. 유효 기간 동안 API 또는 리소스 접근 시 사용되며, 보안상 짧은 수명을 갖는다.
• Refresh Token: Access Token 만료 시 새로운 Access Token 재발급을 위해 사용되는 토큰이다. 주로 데이터베이스에 사용자 정보와 함께 저장되어 관리된다.

Access Token, Refresh Token 인증 과정

1. 클라이언트는 로그인을 요청한다.
2. 로그인 성공 시 서버는 Access Token과 Refresh Token을 모두 생성한다. 각 토큰은 Header, Payload, Signature로 구성된다.
3. 클라이언트는 발급받은 Access Token과 Refresh Token을 안전하게 저장한다. API 요청 시 Authorization Header에 Access Token을 담아 전송한다.
4. 서버는 수신한 Access Token의 유효성을 검사하고, 통과 시 인증된 사용자로 간주하여 요청을 처리한다.
5. Access Token 만료 시 클라이언트는 저장된 Refresh Token을 사용하여 서버에 Access Token 재발급을 요청한다.
6. 서버는 수신한 Refresh Token의 유효성을 검사하고, 유효하다면 새로운 Access Token을 발급하여 클라이언트에게 응답한다.

참고 영상: https://www.youtube.com/watch?v=XXseiON9CV0

결론적으로, JWT는 클라이언트에게 '인증 완료' 표식을 부여하고 서버는 해당 표식의 유효성을 검증하는 방식으로 작동한다. 그러나 표식 탈취 및 변조 가능성에 대한 지속적인 경계가 요구된다.