JWT토큰 인증

1.  인증과 인가의 차이
   • 인증 (Authentication)
     → 로그인 (아이디, 패스워드를 통해 인증받음)
     → 특정 서비스에 일정 권한이 주어진 사용자임을 인증받는 것
   • 인가 (Authorization)
     → 로그인이 유지되고 있는 중에 하는 허가
     → 한 반 인증받은 사용자가 이후 서비스의 여러 기능들을 사용할 때 허가해주는 것인증 vs 인가
     → JWT 토큰 인증은 인가에 속하는 방식 (Authorization에 관련된 기술)
     
     
2. 왜 매번 로그인을 하면 안되는가?
   → 쿠키 등에 사용자의 아이디, 비밀번호를 저장해 놓고, 매 요청마다 로그인을 하면 안되는 것인가?
   → ‘로그인’ 작업은 리소스가 많이 드는 행위
   → 사용자의 암호를 알고리즘으로 계산하여 DB에 저장된 정보와 대조하는 작업등의 과정이 어려움 + 보안상의 문제
   
   
3. 세션
   • 방식
     
     •  사용자가 로그인에 성공하면, 사용자와 서버가 각각 고유 키를 나눠가짐
     • 이후 사용자가 매 요청마다 세션을 서버로 보내면, 서버는 해당 세션이 메모리 (혹은 하드디스크, DB )에 있는지 확인하고 이를 인가 함
     • 어떤 사용자들이 현재 로그인해 있는지를 ‘서버’에 저장하는 방식
   • 단점
     • 서버 재부팅 시, 모든 사용자의 로그인이 해제됨 (메모리에 저장시)
     • 느린 속도 (하드 디스크 혹은 DB에 저장 시)
     • 서버가 여러대 인 경우, 서비스의 구조가 복잡해짐
     ⇒ 서버가 로그인 여부를 기억하고 처리하는 것 자체가 상당한 부담
   • 장점
     • 사용자의 제어가 매우 용이
4. JWT 토큰 (JSON Web Token)
   • 방식
     
     • 사용자 로그인에 성공하면, 사용자에게 고유 키를 제공함. (서버에 저장 X)
   • JWT 토큰의 구성
     • 인코딩 또는 암호화 된 3가지 데이터를 이어 붙인 형태 
     • .(마침표)를 통해 각 부분을 구분 .
       • header (헤더)
         → 디코딩 시 2가지 정보
         • type (토큰의 type)
           → 항상 JWT가 들어감 [고정 값]
         • alg (알고리즘)
           → 3번 서명값을 만드는 데에 사용될 알고리즘이 지정 (Ex. SHA256 등)
       • payload (페이로드)
         → Base64로 디코딩 할 경우, Json 형식으로 여러 정보가 담김
         • 누가 누구에게 발급했는가
         • 토큰 유효 기간
         • 서비스가 사용자에게 토큰을 통해 공개하고자 하는 내용
           (사용자 닉네임, 서비스 상 레벨, 관리자 여부)
           → 토큰에 담긴 사용자 정보 등의 데이터를 Claim이라 칭함
       • verify signature (서명)
         → 헤더+페이로드+’서버에 감춰놓은 비밀 값’을 암호화 알고리즘을 통해 암호화 한 값
         ⇒ 조작 불가
       ⇒ 사용자가 서버에 요청시, 서버는 1, 2번의 값을 ‘서버의 비밀 키’와 함께 돌려서 계산된 결과값이 서명값과 같은지 여부를 확인
       ⇒ 만약 정보가 다르다면, 정보를 조작한 사용자 이거나 해커인 것으로 간주 & 거부
       ⇒ 서명값 == 계산 결과 && 유효기간이 지나지 않으면 인가
   • 단점
     → 한 번 인증 받은 사용자에게서 토큰을 회수하는 것이 불가능
     → 인가받은 사용자를 제어하는데에 어려움이 많음
5. Stateless vs Stateful
   • Stateless
     → 시간에 따라 바뀌는 특정 상태 값을 저장하지 않는 것 (JTW)
   • Stateful
     → 시간에 따라 바뀌는 특정 상태값을 저장하는 것 (Session)
6. Access Token & Refresh Token 방식
   → 기존 JWT 방식을 해결하기 위한 방식
   
   1. 사용자 로그인 시, Access Token과 Refres Token을 동시 부여
      → Refresh Token의 수명은 상당히 긴 편 (보통 2주)
      → Access Token의 수명은 몇 시간 혹은 몇 분 이하로 굉장히 짧음
   2. Refresh Token의 상응 값을 DB에도 저장
   3. 사용자가 AccessToken의 수명이 다하면, Refresh Token을 서버로 전송
   4. 받은 Refresh Token과 DB에 저장된 값과 비교
   5. 일치하면 새 Access token을 발급
   ⇒ Refresh Token이 안전하게 관리된다면, 해당 토큰이 유효한 동안에는 access Token이 만료될 때 마다 굳이 로그인을 다시 할 필요 X

---

 

이 내용을 토대로 마이무브의 인증, 인가 내용을 구현했다. 

 

최초 로그인 시에 JWT로 Refresh Token을 발급하고, 이후 로그인에는 쿠키에 저장해놓은 토큰을 통해 Access Token을 발급받도록 자동 로그인 과정을 구현했다. 

 

오픈소스 라이브러리를 사용해서 구현 자체는 어렵지 않았으나, 서버에 보내는 매 요청마다 검증과정을 넣으니 코드가 꼬이는 경우가 많아 꽤 애를 먹었었다.

 

그래도 나중에 로그를 확인해보고 이상한 접근 시도들이 막힌 것들을 보니 꽤나 뿌듯했다.