JWT(JSON Web Token)란?

✅ JWT(JSON Web Token)란?

• 인증에 필요한 정보들을 암호화 시킨 JSON토큰
• 따라서 JWT를 이용한 인증은 유저를 인증하고 식별하기 위한 Token 기반 인증이다.

JWT 구성요소

JWT는 헤더(header), 페이로드(payload), 서명(signature) 세 파트로 나뉘며 아래와 같은 형태로 구성

 

• 헤더 (Header)
  • 어떤 종류의 토큰인지, 어떤 알고리즘으로 Sign할지 정의하는 부분.
  • alg : 서명 암호화 알고리즘
  • typ : 토큰 유형

• 정보 (Payload)
  • 서버에서 활용할 수 있는 사용자의 정보가 담겨 있다.
  • 사용자 정보나 접근 권한에 대한 내용을 담을 수 있다.
  • 단순 인코딩된 값이 담기기 때문에 민감한 정보는 담지 않도록 주의해야 한다

위와 같이 key-value형식의 하나의 쌍들이 모두 claim

 

서명 (Signature)
JWT 구조에서 가장 중요한 Signature(서명)

• 원하는 비밀 키(Secret Key)와 Header에서 지정한 알고리즘을 사용하여 Header와 Payload에 대해서 단방향 암호화를 수행한다.
• 암호화 된 메세지는 토큰의 위변조 유무를 검증하는데 사용한다.

💡 Header와 Payload는 단순히 인코딩된 값이 때문에 누군가 복호화 및 조작이 가능하다. 하지만 Signature는 서버에서 관리하는 비밀키임으로 유출되지 않는 이상 복호화가 불가능해 토큰의 위변조 여부를 확인하는데 사용하는 것

JWT 동작원리

1. 사용자가 id와 password를 입력하여 로그인 요청을 한다.
2. 서버는 회원DB에 들어가 있는 사용자인지 확인을 한다.
3. 확인이 되면 서버는 로그인 요청 확인 후, secret key를 통해 토큰을 발급한다.
4. 이것을 클라이언트에 전달한다.
5. 서비스 요청과 권한을 확인하기 위해서 헤더에 데이터(JWT) 요청을 한다.
6. 데이터를 확인하고 JWT에서 사용자 정보를 확인한다.
7. 클라이언트 요청에 대한 응답과 요청한 데이터를 전달해준다.

💡 이와 같이 토큰 기반 인증방식은 사용자의 인증이 완료된 이후에 토큰을 발급한다. 클라이언트쪽에서는 전달 받은 토큰을 저장해두고 서버에 요청을 할 때마다 해당 토큰을 서버에 함께 전달한다. 그 이후 서버는 토큰을 검증하고 응답하는 방식으로 작동한다.

 

JWT의 종류

• Access Token
• Refresh Token

JWT도 토큰 탈취 위험성을 가지고 있기 때문에 두 가지 종류의 토큰을 사용

정확하게는 이중으로 나누어 인증을 처리하는 방식

Access Token, Refresh Token는 같은 JWT지만 어디에 저장되고, 관리되는지에 대한 차이를 가짐

🔐Access Token

클라이언트가 가지고 있는 실질적인 사용자의 자격 증명 정보가 담긴 토큰
보호된 정보들에 접근할 수 있는 권한부여에 사용됨

클라이언트에서 요청이 오면 서버는 해당 토큰에 있는 정보를 활용하여 사용자 정보에 맞게 응답을 진행한다.

🔐Refresh Token

새로운 Access Token을 발급해주기 위해 사용하는 토큰으로 보통 데이터베이스에 유저 정보와 같이 기록됨

왜 두가지 토큰을 사용하지?

Access Token는 사용자의 자격 증명 정보가 들어가 있기 때문에 해당 토큰이 탈취 당할 가능성이 크다. 그런 문제를 대응하기 위해 Access Token의 유효 기간은 비교적 짧게 설정해 탈취되더라도 오랫동안 사용할 수 없도록 한다.

Access Token의 유효 기간이 끝나면 다시 서버에 인증을 거쳐 Access Token을 받아내야 할까?

NOPE

애초에 서버로부터 가장 처음 JWT 토큰을 받을 때, Access Token와 Refresh Token를 같이 보내주는 것은 이러한 점을 고려한 것이다. 사용자는 별도의 재인증을 거치치 않아도 Refresh Token를 통해 Access Token를 재발급 받아 사용할 수 있다.

JWT의 장단점

장점

1. 상태를 유지하지 않고(Stateless), 확장에 용이한(Scalable) 애플리케이션을 구현하기 용이
2. 클라이언트가 request를 전송할 때마다 자격 증명 정보를 전송할 필요가 없다.
3. 인증을 담당하는 시스템을 다른 플랫폼을 분리하는 것이 용이하다.
4. 권한 부여에 용이하다.
5. 인증 정보를 저장할 별도의 저장소가 필요하지 않다

단점

1. Payload는 디코딩이 용이해, 민감한 정보를 담았을 경우 탈취 위험성이 있다.
2. 토큰의 길이가 길어지면 네트워크 부하를 줄 수 있다.
3. 토큰은 자동으로 삭제되지 않아 반드시 만료 기간을 추가해주어야 한다.
4. 토큰은 클라이언트 측에서 관리하고 저장하기 때문에 토큰 자체를 탈취당하면 대처하기가 어렵다.

결론

• 클라이언트에서 서버로부터 전달 받은 토큰을 저장한 후 서버에 API요청을 하기 때문에 토큰에 대한 보안이 중요
• 토큰을 탈취당할 경우 사용자가 의도하지 않은 요청을 할 수 있기 때문
• JWT를 관리하는 방식은 여러가지 존재. 프로젝트에 맞는 방식을 선택하는 것이 중요