JWT

JWT

인증과 인가

• 인증: 사용자가 누구인지 확인하는 절차, 회원가입하고 로그인하는 것
• 인가: 서버가 인증을 받은 사용자임을 알아보고 허가해주는 것
  • 문제: 인가 과정에서 사용자의 로그인 여부를 확인하기 위해, 아이디와 비밀번호를 매 요청마다 보내게 되면 DB에 저장된 사용자 계정의 해시값을 꺼내온 뒤 사용자의 암호를 복잡한 알고리즘으로 계산한 값과 일치하는지를 확인하는 등 그 과정이 굉장이 복잡함
  • 이를 대체하고자 나온 개념이 세션과 토큰

세션

사이트와 특정 브라우저 사이의 state를 유지시키는 것

• http프로토콜의 특징인 비연결지향, 무상태을 극복하기 위함
• Session ID를 사용해서 사용자가 서버에 로그인 되어있다는 것이 지속되는 상태
• 세션의 원리
  1. 사용자가 로그인하면 서버는 Session ID를 쿠키에 담아 전송
  2. 사용자는 브라우저에 쿠키를 저장
  3. 브라우저는 앞으로 요청을 보낼 때마다 Session ID가 담긴 쿠키(브라우저에 저장되는 정보)를 실어서 보냄
  4. 서버는 브라우저의 Session ID를 데이터베이스와 비교해서 있으면 인가해줌
• 그러나 이 방식은 문제가 있음.
  • 메모리에 Session ID를 넣어두면 사용자가 동시에 많이 접속 시 메모리가 부족하게 됨
• 이러한 번거로움을 해결하기 위해 JWT 토큰이 등장함

JWT(JSON Web Token)

Json 형식으로 사용자에 대한 속성을 저장하는 Claim 기반의 Web Token

• 구성

  • header : 토큰의 타입과 서명 값을 만드는 데 사용하는 알고리즘
  • payload(Base64) : 토큰에 담긴 사용자 정보 등의 데이터(누가 누구에게 발급했는지, 토큰의 유효기간은 얼마인지, 서비스가 사용자에게 이 토큰을 통해 공개하기를 원하는 내용) = Claim
  • verify signature: header, payload, 서버의 비밀키를 암호화 알고리즘에 넣고 돌리면 나오는 것

• 원리

  • 클라이언트가 유저 로그인 요청
  • 서버에서 클라이언트에게 JWT를 발급
  • 클라이언트에서는 이후 요청시 발급받은 JWT를 함께 전송
  • 서버에서 JWT에 포함된 Signature를 확인 후 클라이언트의 요청에 응답

• 장점

  • Statelessness & Scalability(무상태성 & 확장성): 서버에서 클라이언트 정보를 저장할 필요가 없고 토큰을 헤더에 추가만 하면 인증 절차가 완료됨
  • 안정성 : 암호화한 토큰을 사용하므로 암호화 키를 노출할 필요가 없음

• 단점

  • 토큰 탈취 위험 → 이 위험을 최소화하기 위해 Refresh Token, Access Token이 나옴

• Refresh Token, Access Token 원리

Access Token의 경우 수명을 매우 짧게 주고 Refresh Token의 경우 꽤 길게 보통 2주 정도로 준다. Refresh Token만 안전하게 관리된다면 이게 유효할 동안은 Access Token이 만료될 때마다 다시 로그인할 필요없이 새로 발급 받을 수 있다. 중간에 Access Token이 탈취당해도 오래 쓰지는 못할 것이므로 보완성이 좋다. 또한, 어떠한 사용자를 강제 로그아웃 시키려면 리프레시 토큰을 DB에서 지워 토큰 갱신이 되지 않게 하는 방법을 활용할 수도 있다.