Json Web Token

등장 배경

기존 세션 기반 인증 방식

• stateful (클라이언트, 서버의 state를 (서버에) 저장)
  • 실제 인증 정보는 서버(세션)에 저장하고, 클라이언트에게 세션의 id만 전달하는 방식
    • 쿠키로 전달, 해당 session-id에 해당하는 인증정보가 존재하면 인증된 사용자로 판단함.
• 단점
  • 세션이 많아질수록 매 요청시 해당 세션을 찾아야하므로 서버 부담이 증가함.
  • 다중 서버 환경에서 모든 서버가 동일한 세션을 유지하기 위해 별도의 조치 필요

SAML 2.0

• JWT 이전에도 JWT와 같이 모든 인증 정보를 토큰에 담고있는 방식이 있었음 (클레임 기반)
  • Assertion 이라는 개념으로 XML 안에 이러한 Claim 정보를 넣어서 넘길 수 있었음.
  • 그러나 전체적인 사이즈가 너무 크고, 구조가 복잡하여 쉽게 접근이 어려움 + 파싱에 오버헤드가 큼
  • 표준화가 잘 되어있어 SSO(한번의 로그인으로 여러 서비스 엑세스)에 많이 사용됨(상호 운영성이 좋음)
  • 개방된 인터넷에서 사용하도록 개발되었지만, 실제로는 기업 네트워크 내에서 SSO에 가장 많이 사용함.
    • 마이크로스프트는 인증에는 SAML을 사용하고, 권한 부여는 OAuth (JWT)를 사용하는 식으로 조합해서 사용하는 경우도 있음.
    • 추가 조사 필요

• 위 사진은 토큰 길이의 차이 (출처 : JWT Docs)

JWT 방식

• stateless (클라이언트,서버의 state를 저장하지 않음)
  • 토큰 내부에 인증에 필요한 정보들을 넣어둠 (클레임(사용자에 대해 작성된 정보) 기반)
  • 서버간 세션 불일치 문제, 서버 부하 증가와 같은 문제를 해결함
• 단점
  • Session기반의 경우 Session id만 주고받지만, 이건 정보를 주고받으므로 네트워크 자원을 상대적으로 많이 소모 (But SAML보다는 확연히 작음.)
  • 발급된 이후로 서버는 토큰에 대한 제어권을 완전히 상실함.
    • HTTPS 통신으로만 통신함
    • accessToken, refreshToken 방식으로 어느정도 보완이 가능함.
      • Access Token은 유효기한을 짧게 설정해서 위험성을 줄임.
      • Refresh Token은 유효기간을 길게 설정하는 대신, 추가적인 검증을 필요로하게 하며, 탈취 위험을 줄이기 위해 토큰 갱신시를 제외하고는 사용하지 않음.
        • Refresh Token의 추가적인 검증
          • 카카오
            • client_id를 필수로 함께 요청
            • (선택) client_secret 를 함께 요청 ([내 애플리케이션] > [보안]에서 설정 가능)
          • 네이버
            • client_id, client_secret를 필수로 함께 요청

JWT 구성