들어가며
이번 외개인 프로젝트를 진행하면서 로그인 기능을 처음 개발해보았다. 여러 클라이언트 인증 방식이 존재하지만 우린 그 중에서 JWT 토큰 인증방식을 이용하여 로그인 기능을 구현하였다. JWT 토큰 인증 방식에 대해 공부해보고 내가 실제로 진행했던 과정을 보여드리면서 포스팅을 진행해보겠다.
토큰 인증 방식
토큰 기반 인증 방식이란 서버가 클라이언트에게 토큰을 발급하고, 이후 클라이언트가 서버에 요청할 때 받은 토큰을 이용하여 인증을 수행하는 방식이다.
토큰 인증 방식의 장점
- 서버가 클라이언트의 세션 정보를 저장할 필요가 없어 서버 부담이 적다.
- 세션, 쿠키와 달리 토큰 인증 방식은 웹뿐만 아니라 앱에서도 사용이 가능하다.
토큰 인증 방식의 단점
- 일반적으로 토큰의 크기가 커질 수 있으며, 이는 서버에 부하를 주거나 네트워크 효율성 저하를 일으킬 수 있다.
- 토큰에 사용자 정보가 포함될 경우, 이를 탈취당했을 때 개인정보가 유출될 수 있다.
JWT (JSON Web Token)
JWT(JSON Web Token)는 클라이언트와 서버 간의 정보를 안전하게 전송하기 위해 사용되는 개방형 표준이다. 인증에 필요한 정보들을 암호화시킨뒤 HTTP 헤더에 실어 서버가 클라이언트를 식별한다.
구성요소
- 헤더(Header)(위 토큰에서 앞 빨간 부분):
- JWT의 유형과 서명 알고리즘을 정의한다. 일반적으로 typ은 "JWT"이고, alg는 사용할 서명 알고리즘(예: HMAC SHA256, RSA 등)을 지정한다.
- 페이로드(Payload)(위 토큰에서 중간 보라색 부분):
-
실제로 전송할 데이터가 포함된다. 이 데이터는 클레임(claim)이라고 하며, 등록된 클레임, 공개 클레임, 비공식 클레임으로 나뉜다.
-
등록된 클레임: iss(발행자), exp(만료 시간), sub(주제) 등.
-
공개 클레임: 사용자 정의 클레임으로, 충돌을 피하기 위해 URI 형식으로 이름을 지정하는 것이 좋음
-
비공식 클레임: 애플리케이션에서 사용하는 임의의 클레임.
-
- 서명(Signature)(위 토큰에서 뒤 파란 부분):
- 헤더와 페이로드를 인코딩한 후, 비밀 키 또는 개인 키를 사용하여 서명한다. 이 서명은 JWT의 무결성을 검증하는 데 사용된다.
Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작을 할 수 있다. 하지만 Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없어 토큰의 위변조 여부를 확인하는 데 사용된다.
종류
Access Token
Access Token은 사용자가 인증된 후, 특정 리소스나 API에 접근(즉, 전반적인 서비스 이용)할 수 있도록 허용하는 토큰이다. 보통 짧은 유효 기간을 가지며, 서버에 요청할 때마다 헤더에 포함되어야 한다.
특징
- 몇 분에서 몇 시간까지 유효시간을 설정하여 보안을 강화한다.
- 클라이언트가 API를 요청할 때 Authrization 헤더에 포함하여 서버에 전송한다.
- 사용자의 ID, 권한 및 기타 정보가 포함된다. 민감한 정보는 포함하지 않는 것이 좋다.
- 서버에서 발급하여 클라이언트에 보내주며, 서명을 통해 변조 여부를 검증할 수 있다.
Refresh Token
Refresh Token은 Access Token이 만료되면 새로운 Access Token을 발급받기 위해 사용하는 토큰이다.
특징
- 일반적으로 Access Token보다 유효기간이 훨씬 길며, 몇 주에서 몇 달까지 설정할 수 있다.
- Access Token이 만료되었을 때, 클라이언트는 Refresh Token을 서버에 전송하여 새로운 Access Token을 요청한다.
- 사용자 ID와 같은 기본적인 정보만 포함된다. Access Token보다 보안이 강화된 방식으로 저장해야 한다.
- Refresh Token은 클라이언트 측에서 안전하게 저장해야 하며, 유출될 경우 보안 문제가 발생할 수 있다.
JWT 인증 과정
참고
