Auth

• Authentication(인증): 로그인, 특정 서비스에 일정 권한이 주어진 사용자임을 ID, PW를 통해 인증을 받는 것
• Authorization(인가): 인증을 받은 사용자가 이후 인증이 필요한 서비스를 이용할 때 서버에서 로그인(인증된 사용자)인지 확인 후 허가를 해주는 것

인증 상태를 유지하는 작업은 무거운 작업

• 로그인이라는 작업은 꽤 무거운 작업이다.
  • DB에서 사용자 계정의 해시값 등을 꺼낸다.
  • 암호값이 복잡한 알고리즘으로 계산된 값과 일치하는지 조회
  • 시간과 자원을 적지 않게 소모
• HTTP는 Stateless(무상태) 프로토콜로 서버가 클라이언트의 상태를 보존하지 않는다.
  • 상태가 보존되지 않으므로 클라이언트는 매 요청 마다 필요 데이터를 담아서 보내야 한다.
  • 매 요청마다 ID, PW를 HTTP 요청에 담아 보내면 보안상 취약하고 네트워크 트래픽 추가 유발

Stateless

• HTTP는 무상태(Stateless) 프로토콜이다.
• 클라이언트와 서버가 요청과 응답을 주고 받으면 연결이 끊어진다.
• 클라이언트가 다시 요청하면 서버는 이전 요청을 기억하지 못한다.
• 클라이언트와 서버는 서로 상태를 유지하지 않는다.

Session

• 사용자가 로그인을 성공하면 서버는 Sesseion ID를 발급
• Session ID를 서버의 메모리에 저장 후 클라이언트에게 전달
• 클라이언트는 Session ID를 Cookie에 저장
• 요청시 Session ID를 포함해서 전송 후 서버는 저장된 Session List를 확인 후 Authorization 처리

Cookie

• 클라이언트(브라우저)에 저장되는 정보
• 매 요청마다 쿠키정보는 자동으로 포함되서 보내진다.

Session 장점

• 메모리에 있는 상태(Session ID)들을 제어 가능하다.

Session 단점

• 사용자의 요청이 많을 수록 서버의 메모리 부족
• 서버의 메모리는 휘발성 메모리 (ex: 서버 재부팅하면 날라감)
• 서버가 여러대가 있을 경우 세션 유지가 번거롭다.
  • DB (서버 공통창고)에 보관하면 속도는 많이 느려진다.

Json Web Token

• Authorization을 보다 부담없이 사용하기 위해 나온 기술
• 서버에서 인증된 사용자인지 확인하는 기술이다.
• 사용자가 인증이 완료되면 Token을 발급하여 통째로 클라이언트에게 전달
  • (서버는 저장X === stateless)
• 서버는 요청에 Token값이 실려들어오면 Header + Payload 값을 서버의 비밀 키와 함께 돌려봐서 계산된 결과값이 Sign값과 일치하는 결과가 나오는지 확인
• 계산값이 일치하고 유효기간이 남아있다면 그 사용자는 로그인 된 회원으로서 인가를 받는다.

Token

• 인코딩 또는 암호화된 3가지 데이터를 .을 구분자로 이어붙인 것

헤더(Header)

• 헤더는 2가지의 정보를 지님
• typ: 토큰의 타입을 지정
  • ex: JWT
• alg: 해싱 알고리즘 지정
  • ex: HMAC SHA256 RSA
  • 이 알고리즘으로 토큰을 검증하는 signature 부분에서 사용

내용(Payload)

• Base64로 디코딩(복호화)해보면 JSON 형식으로 여러 정보들이 들어 있다.
• 토큰에 담을 정보가 담겨있음
  • 누가 누가에게 발급햇는지
  • 토큰의 유효시간
  • 이 토큰을 통해 공개하기 원하는 내용(닉네임, 권한 정보 등)
• 정보의 한 조각(claim)이 name/value의 한 쌍으로 이루어짐

registered claim

• 서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기 위해 이름이 이미 정해진 클레임들
• 토큰 발급자, 토큰 제목, 토큰 대상자, 토큰 만료시간 등등

public claim

• 충돌이 방지된(collision-resistant)이름을 가지고 있어야 한다.
• 사용자가 마음대로 값(value)을 작성 가능하다.
• 충돌 방지를 위해 클레임 이름(key)을 URI 형식으로 짓는다.

private claim

• 클라이언트와 서버간 협의하여 자유롭게 key/value 설정 가능
• 이름이 중복되어 충돌될수 있기 때문에 사용에 유의

서명(Sign)

• Header의 인코딩값과, Payload의 인코딩값을 합친 후 서버의 비밀키와 함께 지정한 암호화 알고리즘을 통해 생성

JWT 장점

• 사용자 인증에 필요한 모든 정보는 토큰 자체에 포함하기 때문에 별도의 인증 저장소가 필요없다
• 토큰 기반으로 하는 다른 인증 시스템에 접근이 가능하며 확장성이 뛰어나다.

JWT 단점

• Session과 달리 stateless하기 때문에 상태들을 제어하지 못한다.
• 상태들을 제어가능 할때 이점
  • 한 기기에서만 로그인 가능한 서비스 구현
• 토큰을 무효화할 방법도 없다.

JWT 단점을 보완하기 위해 나온 방법

• 만료시간을 가깝게 잡아서 토큰의 수명을 짧게 가져가는 방법

• 로그인을 하면 토큰을 2개 발급

  • 수명이 몇시간 또는 몇 분 이하로 짧은 access token
  • 그보다 길게 수명이 잡혀있는 refresh token

• refresh token의 상응값을 DB에 저장

• 클라이언트는 access token의 수명이 다하면 refresh token을 서버에 보낸다.

• 서버는 DB에 저장해둔 값과 비교한 후에 일치하면 새 access token 발급

• refresh token만 안전하게 관리된다면 이것이 유효할동안은 accees token이 만료될 때마다 다시 로그인 할 필요없이 새로운 access token을 발급받을 수 있다.

• 중간에 access token이 탈취 당해도 수명이 짧기 떄문에 오래 사용 못하게 된다.

• 특정 사용자의 토큰을 무효화 시키는 방법으로 refresh token을 삭제, access token의 짧은 수명이 지나면 무효화됨

• 바로 토큰을 무효화 시키는 방법은 없고 access token의 수명이 다해야 무효화됨 === JWT의 한계