4/14 스터디

# 4/14 스터디 ## 임태현 ### HTTPS 정리한 링크 https://hackmd.io/vpLnTXLpQS6I25qt1f-GCg ### HTTPS 질문 및 답변 #### Public Key와 Private Key Public Key와 Private Key는 공개키 암호방식에서 사용되는 용어입니다. 키를 두개를 가지고 있으면서 키들은 서로 암호화와 복호화를 해줄 수 있습니다. 이 공개키 암호화 방식은 클라이언트들에게 Public Key를 공개적으로 나누어줘도 클라이언트측에서 암호화 한것은 Private Key를 가진 서버측에서만 가능하기 때문에 보안성이 높습니다. #### HTTPS에서 사용하는 암호화 기법들 공개키 암호화 방식은 보안성이 높으나, 컴퓨터 자원을 많이 소모하는 단점이 있기 때문에 HTTPS에선 비교적 자원을 덜 소모하는 대칭키 암호화를 같이 사용합니다. 실질적인 데이터를 교환할 때는 컴퓨팅 자원 소모를 줄이기 위해 대칭키 암호화 방식을 사용합니다. 이 때, 대칭키의 단점으로 통신 전에 키를 보낼 때 탈취되는 보안문제를 공개키 방식으로 커버합니다. 우선 대칭키를 만들기 위해 공개키 방식으로 필요한 데이터를 통신합니다. 클라언트에서 대칭키를 만들기 위한 데이터인 Pre Master Secret을 Public Key로 암호화 해 서버로 전송합니다. 서버는 클라이언트에게 받은 Pre Master Secret과 자신이 만든 데이터를 합친 Master Secret으로 대칭키로 사용할 Session Key를 만들어 클라이언트에게 전송합니다. 이 이후엔 Seesion Key란 대칭키로 서로 요청하고 응답할 데이터를 암호화, 복호화하면서 통신합니다. #### HTTPS 연결 과정 먼저 클라이언트와 서버는 TCP Connection을 수립하기 위해 3-way HandShake를 합니다. 이 과정을 거치고 연결이 확립되었으면 SSL 연결을 시작합니다. ![](https://i.imgur.com/THEcD7O.png) > 아래의 순번이랑 위의 번호는 일치하지 않습니다. 1. 우선 클라이언트와 서버는 서로 지원하는 암호화 방식들을 협의하기 위해 메타 데이터들을 전송하는 Client Hello, Server Hello를 수행해 암호화 방식을 결정합니다. 2. 클라이언트에서 Server Hello 과정에서 받은 인증서의 정보와 서명을 이용해 신뢰가는 CA가 증명한 서버로의 통신인지 확인합니다. 3. 인증서에 포함된 서버의 Public Key를 이용해 client hello, server hello과정에서 발생한 데이터 두개를 조합한 Pre Master Secret을 암호화해서 서버에게 전송합니다. 4. 서버는 Pre Master Secret과 자신이 만든 랜덤 데이터로 Master Secret을 생성한 뒤, 세션에서 사용할 대칭키인 Session Key를 생성해 클라이언트에게 전송합니다. 5. 클라이언트가 서버에게 Session Key를 받은 순간 터널링 세션이 성립되어 Session Key로 대칭키 암호화 방식으로 통신합니다. #### HTTPS의 장점 HTTPS는 HTTP에 over Secure Socket Layer란 용어가 포함된 것처럼 보안성을 높인 것이 장점입니다. 보안을 높인 효과로 생긴 장점을 두가지를 들 수 있습니다. 첫번째로, 클라이언트와 서버는 서로가 의도한 통신 대상인지를 확인할 수 있습니다. 서로 통신을 연결할 때 인증서를 교환을 합니다. 이 인증서의 메타 데이터로 CA란 보증인을 두어 신원 확립이 됩니다. 그리고 인증서 또한, 디지털 서명을 포함하고 있어 인증서 내용의 신뢰성도 보장이됩니다. 두번째, 통신간의 패킷 데이터를 암호화해 도청의 위험이 줄어듭니다. 클라이언트와 서버간 통신은 대칭키 알고리즘으로 데이터를 암호화하기 때문에 키를 가지고 있지 않는 Sniffing 공격자는 실질적인 데이터를 알기 어렵습니다. #### 인증서를 이용한 터널링 원리 https는 인증서를 사용해 터널링을 진행할 대상이 의도한 대상인지 또한 의도한 대상이 신뢰가 있는지 확인할 수 있습니다. 우선 서버측에선 https 서비스를 제공하기 위해 CA에게 인증서를 발급 신청을 합니다. 발급 신청을 하면서 자신의 Public key와 서비스 정보등을 제출해 심의를 거쳐 CA 자신의 정보와 서버측에서 사용될 Private Key를 포함한 인증서를 제공 받습니다. 이 때 제출하면서 첨부한 서버의 Public key가 인증서에 포함되어있기 때문에 클라이언트측에서 인증서를 전달 받는 Server Hello 이후에 공개키 암호화를 진행할 수 있습니다. 또한, 인증서엔 디지털 서명이 포함되어있기 때문에 인증서 내용이 변조되었는지 확인할 수 있습니다. 디지털 서명은 CA측에서 자신의 Private Key로 암호화한 것이기 때문에 중간에 내용을 변경할 때 디지털 서명까지 위조하기 힘듭니다. 따라서, 클라이언트측에서 디지털 서명을 복호화한 것과 인증서 내용을 비교하면서 변조의 유무를 따지는 과정을 신뢰할 수 있습니다. #### 클라이언트측에서 인증서를 확인하는 과정 브라우저에선 심의를 거쳐 신뢰성을 판단할 수 있는 CA들을 선정합니다. 그 CA들의 리스트는 물론 CA의 public key도 브라우저의 배포때마다 내장시킵니다. 그래서 서버측의 Server Hello과정에서 받는 인증서에서 인증서 정보에 있는 CA가 브라우저에서 내장된 CA리스트에 있는지 확인이 가능하고 서명을 확인할 수 있습니다. 그 과정은 1. 우선 인증서 정보의 만료기간을 따져 CA 보증이 유효한지 확인합니다. 보증이 유효하면 2. CA가 브라우저에 내장된 곳인지 판단해, CA리스트에 없는 경우 보안 경고를 발생시킵니다. 3. 인증서를 발급한 CA가 신뢰가 있다는 것을 판단하면 이 인증서가 실제 CA가 발급한지를 확인합니다. 이 과정은 브라우저에 CA의 Public Key를 내장하고 있어 가능합니다. 인증서에 포함된 디지털 서명은 CA에서 인증서 정보를 Private Key로 발급한 것이기 때문에, Private Key가 없는 이상 Checksum 때문에 변조가 어렵습니다. ### MSA 정리 링크 https://hackmd.io/87H7X5uRS2K4fdovs_lXGw?edit ### MSA 질문 및 답변 #### MSA란 MSA는 하나의 프로젝트를 작은 단위로 서버들을 나눈 아키텍처입니다. 보통 모놀리식 아키텍처와 비교가 됩니다. 모놀리식 아키텍처는 하나의 프로젝트자체가 단위가 되기 때문에 분산처리란 개념은 선택적이고 서버 Cluster, DB Cluster에만 속합니다. 하지만 MSA는 각 서비스를 하나의 서버로 두기 때문에 처음부터 분산처리를 기반으로 시작합니다. 또한 서비스가 정해진 기준을 단위로 나뉘어졌기 때문에 부분적인 스케일 아웃이 가능합니다. 그리고 각각 의존성이 적기 때문에, 하나의 서비스에 장애가 발생해도 다른 서비스들에게 영향을 주지 않습니다. #### 아키텍처에서 서버를 나누는 기준 저희는 프로젝트가 절대적으로 보았을 때 크다고 생각하지 않았고 서비스 관점에서의 확장성을 고려할 필요가 없다고 판단했습니다. 그래서 앞으로의 확장성을 생각하면 작은 단위로 서비스를 설계하는 것이 맞지만, 퀄리티면에서 내부 통신간의 데이터 유실을 고려하면 API 호출 빈도가 적은 것을 신경을 쓰는 것이 맞다고 판단했습니다. 그래서 첫번째로, 프론트의 페이지 구성과 서비스 흐름도를, 두번째로 DB 컬렉션 스키마를 이용했습니다. 그래서 각 페이지에서 요청하는 API에서 응답을 원하는 것들을 정리하고, 컬렉션 스키마들을 비교하면서 필요한 부분에 선을 그으면서 Top-Down 방식으로 나누고 자원의 의존성을 유지하는 방향으로 진행했습니다. #### 사용했던 설계가 과연 부합했을까? 이 주제로 많은 생각을 했지만 아직도 답을 내리지 못한 상태입니다. MSA에서 가장 어렵다고 생각하는 부분이 서비스를 설계하는 것이였습니다. 왜냐하면 잘게 나누어 의존성이 작은 설계와 서비스간의 API 호출 수, 이 두 개는 Trade Off 관계라 명확한 판단하기 어렵습니다. 또한, 공유 자원까지 고려해서 아키텍처를 설계하면 생각할 것이 많기 때문입니다. 그리고 사람들의 가치관이 다르기 때문에 어렵습니다. 예를 들어 쇼핑몰을 주제로 기획했을 때 구매 버튼으로 이루어지는 서비스와 장바구니 버튼으로 이루어지는 서비스가 하나의 거래 서비스로 둘지, 각각의 서비스로 둘지 딱 정할 수 없기 때문입니다. 그래서 이런 문제는 팀원들의 성향도 중요해서 그때그때마다 다를 것 같습니다. #### MSA의 장단점 제가 생각하는 MSA의 장점은 트래픽 분산인 것 같습니다. 처음부터 서비스들이 나누어져있는 상태이기 때문에 트래픽의 스트레스의 한도가 높아집니다. 수치적으로 기억이 나지 않지만 실제로도 스트레스 테스트할 때 많은 트래픽에서도 서비스가 유지가 되었던 기억이 있습니다. 그리고 서비스들간의 장애 전파가 없다는 것입니다. 실제로 검색 서비스 서버를 종료해도 스터디 그룹 정보를 확인할 수 있고 예약과 결제가 되었습니다. 그리고 단점으로는 규모가 있는 서비스외엔 관리가 어렵다는 것입니다. 저희가 MSA를 채택할 때 가장 눈에 띈 것은 프로젝트 관리가 편해진다는 것입니다. 하지만 서비스라는 단위마다 관리를 해야하니까 CI/CD는 물론, 프로젝트 관리가 어려웠습니다. 아마 이 장점은 어느정도 규모일 때 성립한다고 생각이 들어 적당선의 프로젝트는 모놀리식 아키텍처가 관리가 편할 것이라고 생각합니다. 또한, 서비스 간의 통신 문제에 대해서도 고려할 것이 많고 서비스간 데이터 유실을 고려해야 하는 복잡성이 있습니다. #### MSA 내부 통신의 데이터 유실 문제 해결 방법 저희는 데이터 유실 문제를 해결하기 위해 각 서비스마다 Redis로 Job Queue를 구현했습니다. 예를 들어 사용자가 스터디 그룹을 가입하게 되면 스터디 그룹 DB에 해당 그룹의 참여자 배열에 push를 한 뒤, 다른 서비스인 사용자 서비스에서 DB에도 사용자의 참여 그룹 배열에 push를 해야했습니다. 이 때, 데이터가 유실되는 문제는 중간 서비스의 다운으로 판단했습니다. 그래서 소켓은 상대방의 다운을 감지하는 것을 이용해서 다음 서비스로 데이터를 전달할 때 해당 서비스의 Job Queue에 push를 했습니다. 그래서 다운된 서버를 가동했을 때 먼저 Job Queue의 내용을 처리하게해 나중에 생기는 데이터 불일치성을 방지했습니다. 서버 가동 중일 때 오류가 발생하면 바로 API Gateway에게 오류 의미가 담긴 데이터를 전달을 하게 됩니다. 하지만 구체적인 에러 처리 로직을 처리하지 못했습니다. ### DNS 정리 링크 https://hackmd.io/gRvsH_-uQ5exoRW_P5VBoQ ### DNS 질문 및 답변 #### TLD란?(Top Level Domain) TLD는 com, net, org같이 Root Domain 다음에 해당되는 최상위 도메인입니다. 그 종류로 gTLD, new gTLD, ccTLD가 있는데 운영 주체에 따라 분류한 것입니다. ccTLD는 국가별로 도메인을 관리하기 위해 할당된 TLD입니다. gTLD는 범용적으로 사용하기 위해 존재하는 TLD입니다. 그래서 신청 자격제한의 장벽이 낮습니다. new gTLD는 gTLD의 범위만으론 도메인 수요를 감당할 수 없어 새로 정의한 TLD 규격입니다. #### Thin, Thick Registry란? WHOIS 시스템으로 조회할 수 있는 정보 수가 많은 Domain을 Thin Domain, Thick Domain이라고 합니다. 이 Domain들은 등록 대행 업체가 등록소에 공개한 정보가 되는데, 이 정보양에 따라 나눈 TLD를 취급하는 등록소입니다. #### WHOIS란 등록한 도메인의 책임자가 누군인지 조회할 수 있는 질문 시스템입니다. 도메인을 등록할 때 입력하는 정보들을 누구든지 열람할 수 있어 웹 사이트의 운영자 정보를 쉽게 알 수 있습니다. 이 시스템의 장점은 두가지가 있습니다. 첫번째는 운영의 편리성입니다. 홈페이지를 운영하는 관리자가 사용한 도메인을 잊어버려도 도메인 만료일 등 필요한 정보를 쉽게 알 수 있습니다. 두번째는 악의적인 페이지 운영을 제한할 수 있습니다. 페이지 운영자의 정보는 쉽게 열람할 수 있어 경찰 조사나 법적인 문제의 증거 수집에 도움이 되기 때문입니다. 또한 정보의 타당성이나 정보의 수가 마땅히 충족되지 않을 경우 등록 대행업체가 해당 도메인의 사용을 제한할 수 있습니다. #### Privacy and Proxy 서비스 WHOIS는 도메인 책임자의 열람 시스템은 운영의 편리성, 악의적인 운영에 대한 제한등 장점으로 활용할 수 있습니다. 하지만 개인 정보 보호면에서 말이 많은 시스템입니다. 그래서 실질적인 정보를 숨기고 등록 대행 업체의 정보를 공개하는 서비스가 나오게 되었고 그 서비스가 Privacy and Proxy 서비스입니다. 이 서비스로 실질적인 정보는 등록 대행 업체가 가지고 있고 도메인 사용처에 대한 정보는 가려져 있는 상태로 등록 대행 업체를 통해 열람할 수 있게 됩니다. 이 서비스의 장점은 개인 정보 보호가 가능하다는 것입니다. 또한 등록 대행 업체에서 도메인 등록 심사 과정으로 신뢰성이 높은 도메인 등록이 가능해 WHOIS 시스템의 본질을 유지할 수 있습니다. 또한, 웹 페이지의 등록 정보를 알기 위해 물어볼 대상이 명확해진다는 것입니다. 하지만 도메인 정보에 대한 열람자체도 등록 대행 업체의 심사를 거쳐야 하기 때문에, 정보 열람 프로세스가 번거로워졌다는 단점이 있습니다. #### DNS 이전의 Name System DNS 시스템을 도입하기 전에는 호스트 수가 적어 도메인 관리면에서 자동화가 필요 없었습니다. 그래서 Standard Research Institue에 ip를 등록하고 SRI에서 배포하는 host 파일을 각 호스트에서 다운 받아 사용하는 시스템이였습니다. 하지만 host 사용 수가 많아지면서 잦아진 도메인 정보의 변경이 어려워지고 실시간으로 도메인 정보를 공유해야하는 필요성이 생기면서 DNS 시스템이 도입되게 되었습니다. #### DNS 구성 요소 Domain을 트리 형태로 상위 도메인부터 하위 도메인까지 종류를 나타내는 구조입니다. 도메인들은 각각 정보를 나타내는데 최상위 도메인으로 갈수록 많은 도메인이 포함되어있는데, 각 도메인의 범주를 포괄하는 범주인 `Domain Space`가 첫번째 구성요소 입니다. 두번째는 `Domain Name Server`로, IP 정보를 분산 관리하기 위해 Domain Space범주로 정보를 관리하는 서버입니다. 세번째론 `Zone File`이 있습니다. 각 Domain Name Server가 각 하위 Domain Name Server로 IP 정보를 찾아주기 위해 가르쳐주는 길 정보입니다. #### DNS를 통한 IP 찾는 과정 만약 `www.gabia.com` 이란 도메인의 서비스를 사용하려고 합니다. 그렇게 되면 먼저 컴퓨터 시스템내의 hosts파일에 `www.gabia.com`에 매핑된 ip 정보가 있는지 확인합니다. 없으면 컴퓨터에 설정되어있는지 DNS 서버에게 `www.gabia.com` ip를 물어봅니다. 없으면 DNS 서버는 IANA의 서버인 Root Name Server의 ip를 알려줍니다. 그래서 Root Name Server에게 `.com` 이란 Name Server 위치를 응답 받게 되어 `.com` Name Server에게 `gabia`란 Domain Space가 있는지 물어봅니다. 만약 있으면 ip 정보를 응답받게 되고 없으면 등록된 도메인이 없다는 정보를 받게됩니다. --- ## 최지수 ### Oracle, MySQL, PostgreSQL 차이점 #### Oracle 성능이 좋고, 기능이 많은데 비싸다. 그래서 나는 사용할 일이 없을 것 같다. - 대규모 데이터베이스를 지원한다. - 고성능 트랜잭션 처리를 제공하여 속도가 빠르다. - SQL문을 실행하는 가장 효율적인 방법을 선택한다. 비용을 최소화하기 위해 테이블과 인덱스를 분석한다. #### MySQL 오픈 소스로 무료로 사용 가능하다. - top n개의 레코드를 가지고 오는 케이스에 특화되어 있다. - update 성능이 postgre보다 우수하다. - Nested Loop Join만 지원한다. > **Nested Loop Join** 바깥 테이블의 처리 범위를 하나씩 접근하면서 추출된 값으로 안쪽 테이블을 조인하는 방식이다. - 중첩 루프문과 동일한 원리 - 좁은 범위에 유리하다. - 순차적으로 처리한다. - 복잡한 알고리즘은 가급적 지원하지 않는다. - 문자열 비교에서 대소 문자를 구분하지 않는다. - 간단한 처리 속도를 향상 시키는 것을 추구함 간단한 데이터 트랜잭션을 위한 데이터베이스가 필요한 웹 기반 프로젝트에 널리 사용된다. 로드가 많거나 복잡한 쿼리는 성능이 저하된다. #### PostgreSQL 오픈 소스로 무료로 사용 가능하다. - 다양한 join 방법을 제공한다. - nested loop join, hash join, sort merge join - 결합 할 데이터가 많을 때는 hash, sort merge join - 데이터가 이미 정렬 되어 있는 경우에는 sort merge - 그렇지 않으면 hash join 추천 > **sort merge join** 조인의 대상범위가 넓을 경우 발생하는 Random Access를 줄이기 위한 경우나 연결고리에 마땅한 인덱스가 존재하지 않을 경우 해결하기 위한 조인 방안 양쪽 테이블의 처리범위를 각자 Access하여 정렬한 결과를 차례로 Scan하면서 연결고리의 조건으로 Merge하는 방식 > **hash join** 해시값을 이용하여 테이블을 조인하는 방식 - update를 할 때, 과거 행을 삭제하고 변경된 데이터를 가진 새로운 행을 추가하는 형태라서 update가 느리다. - 처리 속도를 빠르게 하기 위해 여러 CPU를 활용하여 쿼리를 실행한다. - 데이터베이스 클러스터 백업 기능을 제공한다. > 클러스터 : 디스크로부터 데이터를 읽어오는 시간을 줄이기 위해 자주 사용되는 테이블의 데이터를 디스크의 같은 위치에 저장시키는 방법 읽기, 쓰기 속도가 중요하고 데이터를 검증해야 하는 대규모 시스템에서 널리 사용된다. 빈번한 update 성격일 경우 성능, 불안정 하지만 insert 위주 성격일 경우에는 적합하다. 복잡한 쿼리를 실행해야하는 시스템에서 가장 잘 사용 된다. 동시성을 효율적으로 처리하여 매우 높은 수준의 동시성을 달성한다. ### SQL Join 종류 #### INNER JOIN 쉽게 말해서 교집합이라고 생각하면 된다. 두개 테이블의 중복된 값을 보여준다. 즉 두 테이블 모두가 가지는 데이터만 보여준다. #### OUTER JOIN 조건에 맞지 않는 데이터도 보고 싶을 때 사용한다. 두 테이블의 공통 영역을 포함해 한 쪽 테이블의 다른 데이터를 포함한다. ##### LEFT OUTER JOIN 좌측 테이블에 해당하는 데이터는 전체 포함하고, 우측 테이블은 좌측과 겹치는 부분만 포함한다. 값이 없는 경우는 NULL로 표시 됨. ##### RIGHT OUTER JOIN left join과 반대로 우측 테이블 데이터 전체를 포함하는 경우다. ##### FULL OUTER JOIN 두 테이블의 모든 데이터를 읽어 join하여 결과를 생성한다. #### SELF JOIN 자기 스스로를 조인한다. #### CROSS JOIN 보통 join을 할 때 특정 조건을 걸어주는데 그런 조건 없이 모든 경우를 다 결헙하는 방법이다. --- ## 문예지 ### OAuth Auth의 의미: 'Authentication'(인증) + 'Authorization'(허가) - 인증: 신원 확인 - 허가: 인증된 유저의 권한을 파악 > 인증을 위한 프로토콜 > 비밀번호를 제공하지 않고 다른 웹이나 어플리케이션에 접근 권한을 주는 방법 > OAuth와 로그인 > 둘이 접근 권한이 다름 - OAuth: 방문증을 가지고 회사를 방문한 외부인 - 로그인: 사원증을 가진 사원 - 로그인한 서비스 사용자와 OAuth를 통해 인증받은 사용자는 할 수 있는 것이 다름 > OAuth와 OpenID - OpenID의 주요 목적은 인증(Authentication) - OAuth의 주요 목적은 허가(Authorization) > OAuth 인증 과정 1. Request Token 요청과 발급 2. 사용자 인증 페이지 호출 3. 사용자 로그인 완료 4. 사용자의 권한 요청 및 수락 5. Access Token 발급 6. Access Token을 이용해 서비스 정보 요청 ### JWT Json Web Token - JSON 포맷을 이용한 Web Token - Claim based Token - 두 개체에서 JSON 객체를 이용해 Self-contained 방식으로 정보를 안전한게 전달 - 회원 인증, 정보 전달에 주로 사용 > Claim based? > - Claim : 사용자에 대한 프로퍼티 / 속성 - 토큰 자체가 정보 - Self-contained : 자체 포함, 즉 토큰 자체가 정보 - key / value 로 이루어짐 > 왜 쓰는걸까? > - 다양한 클라이언트(web,ios,android) 커버할 수 있음 - session의 한계 1. 서버 확장시 세션 정보의 동기화 문제 > 서버가 스케일아웃 돼서 여러 개가 생기면 각 서버마다 세션 정보가 저장로그인시(서버1), 새로고침(서버2) 로 접근하면 서버는 인증이 안됐다고 판단 > 2. 서버 / 세션 저장소의 부하 3. 웹 / 앱 간의 상이한 쿠키-세션 처리 로직 > 구조 > **JWT의 기본 구조** > Header . Payload . Signature **Header** JWT 웹 토큰의 헤더 정보 ```json= { "typ" : "JWT", "alg" : "HS256" } ``` typ : 토큰의 타입, JWT만 존재 alg : 해싱 알고리즘 / 헤더를 암호화 하는게 :x: / 토큰 검증시 사용 **Payload** 실제 토큰으로 사용하려는 데이터가 담기는 부분 각 데이터를 Claim이라고 함 - Reserved claims : 이미 예약된 Claim 필수는 아니지만 사용하길 권장 - Public claims : 사용자 정의 Claim Public 이라는 이름처럼 공개용 정보 충돌 방지를 위해 URI 포맷을 이용해 저장 - Private claims : 사용자 정의 Claim 사용자가 임의로 정한 정보 ```json= { "name" : "moon", "age" : 26, } ``` **Signature** Header와 Payload의 데이터 무결성과 변조 방지를 위한 서명 최종적으로 만들어진 토큰은 HTTP 통신 간 이용되며, Authorization 이라는 key의 value로서 사용 > JWT 의 단점 & 도입시 고려사항 1. **Self-contained** 토큰 자체에 정보가 있다는 사실은 양날의 검 2. **토큰 길이** 토큰 자체 payload 에 Claim set을 저장하기 때문에 정보가 많아질 수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있음 3. **payload 암호화** payload 자체는 그냥 인코딩된 데이터 중간에 payload를 탈취하면 디코딩을 통해 테이터를 볼 수 있음 payload에 중요 데이터를 넣지 않아야 함 4. **Stateless** 토큰은 한번 만들면 서버에서 제어가 불가능