[Japring-Study 12] spring-auth-1

spring-learning-test의 마지막 과제이다!
제일 어렵게 느껴져서, 배울 엄두가 잘 안났던 Auth에 대해 배울 수 있어서 너무 좋았다!
막상 공부해보니 그렇게 어렵지 않았고, 학습에 대한 두려움이 조금 사라진 기분이다ㅎㅎ
다음 주 부터는 우테코 프리코스 과제나 책으로 스터디를 진행한다고 하니 기대가 된다~

---

JWT? (Json Web Token)

JSON 포멧을 이용한 Web Token이며, 필요한 정보를 지니는 Self-Contained 방식으로 정보를 안정성 있게 전달한다.
인증에 필요한 정보를 Token에 담아 암호화시켜 사용하는 인터넷 표준 인증 방식이다.

구조

크게 3가지 단위로 나눠지고, .을 통해 구분한다.
1. Header
2. Payload
3. Signature

Header

해싱 알고리즘, 토큰 종류를 알 수 있다.

{ 
   "alg": "HS256",
   "typ": "JWT"
}

• alg : 해싱 알고리즘. Signature를 해싱하기 위한 알고리즘. Signature 및 토큰 검증에 사용된다.
• typ : 토큰의 타입

Payload

Claim들이 key-value 형태로 저장된다.
Claim은 3가지 종류로 나눠진다.

• Registered Claim

  • { 
       "sub": "email@email.com",
       "iss": "yohan",
       "exp": 1234654321,
       "iat": 1234123456
    }

  • 표준 스팩이며, 꼭 7까지 모두 포함할 필요는 없다.
    • iss (issuer) : 토큰 발급자
    • sub (subject): 토큰 제목, unique한 값을 사용한다. 주로 사용자 이메일 사용
    • aud (audience): 토큰 대상자
    • exp (expiration): 토큰 만료 시간, NumericDate 형식으로 되어 있어야 함
    • nbf (not before): 토큰 활성 날짜
    • iat (issued at): 토큰 발급 시간, 토큰 발급 이후의 경과 시간
    • jti (JWT Id): JWT 토큰 식별자, 중복 방지를 위해 사용하며, 일회용 토큰(Access Token) 등에 사용

• Public Claim

  • 공개 클레임
  • 사용자 정의 클레임으로, 공개용 정보를 위해 사용된다. 충돌 방지를 위해 URI 포맷을 사용한다.

• Private Claim

  • 비공개 클레임
  • 사용자 정의 클레임으로, 서버와 클라이언트 사이에 임의로 지정한 정보를 저장한다.
  • 예를 들면, Access Token과 Refresh Token 구별을 위해 사용

Signature

Header와 Payload, 그리고 Private Key를 통해 생성되며, 해당 토큰이 변조되지 않았음을 확인하는 용도이다.

• 생성 과정

  1. Header, Payload 각각 Base64로 인코딩
  2. 인코딩된 값들을 합치고, Private Key를 이용해 Header에서 정의한 알고리즘으로 해싱
  3. 해싱한 값을 다시 Base64로 인코딩

• 확인 과정

  1. 클라이언트가 헤더에 JWT 토큰을 담아 요청
  2. 서버가 Private Key를 통해 복호화하고, 인코딩된 Header 값, 인코딩된 Payload 값과 일치하는 지 확인
  3. 일치하면 인증 성공

⛑️ 주의할 점!!
Header와 Payload는 Base64로 인코딩되기 때문에, 쉽게 디코딩된다!
때문에, Payload에 보안이 중요한 정보를 저장해서는 안된다.
그래서, 오로지 '식별을 하기 위한' 정보만을 담아야한다.

---

Cookie & Session & JWT Token 장단점

Cookie

• 장점
  • 매 요청마다 id&pw를 작성해서 전달할 필요가 없다!
• 단점
  • 탈취당할 수 있어서, 보안이 취약하다
  • 위조가 가능하다
  • 웹 브라우저마다 쿠키 지원 형태가 달라서, 여러 브라우저간의 공유가 불가능
  • 사이즈 제한(4KB) 때문에, 원하는 정보를 모두 담기 힘들 수 있다
  • 서버가 매번 id&pw를 받아, 인증해야한다

Session

• 장점
  • 서버에 저장되어서, 보안에 이점이 있다
  • 서버가 매번 id&pw를 인증할 필요 없다
• 단점
  • 세션 저장소에 문제가 발생하면, 인증 체계가 무너짐
  • stateful해서, stateless에 위반되고, scale out에 걸림돌이 생겨 http의 장점을 발휘 못함
  • 세션 저장소 비용이 들고, 사용자가 많으면 메모리를 차지
  • 매번 요청 시 세션 저장소를 조회(db 접근)해야 하는 비용

JWT Token

• 장점
  • 인증 저장소 필요 없음
  • stateless
  • signature를 통한 보안성
  • 공통적인 스팩
  • 서버측 부하를 낮춤
• 단점
  • 탈취당할 위험이 있어, token에 민감한 정보를 포함시키면 안됨
  • token에 담는 정보가 많아질수록, 네트워크 부하
  • stateless 하기 때문에, 한번 발급된 token은 수정, 폐기가 불가
    -> AccessToken, RefreshToken 사용으로 보완