TIL 57일차 - [Backend] 인증 / 보안 : Token

• Hashing이 필요한 이유에 대해 이해한다.

  o
  해싱은 복호화(해석)할 수 없는 암호화만 가능한 방식으로
  해시 함수(Hash Function)를 사용하여 암호화를 진행힌다.

  해싱은 데이터 그 자체를 사용하는 것이 아니라
  동일한 값의 데이터를 사용하고 있는지 여부만 확인하는 것이 목적이므로 복호화가 불가능한 암호화 방식이다.

  이러한 해싱은 민감한 데이터를 다뤄야 하는 상황에서
  데이터 유출의 위험성을 줄이면서 데이터의 유효성을
  검증하기 위해 사용되는 단방향 암호화 방식이다.

• 데이터베이스에 유저의 비밀번호와 같이 민감한 정보를 평문으로
  저장하지 않는 이유에 대해 이해한다.

  o

• Salt가 필요한 이유에 대해 이해한다.

  o
  

  레인보우 테이블은 해싱 이전의 값을 알아낼 수 있으므로 보안에 취약하다.
  따라서 이때 솔트(Salt)를 사용한다.
  솔트는 소금을 치듯 해싱 이전의 값에 임의의 값을 더하여
  해싱 이전의 값을 알아내기 어렵게 만드는 방법이다.

  솔트를 사용하게 되면 해싱 값이 유출되더라도,
  솔트가 함께 유출된 것이 아니라면
  암호화 이전의 값을 알아내는 것은 불가능에 가깝다.

• 토큰의 개념을 이해할 수 있다

  • Refresh Token과 Access Token의 차이를 이해한다.

    o
    토큰 인증 방식의 한계를 보안하기 위해 등장하였다.

    Access Token은 말 그대로 서버에 접근하기 위한 토큰으로
    보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.

    Refresh Token은 서버 접근을 위한 토큰이 아닌
    액세스 토큰이 만료되었을 때, 새로운 액세스 토큰을 발급받기 위해
    사용되는 토큰이다. 따라서 리프레시 토큰은 액세스 토큰보다
    긴 유효기간을 설정한다.

    이렇게 두 가지의 각기 다른 토큰을 사용하는 경우,
    액세스 토큰이 만료 되더라도 리프레시 토큰의 유효기간이 남아있다면,
    사용자는 다시 로그인을 할 필요 없이 지속해서 인증 상태를 유지할 수 있다.

• 쿠키 / 세션 방식과 토큰 방식의 차이를 이해할 수 있다.

  o
  !

• JWT의 작동원리에 대해 이해할 수 있다.

  • header, payload, signature가 각각 어떤 역할을 하는지 이해할 수 있다.

    

    • Header에는 마치 HTTP의 헤더처럼 해당 토큰 자체를 설명하는 데이터가 담겨 있다. 토큰의 종류, 그리고 시그니처를 만들 때 사용할 알고리즘을 JSON 형태로 작성한다.
      이 JSON 객체를 base64 방식으로 인코딩하면,
      JWT의 첫 번째 부분인 Header가 완성된다.
    • Payload는 HTTP의 페이로드와 마찬가지로
      전달하려는 내용물을 담고 있는 부분이다.
      어떤 정보에 접근 가능한지에 대한 권한,
      유저의 이름과 같은 개인정보, 토큰의 발급 시간 및 만료 시간 등의
      정보들을 JSON 형태로 담는다.
      이 JSON 객체를 base64로 인코딩하면,
      JWT의 두 번째 부분인 Payload가 완성된다.
    • Signature는 토큰의 무결성을 확인할 수 있는 부분이다.
      Header와 Payload가 완성되었다면,
      Signature는 이를 서버의 비밀 키(암호화에 추가할 salt)와 Header에서 지정한 알고리즘을 사용하여 해싱한다.

  • JWT가 어떻게 토큰의 변조를 판별하는지 이해할 수 있다.

    o
    JWT는 JSON 객체에 정보를 담고 이를 토큰으로 암호화하여
    전송할 수 있는 기술이다. 클라이언트가 서버에 요청을 보낼 때,
    인증정보를 암호화된 JWT 토큰으로 제공하고,
    서버는 이 토큰을 검증하여 인증정보를 확인할 수 있다.

    토큰의 Payload를 변조하는 등의 시도를 하더라도
    토큰을 발급할 때 사용한 Secret을 정확하게 알고 있지 못한다면,
    유효한 Signature를 만들어낼 수 없기 때문에
    서버는 Signature를 검증하는 단계에서 올바르지 않은 토큰임을 알아낼 수 있다.

• 토큰 방식의 한계를 이해할 수 있다.

  o
  1) 무상태성
  인증 상태를 관리하는 주체가 서버가 아니므로,
  토큰이 탈취되어도 해당 토큰을 강제로 만료시킬 수 없다.
  따라서 토큰이 만료될 때까지 사용자로 가장해 계속해서 요청을 보낼 수 있다.

  2) 유효 기간
  토큰이 탈취되는 상황을 대비해서 유효 기간을 짧게 설정하면,
  사용자는 토큰이 만료될 때마다 다시 로그인을 진행해야 하므로
  좋지 않은 사용자 경험을 제공한다.
  그렇다고 유효 기간을 길게 설정하면
  토큰이 탈취될 경우 더 치명적으로 작용할 수 있다.

  3) 토큰의 크기
  토큰에 여러 정보를 담을 수 있는 만큼 많은 데이터를 담으면
  그만큼 암호화하는 과정도 길어지고, 토큰의 크기도 커지기 때문에
  네트워크 비용 문제가 생길 수 있다.

과제

들어가기에 앞서 check 해보기

☑️세션에 대한 이해

• 기존 세션 방식과 비교해 서버의 부담을 줄이고 확장성을 높이는 토큰 인증 방식을 구현한다.
• 토큰 기반 인증 중 가장 대표적인 JWT를 이용하여 웹 앱을 구현한다.
• 토큰의 일종인 JSON Web Token을 이용하여 토큰방식 인증을 구현한다.
• 클라이언트 코드는 쿠키 및 세션 인증방식과 동일하다.
  기존 쿠키, 세션 과제에서 풀었던 클라이언트 코드를 가져와도 된다.
• 이번 과제에서는 JWT 생성 및 검증을 도와주는 헬퍼 펑션이 있다.
  helper/tokenFunctions.js에서 각각의 메서드들의 역할을 먼저 파악한다.

• 토큰의 개념을 이해할 수 있다.

  • Refresh Token과 Access Token의 차이를 이해한다.

    o (위에서 설명함)

  • 왜 Access Token이 Refresh Token보다 짧은 주기를 갖는지 이해한다.

    o
    Access Token은 서버에 접근하기 위한 토큰으로
    보안을 위해 보통 24시간 정도의 짧은 유효기간이 설정되어 있다.

• 쿠키 / 세션 방식과 토큰 방식의 차이를 이해할 수 있다.

  o (위에서 설명함)

• JWT의 작동원리에 대해 이해할 수 있다.

  • header, payload, signature가 각각 어떤 역할을 하는지 이해할 수 있다.

    o (위에서 설명함)

  • JWT에 salt가 필요한 이유를 이해할 수 있다.

    o
    해싱 이전 값에 임의의 값을 더해 데이터가 유출되더라도
    해싱 이전의 값을 알아내기 더욱 어렵게 만들어 보안을 강화하였다.

  • JWT가 어떻게 토큰의 변조를 판별하는지 이해할 수 있다.

    o (위에서 설명함)

• 토큰 방식의 한계를 이해할 수 있다.

  o (위에서 설명함)

소감

🔡➡️💻➡️🤓👍

어렵고 또 어려웠다..
과제를 당일에 다 마치지 못해서
다음날까지 했다..