Json Web Token (JWT)

작년에 HTTP 스터디를 했었는데 그 때 쿠키에 대해서 공부하고, 발표하면서 연관 지어서 JWT에 대해서도 공부하고, 발표를 했던 경험이 있었다. 그 때는 사용할 일이 없었지만 현재는 최근 시작한 프로젝트에서 사용 하기로 해서 다시 공부하였고, 이 내용을 정리 해보려고 한다.

 

먼저 왜 사용하는지 알고 사용하는 것이 좋을 것 같아서 왜 사용하는 지 부터 JWT가 무엇 인지, 어떤 구조를 가지고 있는지, 어떤 과정으로 동작하는지 순으로 정리 하였다. 

Cookie

HTTP는 Stateless라는 특징을 가지고 있어서 상태를 유지하지 않는다. 그런데 로그인이 필요한 작업을 처리할 때 해당 사용자가 로그인을 했는지 안했는지 서버는 알 수 없다. 그래서 사용자가 로그인을 하였다는 것을 서버에 알려주기 위해서 쿠키를 사용한다.

서버에서 쿠키를 클라이언트에 전달하면 클라이언트는 이를 내부에 저장하고 있다가 서버에 요청할 때 받았던 쿠키를 같이 전달한다.

Session

쿠키를 주고 받는 것에 있어서 다른 것은 없지만 민감한 정보를 주고 받을 때 보안을 위해서 나왔다. 세션은 쿠키와 달리 서버에서 관리가 된다. 서버에서 세션 저장소라는 별도의 공간에서 세션을 관리, 저장한다.

Json Web Token

세션은 요청할 때마다 DB에 접근을 해야 하는 단점이 있는데 이러한 단점을 보완하기 위해서 JWT가 생겨났다.

JWT는 인증에 필요한 정보들을 암호화 시킨 JSON 토큰을 의미한다.

구조

Header(헤더), Payload(내용), Signature(서명)로 구성이 된다.

• Header에는 서명 암호화 알고리즘과 토큰의 유형이 들어간다.
• Payload에는 사용될 정보에 대한 내용이 담겨있다.
• Signature에는 Header + Payload의 정보와 서버가 갖고 있는 key값을 합친 것을 헤더에서 정의한 알고리즘으로 암호화 한다.

위와 같이 JSON을 암호화 하여 사용한다. Header, Payload, Signature은 . 을 기준으로 나눠진다.

인증 과정

인증을 진행하는 과정은 쿠키와 비슷하다. 서버에서 제공해주고, 이를 클라이언트가 저장하고 있다가 요청할 때마다 같이 전송하게 된다. 그런데 주고 받는 것이 암호화된 토큰이라는 점이 중요하다.

이 암호화된 토큰을 Access Token이라고 한다.

위와 같은 과정을 통해서 Access Token을 인증한다. 앞에서 언급했던 것처럼 쿠키와 비슷한 과정을 보인다.

Access Token은 발급하면 삭제는 불가능하고, 유효 기간을 지정하여 Access Token을 만료 시킨다.

근데 만약 Access Token 자체를 탈취 당한다면 어떻게 될까?

Access Token을 가지고 있으면 유효 기간 동안 누구나 서버 접근이 가능하다. 서버에서는 받은 Access Token이 탈취 당한 것인지 클라이언트에서 정상적으로 전송한 것인지 알 수가 없다. 이렇게 Access Token 하나만 사용하면 보안적으로 취약할 수 있기 때문에 Access Token의 유효 기간을 짧게 하고, Refresh Token을 사용한다.

Refresh Token은 Access Token을 발급해주는 key라고 생각하면 된다.

 

Refresh Token을 같이 사용하면 다음과 같은 흐름으로 인증이 진행된다. 먼저 클라이언트에서 로그인을 하면 서버는 클라이언트에 Access Token과 Refresh Token 둘 다 제공한다. 클라이언트는 이를 가지고 있다가 서버에 요청할 때 Access Token만 사용한다.

만약 클라이언트가 만료된 Access Token을 전달하면 서버는 Access Token 만료 신호를 응답으로 준다. 이 때 클라이언트는 Access Token과 Refresh Token을 서버로 같이 전송한다. 그럼 서버는 Refresh Token을 확인하고 새로운 Access Token을 제공한다.

JWT 장점

• 무상태(stateless) 라서 서버의 확장에 유리하다.
• 데이터 베이스를 조회하지 않아도 된다.
• 세션과 달리 모바일 어플리케이션에서도 잘 동작한다.
• 모바일에 적합하다.

JWT가 모바일에 적합한 이유

why? -> HTTP 기본 인증은 Raw한 API키를 매 요청 때 마다 사용해야 하는데 모바일 기기 내에서 안전하게 저장할 수 있는지 의문 (Raw한 것이라서 탈취 당하면 큰일남!)

그래서 암호화된 토큰을 사용 액세스 토큰을 기기 내에 저장하고 사용 어디에? -> SharedPreference에 저장

 

SharedPreference? ⇒ DB에 저장하기에는 좀 그런(가벼운?) 것들 저장하는 곳

• 애플리케이션이 살아있는 동안에는 값이 유지 되다가 종료하면 저장된 값들 삭제
• 파일 형태로 저장
• key-value 형식