# MSA Showcase

목차   
1\. MSA 다른 회사는 어떨까 ?   
2\. MSA 모든 기술은 명암이 있다 !  
3\. 온라인 가래 예제를 통하여 엔터프라이즈 기반의 MSA 예시 !   
4\. MSA 금융권의 Mission Critical Biz에서의 Transaction은 ?  
5\. MSA 기본의 APM으로 모니터링이 가능한가 ?   
6\. MSA 로그인 session 관리는 어떻게 ?   
  
일부 문서는 내부 자료로 공개되지 않고 로그인 사용자로 한정합니다.

# MSA 다른 회사는 어떨까 ? [동영상]

MSA 다른 회사는 어떨까 ?

<video controls="controls" height="400" width="800"><source src="http://web.joang.com:8083/attachments/16"></source></video>

# 온라인 거래 예제를 통하여 엔터프라이즈 기반의 MSA 예시 !

온라인 거래 시나리오

### **로그인** \[로그인\]

<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EB%93%B1" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">등록된 사용자가 id / password를 통하여 로그인 </td><td style="height: 120.25px;">Spring Security</td><td style="height: 120.25px;">- 로그인 (id/password),
- 로그인 실패,
- 미허용 URL을 통한 접근 제어
- 허용 URL 접근

</td><td style="height: 120.25px;"> </td></tr></tbody></table>

### **상품 조회** \[상품\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EC%83%81" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 리스트 조회</td><td style="height: 120.25px;">영업모듈 --&gt; 상품 조회

(모듈 간 호출)

</td><td style="height: 120.25px;">- 채널에 해당하는 상품 리스트 조회
- 각 채널에 맞는 상품 가격/단위/결재수단/할인/행사/배송 조회

</td><td style="height: 120.25px;"> </td></tr></tbody></table>


### **상품 구매** \[영업\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EC%83%81-1" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 선택 후 구매</td><td style="height: 120.25px;">영업 모듈 --&gt; 상품 --&gt; 구매 조건 --&gt; 재고 --&gt; 배송 다중 호출 구조 및 성능 </td><td style="height: 120.25px;">- 상품 조회 후 조건 입력 후 구매 결정 --&gt; 개인 구매 페이지로 이동 --&gt; 구매 내역 확인 --&gt; 배송일 표시
- 상품 목록 조회 시에 재고 수량 감소

</td><td style="height: 120.25px;"> </td></tr></tbody></table>


### **상품 초과 구매** \[영업\]\[WMS\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EC%83%81-2" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 구매 시에 재고 이상 구매 </td><td style="height: 120.25px;">트렌젝션 롤백</td><td style="height: 120.25px;">- 상품 조회
- 상품 선택
- 상품 재고량 이상 선택
- 상품 구매
- 상품 구매 실패
- 재고량 복귀
- 거래 내역 취소
- 트렌젝션 롤백 내역 확인(Axon)
- 통합모니터링 롤백 확인

</td><td style="height: 120.25px;">- AXON
- ELK

</td></tr></tbody></table>


### **상품 등록** \[상품\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EB%93%B1-1" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">신상품 등록 </td><td style="height: 120.25px;">CQRS

Master DBMS insert

Slave DBMS replication

</td><td style="height: 120.25px;">- 관리자 로그인
- 신상품 등록
- 상품 속성 등록

</td><td style="height: 120.25px;"> </td></tr></tbody></table>


### **상품 입고** \[WMS\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EB%93%B1-2" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 입고 </td><td style="height: 120.25px;">CQRS

Master DBMS insert

Slave DBMS replication

</td><td style="height: 120.25px;">- 재고량 증가 (입고)

</td><td style="height: 120.25px;"> </td></tr></tbody></table>


### **상품 출고** \[WMS\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EB%93%B1-3" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 구매 후 배송시 상품 출고 </td><td style="height: 120.25px;">Event driven

Queue

</td><td style="height: 120.25px;">- 상품 구매
- 상품 배송 요청
- 상품 배송 --&gt; 재고 출고 요청

</td><td style="height: 120.25px;"> </td></tr></tbody></table>


### **상품 배송** \[배송\]


<table border="1" id="bkmrk-%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4-%EA%B2%80%EC%A6%9D-%EA%B8%B0%EC%88%A0-%EC%8B%9C%EB%82%98%EB%A6%AC%EC%98%A4-%EA%B8%B0%ED%83%80-%EB%93%B1-4" style="border-collapse: collapse; width: 100%; height: 149.85px;"><colgroup><col style="width: 24.9629%;"></col><col style="width: 24.9629%;"></col><col style="width: 29.041%;"></col><col style="width: 20.8848%;"></col></colgroup><tbody><tr style="height: 29.6px;"><td class="align-center" style="height: 29.6px;">비즈니스</td><td class="align-center" style="height: 29.6px;">검증 기술</td><td class="align-center" style="height: 29.6px;">시나리오</td><td class="align-center" style="height: 29.6px;">기타</td></tr><tr style="height: 120.25px;"><td style="height: 120.25px;">상품 배송 </td><td style="height: 120.25px;">Event driven

Queue

Kubernetes Batch

</td><td style="height: 120.25px;">- 상품 구매
- 상품 구매 조건에 따른 배송 이벤트 발생
- 상품 배송 이벤트에 따른 - 재고 이벤트 발생
- 상품 판매 이력 / -재고 / 출고 내역 / 배송 내역 확인

</td><td style="height: 120.25px;">배송은 배치 </td></tr></tbody></table>

# MSA 금융권의 Mission Critical Biz에서 Transaction은 ?

## Axon Server 

Axon Framework란 **EventSourcing, CQRS, DDD 세가지 Concept을 중심으로 어플리케이션을 개발**할 수 있게 도와주는 프레임워크이다.

Axon Framework가 Event Sourcing, CQRS, DDD를 중심으로 애플리케이션을 작성하게 도와주는 프레임워크라면, Axon Server는 그러한 프레임워크를 작동하게 하는 서버이다.

Axon Server는 메세지 라우팅, 이벤트 저장소 등의 역할을 수행한다.

Axon Framework + Axon Server 조합이 필수는 아니다. Axon Server대신 Kafka + NoSQL 등을 사용할 수도 있다. 하지만, Axon Server는 Event Store에 특화되어있으므로, 다른 것으로 대체하기엔 무리가 있을 수 있다.Event Store의 역할은 이벤트를 저장하는 것은 물론이고, 이벤트 전파, 스냅샷 저장등의 특성을 가져야 하기 때문이다.

Axon Server는 다음과 같은 특징이 있다.

- 높은 가용성
- 클러스터 모드를 지원함
- 핸들러가 먹통이 되었더라도 큐에 메세지를 저장
- 서비스간 통신은 gRPC 방식을 사용

### Axon Server 띄우기

Axon 서버는 Axon 공식홈페이지([https://axoniq.io/](https://axoniq.io/))에서 다운받아 띄울 수도 있지만, docker hub에도 이미지가 등록되어 있기 때문에, docker만 설치되어있다면 아래와 같이 간단하게 실행이 가능하다.

```
$ docker run -d --name axonserver -p 8024:8024 -p 8124:8124 axoniq/axonserver
```

### 메세지 종류

Axon은 메세지에 종류가 있다. 또한 이러한 메세지는 명시적으로 Label을 가진다.  
예를 들어, 애플리케이션의 자바클래스가 Label처럼 발행된다. 이러한 명시적 메세지는 약간의 오버헤드가 발생하지만, 장점이 더욱 많다. 또한, 메세지는 요구되는 의도에 따라 라우팅 패턴이 다르다.

#### Commands

- 액션을 취할 때(= Client가 명령을 내릴 때) 사용된다.
- 커맨드는 하나의 목적지로 라우팅되고, 응답을 제공할 수 있다.
- 커맨드는 동시성을 피하기 위해 항상 같은 애플리케이션 인스턴스로 전달한다.

#### Queries

- 액션이 된 정보가 필요할 때 사용된다.
- 전략에 따라 하나 이상의 목적지로 라우팅된다.
- Multiple 인스턴스로 구성했다면, 그 중 하나로만 쿼리가 전달된다.

#### Events

- 발생된 액션을 알릴 때 사용된다.
- 이벤트는 이벤트 저장소에 저장되고, 구독하고 있는 모든 목적지에 라우팅된다.
- 이벤트에 보통 비즈니스 결정사항을 담지 않는다.

이렇게 명시적으로 분리된 메세지 컴포넌트는 각자 역할에 관심이 없다. 이러한 관심사의 분리는 MSA에도 잘맞는 개념이다.  
(Axon 에서는 MSA환경에도 물론 잘맞는다고 하지만, 모놀리스 환경에서도 유용하게 사용될 수 있다고 말한다.)

```yaml
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: axonserver
  namespace: showcase-apps
  labels:
    app: axonserver
spec:
  serviceName: axonserver
  replicas: 1
  selector:
    matchLabels:
      app: axonserver
  template:
    metadata:
      labels:
        app: axonserver
    spec:
      containers:
      - name: axonserver
        image: axoniq/axonserver
        imagePullPolicy: Always
        ports:
        - name: grpc
          containerPort: 8124
          protocol: TCP
        - name: gui
          containerPort: 8024
          protocol: TCP
        readinessProbe:
          httpGet:
            port: 8024
            path: /actuator/health
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 1
---
apiVersion: v1
kind: Service
metadata:
  name: axonserver-gui
  namespace: showcase-apps
  labels:
    app: axonserver-gui
spec:
  ports:
  - name: gui
    port: 8024
    targetPort: 8024
  selector:
    app: axonserver
  type: LoadBalancer
---
apiVersion: v1
kind: Service
metadata:
  name: axonserver
  namespace: showcase-apps
  labels:
    app: axonserver
spec:
  ports:
  - name: grpc
    port: 8124
    targetPort: 8124
  clusterIP: None
  selector:
    app: axonserver
---
```

[http://192.168.0.100:30216/](http://192.168.0.100:30216/)

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/qfvimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/qfvimage.png)

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/SDSimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/SDSimage.png)

설치 후 화면

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/OQ0image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/OQ0image.png)

예제를 구성한 모습

각가의 모듈을 1 또는 2개의 Pod로 구성한 모습

# MSA 기본의 APM으로 모니터링이 가능한가 ?

### Kiali (Kubernetes add on for istio)

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/MIMimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/MIMimage.png)

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/DyWimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/DyWimage.png)

- [**Istio** ](https://istio.io/)+ [**Kiali**](https://kiali.io/) :   
    [Istio Install](https://istio.io/latest/docs/setup/install/istioctl/)   
    [Kiali Install](https://kiali.io/docs/installation/) 웹 대시보드 형태로 Istio 정책을 제어하고 Istio 동작을 확인할 수 있는 기능을 지원  
    [https://isn-t.tistory.com/43](https://isn-t.tistory.com/43)
- 오픈 소스 APM Pinpoint 도입 및 후기 :   
    [https://tech.trenbe.com/2022/02/22/pinpoint.html](https://tech.trenbe.com/2022/02/22/pinpoint.html)  
    [https://pinpoint-apm.github.io/pinpoint/index.html](https://pinpoint-apm.github.io/pinpoint/index.html)

### Pinpoint 

Pinpoint는 분산 서비스 및 시스템의 성능 분석/진단/추적 플랫폼 서비스로서 “N” 계층의 SOA(Service Oriented Architecture) 및 Micro-Service로 구성된 아키텍처 서비스의 추적 및 분석 기능을 제공하고, 분산 애플리케이션의 트랜잭션 분석, Topology Detection, Bytecode Instrumentation을 활용한 진단 기능을 제공

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/i1Kimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/i1Kimage.png)

[https://guide-fin.ncloud-docs.com/docs/pinpoint-pinpoint-1-1](https://guide-fin.ncloud-docs.com/docs/pinpoint-pinpoint-1-1)

<iframe allowfullscreen="allowfullscreen" height="314" src="https://www.youtube.com/embed/U4EwnB34Dus?si=h-BxZI9QcCpZ7MDS" width="560"></iframe>

### Istio 설치시 선택 profile 

- <span style="color: rgb(255, 255, 255);">**default**</span>: 디폴트 프로필은 IstioOperator API의 기본 설정에 따라 구성 요소를 활성화합니다. 이 프로필은 프로덕션 배포 및 멀티클러스터 메시의 주요 클러스터에 권장됩니다. 디폴트 설정을 확인하려면 istioctl profile dump 명령을 실행할 수 있습니다.
- <span style="color: rgb(255, 255, 255);">**demo**</span>: 이 프로필은 Istio의 기능을 적은 자원 요구 사항으로 표시하기 위해 설계된 구성입니다. Bookinfo 애플리케이션과 관련 작업을 실행하는 데 적합합니다. 이 프로필은 높은 수준의 추적 및 액세스 로깅을 활성화하므로 성능 테스트에는 적합하지 않습니다.
- <span style="color: rgb(255, 255, 255);">**minimal**</span>: 디폴트 프로필과 동일하지만 제어 플레인 구성 요소만 설치됩니다. 이를 통해 제어 플레인 및 데이터 플레인 구성 요소 (예: 게이트웨이)를 별도의 프로필을 사용하여 구성할 수 있습니다.
- <span style="color: rgb(255, 255, 255);">**remote**</span>: 외부 제어 플레인 또는 멀티클러스터 메시의 주요 클러스터에서 관리되는 원격 클러스터를 구성하는 데 사용됩니다.
- <span style="color: rgb(255, 255, 255);">**empty**</span>: 아무 것도 배포하지 않습니다. 사용자 정의 구성을 위한 기본 프로필로 유용할 수 있습니다.
- <span style="background-color: rgb(0, 0, 0);">**preview**</span>: 프리뷰 프로필에는 실험적인 기능이 포함되어 있습니다. Istio에 새로운 기능을 탐색하기 위해 사용됩니다. 안정성, 보안 및 성능은 보장되지 않으므로 사용 시 주의가 필요합니다.
- <span style="color: rgb(255, 255, 255);">**ambient**</span>: 앰비언트 프로필은 앰비언트 메시를 시작하는 데 도움을 주도록 설계되었습니다.

The components marked as ✔ are installed within each profile:

<table id="bkmrk-%C2%A0-default-demo-minim"><thead><tr><th> </th><th>default</th><th>demo</th><th>minimal</th><th>remote</th><th>empty</th><th>preview</th><th>ambient</th></tr></thead><tbody><tr><td>Core components</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td> `istio-egressgateway`</td><td> </td><td>✔</td><td> </td><td> </td><td> </td><td> </td><td> </td></tr><tr><td> `istio-ingressgateway`</td><td>✔</td><td>✔</td><td> </td><td> </td><td> </td><td>✔</td><td> </td></tr><tr><td> `istiod`</td><td>✔</td><td>✔</td><td>✔</td><td> </td><td> </td><td>✔</td><td>✔</td></tr><tr><td> `CNI`</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td>✔</td></tr><tr><td> `Ztunnel`</td><td> </td><td> </td><td> </td><td> </td><td> </td><td> </td><td>✔</td></tr></tbody></table>

To further customize Istio, a number of addon components can also be installed. Refer to [integrations](https://istio.io/latest/docs/ops/integrations) for more details.

# MSA 로그인 Session 관리는 어떻게 ?

### <span style="color: rgb(255, 255, 255);">**Jason 기반의 Web Token 인증**</span>

#### 일반 인증방식이 MSA에 어려운 경우 

1. 서버가 각각 다른 수십 또는 수 백 수 천의 client의 세션을 동기화하고 인증하고 권한을 할당할 필요가 있다 기존의 세션관리하는 방식으로 수용이 가능한 것일까 ?
2. 기존의 session의 방식은 하나의 서버에서 통용되는 방식으로 사실 심플하고 명료하고 편리한 것은 사실이지만 여러대의 서로 다른 서버의 session 동기화의 경우는 SSO를 통하여 공유하는 방식의 한계가 있다

MSA의 세상에서는 내부 뿐만 아니라 외부의 서비스까지도 통합하는 시나리오가 존재한다.

프런트엔드 애플리케이션 또는 백엔드 서비스는 API를 통해 실시간 데이터를 요청하고 이를 사용자 인터페이스에 표시하거나 비즈니스 프로세스를 지원하기 위해 백엔드 서비스를 통해 처리할 수 있습니다. 예를 들어, 지불 처리 업체를 선택한 개발자는 해당 업체의 API를 활용하여 앱이나 웹 사이트에서 PCI(결제 카드 산업) 준수 온라인 결제 기능을 쉽게 활성화할 수 있습니다.

이런 사용의 경우 내부 시스템이 아닐 뿐만 아니라 높은 수준의 보안이 요구됩니다. 이렇듯 내부 또는 외부의 여러가지 서비스를 특별한 SSO 기술이 없이 자연스럽게 통하는 기술이 API Token 기술입니다.

**<span style="color: rgb(255, 255, 255);">1. </span><span style="color: rgb(255, 255, 255);">**Scaling Scenario 1 : 익숙**한 방법</span>**이기도 한데 하루에 최소 100번이상 Basic 인증을 사용하여 API를 호출하는 한 고객을 가정해 보면 , 각각의 요청은(API 호출마다)는 개별적으로 인증되어야 하므로 인증 서버에 대한 총 호출 횟수도 하루에 최소 100번 이상이 될 수 있습니다.

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/WXZimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/WXZimage.png)

 만약 우리가 고객 수를 두 배로 확장한다면 (즉, 2명의 고객), API 호출 횟수는 이제 하루에 200번이 될 것이므로, 인증 서버 호출 횟수 역시 두 배로 증가하여 하루에 200번의 호출이 될 것입니다. 따라서 API 인프라의 용량을 늘려야 하는 경우, 인증 서버의 용량도 함께 확장해야 합니다.

이것은 이전의 SSO 방식과 유사 , 사실 일반 SSO 솔루션은 로컬에서 SSO Key를 인증하는 라이브러리가 있고 그것을 설치해야 하고 각각의 클라이언트 수 만큼의 **<span style="color: rgb(255, 255, 255);">라이선스 비용이 발생</span>**함

**<span style="color: rgb(255, 255, 255);">2. </span><span style="color: rgb(255, 255, 255);">Scaling Scenario 2</span> :** 두 개의 외부 노출 API가 하나의 인증 서버를 통해 Basic 인증으로 보호된 상황을 상상해보겠습니다. 또한 단일 고객이 각각의 API를 하루에 100번씩 호출한다고 가정해봅시다. 이러한 상황에서 인증 서버 호출은 두 API 간의 인증 합계로 나타날 것이며, 즉 하루에 200회의 인증이 이루어 집니다.

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/1r5image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/1r5image.png)

Scenario 1와 마찬가지로 고객 기반이 2배로 늘어나 2명의 고객이 각각의 API를 하루에 100번 호출하는 경우, 총 API 호출 수는 다음과 같은 순서가 될 것입니다.

2명의 고객 x (100회 호출 x 2개의 API) = 하루에 약 400회의 호출

실제로는 이렇게 되어, 인증 서버에 대한 호출도 하루에 400번이 될 것입니다.

요약하면, 각각의 API 서비스는 호출량에 따라 개별적으로 확장될 수 있지만, 총 API 호출량을 고려하여 인증 서버를 확장해야 합니다. 또한 이것은 **<span style="color: rgb(255, 255, 255);">전체 아키텍처의 단일 장애 지점</span>**이 될 가능성이 빠르게 나타납니다.

결국은 **<span style="color: rgb(255, 255, 255);">MSA의 늘어나는 서비스들을 수용하기에는 어려운 방식</span>**입니다.

#### Authentication Methods and Challenges

여러 가지 인증 방법이 있습니다. 각 인증 방법은 그 장단점과 사용 사례에 대한 적합성을 가지고 있습니다. 예를 들어, 소셜 미디어 애플리케이션에서 사용자 프로필 이미지를 검색하는 API는 기본 인증 또는 API 키 기반 인증을 사용할 수 있지만, **<span style="color: rgb(255, 255, 255);">은행에서 사용자 프로필을 검색하는 경우 더 높은 수준의 보안과 인증 방법이 필요</span>**하며 이를 악의적인 요청을 방어할 수 있도록 보호해야 합니다.

##### Basic Authentication은 아래와 같은 단순한 암복호화입니다. 

그러나 이 정보를 평문으로 네트워크를 통해 전송하는 대신, base64로 인코딩(암호화되지 않음)하여 HTTP 요청의 헤더에 첨부됩니다. 예를 들어, 연락처 목록을 검색하는 데 사용되는 다음 REST API를 기본 인증을 사용하여 호출할 수 있습니다.

사용자 이름이 'hello'이고 비밀번호가 'w0rL%'이라고 가정하면, 다음 명령을 사용하여 API를 호출할 수 있을 것입니다.

```javascript
$ echo 'hello:w0rL%' | base64 
aGVsbG86dzByTCUK

$ curl -X GET https://api-examples.com/contacts \
-H 'Authorization: Basic aGVsbG86dzByTCUK'

```

이 접근 방식에는 몇 가지 문제가 있습니다. **<span style="color: rgb(255, 255, 255);">첫째, 사용자 이름과 비밀번호는 base64로 인코딩되었지만 완전히 역으로 변환 가능</span>**합니다.

```javascript
$ echo 'aGVsbG86dzByTCUK' | base64 --decode
hello:w0rL%
```

**<span style="color: rgb(255, 255, 255);">둘째, 앞서 논의한 대로 이 접근 방식은 과도한 인증 서버의 문제로 인해 확장성 문제</span>**가 발생할 수 있습니다. 이로 인해 API 응답 시간이 느려지거나 시간 초과 또는 인증 서버의 실패로 인한 문제가 발생할 가능성이 있습니다.

##### <span style="text-decoration: underline;">API Key Authentication</span> 

이 인증 방법에서는 직접 사용자 이름과 비밀번호에 의존하는 대신, 개발자는 개발을 시작하기 전에 서비스 제공자로부터 **<span style="color: rgb(255, 255, 255);">(1)</span>**고유한 해시된 문자열을 얻습니다. 이 해시된 문자열을 API 키라고 합니다. API 제공자는개발자와 **<span style="color: rgb(255, 255, 255);">(2)</span>**고유한 API 키를 매핑하고 확인할 수 있습니다. API 제공자에 따라 개발자는 **<span style="color: rgb(255, 255, 255);">(3)</span>**여러 개의 API 키를 생성할 수 있을 수 있습니다. 이렇게 하면 애플리케이션의 <span style="color: rgb(255, 255, 255);">**(4)**</span>특정 영역에 따라 전략적으로 사용하고 일정한 주기로 **<span style="color: rgb(255, 255, 255);">(5)</span>**철회하거나 수정할 수 있는 능력을 제공합니다. 따라서 Basic 인증과 비교하여, **<span style="color: rgb(255, 255, 255);">개발자는 비밀번호를 자주 변경하고 다른 API에서 단일 사용자를 사용해야 하는 대신 API 키 기반 인증은 사용자를 API 키에 일대다 매핑하고 전체 API 사용에 영향을 주지 않고 개별적으로 철회할 수 있는 기능을 제공</span>**합니다.

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/WpRimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/WpRimage.png)

API 키 유효성 검사는 사용자와 API 키 간의 매핑을 저장하는 데이터베이스에 대한 것으로 진행될 수 있습니다. 각 API 호출마다 API 키와 해당 유효성을 이 데이터베이스에서 조회하여, 인증 서버에 대한 빈번한 호출을 제거하고 잠재적으로 단일 장애 지점이 되지 않도록 할 수 있습니다. API 키를 조회하기 위한 응답 시간을 개선하기 위해 키-값 또는 문서 데이터베이스를 활용할 수 있습니다.

그러나 이것은 Basic 인증보다는 개선된 방법이지만, <span style="text-decoration: underline;">API 키에는 여전히 단점</span>이 있습니다. <span style="color: rgb(255, 255, 255);">**API 키를 수동으로 변경해야 하므로 오버헤드와 연관된 코드 유지 관리 부담이 늘어납니다. 또 다른 단점은 API 키가 여전히 쿼리 매개변수 또는 헤더를 통해 평문으로 전송되며, 그것이 잘못된 손에 빠질 우려가 항상 존재합니다. 마지막으로, 인증의 확장성 문제(빈번한 API 키 조회)는 여전히 존재하며, 이것은 단순히 인증 서버에서 API 키 데이터베이스로 이동하는 것뿐입니다.**</span>

##### <span style="text-decoration: underline;">Token Based Authentication(구현 내용)</span> 

토큰은 이 문맥에서는 인증 서버에서 요청된 길이가 다른 무작위 문자열의 문자열입니다. 토큰 기반 인증 방법을 사용한 API 호출은 다음과 같은 세 단계로 진행됩니다. 아래에서 자세히 설명하겠습니다.

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/blrimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/blrimage.png)

**<span style="color: rgb(255, 255, 255);">첫 번째 단계</span>**에서 인증된 개발자는 비즈니스 API 호출을 위한 자격 증명으로 클라이언트 ID와 시크릿 형태의 자격 증명을 얻기 위해 API 제공업체와 그들의 애플리케이션을 등록해야 합니다.

등록된 클라이언트 ID와 시크릿을 사용하여 **<span style="color: rgb(255, 255, 255);">두 번째 단계</span>**에서 개발자는 비즈니스 API 호출을 시작하기 전에 토큰을 요청합니다. 인증 서버에서는 특정 유효 기간을 가진 서명된 토큰이 발급됩니다.

**<span style="color: rgb(255, 255, 255);">이후의 단계</span>**에서는 토큰이 유효한 동안 두 번째 단계에서 받은 토큰을 전달하면서 적절한 비즈니스 API 엔드포인트를 호출합니다. API 엔드포인트는 토큰을 확인하고 적절한 기능적인 응답을 반환합니다. <span style="text-decoration: underline; color: rgb(255, 255, 255);">토큰의 확인은 데이터베이스 조회나 인증 서버에 대한 호출과 같이 의존하지 않습니다. API 키 기반 인증과 달리, 토큰의 서명을 검증함으로써 토큰의 유효성을 확인합니다.</span>

**<span style="color: rgb(236, 240, 241);">주민등록증</span>**을 이해해 보면, 주민등록증은 동사무소에서 발급됩니다. 동사무소(인증 서버)은 원본 문서(인증)를 기반으로 여러 점의 확인을 수행한 후 특별한 검증 가능한 도장(지문)이 있는 주민등록증(토큰)을 발급합니다. 그 이후에는 주민등록증이 유효한 동안 비행기 탑승권 발급, 은행 계좌 개설 등과 같은 적절한 장소에서 주민등록증을 제시할 수 있습니다. 공항 및 은행 직원들은 실제로 우리가 누구인지(신원)를 확인할 필요가 없습니다. 즉 국가 기관에 모두 전화,팩스,인터넷 등을 통하여 모두 확인하지 않아도, **<span style="color: rgb(236, 240, 241);">주민등록증 자체에 적시된 유효기간 내에 도장(지문)을 확인함으로써 운전면허증이 유효한지 확인</span>**하고 그렇다면 해당 서비스를 사용할 권한이 있다고 가정합니다(즉, 비행기를 탑승하거나 은행 계좌를 개설할 수 있다).

<span style="color: rgb(236, 240, 241);">**토큰 기반 인증 방법은 토큰 검증을 위한 데이터베이스 조회가 없으므로 높은 확장성을 제공**</span>합니다. 실제로 증명은 토큰의 진위성에 대한 것이며, 토큰의 서명을 검증함으로써 해결됩니다. 서명에 대해서는 다음 섹션에서 자세히 다루겠지만, 현재는 토큰이 유효로 선언되려면 인증 서버에서 생성한 서명과 호출자로부터 수신한 API 서버의 서명이 일치해야 합니다. 토큰 기반 인증 방법은 또한 만료 및 새로운 토큰 요청(토큰 로테이션)을 강제하여 설계의 추가 보안을 보장합니다.

이제 본론으로 들어와서

#### **<span style="color: rgb(236, 240, 241);">JSON Web Tokens (JWTs)</span>**

JWT (또한 "jot"으로 발음)는 JSON 객체 서명 및 암호화 그룹인 JOSE (JSON Object Signing and Encryption) 그룹에서 2011년부터 2016년까지 등장한 표준입니다 (Peyrott, 2018). JWT 표준은 컴팩트하고 자체 포함된 아티팩트를 사용하여 두 당사자 간에 정보(예: 보안 정보)를 공유할 수 있게 합니다. 따라서 JWT는 내장된 신뢰 메커니즘을 통해 정보를 간결하게 공유할 수 있습니다. 그럼에도 불구하고 이 표준의 가장 일반적인 구현은 API 보안에서 찾을 수 있습니다. JSON(JavaScript Object Notation)은 가벼운 데이터 교환 형식이므로 상태 없는 통신을 통해 클라이언트와 서버 간에 보안 클레임을 교환하는 데 활용되었습니다.

**부가 정보: JWT (JSON Web Tokens)는 종종 다른 표준과 함께 작동합니다. 예를 들면 다음과 같습니다.**

- <span style="color: rgb(236, 240, 241);">JWS </span>(JSON Web Signatures): 디지털 서명을 사용하여 JSON 콘텐츠에 서명하는 데 사용됩니다.
- <span style="color: rgb(236, 240, 241);">JWK </span>(JSON Web Keys): JSON 형식의 암호화 키 및 키 세트로 사용됩니다.
- <span style="color: rgb(236, 240, 241);">JWE </span>(JSON Web Encryption): JSON 콘텐츠를 암호화하거나 해독하는 데 사용됩니다.
- <span style="color: rgb(236, 240, 241);">JWA </span>(JSON Web Algorithms): JWS, JWE 및 JWK에서 사용되는 암호 알고리즘을 나타내기 위해 사용됩니다.

보안 클레임은 어떤 것에 대한 주장입니다. JWT 사양에서는 여러 표준 클레임이 제공되며, 다양한 당사자 간의 상호 운용성을 가능하게 합니다. JWT의 표준 클레임 중 하나는 토큰의 "발급자" (표준에서 "iss"로 지정됨)입니다. 이를 이해하기 위해 주민등록증 예제를 참조하십시오. 유효한 주민등록증은 공인된 동사무소 또는 구청등의 국가 기관에 의하여 발급되었다고 가정합니다. 이로써 검증자는 국내의 소재하고 있는 국민으로서의 자격과 주소지를 인증을 받는 사람임을 확인할 수 있습니다. 다시 말해, 특정 지역 출신의 대한민국 국민이라고 주장하는 것은 주민등록증 발급 기관에 의해 보증됩니다.   
 운전면허증도 유사한내용인데 제 개인적으로 대구 출장 시에 운전면허증을 갱신하여서 지금도 운전면허증의 방급 기관이 대구로 되어 있습니다. 하지만 그 이후 대구에 방문한 적이 없지만 여전히 대구 경찰청(발급자)에서 제 개인 운전면허증을 보증하고 있습니다.

1. **Subject (sub)**: 토큰의 주제를 나타내며, 주로 사용자를 고유하게 식별하는 정보를 포함합니다.
2. **Audience (aud)**: 토큰의 대상 청중(수신자)를 나타내며, 토큰이 어떤 서비스나 애플리케이션을 위해 발급되었는지를 지정합니다.
3. **Expiration Time (exp)**: 토큰의 만료 시간을 나타내며, 이 시간 이후에는 토큰이 더 이상 유효하지 않습니다.
4. **Not Before (nbf)**: 토큰의 시작 유효 시간을 나타냅니다. 이 시간 이전에는 토큰이 유효하지 않습니다.
5. **Issued At (iat)**: 토큰이 발급된 시간을 나타냅니다.
6. **JWT ID (jti)**: JWT의 고유 식별자를 나타냅니다. 토큰을 고유하게 식별하는 데 사용됩니다.

JWT 구조는 점(.)으로 구분된 세 부분을 포함하고 있습니다. 예를 들어, 다음과 같이 간결한 평문 JWT는 표시된 JSON 객체를 나타냅니다.

JWT는 Header, Payload, Signature로 이루어져 있으며 각각 점으로 구분

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
<strong>eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9</strong>.
TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

{ "alg": "HS256", "typ": "JWT" }.
<strong>{ "sub": "1234567890", "name": "John Doe", "admin": true }</strong>.
<signautre>
```

첫 번째 부분은 헤더(header)로, JWT를 서명하는 데 사용된 알고리즘을 나타내는 JSON 객체의 base64 인코딩된 문자열입니다.  
{  
 "typ": "JWT",  
 "alg": "HS256"  
}

두 번째 부분은 payload로, 표준 및 사용자 정의 클레임을 포함하는 JSON 객체의 base64 인코딩된 문자열입니다.

- 등록된 클레임 : iss(발행자), exp(만료시간), sub(제목), aud(대상) 등이 있음 =&gt; 권장되긴 하지만 필수는 아님
- 개인 클레임 : 서로 정보를 공유하기 위해 생성된 사용자 지정 클레임 =&gt; 원하는 정보들을 넣으면 됨  
    {  
     // 등록된 클레임  
     "iss": "chb2005.tistory.com",  
     "sub": "123456789",  
     "exp": "1659002265",  
     // 개인 클레임  
     "userName": "changbum",  
     "isAdmin": false  
    }

마지막 부분은 이 토큰을 교환하는 당사자만이 알고 있는 비밀을 사용하여 서명된 헤더와 payload를 연결하여 생성된 서명입니다.

- Signature은 Header, Payload, Secret Key를 합쳐 암호화한 결과값 
    - HS256( base64UrlEncode(header) + "." + base64UrlEncode(payload), Secret key)

```
signing_algorithm(<header>.<payload>) = <signature>
```

따라서 초기 인증 프로세스 중에 발급된 JWT에 포함된 인증 서버(Steps 2 &amp; 3 in Fig. 3)에서 제공한 서명은 API에서 동일한 비밀(Steps 4 in Fig. 3 사용됨)을 사용하여 확인해야 합니다. 서명이 일치하면 API는 토큰의 발급자가 호출자에 의해 성공적으로 인증되었으며 따라서 응답을 신뢰할 수 있음을 확인할 수 있습니다.

#### Example of API authentication using JWT

1. 사용자의 정보를 등록함
2. 로그인 : 등록한 이메일과 패스워드를 확인하고 맞으면 사용자에 특정한 비밀키를 생성
3. 이후로 사용자는 모든 요청이 있을 때 헤더에 해당 비밀키를 전달함   
    ex) 발급받은 Jwt Token이 'xxxx.yyyy.zzzzz'라면  
    A가 B에 요청 전송시 Request Header의 'Authorization'에 'Bearer xxxx.yyyy.zzzzz'를 담아 전송
4. 요청과 토큰을 받은 인증서버는 토큰을 통해 사용자를 인증하고 요청에 대한 응답을 진행
5. 만약 악의적으로 사용자를 바꾸어서 요청허ㅏ고자 하여도 사용자의 비밀키를 알 수 없기 때문에 정확한 Signature을 만들 수 없음

##### Endpoints

동일한 방식으로, 코드는 두 가지 서비스로 구성되어 있습니다.

1. **<span style="color: rgb(236, 240, 241);">Authentication Service, with endpoints for:</span>**
    - **<span style="color: rgb(236, 240, 241);">registering the user</span>** : [http://localhost:9090/auth/signup](http://localhost:9090/auth/signup)  
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/tEUimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/tEUimage.png)
        
          
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/cnEimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/cnEimage.png)
    - login &amp; generating : [http://localhost:9090/auth/login](http://localhost:9090/auth/login)   
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/U8kimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/U8kimage.png)
        
        ```json
        {
            "grantType": "Bearer",
            "accessToken": "eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIyIiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTY5NTk5ODExM30.Z5-tmiOarkWi66fLZite1ZBoi1Duhc_Qm0R6m4l8qg5f8B23GpxxcjFjyOJmLOFiyZEPIkeFEHPkylAVIYjX4A",
            "refreshToken": "eyJhbGciOiJIUzUxMiJ9.eyJleHAiOjE2OTY2MDExMTN9.TDa1ko2zIF0f3tKNaRzzxZA-VOgKRiOXa5_4iIBzBCRgkW_-VRugqYILIC9qqgWkbcSuOf3mfhNZ377idgcsyg",
            "accessTokenExpiresIn": 1695998113455
        }
        ```
        
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/fw4image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/fw4image.png)
2. <span style="color: rgb(236, 240, 241);">**API endpoint with business function**</span>
    - <span style="color: rgb(236, 240, 241);">**biz call**</span> : [http://localhost:9090/api/member/me](http://localhost:9090/api/member/me)   
        <div><div> "accessToken": "eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIyIiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTY5NTk5ODExM30.Z5-tmiOarkWi66fLZite1ZBoi1Duhc_Qm0R6m4l8qg5f8B23GpxxcjFjyOJmLOFiyZEPIkeFEHPkylAVIYjX4A"  
        </div></div>[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/E71image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/E71image.png)
        
        <div>  
        </div>[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/tFmimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/tFmimage.png)
3. <span style="color: rgb(236, 240, 241);">**re generating**</span>
    - <span style="color: rgb(236, 240, 241);">**re generating**</span> : [http://localhost:9090/auth/reissue](http://localhost:9090/auth/reissue)   
        만료인 경우 재발급   
        ```json
        "accessToken": "eyJhbGciOiJIUzUxMiJ9.eyJzdWIiOiIyIiwiYXV0aCI6IlJPTEVfVVNFUiIsImV4cCI6MTY5NTk5ODExM30.Z5-tmiOarkWi66fLZite1ZBoi1Duhc_Qm0R6m4l8qg5f8B23GpxxcjFjyOJmLOFiyZEPIkeFEHPkylAVIYjX4A",
            "refreshToken": "eyJhbGciOiJIUzUxMiJ9.eyJleHAiOjE2OTY2MDExMTN9.TDa1ko2zIF0f3tKNaRzzxZA-VOgKRiOXa5_4iIBzBCRgkW_-VRugqYILIC9qqgWkbcSuOf3mfhNZ377idgcsyg"
        ```
        
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/H7fimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/H7fimage.png)
        
        --&gt;   
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/oHmimage.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/oHmimage.png)
        
        [![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-09/scaled-1680-/zD1image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-09/zD1image.png)

#### JWT의 장단점 

##### 장점

- 서버는 비밀키만 알고 있으면 되기 때문에 세션 방식과 같이 별도의 인증 저장소가 필요하지 않음 =&gt; 서버측 부하 감소
- 여러개의 서버를 사용하는 대형 서비스 같은 경우에 접근 권한 관리가 매우 효율적임 =&gt; 확장성이 좋음
- Refresh Token까지 활용한다면 더 높은 보안성을 가질 수 있음

##### 단점

- Payload의 정보(Claim)가 많아질 수록 토큰이 커짐
- 중요한 데이터는 넣을 수 없음
- 토큰 자체를 탈취당하면 대처가 어려움
- 로그아웃 시 JWT 방식은 세션이 없는 stateless 방식이기 때문에 토큰 관리가 어려움

#### Conclusion

토큰 기반 인증은 API를 무단 액세스로부터 보호하는 보안 수준을 높이는 것뿐만 아니라 토큰 검증 프로세스를 인증 프로세스와 분리함으로써 API 기반 데이터 교환 아키텍처를 확장하는 데 기여했습니다.   
<span style="color: rgb(255, 255, 255);"> JWT 표준이 개념을 더 확장하려면 인터넷을 통해 추가적인 오버헤드 없이 전달할 수 있는 간결한 평문 페이로드를 생성할 수 있는 능력입니다.   
 또한 대칭 및 비대칭 암호화를 사용하여 페이로드를 서명하고 이를 단일 토큰의 일부로 전달하는 개념은 종단 간 솔루션 아키텍처 관점에서 다중 보안 레이어를 추가.</span>

JWT 기반 토큰은 API 인증 영역에서 널리 채택된 표준이 되었습니다. 사실, SAP BTP의 SAP Credential Store 서비스 및 Google Identity 인증 서비스를 활용한 예제에서 동일한 접근 방식이 필요했음을 알 수 있습니다.

원문 : <span style="color: rgb(126, 140, 141);">[https://blogs.sap.com/2023/02/05/secure-your-apis-using-json-web-token-jwt/](https://blogs.sap.com/2023/02/05/secure-your-apis-using-json-web-token-jwt/) 을 약간 수정함 </span>

### References

Palmer. (2006, November 3). Data is the New Oil. ANA Marketing Maestros: Data Is the New Oil. Retrieved January 5, 2023, from https://ana.blogs.com/maestros/2006/11/data\_is\_the\_new.html

Jones, M., Bradley, J., &amp; Sakimura, N. (2015, May). RFC 7519: JSON Web Token (JWT). RFC 7519: JSON Web Token (JWT). Retrieved January 9, 2023, from https://www.rfc-editor.org/rfc/rfc7519

JWT.IO. (n.d.). JSON Web Tokens – jwt.io. Retrieved January 10, 2023, from http://jwt.io/

Peyrott. (2018). JWT Handbook. Auth0 Inc. https://auth0.com/resources/ebooks/jwt-handbook

Barnes, R. (2014, April). RFC 7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). RFC 7165: Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). Retrieved January 11, 2023, from https://www.rfc-editor.org/rfc/rfc7165

# MSA 서비스는 어떤 단위로 어떤 기준으로 ?

MSA 서비스는 어떤 단위로 어떤 기준으로 ?

# DBMS도 나누어야 하나요 ?

DBMS는 어떻게 나누어야 하나요 ? 정합성의 문제는 어떻게 해야 하나요 ?

[![image.png](http://web.joang.com:8083/uploads/images/gallery/2023-10/scaled-1680-/3I6image.png)](http://web.joang.com:8083/uploads/images/gallery/2023-10/3I6image.png)