JWT Authentication

JWT Access Token Authentication에 대해 학습하였다

JWT

JWT(JSON-Web-Token) 이란?

• 인증에 필요한 정보들을 암호화 시킨 토큰을 말함

• JWT(Access Token) 를 Http 헤더에 같이 넣어 서버가 클라이언트를 식별하도록 한다.

JWT 구조

aaaaa.kkkkk.zzzzz

• . 을 구분자로 나누어지는 세 문자열의 조합이다.

1. Header

{
    "alg": "HS256",
    "typ": "JWT"
}

• type: 토큰의 타입

• alg: 해싱 알고리즘

2. Payload

{
    "name" "hi",
    "date" "..."
}

• 토큰에 담을 정보(로그인한 유저임을 증명할 수 있는)가 들어있다.
• 클라이언트의 고유 ID값 및 유효기간 등이 포함됨
• Key-Value 형식으로 이루어진 한 쌍의 정보를 Claim 이라고 한다.

3. Signature

• 토큰을 인코딩하거나 유효성 검증할 때 사용되는 고유한 암호화 코드다
• 인코딩된 Header 와 Payload 를 더하여 BASE64 로 인코딩하고 이 인코딩한 값을 비밀키를 이용해 헤더에서 정의한 알고리즘으로 해싱하고 다시 BASE64 로 인코딩하여 생성한다.
• 헤더와 페이로드는 단순히 인코딩 된 값이기 때문에 공격자가 복호화할 수 있지만 Signature 는 서버측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없다.

동작 과정

1. 클라이언트 요청 시 서버는 검증 후 클라이언트의 고유 ID 등의 정보를 Payload 에 담는다.

2. 암호화할 비밀키를 사용해 Access Token 을 발급한다.

3. 클라이언트는 이를 저장해두었다가 서버에 요청할 때 요청 헤더 Authorization 에 포함시켜 전달한다.

4. 서버는 토큰의 Signature 를 비밀키로 복호화해 위변조 여부, 유효기간 등을 검사한다.

5. 유효한 토큰일 경우 요청에 응답해준다.

장점

• Header 와 Payload 를 가지고 Signature 를 생성하기 때문에 위변조 를 막을 수 있다.

• 인증 정보에 대한 별도의 저장소가 필요 없다.

• JWT 는 기본정보, 전달할 정보, 서명 등 필요한 걸 모두 자체적으로 지니고 있다.

• 서버의 Stateless 가 가능하다.

• 모바일 등 다양한 애플리케이션 환경에서 잘 동작한다.

단점

• 토큰 자체의 길이가 길어서 인증 요청이 많을 수록 네트워크 부하가 심해진다.

• Payload 자체는 암호화 되지 않기 때문에 중요한 정보를 담을수는 없다.

• 클라이언트가 가지고 있어서 토큰을 탈취당했을 때 우리가 대처하기 힘듬(쿠키/세션은 우리가 만료시킬 수 있다.)

보안 전략

• 만료 기한은 짧게!
  - 탈취되도 피해를 최소화 할 수 있다.
  - 자주 로그인해야되는 불편함이 있다.

• Sliding Session
  - 서비스를 지속적으로 이용할 경우 토큰 만료 기한을 자동으로 늘려주는 방식

• Refresh Token
  - 클라이언트 로그인 시 Access Token 보다 만료 기간이 긴 Refresh Token 을 발급하는 것이다.
  - 클라이언트의 액세스 토큰이 만료되었을 때 서버가 DB 등의 저장소에 있는 Refresh Token 값과 비교해 유효하면 액세스 토큰을 발급하고 인증시킴
  - 해당 전략 사용시 Access Token 만료 기한이 짧으면서도 가용성이 좋아짐
  - 단점
  - 검증을 위해 서버가 Refresh Token 을 별도로 가지고 있어야 한다는 것 자체
  - 이는 추가 IO 를 말한다.
  - 클라이언트도 결국 Refresh Token 을 보안이 유지되는 공간에 저장을 해야한다는 것
  - 로컬스토리지 등에 저장하면 XSS 에 취약해진다.
  - HttpOnly 설정되서 브라우저만 접근 가능한 쿠키에 토큰을 실어보내면 방지됨

Reference

• jwtio
• 내 깃허브