JWT (Json Web Token)
웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격.
주로 사용자의 인증(authentication) 또는 인가(authorization) 정보를 서버와 클라이언트 간에 안전하게 주고 받기 위해서 사용된다.
※ 인증(authentication)
: 사용자의 신원을 검증하는 행위.
ex) 비밀번호, 생체인식
※ 인가(authorization)
: 사용자에게 특정 리소스나 기능에 액세스할 수 있는 권한을 부여하는 프로세스.
ex) 서버에서 특정 파일을 다운로드할 수 있는 권한 부여,
애플리케이션에 액세스할 수 있는 권한 부여JWT 토큰 웹에서 보통 Authorization HTTP 헤더를 Bearer <토큰>으로 설정하여 클라이언트에서 서버로 전송되며, 서버에서는 토큰에 포함되어 있는 서명(signature) 정보를 통해서 위변조 여부를 빠르게 검증할 수 있다.
같은 Token 인증방식이지만 OAuth와 달리 아무 의미없는 문자열로 된 토큰이 아니라 토큰 자체가 의미를 갖는 *Claim 기반의 토큰 방식이다.
* Claim( 권한 ) : 사용자에 대한 프로퍼티나 속성구조
- 헤더(header) - 토큰의 유형과 서명 알고리즘 명시
- 페이로드(payload) - claim이라고도 불리는 사용자의 인증/인가 정보
- 서명(signature) - 헤더와 페이로드가 비밀키로 서명되어 저장
특징
정보가 담긴 데이터( JSON 객체 )를 암호화 하여, HTTP 헤더에 추가 시키는 방식으로 권한을 부여하기 위해 필요한 데이터가 JWT안에 모두 담겨다.
OAuth 처럼 인증 서버에서 토큰에 대한 정보를 찾을 필요가 없다.
프로세스
- JSON 객체에 요구사항을 작성
- 어떠한 암호화 방식을 사용해서 문자열로 인코딩
- HTTP header에 추가함으로써 사용자 인증을 요청
- 서버에서는 Header에 추가된 Token을 디코딩하여 사용자를 인증
장점(vs 쿠키, 세션)
- 쿠키와 세션을 사용할 때는 서버 단에 로그인한 모든 사용자의 세션을 DB나 캐시(cache)에 저장해놓고 쿠키로 넘어온 세션 ID로 사용자 데이터를 매번 조회해야함
- JWT는 토큰 자체에 사용자의 정보가 저장되어 있어있기 때문에 서버 입장에서 토큰 검증만 해주면 된다
→ 사용자가 늘어나더라도 사용자 인증을 위해서 추가로 투자해야하는 인프라 비용 절감 가능. - 쿠키를 사용하지 않으므로 CORS 문제에서 자유로움
단점
- JWT 토큰 서버 안에 저장된 데이터는 누구나 쉽게 열람이 가능
(누군가가 토큰을 탈취한다면, 그 토큰을 이용하여 권한을 수행할수 있게 된다)
→ 민감한 사용자 정보를 JWT 토큰에 그대로 저장하게 되면 보안 문제발생 가능성.
→ 따라서 토큰에 유효시간을 설정해야 하며, 탈취될 가능성을 줄이기 위해 유효시간을 짧게 해주는 것이 권장된다.
Access Token & Refresh Token 인증 방식
: 기본 JWT 방식의 인증(보안) 강화 방식
Access Token은 발급된 이후 서버에 저장되지 않고 토큰 자체로 검증을 하며 사용자 권한을 인증한다. 따라서 Access Token이 탈취되면 토큰이 만료되기 전까지 토큰을 획득한 사람은 누구나 권한 접근이 가능해지기 때문에 제3자에게 탈취당할 경우 보안에 취약하다.
JWT는 발급한 후 삭제가 불가능하기 때문에 접근에 관여하는 토큰에 유효시간을 부여하는 식으로 탈취 문제에 대해 대응을 하여야 한다.
이처럼 토큰 유효기간을 짧게하면 토큰 남용을 방지하는 것이 해결책이 될 수 있지만, 유효기간이 짧은 Token의 경우 그만큼 사용자는 로그인을 자주 해서 새롭게 Token을 발급받아야 하므로 불편하다는 단점이 있다. 그렇다고 무턱대고 유효기간을 늘리는 경우 토큰을 탈취당했을 때 보안에 더 취약해지게 된다.
이를 보완하기 위해 Refresh Token이 만들어지게 되었다.
서버는 로그인을 성공시키면서 클라이언트에게 Access Token과 Refresh Token을 동시에 발급한다.
→ 서버는 데이터베이스에 Refresh Token을 저장하고, 클라이언트는 Access Token과 Refresh Token을 쿠키, 세션 혹은 웹스토리지에 저장하고 요청이 있을때마다 이 둘을 헤더에 담아서 보낸다.
이 Refresh Token은 긴 유효기간을 가지면서, Access Token이 만료됐을 때 새로 재발급해주는 열쇠가 된다. 따라서 만일 만료된 Access Token을 서버에 보내면, 서버는 같이 보내진 Refresh Token을 DB에 있는 것과 비교해서 일치하면 다시 Access Token을 재발급하는 간단한 원리이다. 그리고 사용자가 로그아웃을 하면 저장소에서 Refresh Token을 삭제하여 사용이 불가능하도록 하고 새로 로그인하면 서버에서 다시 재발급해서 DB에 저장한다.
동작 프로세스
- Access Token의 유효 기간을 짧게 설정한다.
- Refresh Token의 유효 기간은 길게 설정한다.
- 사용자는 Access Token과 Refresh Token을 둘 다 서버에 전송하여 전자로 인증하고 만료됐을 시 후자로 새로운 Access Token을 발급받는다.
- 공격자는 Access Token을 탈취하더라도 짧은 유효 기간이 지나면 사용할 수 없다.
- 정상적인 클라이언트는 유효 기간이 지나더라도 Refresh Token을 사용하여 새로운 Access Token을 생성, 사용할 수 있음.
