JWT (Json Web Token)

개념

Json 객체 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, 인터넷 표준 인증 방식이다. 공식적으로 인증(Authentication) & 권한허가(Authorization) 방식으로 사용된다.

프로세스

 

1. 사용자가 아이디와 비밀번호 혹은 소셜 로그인을 이용하여 서버에 로그인 요청을 보낸다.
2. 서버는 비밀키를 사용해 json 객체를 암호화한 JWT 토큰을 발급한다.
3. JWT를 헤더에 담아 클라이언트에 보낸다.

여기까지가 JWT를 발급받기까지의 (로그인 전)과정이다. 로그인 이후에는 다음과 같은 과정이 이루어진다.

1. 클라이언트는 JWT를 로컬에 저장해놓는다.
2. API 호출을 할 때마다 header에 JWT를 실어 보낸다.
3. 서버는 헤더를 매번 확인하여 사용자가 신뢰할만한지 체크하고, 인증이 되면 API에 대한 응답을 보낸다.

그런데 로그인 후에 왜 매번 JWT를 헤더에 넣어서 보내야 할까? 비효율적이라는 생각이 들 수 있다. 매번 인증 과정을 거쳐야하는 이유는 HTTP의 특성 때문이다.

HTTP 특성

Connectionless : 한 번 통신이 이뤄지고 난 후에 연결이 바로 끊어진다
Stateless : 이전 상태를 유지/기억하지 않는다

 

터넷을 사용하는 우리는 HTTP 프로토콜을 사용해서 통신을 한다. 웹 페이지를 열 때도, 핸드폰 어플을 사용할 때도, 클라우드를 사용할 때도 HTTP 통신으로 서버와 클라이언트가 데이터를 주고 받는다. 그런데 이런 HTTP는 connectionless하고 stateless하다는 특성이 있다. 쉽게 설명하면 한 번 통신이 일어나고 나면 연결이 끊어진다는 것이고, 다시 연결해도 이전 상태를 유지하지 않아 과거에 어떤 정보를 보냈었는지 기억하지 못한다는 것이다. 즉, 화면을 이동하며 새로운 API를 요청하면 다시 신뢰할만한 사용자인지 인증하는 과정을 거쳐야하는 것이다.

매번 사용자가 인증하는 과정은 귀찮을 뿐만 아니라 통신이 느려지는 문제가 될 수 있다. 따라서 인증된 사용자가 어느 정도 기간동안 재인증 하지 않아도 되도록(로그인이 유지되도록) 만든 것이 Access Token이다.

구조

JWT는 Header, Payload, Signature 3개로 구성되어 있다.

 

Header

• alg : Signature에서 사용하는 알고리즘
• typ : 토큰 타입

Signature에서 사용하는 알고리즘은 대표적으로 RS256(공개키/개인키)와 HS256(비밀키(대칭키))가 있다. 이 부분은 auth0 공식 문서에서 자세히 설명해주고 있다.

 

Payload

사용자 정보의 한 조각인 클레임(claim)이 들어있다.

• sub : 토큰 제목(subject)
• aud : 토큰 대상자(audience)
• iat : 토큰이 발급된 시각 (issued at)
• exp : 토큰의 만료 시각 (expired)

Signature

Signature는 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 key를 이용해 암호한 값이다.

Header와 Payload는 단순히 Base64url로 인코딩되어 있어 누구나 쉽게 복호화할 수 있지만, Signature는 key가 없으면 복호화할 수 없다. 이를 통해 보안상 안전하다는 특성을 가질 수 있게 되었다.

앞서 언급한 것처럼 header에서 선언한 알고리즘에 따라 key는 개인키가 될 수도 있고 비밀키가 될 수도 있다. 개인키로 서명했다면 공개키로 유효성 검사를 할 수 있고, 비밀키로 서명했다면 비밀키를 가지고 있는 사람만이 암호화 복호화, 유효성 검사를 할 수 있다.

장단점

장점

• 로컬에 저장하기 때문에 서버 용량에 영향을 끼치거나 받지 않는다.
• 보다 안전하다. (공개키/개인키 or 비밀키를 통해 서명되기 때문에)
• 모바일 앱에서 사용하기 적합하다.
  모바일 앱은 여러 플랫폼 및 기기에서 동작할 수 있고, 서로 다른 도메인에서 통신할 수도 있다. 이때 JWT를 사용하면 플랫폼 독립적으로 사용자 인증을 처리할 수 있기 때문에 적합하다.
• 네트워크 부하가 적다.
  http헤더나 url 파라미터를 통해 간단하게 전송되기 때문이다.

단점

• 토큰의 크기가 커질수록 트래픽에 영향을 미칠 수 있다.
• 토큰은 발급되면 만료 기간 변경이 불가능하므로 토큰 만료 처리를 구현해야 한다.

 

https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token