[과제] 03주차(3) - JWT 란?

JWT 에 대한 이해

 

이전 글에서 이어지는 내용

모의 해킹 스터디 - 기록일지 03주차 (로그인 로직/로그인 유지)

모의 해킹 스터디 - 기록일지 03주차 (로그인 로직/로그인 유지)

 

왜 JWT일까?

 

앞서 보았듯이 인증을 위해 Cookie와 Session을 사용하고, 그 한계점, 보안성의 문제가 존재

쿠키와 세션의 단점에 대하여 좀 더 살펴 보자면...

---

쿠키(Cookie)

로그인 했을 때 Set-Cookie의 형태로 반환을 받은 쿠키를 토대로 로그인이 필요한 요청마다 쿠키를 던져 동작

(쿠키를 사용한 이유는 어떤 특정 정보를 저장해야 했기 때문, 매번 요청마다 사용자가 특정 정보를 날려야하는 번거로움을 막기 위해)

 

하지만 많은 단점이 존재

• 쿠키는 노출되었을때 id, pw와 같은 민감 정보까지 다 노출되어 보안이 좋지 못함
• 조작당해서 들어올 가능성이 존재
• 웹 브라우저마다 쿠키에 대한 지원 형태가 다르기 때문에 다른 브라우저간의 공유가 불가능
• 쿠키의 사이즈가 제한(4KB)되어 있어 원하는 만큼의 충분한 데이터를 담을 수 없는 경우가 존재
• 서버는 매번 id, pw를 받아서 인증해야 하는 불편함이 존재
  • (또한 조작된 데이터가 넘어오는 경우를 방지할 수 없음)

 

위의 단점을 보완하고자 쿠키(Cookie)와 함께 세션(Session)을 사용

---

쿠키(Cookie) &세션(Session)

무언가에 대한 특정 인증 정보를 서버가 가지고 있고, 그 값을 클라이언트에게 전달하여 인증

(마치 키를 주고 자물쇠를 여는 방식) - 세션 ID를 특정 저장소에 저장하여 사용

 

• 개인 민감정보를 그대로 노출했을 때의 단점을 막아내기 위해 나온 것이 바로 세션(Session)
• 쿠키안에 넣어서 보내기 때문에 쿠키라는 정보 자체를 주고 받는다는 사실은 크게 다르지 않음
  • (id, pw와 같은 민감정보를 다루는 상황에서의 보완점을 찾기 위해 나온 것)
• 쿠키와 같은 매개체를 주고 받음으로써 매번 로그인 시 id, pw를 작성하여 전달해야하는 번거로움을 보완
• id, pw를 주고받는 것이 아니라, 인증 정보 자체를 특정 세션 저장소에 저장하고,
• 이 값을 쿠키에 담아 클라이언트가 쿠키를 요청할 때마다 세션 저장소에 있는 정보랑 동일한지로 로그인을 확인하자는 것

세션을 이용한 인증 절차

1. 클라이언트가 id / pw로 서버에 로그인 요청을 함
2. id / pw로 인증 후 사용자를 식별할 특정 유니크한 세션 ID를 만들어 서버의 세션 저장소에 저장
3. 세션 ID를 특정한 형태(쿠키 or json)로 클라이언트에 다시 반환
4. 사용자 인증이 필요한 정보를 요청할 때마다 이 세션 ID를 쿠키에 담아 서버에 함께 전달
5. 인증이 필요한 api의 경우, 서버는 세션 ID가 세션 저장소에 있는지 확인
6. 있다면 인증 완료 후 api 처리, 없다면 401 에러를 반환

 

• 쿠키만을 전송할 때와는 다르게 세션 저장소에 식별 가능한 값을 넣어두고 그 값이 일치했는지만 보면 인증이 되니 보완이 조금은 올라갔다고 볼 수 있음

 

• 만약 보안 문제가 발생(탈취 당한 세션 ID) 한다면, 그냥 세션 저장소를 전부 지워버리면 됨.
• (세션 ID가 탈취당했어도 세션 저장소를 전부 비우면, 해당 세션 ID로 서버에 접근해도 인증될 수단이 없음)
• BUT 다른 관점에서 본다면, 세션 저장소가 모종의 이유로 장애가 난다면 인증 전체에 문제가 생겨 정상적인 사용자가 인증을 하지 못하게된다고 볼 수도 있음
• 또한 HTTP의 장점이라 할 수 있는 무상태성(stateless)을 위해 서버의 세션 저장소에 세션ID, 즉 상태를 저장하는 상황이기 때문에 stateful 하게 되는 것

 

하여 쿠키와 마찬가지로 많은 단점이 존재

• 세션 저장소에 문제가 발생하면 인증 체계가 무너져 이전에 인증된 다른 유저 또한 인증이 불가해 짐
• stateful 하기 때문에 http의 장점을 발휘 하지 못함 scale out에 걸림돌이 됨
  • (완전한 무상태성(stateless)이라고 볼 수 없음)
• 세션 저장소가 필수적으로 존재하기 때문에 이를 사용하기 위한 자원이 소모됨
• 세션 ID가 탈취되었을 경우 대처는 가능하지만, 클라이언트 인척 위장하는 보안 취약점이 존재
• 사용자가 많아질수록 많은 메모리를 차지(많은 자원을 소모)
• 매번 요청시 세션 저장소를 조회해야 한다는 단점
• (요청을 진행할 때마다 DB 접근이라는 로직이 한번 더 수행된다는 것)

 

위와 같은 일련의 과정(쿠키와 세션의 한계점) 속에서 등장한 것이 바로 JWT

---

JWT 란? -  JSON 웹 토큰(JSON Web Token)

 

JSON Web Token (JWT) 은 웹표준 (RFC 7519) 으로서, 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달

• (선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준 인증 방식)
• C, Java, Python, C++, R, C#, PHP, JavaScript, Ruby, Go, Swift 등 대부분의 주류 프로그래밍 언어에서 지원
• JWT 는 필요한 모든 정보를 자체적으로 지니고 있음 (= Self-contained)
  • JWT 시스템에서 발급된 토큰은, 토큰에 대한 기본정보, 전달 할 정보, 그리고 토큰이 검증됐다는것을 증명해주는 signature 를 포함
• JWT 는 자가수용적이므로, 두 개체 사이에서 손쉽게 전달 가능
• 웹서버의 경우 HTTP의 헤더에 넣어서 전달 할 수도 있고, URL 의 파라미터로 전달 할 수도 있음

 

• 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명됨
  • 이 토큰들은 한쪽 당사자의 비공개 키(일반적으로 서버의 비공개 키)에 의해 서명이 가능하며 이로써 해당 당사자는 최종적으로 토큰이 적법한지를 확인할 수 있음

 

기본적인 인증을 진행하는 구조는 Cookie 때와 크게 다르지 않지만,
강조되는 점은 JWT는 서명된 토큰이라는 점

---

JWT의 사용

 

• 회원인증 : JWT를 사용하는 가장 흔한 시나리오
  • 유저가 로그인 하면, 서버는 유저의 정보에 기반한 토큰을 발급하여 유저에게 전달
  • 그 후, 유저가 요청을 할 때마다 JWT를 포함하여 전달
  • 서버가 클라이언트에게서 요청을 받을때 마다, 해당 토큰이 유효하고 인증되어있는지 검증
  • 유저가 요청한 작업에 권한이 있는지 확인하여 작업을 처리
  • 서버측에서는 유저의 세션을 유지할 필요가 없어짐
  • (즉, 유저가 로그인 되어있는지 안되어있는지는 신경 쓸 필요가 없고, 유저가 요청 했을때만 토큰을 확인하면되기 때문에 세션관리가 필요 없어 서버자원을 많이 아낄 수 있음)

• 정보 교류 : JWT는 두 개체 사이에서 안정성 있게 정보를 교환하기에 좋은 방법
  • 그 이유는 정보가 sign이 되어있기 때문에 정보를 보낸이가 바뀌진 않았는지, 또 정보가 도중에 조작되지는 않았는지 검증 가능

---

JWT의 구조

https://jwt.io/ 의 JWT 예시

 

JWT는 Header . PayLoad . Signature의 세 덩어리로 이루어져 있으며, 각 부분은 점(.)으로 연결

하단의 텍스트가 파란색으로 Signature Verified 라고 뜨면 JWT 토큰이 검증되었다는 것 !

 

헤더(header)

알고리즘의 형식을 기술하는 부분

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

• alg : 해싱 알고리즘 지정(서명 생성을 위해 어느 알고리즘을 사용할지를 식별)
  • HS256는 이 토큰이  HMAC-SHA256를 사용하여 서명됨을 의미
  • 일반적으로 많이 쓰이는 암호화 알고리즘
  • SHA-2(HS256) 방식의 HMAC와 SHA-256(RS256) 방식의 RSA 서명
  • (이 알고리즘은 토큰을 검증할 때 사용되는 signature 부분에서 사용됨)

(선택 가능 알고리즘)

• typ : 토큰의 타입을 지정 - JWT

참고 : JSON 형태의 객체가 base64로 인코딩 되는 과정에서 공백/엔터 들은 사라짐
따라서 다음과 같은 문자열을 인코딩 하게 됨
{"alg":"HS256","typ":"JWT"}

---

페이로드(payload) - 정보

{
  "sub": "1234567890",
  "name": "admin",
  "iat": 1516239022
}

• sub 토큰제목
• name 사용자 지정 클레임
• iat 토큰 발급시간

• 페이로드는 토큰에 담을 정보로서 클레임(claim) 표명(assert)을 처리 하는 JSON을 보관하고 있음
  • (페이로드. payload 는 전송되는 '순수한 데이터'를 의미)
  • 클레임(claim) : 담는 정보의 한 '조각'을 의미
  • name/value의 한 쌍으로 구성(key-value의 형태로 저장)
  • (토큰에는 여러개의 클레임을 넣을 수 있음)

• 클레임의 종류는 크게 세 분류로 나누어짐
  • 등록된(registered) 클레임
  • 공개(public) 클레임
  • 비공개(private) 클레임

---

등록된(registered) 클레임

 

서비스에서 필요한 정보들이 아닌, 토큰에 대한 정보들을 담기 위하여 이름이 이미 정해진 클레임들

표준 스펙상 key의 이름은 3글자로 되어 있음

(JWT의 핵심 목표는 사용자에 대한, 토큰에 대한 표현을 압축하는 것이기 때문)

토큰에 일반적으로 포함되는 표준 필드인 7개의 등록 클레임 이름(Registered Claim Names)을 정의

1. iss (Issuer) : 토큰 발급자
2. sub (Subject) : 토큰 제목 - 토큰에서 사용자에 대한 식별 값
3. aud (Audience) : 토큰 대상자
4. exp (Expiration Time) : 토큰 만료 시간 - 시간은 NumericDate 형식
5. nbf (Not Before) : 토큰 활성 날짜 (이 날짜 이전의 토큰은 활성화되지 않음을 보장)
   • NumericDate 형식
   • 이 날짜가 지나기 전까지 토큰이 처리되지 않음
6. iat (Issued At (Time)) : 토큰 발급 시간 - 이 값을 사용하여 토큰의 'age'가 얼마나 되었는지 판단 가능
7. jti (JWT Id) : JWT 토큰 식별자 (issuer가 여러 명일 때 이를 구분하기 위한 값)
   • JWT의 고유 식별자
   • 주로 중복적인 처리를 방지하기 위하여 사용
   • 일회용 토큰에 사용하면 유용함

이러한 표준 스펙으로 정의되어 있다는 것이지, 꼭 이 7가지를 모두 포함해야 하는 것도 아니고(모두 선택적 (optional)), 표준 스펙 외에도 필요하다 싶으면 추가해도 전혀 문제가 없음 (개발자의 자유)

---

공개(public) 클레임

 

공개 클레임들은 충돌이 방지된(collision-resistant)이름을 갖고 있어야 함

충돌을 방지하기 위해 클레임 이름을 URL 형식으로 지음

{
    url : (bool type)
}

 

주의: base64 로 인코딩을 할 때, 뒤에 = 문자가 한두개 붙을 때가 있음.
이 문자는 base64 인코딩의 padding 문자라고 부르는데,  URL 의 파라미터로 전달되는 경우도 존재
따라서 = 문자는, url-safe 하지 않으므로, 제거되어야 함.
(패딩이 한개 생길 때도 있고, 두개 생길 때도 있는데, 전부 지워도 (제거해줘도) 디코딩 할 때 전혀 문제 X)

---

비공개(private) 클레임

 

등록된 클레임도 아니고, 공개된 크레임들도 아닌 것

양 측간에 (보통 클라이언트 - 서버) 합의 하에 사용되는 클레임 이름

(공개 클레임과 달리 이름이 중복되어 충돌 가능성이 있으니 사용할 때 유의해야 함)

 

다만 가장 중요한 것은 payload에 민감한 정보를 담지 않는 것

header와 payload는 json이 디코딩되어있을 뿐이지 특별한 암호화가 걸려있는 것이 아니기 때문에 누구나 jwt를 가지고 디코딩을 한다면 담겨있는 값을 알 수 있기 때문

그러므로 JWT에는 단순히 "식별을 하기 위한" 정보만을 담아두어야 하는 것

---

서명(signature)

헤더의 인코딩 값과, 정보의 인코딩 값을 합친 후 주어진 비밀키로 해시를 하여 생성

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your-256-bit-secret
) //secret base64 encoded

• 위의 과정으로 만든 해시를, base64 형태로 나타내면 됨
• (문자열을 인코딩 하는게 아닌 hex → base64 인코딩을 해야 함)
• 앞에서 header 와 payload를 보여줄 때는 인코딩 되어 있던 값들을 JWT에 담겨있는 것처럼 디코딩된 상태를 사용
• heder를 디코딩한 값, payload를 디코딩한 값을 위처럼 합치고
• 이를 your-256-bit-secret 즉, 서버가 가지고 있는 개인키를 가지고 암호화되어있는 상태
• 따라서 signature는 서버에 있는 개인키로만 암호화를 풀 수 있으므로 다른 클라이언트는 임의로 복호화 불가능

복호화 인증 절차

1. JWT 토큰을 클라이언트가 서버로 요청과 동시에 전달
2. 서버가 가지고 있는 개인키를 가지고 signature를 복호화
3. base64UrlEncode(header)가 JWT의 header 값과 일치하는지 확인
4. base64UrlEncode(payload)와 일치하는지 확인
5. 일치한다면 인증을 허용

 

만약 클라이언트가 payload에 담긴 식별자가 변조된 JWT로 요청한다면, 서버가 애초에 발급했던 signature 안의 payload와 다르기 때문에 인증이 불가능

 

JWT의 장점

• 지금까지 쿠키와 세션을 넘어오면서 겪었던 모든 단점을 해결하는 것이 JWT (각각의 단점을 뒤집으면 장점)
• 이미 토큰 자체가 인증된 정보이기 때문에 세션 저장소와 같은 별도의 인증 저장소가 '필수적'으로 필요하진 않음
• 세션과는 다르게 클라이언트의 상태를 서버가 저장해 두지 않아도 됨
• signature를 공통키 / 개인키 암호화를 통해 막아두었기 때문에 데이터에 대한 보완성이 높음
• 다른 서비스에 이용 가능한 공통적인 스펙으로써 사용 가능

 

즉, stateful 해야 하는 세션의 단점을 보완하기 위해 만들어진 JWT는 별도의 세션 저장소를 강제하지 않기 때문에 stateless(무상태성을 추구)하여 확장성이 뛰어나고, signature를 통한 보완성까지 갖춤

 

---

JWT의 취약성

JWT의 취약성

JSON 웹 토큰은 세션 상태를 포함할 수 있음
그러나 프로젝트 요건이 JWT 기간 만료 이전에 세션 무효화를 허용하는 경우
-> 서비스는 더 이상 토큰만으로 토큰 표명(token assertion)을 신뢰할 수 없게 됨
    -> 토큰에 저장된 세션이 폐지되지 않음을 확인하기 위해 토큰 표명은 데이터 스토어에 대해 검사되어야 함
        -> 이렇게 하면 토큰이 더 이상 무상태가 아니게 됨으로써 JWT의 주된 이점이 약화되는 결과를 낳음

• 적절히 설계할 경우 개발자는 일부 주의를 기울이면 알고리즘 취약성을 해결 가능
  • JWT 헤더만으로 유효성을 확인하지 않을 것
  • 알고리즘을 인지할 것
  • 적절한 키 크기를 사용할 것

---

짧은 JWT 유효시간을 보완하는 방법

 

JWT가 만료되기 직전의 유효시간을 보고 재발급 방식을 어떤식으로 하느냐?

 

1. Sliding Session
   • 특정한 서비스를 계속 사용하고 있는 특정 유저에 대하여 만료시간을 연장시켜주는 방법
   • ex) 어떤 글을 지속적으로 쓰고 있는 유저가 짧은 만료시간 때문에 글을 쓰다가 인증 취소로 인해 쓰던 글이 날아간다면?
   • Sliding Session을 사용하면, 사용자가 특정 action을 취했을 때, 새롭게 만료시간이 늘어난 JWT를 다시 제공함으로써 만료시간을 연장하여 보완하는 방법
   • 다만, 접속이 단발성으로 발생한다면 Sliding Session으로 연장시켜줄 수 없는 상황이 생김
   • 너무 긴 JWT(Acess Token)을 발급시켜준 상황이라면, Sliding Session에 의해 무한정 사용 가능해지는 상황이 발생할 수 있음
2. Refresh Token
   • 가장 많이 사용하는 방법
   • JWT를 처음 발급할 때 Acess Token과  함께 Refresh Token이라는 토큰을 발급하여 짧은 만료시간을 해결하는 방법
   • 짧은 시간이 아닌 비교적 긴 시간의 만료시간(7일, 30일 etc.)을 가진 Refresh Token은 말 그대로 Acess Token을 Refresh 해주는 것을 보장하는 토큰
     • 7일, 30일, 60일, 90일, 만료없음(No Expiration), 사용자 설정(Custom)
   • 만약 클라이언트가 Acess Token이 만료됨을 인지하거나, 서버로부터 만료됨을 확인 받는다면 Refresh Token으로 서버에게 새로운 Acess Token을 발급하도록 요청하는 방식

Refresh 동작 과정

1. 클라이언트가 ID, PW로 서버에게 인증을 요청
2. 서버는 이를 확인하여 Access Token과 Refresh Token을 발급
3. 클라이언트는 이를 받아 Refresh Token을 본인이 잘 저장하고, Access Token을 가지고 서버에 자유롭게 요청
4. 요청 도중 Access Token이 만료되어 더 이상 사용 불가능하다는 오류를 서버로 부터 전달 받음
5. 클라이언트는 본인이 사용하던 Access Token이 만료되었음을 인지
6. 본인이 가지고 있던 Refresh Token을 서버로 전달하여 새로운 Access Token 발급을 요청
7. 서버는 Refresh Token을 받아 서버의 Refresh Token Storage에 해당 토큰이 있는지 확인
8. 해당 토큰이 확인되면 Access Token을 생성하여 전달
9. (2)로 돌아가서 계속해서 동일한 작업 진행

 

•  Refresh Token Storage 는 서버에서 Refresh Token을 저장하는 저장소
• 어떻게 보면 세션 저장소와 같은 역할을 수행
• 만료된 Access Token이 더 이상 인증의 역할을 수행하지 못하므로, Refresh Token을 서버로 전달하고, 이 Refresh Token이 서버의 Token 저장소에 있는지 확인 후 Access Token을 발급하는 형태
• 사실상 세션과 별반 차이 없이 저장소(Storage)에 I/O 작업이 발생하는 꼴
  • Access Token이 지속되는 짧은 시간동안 이외에 갱신시 마다
  • 결국 세션과 똑같은 단점 하나가 생기게되는 셈
    • 물론 세션의 경우 인증을 요청할 때마다 I/O
    • 하지만 Refresh Token의 경우, Access Token이 만료되었을 때만
    • 주기가 다르긴하지만 I/O가 발생한다는 사실만 같음
  • 다만 세션처럼 토큰 자체가 탈취되었다고 판단되면, Refresh Token Storage를 초기화함으로써 탈취된 토큰이 더이상 Refresh 되지 못하도록 막는 것이 가능

---

JWT를 활용한 로그인 유지

 

모의 해킹 스터디 - 3주차 과제 (3-2) JWT 구현(로그인 유지)

---

Reference

 

https://jwt.io/

JWT.IO

 

 

 

질문 환영, 수정 및 보완에 대한 지적 환영