개요

HTTP 특징

• connectionless : 한번의 통신 이후 그 연결이 바로 끊어짐
• stateless : 이전의 통신에 대한 정보를 가지고 있지 않음

위의 특성들로 인해 사용자가 매번 서버에 요청을 보낼 떄마다 자신이 누구인지 계속해서 인증해줘야 함
-> 매번 로그인 -> 오버헤드
-> 로그인을 유지시킬 방법이 필요함

대표적인 3가지

• Basic
• 세션
• 토큰

Basic

• 가장 쉽고 간단하게 개발하는 인증 방법 중에 하나
• credential : Authorization : Basic aksdmalksdmalsknddkasl
  • 기본적으로 Base64-Encoded(A:B)
  • A는 Id, B는 Password를 대응해서 Base64Encoded("Id:Password") -> sadaddamclk어쩌구 가 나옴
  • Authorization: Basic 어쩌구를 Header에 키와 값을 붙여서 보내면 서버에서 해당 값을 읽어 기본 인증을 확인 한 후에 Id:Password에 맞는 값을 매칭하여 인증을 하는 형태

단점

• 이 방법은 base64로 인코딩하긴 하지만 base64는 디코딩이 가능해서 id, password를 직접적으로 보내는게 됨
• 따라서 보안 이슈떄문에 HTTPS/TLS로만 통신해야하지만 HTTPS/TLS 를 사용해도 가능한 사용하지 않도록 권고되고 있음

장점

• 가장 쉽고 간단하게 개발하는 인증 방법 중 하나 -> 가장 빠르게 개발 가능

session

출처

사용자의 인증 정보가 서버의 세션 저장소에 저장되는 방식

• 사용자가 로그인을 하면, 해당 인증 정보를 서버의 세션 저장소에 저장
• 사용자에게는 저장된 세션 정보의 식별자인 Session ID를 발급
• 브라우저는 인증 절차를 마친 이후의 요청마다 HTTP Cookie 헤더에 Session ID 를 함께 서버로 전송
• 서버는 요청을 전달받고, Session ID에 해당하는 세션 정보가 세션 저장소에 존재한다면 해당 사용자를 인증된 사용자로 판단

장점

• 요청이 외부에 노출되더라도 세션 Id 자체는 유의미한 개인정보를 담고 있지 않음 (해커가 이를 중간에 탈취하여 클라이언트인척 위장할 수 있긴 함)
• 각 사용자마다 고유한 세션 ID가 발급되어 요청이 들어올 때마다 회원정보를 확인할 필요가 없음

단점

• 서버에서 세션 저장소를 사용해서 요청이 많아지면 서버에 부하가 심해짐
• 서버의 확장성이 떨어짐
  • 만약 트래픽 분산을 위해 여러 대의 서버를 사용한다면 모든 서버에 세션 저장소를 만들어야하고 동기화도 해야함
  • 동기화 안하면 처음 로그인한 서버에서만 인증된 사용자로 판단됨(다른 서버의 세션 저장소에는 해당 유저의 세션정보가 들어있지 않기 때문)

token

• 클라이언트의 세션 상태를 저장하지 않고 필요한 정보를 토큰에 저장
• 서버는 이 토큰을 클라이언트에게 전달하고, 그것을 증명서처럼 사용

장점

• 서버에 저장하지 않아서 서버 확장성 좋음 (서버는 유효성 검사만 함)
• 요청이 들어왔을 떄 해당 토큰이 유효한지만 체크하면 되지 때문에 어떤 서버로 요청을 보내도 상관이 없음
• 토큰을 제 3자가 변경하려 하여도 서버의 비밀 키를 알 수 없어서 변경이 어렵고,
  변경을 하더라도 서명이 다르기때문에 요청을 받지 않게 됨

JWT (Json Web Token)

• Jwt는 인증에 필요한 정보들을 암호화시킨 토큰을 의미
• 웹표준 (RF7519)

JWT 구조

1. 헤더 (Header)
   

• alg : 정보를 암호화할 해싱 알고리즘
• typ : 토큰의 타입

2. 페이로드 (Payload)
   

• 토큰의 담을 정보 갖고 있음
• 클라이언트의 정보 및 유효기간 등이 포함되는 영역
• Clain : key-value 형식으로 이루어진 한 쌍의 정보
• 해독 가능하기 때문에 중요한 정보를 토큰에 넣으면 안됨

3. 시그니처 (Signature)
   

• 인코딩된 Header와 Payload를 더한 뒤 비밀키로 해싱하여 생성
• Header와 Payload는 단순히 인코딩된 값이기 때문에 제 3자가 복호화 및 조작할 수 있지만,
  Signature는 서버 측에서 관리하는 비밀키가 유출되지 않는 이상 복호화할 수 없음
• Signature는 토큰의 위변조 여부를 확인하는데 사용되고 Secret key 보안이 중요

단점

• Payload 자체는 조회가 가능하기 때문에 중요한 정보를 담을 수 없음
• 토큰의 길이가 길어 인증 요청이 많아질 수록 네트워크 부하가 심해질 수 있음
• 토큰은 발급하면 만료될 때까지 계속 사용이 가능하기 때문에 토큰이 탈취당하면 대처하기가 어려움

대안

• 위에서 말한 단점들을 보안하기 위해, 토큰의 만료 시간을 짧게 설정하는 방법이 있음
  -> 하지만, 유저가 로그인을 자주해야하는 불편함 발생
  -> Access Token과는 별개로 Refresh Token을 사용하는 방법

• Access Token에는 짧은 유효기간을 설정하고, 그보다는 긴 유효기간을 가진 Refresh Token을 함께 발급

• 서버는 DB에 저장된 Refresh Token과 비교하여 유효성 검사를 실시하고, 유효한 경우 새로운 Access Token을 발급