📖 14. JWT & API

📖 JWT & API

🚀 1. JWT(JSON Web Token)의 정의

• JWT는 유저를 인증하고 식별하기 위한 토큰(Token) 기반 인증이다. RFC 7519에 자세한 명세가 나와있다.

• 토큰은 세션과는 달리 서버가 아닌 클라이언트에 저장되기 떄문에 메모리나 스토리지 등을 통해 세션을 관리했던 서버의 부담을 덜 수 있다.

• JWT가 가지는 핵심적인 특징이 있다면, 토큰 자체의 사용자의 권한 정보나 서비스를 사용하기 위한 정보가 포함(Self-contained)된다는 것이다.

• 데이터가 많아지면 토큰이 커질 수 있으며 토큰이 한 번 발급된 이후 사용자의 정보를 바꾸더라도 토큰을 재발급하지 않는 이상 반영되지 않는다.

• JWT를 사용하면 RESTful과 같은 무상태(Stateless)인 환경에서 사용자 데이터를 주고 받을 수 있게된다.

• 세션(Session)을 사용하게 될 경우에는 쿠키 등을 통해 식별하고 서버에 세션을 저장했지만 JWT와 같은 토큰을 클라이언트에 저장하고 욫어시 단순히 HTTP 헤더에 토큰을 첨부하는 것만으로도 단순하게 데이터를 요청하고 응답을 받아올 수 있다.

---

▶️ 일반적으로 JWT를 사용하면 아래와 같은 순서로 진행된다.

1. 클라이언트 사용자가 아이디, 패스워드를 통해 웹서비스 인증
2. 서버에서 서명된(Signed) JWT를 생성하여 클라이언트에 응답으로 돌려주기.
3. 클라이언트가 서버에 데이터를 추가적으로 요구할 때 JWT를 HTTP Header에 첨부.
4. 서버에서 클라이언트로부터 온 JWT 검증

   ---

• JWT는 JSON 데이터를 Base64 URL-safe Encode를 통해 인코딩하여 직렬화한 것이 포함되며 토큰 내부에는 위변조 방지를 위해 개인키를 통한 전자서명도 있다.

• 따라서 사용자가 JWT를 서버로 전송하면 서버는 서명을 검증하는 과정을 거치게 되며 검증이 완료되면 요청한 응답을 돌려준다.

=> Base64 URL-safe Encode는 일반적인 Base64 Encode에서 URL에서 오류없이 사용하도록 '+'. '/'를 각각 '-','_'로 표현한 것이다.

---

🚀 1-1. JWT(JSON Web Token)의 구조

• JWT의 구조는 Header, Payload, Signature로 구성된다.
  또한, 각 요소는 .으로 구분된다.

• Header에는 JWT에서 사용할 타입과 해시 알고리즘의 종류가 담겨있으며 Payload는 서버에서 첨부한 사용자 권한 정보와 데이터가 담겨있다.

• 마지막으로 Signature 에는 Header, Payload를 Base64 URL-safe Encode를 한 후 Header에 명시된 해시함수를 적용하고, 개인키(Private Key)로 서명한 전자서명이 담겨있다.

• 전자서명 알고리즘으로 타원 곡선 암호화(ECDSA)를 사용한다고 가정하면,

• 이를 JWT로 표현하려면, 다음과 같이 되는데, 위에서 만든 전자서명도 Base64 URL-safe Encode 로 처리해서 합쳐줄 필요가 있다.

• 여기서 만든 전자서명은 Header, Payload가 변조되었는지 확인하기 위해 사용되는 중요 정보이며 JWT를 신뢰할 수 있는 토큰으로 사용할 수 있는 근거가 된다.

• 전자 서명에는 비대칭 암호화 알고리즘을 사용하므로 암호화를 위한 키와 복호화를 위한 키가 다르다. 암호화(전자서명)에는 개인키를, 복호화(검증)에는 공개키를 사용한다.

---

🚀 1-2. JWT(JSON Web Token)의 장*단점

• JWT는 최근 웹서비스에서 범용적으로 사용되고 있으며 규격이 정해져있기 때문에 다양한 클라이언트(웹,모바일 등)에서 호환성이 뛰어나다.

• Payload가 많아지면 토큰이 커져서 서버의 부담이 갈 수 있다.

• 토큰이 재발급되기 전까지 사용자 정보가 갱신되더라도 적용되지 않는 문제가 있다.

• RESTful과 같은 무상태(Stateless)환경에서의 통신이 용이하고 사용하기 쉽다.

• 데이터를 자체적으로 가지고 있어서 데이터를 얻기위해 타 서비스에 다시 요청하는 횟수가 줄어들어 서버의 부담이 줄어들게 된다.

• 토큰의 만료시간이 있는 경우 만료시간까지는 강제적으로 만료시킬 수 없으므로 노출이 되어서는 안 되며 중보정보를 넣는 일은 없어야 한다.

---

🚀 2. API의 정의

• 정의 및 프로토콜 집합을 사용하여 두 소프트웨어 구성 요소가 서로 통신할 수 있게 하는 메커니즘입니다.

• 예를 들어, 기상청의 소프트웨어 시스템에는 일일 기상 데이터가 들어 있습니다. 휴대폰의 날씨 앱은 API를 통해 이 시스템과 "대화"하고 휴대폰에 매일 최신 날씨 정보를 표시합니다.

• API는 Application Programming Interface(애플리케이션 프로그램 인터페이스)의 줄임말입니다. API의 맥락에서 애플리케이션이라는 단어는 고유한 기능을 가진 모든 소프트웨어를 나타냅니다.

• 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있습니다. 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의합니다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있습니다.

---

🚀 2-1. API의 작동방식

• API 아키텍처는 일반적으로 클라이언트와 서버 측면에서 설명됩니다. 요청을 보내는 애플리케이션을 클라이언트라고 하고 응답을 보내는 애플리케이션을 서버라고 합니다.

• 따라서 날씨 예에서 기상청의 날씨 데이터베이스는 서버이고 모바일 앱은 클라이언트입니다.

• API가 생성된 시기와 이유에 따라 API는 네 가지 방식으로 작동할 수 있습니다.

---

▶️ SOAP API

• API는 단순 객체 접근 프로토콜을 사용합니다. 클라이언트와 서버는 XML을 사용하여 메시지를 교환합니다. 과거에 더 많이 사용되었으며 유연성이 떨어지는 API입니다.

▶️ RPC API

• 이 API를 원격 프로시저 호출이라고 합니다. 클라이언트가 서버에서 함수나 프로시저를 완료하면 서버가 출력을 클라이언트로 다시 전송합니다.

▶️ Websocket API

• JSON 객체를 사용하여 데이터를 전달하는 또 다른 최신 웹 API 개발입니다. WebSocket API는 클라이언트 앱과 서버 간의 양방향 통신을 지원합니다.

• 서버가 연결된 클라이언트에 콜백 메시지를 전송할 수 있어 REST API보다 효율적입니다.

▶️ REST API

• REST는 Representational State Transfer의 줄임말입니다. REST는 클라이언트가 서버 데이터에 액세스하는 데 사용할 수 있는 GET, PUT, DELETE 등의 함수 집합을 정의합니다. 클라이언트와 서버는 HTTP를 사용하여 데이터를 교환합니다.

• REST API의 주된 특징은 무상태입니다.
  무상태는 서버가 요청 간에 클라이언트 데이터를 저장하지 않음을 의미합니다.

• 서버에 대한 클라이언트 요청은 웹 사이트를 방문하기 위해 브라우저에 입력하는 URL과 유사합니다. 서버의 응답은 웹 페이지의 일반적인 그래픽 렌더링이 없는 일반 데이터입니다.

---

🚀 2-2. 웹 API란?

• 웹 API 또는 웹 서비스 API는 웹 서버와 웹 브라우저 간의 애플리케이션 처리 인터페이스입니다.

• 모든 웹 서비스는 API이지만 모든 API가 웹 서비스는 아닙니다. REST API는 위에서 설명한 표준 아키텍처 스타일을 사용하는 특수한 유형의 웹 API입니다.

• 역사적으로 API가 월드 와이드 웹 전에 만들어졌기 때문에 Java API, 서비스 API 등 API에 대한 다양한 용어가 존재합니다.

• 최신 웹 API는 REST API이며 용어는 서로 바꿔 사용할 수 있습니다.

🚀 2-3. REST API 사용시 이점

1. 통합
   API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용됩니다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라집니다. API를 사용하여 기존 코드를 활용할 수 있습니다.

2. 혁신
   새로운 앱의 등장으로 전체 산업이 바뀔 수 있습니다. 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 합니다. 전체 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행할 수 있습니다.

3. 확장
   API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공합니다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있습니다. 어느 기업이나 무료 또는 유료 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있습니다.

4. 유지 관리의 용이성
   API는 두 시스템 간의 게이트웨이 역할을 합니다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 합니다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않습니다.