HTTP(HyperText Transfer Protocol)

HTTP는 클라이언트와 서버가 서로 데이터를 주고받기 위해 사용되는 통신 규약이다.
클라이언트와 서버 간의 통신을 담당하며, 웹 브라우저와 웹 서버 간의 데이터 전송을 위해 주로 사용된다.

HTTP 특징

비연결성(Stateless)

• HTTP는 비연결성 프로토콜이다. 즉, 클라이언트와 서버 간의 각 요청은 독립적이며, 이전 요청과 상태를 공유하지 않는다. 예를 들어, 사용자가 한 페이지에서 다른 페이지로 이동할 때, 이전 페이지의 상태는 유지되지 않는다. 이로 인해 서버는 클라이언트의 각 요청을 별도로 처리한다.

무상태성(Stateless)

• HTTP는 무상태 프로토콜로, 각 요청 간의 상태를 유지하지 않는다. 즉, 각 HTTP 요청은 독립적이며, 서버는 이전 요청의 정보를 기억하지 않는다. 이를 해결하기 위해 쿠키나 세션과 같은 메커니즘이 사용된다.

표준 포트

• HTTP는 기본적으로 80번 포트를 사용한다 HTTPS(보안 HTTP)의 경우, 기본적으로 443번 포트를 사용한다.

HTTP 메시지 구조

• HTTP는 요청(Request)와 응답(Response)으로 이루어진 메시지를 사용한다.

• 요청 메시지: 클라이언트가 서버에 보내는 메시지로, 주로 메서드(GET, POST 등), URL, HTTP 버전, 헤더, 바디로 구성되어 있다.

• 응답 메시지: 서버가 클라이언트에 보내는 메시지로, 주로 상태 코드(예: 200, 404), HTTP 버전, 헤더, 바디로 구성된다.

Request-Response 모델

HTTP는 클라이언트가 요청을 보내고 서버가 응답을 반환하는 형태의 모델을 따른다. 클라이언트는 요청 메서드(GET, POST, PUT, DELETE 등)를 사용하여 원하는 동작을 서버에 전달하고, 서버는 상태 코드와 데이터를 포함한 응답을 반환한다.

URI(Uniform Resource Identifier)

HTTP는 리소스를 식별하기 위해 URI를 사용한다. 클라이언트는 URI를 통해 서버에 요청할 리소스를 지정한다. URI는 URL(Uniform Resource Locator)이라는 특정한 형태의 식별자로 표현된다.

HTTP 요청 메서드

HTTP는 다양한 요청 메서드를 통해 클라이언트가 서버에 수행할 작업을 정의고 있으며, 주요 메서드는 아래와 같다.

1. GET: 서버에서 리소스를 요청하고 주로 데이터를 가져오는 데 사용된다.

2. POST: 서버에 데이터를 전송하여 리소스를 생성하거나 업데이트 한다.

3. PUT: 서버에 데이터를 보내 특정 리소스를 업데이트할 때 사용한다.

4. DELETE: 서버에서 특정 리소스를 삭제한다

5. HEAD: GET 요청과 동일하지만, 응답에 본문을 포함하지 않으며 리소스의 메타데이터만 요청할 때 사용한다.

6. OPTIONS: 서버에서 사용할 수 있는 HTTP 메서드를 확인한다.

7. PATCH: 리소스의 부분적인 업데이트를 수행한다.

HTTP 상태 코드

HTTP 상태 코드는 클라이언트의 요청에 대한 서버의 응답 상태를 나타내며, 주요 상태 코드는 아래와 같다.

1. 1xx (정보): 요청을 받았으며 처리가 진행 중.

2. 2xx (성공): 요청이 성공적으로 처리된 경우

• 200 OK: 요청이 성공적으로 처리됨.

• 201 Created: 요청이 성공적으로 처리되었으며, 리소스가 생성됨.

3. 3xx (리다이렉션): 클라이언트는 요청을 완료하기 위해 추가적인 작업이 필요함.

• 301 Moved Permanently: 요청된 리소스가 영구적으로 이동됨.

• 302 Found: 요청된 리소스가 임시적으로 다른 위치에 있는 경우.

4. 4xx (클라이언트 오류): 클라이언트의 요청에 오류가 있는 경우

• 400 Bad Request: 잘못된 요청.

• 401 Unauthorized: 인증 필요.

• 403 Forbidden: 요청된 리소스에 접근할 권한이 없음.

• 404 Not Found: 요청된 리소스를 찾을 수 없음.

5. 5xx (서버 오류): 서버가 요청을 처리하는 도중 오류가 발생.

• 500 Internal Server Error: 서버 내부 오류.

• 503 Service Unavailable: 서버가 현재 요청을 처리할 수 없음.

HTTP 버전

1. HTTP/0.9: 초기 버전으로, 단순 텍스트만 데이터로 전송함.

2. HTTP/1.0: 첫 번째 공식 버전으로, 메타데이터를 포함한 메시지 헤더 도입.

3. HTTP/1.1: 가장 널리 사용되는 버전으로, 연결 지속(Keep-Alive) 및 파이프라이닝 기능 추가.

4. HTTP/2: 성능 개선을 위해 멀티플렉싱, 헤더 압축, 서버 푸시 등의 기능이 추가됨,.

5. HTTP/3: HTTP/2의 문제점을 해결하고, QUIC 프로토콜을 사용하여 성능을 크게 개선한 최신 버전.

HTTPS (HTTP Secure)

HTTPS는 HTTP에 SSL/TLS 프로토콜을 추가하여 데이터를 암호화하여 전송하는 방식이다. 이를 통해 데이터를 안전하게 전송할 수 있으며, 특히 금융 거래나 개인 정보가 포함된 통신에서 널리 사용된다.

서버리스 (Serverless)란 무엇인가

서버리스란 Server + Less의 합성어로 직역하면 서버가 없다는 의미이다. 하지만 실제로 서버가 없지는 않다. 우리가 직접 관리하는 서버가 없을 뿐, 인프라를 프로비저닝하거나 관리할 필요 없이 클라우드 업체가 제공하는 컴퓨팅 모델이다.

서버리스의 탄생

기존의 서버

기존의 서버는 하드웨어와 소프트웨어를 같이 관리해야했다. 회사를 기준으로 보면 회사내의 공간에 서버를 직접 구매해서 인터넷을 연결한 후 관리해야 했으며, 이러한 경우 자연재해나 정전등 여러 변수들에 의해서 서버가 꺼질 확률이 높았다. 또한 트래픽이 증가하면 직접 메모리등을 사서 서버에 꽂았어야 했다. 즉 과거의 서버는 전부를 수동으로 관리해야 했었다.

아마존의 등장

아마존은 EC2라는 서비스를 선보인다. EC2는 (Amazon Elastic Compute Cloud)를 뜻한다.

이전엔 집이나, 사무실등의 공간에 있어야 했던 서버를 아마존이 대신 운영해주는 서비스이다. 간단하게 최신 서버를 정전이나 자연재해등의 사고 없이 안전하게 제공하고, 관리해주는 서비스다. 또한 원하는 만큼 서버의 메모리등을 신천할 수 있다.

이러한 서비스는 아마존, 구글, 마이크로소프트 등 여러가지가 있다.

하지만 이러한 서비스들 역시 하드웨어만 제공할 뿐, 소프트웨어의 관리는 관리자가 직접 해야했다. 즉 업데이트, 보안, 장해회복, 데이터 백업등 여러가지 작업을 관리자가 해야한다.

서버리스

서버리스는 우리의 서버를 작은 함수단위로 쪼개고, 그 함수를 서비스에 업로드해둔다. 업로드된 함수들은 잠들어있으며, 요청이 들어오면 함수가 깨어나 작업을 수행한다. 이로인해 사용한만큼의 비용이 청구되며, 서버리스 서비스가 작업중이지 않을때는 비용이 청구되지 않는다.

또한 서버리스 서비스는 들어오는 트래픽에 따라 자동으로 확장된다. 

이러한 이유들로 인해 서버리스는 개발자가 코드업로드에만 신경쓰면 되며, 인프라 관리에 대한 걱정이 없다.  

서버리스 아키텍처

서버리스 아키텍처의 주요 구성 요소는 FaaS(Funcion as a Sevice) 와 BaaS(Backend as a Service) 두가지가 있다.

FaaS (Function as a Service)

FaaS는 서비스형 함수이다. FaaS는 서버리스의 하위 집합으로, 개발자가  개발한 애플리케이션의 개별 기능을 간단한 함수로 분해하고, 필요할 때만 실해하여 리소스를 효율적으로 사용할 수 있도록 한다.

대표적인 FaaS 플랫폼으로는 AWS Lambda, Google Cloud Functions, Microsoft Azure Functions 등이 있다.

BaaS (Backend as a Service)

BaaS (Backend as a Service)는 개발자가 애플리케이션을 개발할 때 백엔드 서비스를 관리할 필요 없이 사용할 수 있는 서비스이다.BaaS는 주로 모바일앱이나, 웹앱의 백엔드 구성 요소를 제공한다. 즉 인증, 데이터베이스, 파일스토리지, 사용자 관리등 의 기능을 제공한다.

BaaS를 사용하면 개발자는 서버를 관리 할 필요가 없다. 대표적인 BaaS 플랫폼으로는 Firebase, AWS Amplify, Backendless, Kinvey 등이 있다.

서버리스의 단점

서버리스는 몇가지 단점이 존재한다.

콜드 스타트

콜드 스타트란 서버리스의 함수가 깨어나는 시간을 말한다. 함수에 요청이 있어야만 함수가 실행된다. 함수가 실행되기 이전에 함수를 AWS가 꺠워야하고, 깨어나는 시간은 밀리초단위이지만 그 짧은 시간조차 중요한 서비스라면 서버리스는 좋지 않은 선택이 된다.

실행환경

일부 서버리스 플랫폼에서는 실행되는 코드에 대한 제약이 있다.

디버깅

서버리스 환경에선 애플리케이션의 실행 컨텍스트가 동적으로 변경될 수 있으며, 이로인해 로컬 환경에서 디버깅이 어려울 수 있다.

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!

ORM

ORM(Object Realational Mapping) 은 객체지향 언어와 관계형 데이터베이스 간의 데이터 변환을 도와주고 자동으로 매핑(연결) 해주는 프로그래밍 기법이다. 즉 객체지향언어의 Class를 RDBMS의 Table과 연결시켜 주는 것이다. 이를 통해 객체 지향 프로그래밍 언어와 데이터베이스 사이의 간극을 줄여준다.

• ORM 은 "객체로 연결을 해준다" 라는 의미를 가지고 있다. SQL 언어 대신 개발 언어로 데이터베이스에 접근할 수 있다. 
• SQL 쿼리를 작성하지 않아도 되며 어플리케이션 개발 언어의 일관성과 가독성을 높일 수 있다.

ORM의 장단점

장점

• 완벽한 객체지향적인 코드를 작성할 수 있다. ORM 을 이용하여 SQL문이 아닌 클래스의 메서드를 통해 데이터베이스를 조작하며 개발자가 객체 모델만 이용해서 프로그래밍을 하는 데 집중할 수 있으며, 선언물, 할당, 종료 같은 부수적인 코드작성이 사라지거나 줄어들며 코드의 가독성을 높일 수 있다.
• 재사용, 유지보수, 리팩토링에 용이하다. ORM 은 객체로 작성되어 있어 재활용할 수 있다.
• DBMS 종속성이 줄어든다. 객체간의 관계를 바탕으로 SQL문을 자동으로 생성사고, 객체의 자료형 타입까지 사용할 수 있기 때문에 RDBMS의 데이터 구조와 객체지향 모델 사이의 간격을 좁힐 수 있다. 

단점

• 대량의 데이터를 처리하는 경우 성능 문제가 발생할 수 있다.
• ORM은 모든 데이터베이스의 기능을 완벽하게 지원하지 않는다. 즉 일부 고급 데이터베이스 기능이나 복잡한 쿼리는 직접 SQL을 작성해야 한다.

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!

프론트엔드 성능 최적화

프론트엔드 성능 최적화란 웹사이트나 앱의 로딩 속도와 렌더링 품질을 개선시키는 과정이다. 프론트엔드 성능 최적화를 통해 사용자 경험을 향상시키고, 검색엔진 최적화(SEO)를 도모하고, 비용을 절감할 수 있다. 성능 최적화를 통해 사용자 경험을 개선시킬 수 있고, 이는 곧 페이지 이탈률을 줄이기도 한다.

FP, FCP, FMP, TTI, CLS, FID, TBT, LCP 

FP, FCP, FMP, TTI는 웹 페이지의 성능을 측정하는 지표들이다.

• FP (First Paint) : 페이지가 로드되기 시작하고 첫 번째 픽셀이 화면에 그려지는 시간을 나타낸다. FP를 개선하기 위해서는 렌더링을 차단하는 리소스(CSS, JS)를 최소화하고, CDN을 사용하고, 캐시 정책을 적용하는 등의 방법이 있다.
• FCP (First Contentful Paint) : 페이지가 로드되기 시작하고 텍스트나 이미지 등의 컨텐츠가 화면에 그려지는 시간이다. FCP를 개선하기 위해서는 FP와 비슷한 방법을 사용할 수 있으며, 추가적으로 이미지 최적화, 웹 폰트 로드 최적화, 코드 스플리팅 등의 방법이 있다.
• FMP (First Meaningful Paint) : 페이지가 로드되기 시작하고 사용자에게 의미있는 컨텐츠가 화면에 그려지는 시간을 나타낸다. FMP는 페이지의 주요 컨텐츠가 어떤 것인지에 따라 달라질 수 있으며, 정확하게 측정하기 어려운 지표이다. FMP를 개선하기 위해서는 FCP와 비슷한 방법을 사용할 수 있으며, 추가적으로 중요한 컨텐츠를 우선적으로 로드하고, 레이아웃 변화를 최소화하는 등의 방법이 있다.
• TTI (Time To Interactive) : 페이지가 로드되기 시작하고 사용자의 입력에 응답할 수 있는 상태가 되는 시간을 나타낸다. TTI를 개선하기 위해서는 JS의 실행 시간을 줄이고, 메인 스레드를 차단하는 작업을 분할하고, 웹 워커를 사용하는 방법이 있다.

 이 외에도 cls, fid, tbt, lcp등의 웹페이지 성능을 측정하는 지표들이 있다.

• CLS (Cumulative Layout Shift) : 페이지의 레이아웃이 로딩 과정에서 얼마나 변화하는지를 나타낸다. 레이아웃의 변화는 사용자의 입력에 의한 것이 아니라, 리소스의 로드나 스타일의 적용 등에 의한 것이며, CLS가 높으면 사용자의 경험을 저해하고, 잘못된 클릭을 유발할 수 있다. CLS를 개선하기 위해서는 이미지, 광고, 프레임 등의 요소에 크기를 명시하고, 동적으로 삽입되는 컨텐츠를 공간을 확보하고, 웹 폰트의 로딩을 최적화하는 등의 방법이 있다.
• FID (First Input Delay) : 페이지가 사용자의 입력에 응답하는데 걸리는 시간을 나타낸다. 입력은 클릭, 탭, 키보드 입력 등이 될 수 있다. FID가 높으면 페이지의 반응성이 떨어지고, 사용자의 만족도가 감소한다. FID를 개선하기 위해서는 자바스크립트의 실행 시간을 줄이고, 메인 스레드를 차단하는 작업을 분할하고, 웹 워커를 사용하는 등 TTI 개선 방법과 비슷하다.
• TBT (Total Blocking Time) : FCP와 TTI 사이에 메인 스레드가 사용자의 입력에 응답할 수 없는 시간의 총합을 나타낸다. 50ms를 초과하는 작업의 차단 시간을 계산한다. TBT는 FID와 비슷한 개념이지만, 실제 사용자의 입력이 없어도 측정할 수 있으며  FID와 비슷한 방법으로 개선하면 된다.
• LCP (Largest Contentful Paint) : 페이지의 주요 컨텐츠가 화면에 표시되는데 걸리는 시간을 나타낸다. 주요 컨텐츠는 텍스트나 이미지 등이 될 수 있으며, LCP가 높으면 유저는 페이지의 로딩 속도가 느리다고 인식한다. LCP를 개선하기 위해서는 리소스의 크기와 수를 최소화하고, 우선순위를 결정하고 순차적으로 로드하고, CDN을 사용하면 된다.

또한 유저는 optimized rendering과 같은 점차적으로 보이게 되는 화면을 더 빠르다고 인식한다.

로딩 성능

로딩 성능이란 서버에 있는 웹페이지와 기타 리소스(JS 등) 을 다운로드할 때의 성능이다. 로딩 성능을 개선하면 사용자가 원하는 콘텐츠를 빠르게 보여줄 수 있다.

로딩 성능을 개선하는 방법은 다운로드해야하는 리소스의 크기와 요청 횟수를 줄이고, 우선순위에 따라 순차적으로 로드하는 방법 등이 있다. 로딩성능 최적화를 통해 웹페이지의 로딩 시간을 단축하고 사용자 대기시간을 줄일 수 있다. 이는 이탈률에 직접적으로 영향을 끼친다.

• 리소스의 크기와 수를 최소화 :
  • 웹페이지에서 사용되는 리소스(HTML, CSS, JS)크기를 줄이기 위해 압축, 미니파이(minify), 난독화, 지연로딩, 이미지 최적화 등의 방법을 사용한다.
  • 웹페이지에서 사용되는 리소스의 수를 줄이기 위해 코드 분할, 번들링, 스프라이트 이미지, 인라인 리소스 등의 방법을 사용한다. (인라인 리소스는 파일 요청 및 로드시간을 줄여주지만 코드품질을 저하시키기에 지양한다)

• 리소스의 우선순위 결정 및 순차적 로드 : 웹 페이지에 사용되는 모든 리소스는 동일한 중요도를 갖지 않는다. css는 레이아웃과 스타일을 결정하기에 JS 보다 높은 우선순위에 들어간다. 또한 유저가 처음 보는 화면에 필요한 리소스는 나중에 보게 될 화면의 리소스보다 높은 우선순위를 갖는다.
  • react helmet, webpack preload, prefetch 설정등을 통해 우선순위를 정한다.
  • webpack 설정, react-async-script-loader 라이브러리등을 사용하여 JS 우선순위를 정한다.
• CDN(Content Delivery Network) 사용 : CDN은 전세계에 분산된 서버 네트워크이며 사용자와 가장 가까운 서버에서 웹페이지 리소스를 제공한다.

렌더링 성능

렌더링 성능이란 웹페이지의 DOM, CSSOM, JS 등을 효율적으로 처리하고, 브라우저 레이아웃, 페인팅 등을 최소화하는 방법이다. 렌더링 성능이 향상되면 웹 페이지의 반응성을 높일 수 있다.

• DOM 조작 최소화 : DOM 조작은 필요한 경우에만 해야 하며, 한 번에 여러 개의 변경 사항을 같이 적용하고, Virture DOM이나 프레임워크등을 사용해 최소화시켜야 한다.
• CSS 애니메이션 사용 : CSS 속성 중 transfomr, opacity 속성은 CPU에서 동작하므로 CPU의 부하를 줄일 수 있다. layout과 paint를 발생시키는 속성은 피하는 것이 좋다.
• Reflow와 Repaint 방지 : 
  • Reflow는 브라우저가 웹 페이지의 요소들의 크기와 위치를 계산하는 과정이다.
  • Repaint는 브라우저가 웹 페이지 요소들의 색상, 스타일, 텍스트 등을 그리는 과정이다.
  • Reflow와 Repaint는 웹페이지 성능에 큰 영향을 미친다. 요소의 크기와 위치를 고정하고, 불필요한 스타일 변경을 피해야 한다.

Lighthoust

Lighthouse는 웹 페이지의 품질을 개선하기 위해 구글에서 제공하는 자동화 도구이다. Lighthouse는 성능, 접근성, SEO 등에 대한 전반적인 진단을 해준다. 

페이지 로드 분석을 클릭 후 성능(performance)을 보면 해당 페이지의 성능이 측정되어 있다.

Lighthouse는 속도 점수와 FCP, LCP, TBT, CLS 등의 다양한 지표를 표시한다.

Lighthouse로 웹페이지의 성능을 측정하고, 해당 부분에 대한 로직 수정, CDN 사용, 리소스 최소화 등을 통해 성능 최적화를 하면 된다.

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!

구글 OAuth 2.0 사용 준비

구글 OAuth 인가를 받으려면 OAuth  클라이언트 ID와 비밀번호가 필요하다. 이를 위해서 3가지 절차가 필요하다.

1. 구글 클라우드 프로젝트 생성
2. OAuth  동의 화면 생성
3. 클라이언트 ID 생성

새 프로젝트 생성

새 프로젝트 클릭.

프로젝트 이름 입력하고 만들기 클릭.

OAuth 동의 화면 만들기

OAuth 동의 화면 클릭

외부 클릭 후 만들기 클릭

필수 요소인 앱 이름, 사용자 지원 이메일, 개발자 연락처 정보만 입력.

OAuth 클라이언트 ID, 비밀번호 만들기

사용자 인증 정보 클릭

OAuth 클라이언트 ID 클릭

승인된 자바스크립트 원본 에는 서버 주소를 입력.

승인된 리디렉션 URI에 구글 인증 후 리디렉션 할 URL 을 입력

이후 생성된 ID와 비밀번호는 유출되선 절대 안된다. 조심하자

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!

JWT란?

JWT 란 JSON Web Token 의 약자로 말 그대로 웹에서 사용되는 JSON 형식의 토큰에 대한 표준 규격이다. 정보를 안전하게 전송하기 위한 토큰 형식이다. JWT 는 자가 수용적(Self-contained)이다. 자가 수용적이란 토큰 자체에 필요한 모든 정보가 담겨 있어 별도의 저장소가 필요하지 않다는 의미이다. JWT는 JSON 객체를 사용하여 정보를 저장하고 디지털 서명을 통해 검증한다

JWT 토큰은 주로 인증과 정보교환에 사용된다.

인증(Authentication) :  사용자가 로그인하면, 서버는 사용자의 정보를 담은 JWT 토큰을 발급한다. 사용자는 이 토큰을 쿠키나 로컬 스토리지에 저장하고, 서버에 요청할 때마다 토큰을 함께 보낸다. 서버는 토큰을 검증하여 사용자를 인증한다.

정보 교환(Information Exchange) : 두 개체가 안전하게 정보를 주고받을 수 있다. 토큰에 담긴 정보는 디지털 서명에 의해 보호되므로, 정보의 신뢰성을 보장할 수 있다.

웹에서 Authorization HTTP 헤더를 Bearer <JWT토큰> 의 형태로 설정하여 클라이언트에서 서버로 전송된다. 서버에서는 받은 JWT 토큰에 서명확인은 통해서 위변조 여부를 검증한다.

JWT 구조

JWT 토큰은 헤더(header), 페이로드(payload), 서명(signature) 이렇게 세 부분으로 이루어져 있다. JWT 는 네트워크에서 전송이 되어야 하기 때문에 용량을 적게 차지하는 것이 좋기에 JSON key를 3글자로 줄여뒀다.

header

JWT의 유형(typ) 및 사용하는 암호화 알고리즘(alg) 등에 대한 정보를 포함한다. 또한 헤더는 Base64 로 인코딩되어 있다.

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

위는 헤더의 알고리즘은 HMAC SHA-256 을 사용했고, 타입은 JWT라는 것을 보여준다

payload

JWT 에서 payload는 실제로 전달하고자 하는 정보를 포함하고 있다. 예를 들어 사용자의 ID, 이름, 닉네임 등이 포함될 수 있다. 여기에 담긴 정보단위를 클레임(claim)이라고 하며, key / name 한 쌍으로 이루어져 있다. 토큰에는 여러 개의 클레임을 넣을 수 있으며 주로 발급자, 만료시간, 사용자 식별자 등의 정보나, 사용자의 권한, 역할, 선호도 등과 같은 사용자에 관한 정보를 담는다.

클레임은 세가지로 이루어져 있다.

• Registered Claims ( 등록된 클레임)
• Public Claims(공개 클레임)
• Private Claims(비공개 클레임)

Registered Claims(등록된 클레임)

토큰에 대한 정보를 표현하기 위해 미리 정의된 클레임이다. 등록된 클레임은 토큰의 기본적인 정보를 제공하고, 토큰의 유효성 검사에 사용될 수 있다

• iss (Issuer): 토큰 발급자를 나타낸다. 보통은 토큰을 발급한 서버의 도메인이나 식별자이다. 
• sub (Subject): 토큰의 주제를 나타낸다. 주로 토큰을 발급받는 사용자의 식별자나 ID이다. 
• aud (Audience): 토큰의 대상(받는 사람)을 나타낸다. 토큰이 발행되는 서비스나 애플리케이션을 나타내는 보통의 문자열이 될 수 있다. 
• exp (Expiration Time): 토큰의 만료 시간을 나타낸다. 이 시간 이후에는 토큰이 더 이상 유효하지 않다. 
• nbf (Not Before): 토큰이 사용될 수 있는 시간을 나타낸다. 이 시간 이전에는 토큰을 사용할 수 없다. 
• iat (Issued At): 토큰이 발급된 시간을 나타낸다. 
• jti (JWT ID): JWT의 고유 식별자를 나타낸다. 토큰의 중복 사용을 방지하기 위해 사용될 수 있다.

Public Claims(공개 클레임)

Public Claims(공개 클레임)은 JWT의 페이로드에 포함되는 사용자 정의 클레임이다. 공개된 클레임은 충돌을 방지하기 위해 URI 형식으로 이름을 지정해야 한다

{
	"https://doppelgoer.tistory.com" : true
 }

Private Claims(비공개 클레임)

비공개 클레임은 사용자가 직접 정의하는 클레임이다. 비공개 클레임을 사용해서 사용자의 권한등을 추가할 수 있다.

signature

JWT의 서명은 JWT의 무결성을 보장하고, 변조를 방지하기 위한 부분이다. 헤더와 페이로드를 base64 로 인코딩하고, 비밀키나 공개키/비밀키 쌍을 사용하여 암호화 한 값이다.

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!

OAuth 소개

OAuth는 Open Authorization의 약자이며 2006년에 구글과 트위터가 만들 개방형 인가의 표준이다.

많은 사이트에서 네이버, 구글, 페이스북등의 소셜 로그인을 지원하는 경우가 많다. 이때 인증을 구현하기 위해 OAuth를

인증과 인가의 차이

OAuth 는 1.0, 2.0, 2.1 세 가지 버전이 있으며, 2.0 버전이 가장 많이 사용된다.

OAuth 용어

• 인증 : 리소스에 접근 자격이 있는지 검증하는 과정.
• 인가: 자원에 접근할 권한을 부여하는 과정. 인가가 완료되면 리소스의 접근 권한 정보가 있는 액세스 토큰을 클라이언트에게 보내준다.
• 액세스 토큰: 리소스 서버에서 리소스 소유자의 보호된 정보를 획득할 때 사용하는 만료 기간 이 있는 토큰이다.
• 리프레시 토큰 : 액세스 토큰이 만료되었을 때 갱신하는 용도로 사용하는 토큰이며 액세스 토큰보다 만료 기간을 길게 가져간다.
• 리소스 소유자 : 리소스는 사용자의 보호된 정보를 말하며 이런 정보에 접근하도록 자격을 부여하는 사람을 말한다. 즉 'OAuth에서는 사용자가 리소스 소유자다'라고 생각하면 된다
• 클라이언트 : 리소스를 사용하려고 접근을 요청하는 애플리케이션을 의미한다.
• 리소스 서버 : 사용자의 보호된 자원을 가지고 있는 서버.
• 인가 서버 : 인증/인가를 수행하는 서버로 클라이언트의 접근 자격을 확인하고 액세스 토큰을 발급해 권한을 부여한다.

OAuth 프로토콜의 흐름

1. 클라이언트가 리소스 소유자에게 권한 부여를 요청. 
2. 클라이언트에게 권한을 부여.
3. 클라이언트는 2에서 받은 정보를 통해 액세스 토큰을 인가 서버에 요구.
4. 인가 서버에서는 클라이언트를 인증하고 유효성 검사를 진행하며, 유효한 경우 액세스 토큰을 발급함.
5. 클라이언트가 리소스 서버에 보호된 리소스를 요청. 요청 시에는 액세스 토큰을 사용 함.
6. 리소스 서버는 액세스 토큰의 유효성을 검사하고 유효한 경우 보호된 자원 정보를 보내준다.

액세스 토큰 재발행하는 흐름

1. 클라이언트는 인가 서버에 인증을 하고 액세스 토큰을 요청
2. 인가서버는 클라이언트를 인증하고 유효성 검증을 한 후에 문제가 없으면 액세스 토큰과 리프레시 토큰을 발급.
3. 클라이언트가 리소스 서버에 액세스 토큰을 보내면서 보호된 리소스를 요청
4. 리소스 서버가 액세스 토큰의 유효성을 검증하고 유효한 경우 리소스를 내려준다. 3과 4 단계는 액세스 토큰이 만료될 때까지 반복.
5. 액세스 토큰 만료 시에도 클라이언트는 액세스 토큰을 리소 스 서버에 전달하는 경우도 있음. 클라이언트가 액세스 토큰이 만료된 것을 알고 있다면 7로 가게 되고, 모른다면 만료된 액세스 토큰을 전달한다.
6. 리소스 서버에서는 액세스 토큰이 만료되었으 므로 잘못된 토큰 에러를 발생시킨다.
7. 클라이언트에서는 액세스 토큰이 만료되어 에러가 발생했으므로 리프레시 토큰을 인가 서버로 전달해 새 액세스 토큰을 요청.
8. 인가 서버는 리프레시 토큰이 유효한 경우 새로운 액세스 토큰을 발급해 준다. 이 때 리프레시 토큰의 재발급은 선택적이다.

개인 기록용입니다. 만약 잘못된 부분이 있다면 댓글로 알려주신다면 감사하겠습니다!