EunHee-Jeong/TIL

JWT (Access Token, Refresh Token)

Closed this issue · 0 comments

EunHee-Jeong commented

Cookie와 Session의 통신 방식

1. HTTP 프로토콜

  • 특징

    • 비연결성 Connectionless, 비상태성 Stateless

      → 연결 상태가 유지되지 않으며, 연결이 해제된 후에도 상태 정보가 저장되지 않는다.
      → 모든 사용자의 요청마다 연결과 해제의 과정을 거치게 되어, 서버의 자원을 절약할 수 있다.

  • 단점

    • 사용자를 식별할 수 없기 때문에, 같은 사용자가 요청을 여러 번 하더라도 매번 새로운 사용자로 인식하게 된다.

2. Cookie, Session, Token

  • HTTP 프로토콜이 가진 비연결성과 비상태성이라는 특징의 단점을 보완하기 위해 서버가 클라이언트를 식별할 수 있도록 해주는 것을 말한다.

  • 정리한 것 (Cookie, Session, Token)

    • 요약하자면

      1. 서버는 세션의 DB에 사용자의 정보를 저장하고, 이 세션들은 별도의 ID를 가진다.
      2. 쿠키는 세션의 ID를 전달하기 위한 매개체이다. 공간에 제약이 있다. (= 주로 웹에서 사용된다.)
      3. 토큰은 서버로 보내는 일종의 문자열로, 세션이 사용 불가능하기 때문에 쿠키가 없는 iOS, AOS와 같은 Native App에서 사용하는 방식이다.

  • 차이점

    • 쿠키란 클라이언트의 브라우저에 설치되는 작은 기록 정보 파일이다.

      • 요청 시 값을 그대로 보내기 때문에, 유출 및 조작될 위험이 존재한다.
      • 또한 용량 제한이 있어 많은 정보를 담을 수 없다.

    • 세션은 서버 측에 저장되고 관리되는 정보이다.

      • 비밀번호와 같은 클라이언트의 인증 정보를 저장한다.

        • 클라이언트의 요청을 받으면 상태를 계속해서 유지해놓고 사용하기 때문에 (= Stateful) 사용자가 증가함에 따라 성능적인 문제를 일으킬 수 있다. (= 확장성이 어려움)

      • 저장소를 사용하기 때문에 요청이 많아지면 서버에 부하가 생긴다.

JWT (Access Token)

1. 개념

  • JSON Web Tocken 의 줄임말이다.

  • 인증에 필요한 정보들을 암호화시킨 토큰을 의미한다.

    • HTTP 헤더에 실어 서버가 클라이언트를 식별하도록 하는 방식이다.
      • 인증받은 사용자에게 토큰을 발급하고, 다시 돌려 받아 확인한다.

2. 쿠키-세션과의 차이점과 유사점

  • 차이점

    • 클라이언트가 서버에 접속을 하면, 서버에서 해당 클라이언트에게 인증 되었다는 의미로 토큰을 부여한다.

      • 서버에서 준 것이기 때문에, 사용자에 대한 더 자세한 정보가 들어있다.

    • 파일이나 DB에 토큰에 대한 정보를 저장하지 않아도 된다.

      • 클라이언트에게 인코딩한 정보를 던져주고 다시 돌려받고 하는 방식이기 때문이다.
      • Stateless 이다.

    • 클라이언트가 서버에 요청을 했는데, 액세스 토큰의 시간이 만료되었다면 클라이언트는 리프래쉬 토큰을 사용해서 서버로부터 새로운 액세스 토큰을 발급 받는다.

    • 토큰 안의 정보가 무엇인지가 중요한 것이 아니라, 해당 토큰이 유효한 값인지 확인하는 것이 중요하다.

  • 유사점

    • 사용자마다 유일하며, 토큰을 발급받은 클라이언트는 또 다시 서버에 요청을 보낼 때 요청 헤더에 토큰을 넣어서 함께 보낸다.
    • 유효성 검사
      • 서버는 클라이언트로부터 받은 토큰을 자신이 발급했던 토큰과의 일치 여부를 판단하여 인증 과정을 처리한다.

3. 구조

헤더 Header - 내용 Payload - 서명 Signature

  • XXXXX.YYYYY.ZZZZZ

    • 구분자로 . 을 사용하는 세 가지 문자열의 조합

  • 헤더에는 알고리즘 형식과 토큰의 유형이 들어가고,

  • 내용에는 클라이언트와 서버가 주고 받을 시스템에서 실제로 사용될 정보들이 들어가며,

  • 서명은 헤더의 인코딩 값과 내용의 인코딩 값을 합친 후 비밀키로 해쉬하여 생성한 암호가 된다.

4. 단점

  • 토큰의 길이가 길기 때문에, 인증 요청이 많아지면 네트워크의 부하가 심해진다.

  • 내용 payload 자체는 암호화되지 않기 때문에, 사용자의 민감한 정보를 담기에는 신뢰성이 떨어진다.

    • 탈취당하게 되면 대처하기 어렵다.

Refresh Token

도입 배경

  • Access Token JWT 를 통한 인증 방식의 보안성 문제

    • 토큰 자체의 유효 기간을 짧게 하여, 남용을 방지하도록 하는 해결이 있지만 그렇다면 그만큼 사용자에게 로그인을 자주 시켜서 새로운 토큰을 발급 받도록 해야 하기 때문에 좋은 방식은 아니다.

  • 토큰의 유효 기간을 짧게 하면서 보안성을 해결하기 위해 생겨나게 되었다.

개념

  • JWT 형식이며, 사용자가 처음 로그인을 완료했을 때 Access Token과 함께 발급된다.

  • 긴 유효기간을 가지며, Access Token이 만료되었을 때 새로 발급해주는 열쇠가 된다.

    • Refresh Token의 유효기간 전까지는 Access Token을 새로 발급 받을 수 있다.
    • Refresh Token이 만료되었다면, 사용자는 새로 로그인해야 한다.