2. HTTP

■ 1. 인터넷 네트워크

■ 1.1 인터넷 통신의 원리

• 인터넷에서 두 컴퓨터 간의 통신은 클라이언트-서버 모델을 사용합니다.

• 클라이언트가 요청을 보내고, 서버가 이를 처리하여 응답을 반환하는 구조입니다.

■ 1.2 IP(Internet Protocol)

• IP 주소는 인터넷에서 각 기기를 식별하는 주소입니다.

• IP 프로토콜은 데이터를 지정된 IP 주소로 전달하는 역할을 합니다.

• IP 패킷은 출발지 IP, 목적지 IP, 전송 데이터를 포함하며, 이를 통해 데이터를 전달합니다.

■ 1.3 프로토콜의 한계

• 비연결성: 대상이 패킷을 받을 수 없는 상태여도 패킷이 전송됩니다.

• 비신뢰성: 패킷이 도중에 사라지거나 순서가 바뀌어 도착할 수 있습니다.

• 프로그램 구분의 어려움: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상일 때, 구분하기 어렵습니다.

■ 1.4 TCP/UDP

• TCP (Transmission Control Protocol):
• 연결 지향적이며 데이터 전달 보증과 순서 보장을 제공하는 신뢰할 수 있는 프로토콜
• 주로 사용되는 프로토콜이며, TCP 3-way handshake로 연결을 설정

• UDP (User Datagram Protocol):
• 비연결성, 비신뢰성 프로토콜로 TCP보다 빠르지만, 데이터 전달과 순서 보장이 없습니다.

■ 1.5 PORT

• IP 주소가 인터넷에서 컴퓨터를 식별한다면, 포트는 해당 컴퓨터 내에서 어떤 프로그램이 데이터를 받는지를 식별합니다.

• 포트 번호는 0부터 65535까지 할당될 수 있으며, 0~1023은 잘 알려진 포트로 특정 서비스에 예약되어 있습니다. (예: HTTP는 80번 포트)

■ 1.6 DNS (Domain Name System)

• IP 주소는 기억하기 어렵고, 변경될 수 있기 때문에, DNS를 사용해 사람이 이해할 수 있는 도메인 이름을 IP 주소로 변환합니다.

■ 2. URI와 웹 브라우저 요청 흐름

■ 2.1 URI (Uniform Resource Identifier)

• URI는 웹에서 리소스를 식별하기 위한 통일된 방법입니다. URI는 URL과 URN으로 구분될 수 있습니다.
• URL (Uniform Resource Locator): 리소스의 위치를 지정하는 URI의 한 종류입니다.
• URN (Uniform Resource Name): 리소스의 이름을 부여하는 URI의 한 종류입니다.

■ 2.2 URL의 구성

scheme://[userinfo@]host[:port][/path][?query][#fragment]

• scheme: 프로토콜(예: http, https)

• host: 도메인 이름이나 IP 주소

• port: 통신에 사용되는 포트 번호

• path: 리소스의 경로

• query: 추가적인 데이터 전달에 사용되는 쿼리 파라미터

• fragment: 특정 문서 내의 위치를 지정하는 데 사용

■ 2.3 웹 브라우저 요청 흐름

• 단계별 흐름:
• 1단계: 사용자가 URL을 입력
• 2단계: DNS를 통해 IP 주소를 조회
• 3단계: HTTP 요청 메시지를 생성하여 서버에 전송
• 4단계: 서버가 HTTP 응답 메시지를 클라이언트에 반환
• 5단계: 클라이언트가 응답 데이터를 처리하여 화면에 출력

■ 3. HTTP (HyperText Transfer Protocol)

■ 3.1 HTTP의 특징

• 클라이언트-서버 구조: 클라이언트는 서버에 요청을 보내고, 서버는 이에 대한 응답을 반환합니다.

• 무상태 프로토콜: HTTP는 상태를 유지하지 않기 때문에, 각각의 요청은 독립적입니다.

• 비연결성: 요청-응답이 끝나면 연결이 종료되어 서버 자원을 효율적으로 사용할 수 있습니다.

■ 3.2 HTTP 메시지 구조

• 요청 메시지: 클라이언트가 서버에 보내는 메시지로, 메서드(GET, POST 등), 요청 대상, HTTP 버전, 헤더, 본문으로 구성됩니다.

• 응답 메시지: 서버가 클라이언트에 보내는 메시지로, 상태 코드(200, 404 등), HTTP 버전, 헤더, 본문으로 구성됩니다.

■ 4. HTTP 메서드

■ 4.1 GET 메서드

• 서버에서 리소스를 조회할 때 사용됩니다. 데이터 전달은 URL의 쿼리 파라미터를 통해 이루어집니다.
• GET 요청은 서버에서 리소스를 조회할 때 사용됩니다. 쿼리 파라미터를 통해 서버에 필요한 정보를 전달할 수 있습니다.
 

■ 4.2 POST 메서드

• 서버로 데이터를 전송하여 리소스를 생성하거나, 서버에서 특정 작업을 수행할 때 사용됩니다.
• POST 요청은 주로 서버에서 새 리소스를 생성하거나, 데이터를 처리할 때 사용됩니다.

■ 4.2 PUT 메서드

• 지정된 리소스를 생성하거나, 기존 리소스를 대체할 때 사용됩니다.
• PUT 요청은 지정된 리소스를 생성하거나, 리소스를 완전히 대체할 때 사용됩니다.
• 기존 리소스가 있을 경우 덮어쓰고, 없을 경우 새로 생성합니다.

■ 4.2 PATCH 메서드

• 리소스의 일부를 수정할 때 사용됩니다.
• PATCH 요청은 리소스의 일부분을 수정할 때 사용됩니다.
 

■ 4.2 DELETE 메서드

• 서버에서 리소스를 삭제할 때 사용됩니다.
• DELETE 요청은 서버에서 리소스를 삭제할 때 사용됩니다.

■ 5. HTTP 메서드의 속성

■ 5.1 안전 (Safe Methods)

• 안전한 메서드는 서버의 상태를 변경하지 않는 메서드를 의미합니다. 예를 들어, GET 메서드는 리소스 조회에 사용되며, 서버의 상태를 변경하지 않으므로 안전합니다.

■ 5.2 멱등 (Idempotent Methods)

• 예: PUT, DELETE, GET 메서드는 멱등성을 갖습니다. 동일한 요청을 여러 번 보내더라도 서버의 상태는 처음 요청과 동일하게 유지됩니다.

• POST 메서드는 멱등성이 없으므로, 동일한 요청을 여러 번 수행할 경우 중복된 데이터 생성 등이 발생할 수 있습니다.

■ 5.3 캐시 가능 (Cacheable Methods)

• 예: GET 메서드는 응답 결과를 캐시할 수 있으며, HEAD, POST, PATCH도 캐시 가능합니다. 하지만, POST와 PATCH는 캐시하기 위해서는 본문 내용까지 고려해야 하기 때문에 일반적으로 GET만 캐시로 사용됩니다.

■ 6. 클라이언트에서 서버로 데이터 전송

■ 6.1 데이터 전송 방식

• 클라이언트가 서버로 데이터를 전송하는 방식은 크게 두 가지로 나눌 수 있습니다:
• 쿼리 파라미터를 통한 데이터 전송
• 주로 GET 메서드에서 사용되며, URL에 포함된 쿼리 스트링을 통해 데이터를 전달합니다.
• 메시지 바디를 통한 데이터 전송
• POST, PUT, PATCH 메서드에서 사용되며, 본문에 데이터를 담아 서버로 전송합니다.

■ 6.2 전송 상황별 예시

• 정적 데이터 조회:
• 주로 이미지나 텍스트 문서와 같은 정적 리소스를 조회할 때 사용됩니다.
• GET 메서드로 단순히 리소스 경로를 요청합니다.

• 동적 데이터 조회:
• 검색이나 필터링된 결과를 얻을 때 쿼리 파라미터를 사용해 GET 요청을 보냅니다.

• HTML Form 데이터 전송:
• 사용자가 웹 폼에 입력한 데이터를 서버로 전송할 때 사용되며,
• 주로 POST 메서드를 사용합니다.

■ 7. HTTP 상태 코드

■ 7.1 1xx (Informational) - 요청이 수신되어 처리 중

• 거의 사용되지 않음: 이 상태 코드는 거의 사용되지 않으므로 일반적으로 생략됩니다.

■ 7.2 2xx (Successful) - 요청 정상 처리

• 200 OK: 요청이 성공적으로 처리되었습니다.

• 201 Created: 요청이 성공적으로 처리되었으며, 새로운 리소스가 생성되었습니다.

• 202 Accepted: 요청이 접수되었지만 처리가 완료되지 않았습니다.

• 204 No Content: 요청이 성공적으로 처리되었지만, 응답 본문에 보낼 데이터가 없습니다.

■ 7.3 3xx (Redirection) - 요청을 완료하기 위해 추가 조치 필요

3xx (Redirection) - 요청을 완료하기 위해 추가 조치 필요

• 301 Moved Permanently: 리소스의 URI가 영구적으로 이동되었습니다. 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있습니다.

• 302 Found: 리소스의 URI가 일시적으로 변경되었습니다. 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있습니다.

• 303 See Other: 요청 메서드가 GET으로 변경되어 리다이렉트됩니다.

• 304 Not Modified: 클라이언트에게 리소스가 수정되지 않았음을 알려줍니다. 클라이언트는 로컬 캐시를 사용합니다.

• 307 Temporary Redirect: 리소스의 URI가 일시적으로 변경되었으며, 요청 메서드와 본문이 유지됩니다.

• 308 Permanent Redirect: 리소스의 URI가 영구적으로 변경되었으며, 요청 메서드와 본문이 유지됩니다.

■ 7.4 4xx (Client Error) - 클라이언트 오류

4xx (Client Error) - 클라이언트 오류

• 400 Bad Request: 클라이언트의 요청이 잘못되었거나 문법 오류가 있습니다.

• 401 Unauthorized: 해당 리소스에 대한 인증이 필요합니다.

• 403 Forbidden: 서버가 요청을 이해했지만 승인을 거부했습니다.

• 404 Not Found: 요청한 리소스를 찾을 수 없습니다.

■ 7.5 5xx (Server Error) - 서버 오류

5xx (Server Error) - 서버 오류

• 500 Internal Server Error: 서버 내부에서 오류가 발생했습니다.

• 503 Service Unavailable: 서버가 일시적으로 과부하 상태이거나, 예정된 작업으로 인해 요청을 처리할 수 없습니다.

■ 8. HTTP 헤더

■ 8.1 HTTP 헤더 개요

• 일반 헤더: 클라이언트와 서버 모두 사용 가능한 헤더.

• 요청 헤더: 클라이언트에서 서버로 요청할 때 사용되는 헤더.

• 응답 헤더: 서버에서 클라이언트로 응답할 때 사용되는 헤더.

• 엔티티 헤더: 전송되는 데이터에 대한 정보를 제공하는 헤더.

■ 9. HTTP 헤더 - 일반 헤더

■ 9.1 Host

• Host 헤더는 HTTP/1.1에서 필수적으로 사용되는 헤더로, 요청하는 호스트와 포트를 명시합니다.
• 예: Host: www.example.com

■ 9.2 User-Agent

• User-Agent 헤더는 클라이언트 애플리케이션(주로 웹 브라우저)의 정보를 서버에 전달합니다.
• 예: User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

■ 9.3 Content-Type

• Content-Type 헤더는 메시지 본문에 포함된 데이터의 미디어 타입을 명시합니다.
• 예: Content-Type: application/json

■ 9.4 Content-Length

• Content-Length 헤더는 메시지 본문의 길이를 바이트 단위로 명시합니다.
• 예: Content-Length: 348

■ 9.5 Authorization

• Authorization 헤더는 클라이언트가 서버로부터 인증을 받을 때 사용됩니다.
• 예: Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

■ 9.6 Accept

• Accept 헤더는 클라이언트가 서버로부터 받을 수 있는 미디어 타입을 명시합니다.
• 예: Accept: text/html
 

■ 9.7 Accept-Encoding

• Accept-Encoding 헤더는 클라이언트가 지원하는 콘텐츠 인코딩 방식을 명시합니다.
• 예: Accept-Encoding: gzip, deflate
 

■ 9.8 Accept-Language

• Accept-Language 헤더는 클라이언트가 선호하는 언어를 서버에 전달합니다.
• 예: Accept-Language: en-US,en;q=0.9,ko;q=0.8
 

■ 9.9 Cache-Control

• Cache-Control 헤더는 클라이언트와 서버 간의 캐시 동작을 제어합니다.
• 예: Cache-Control: no-cache
 

■ 9.10 Cookie

• Cookie 헤더는 클라이언트가 서버에 이전에 저장된 쿠키 데이터를 전달하는 데 사용됩니다.
• 예: Cookie: sessionId=abc123
 
 

■ 10. HTTP 헤더 - 요청 헤더

■ 10.1 Referer

• Referer 헤더는 현재 요청이 발생한 이전 페이지의 URL을 명시합니다.
• 예: Referer: https://www.example.com/previous-page

■ 10.2 Connection

• Connection 헤더는 클라이언트와 서버 간의 연결 방식(유지, 종료)을 명시합니다.
• 예: Connection: keep-alive

■ 10.3 Upgrade-Insecure-Requests

• Upgrade-Insecure-Requests 헤더는 클라이언트가 HTTP 요청을 HTTPS로 업그레이드할 것을 서버에 요청합니다.
• 예: Upgrade-Insecure-Requests: 1

■ 11. HTTP 헤더 - 응답 헤더

■ 11.1 Location

• Location 헤더는 리다이렉션을 수행할 URL을 명시합니다. 3xx 응답 코드와 함께 사용됩니다.
• 예: Location: https://www.example.com/new-location

■ 11.2 Server

• Server 헤더는 서버의 소프트웨어 정보를 클라이언트에 전달합니다.
• 예: Server: Apache/2.4.41 (Ubuntu)

■ 11.3 Set-Cookie

• Set-Cookie 헤더는 서버가 클라이언트에게 새로운 쿠키를 설정할 때 사용됩니다.
• 예: Set-Cookie: sessionId=abc123; Path=/; HttpOnly

■ 11.4 WWW-Authenticate

• WWW-Authenticate 헤더는 클라이언트에게 인증 방법을 제시합니다.
• 예: WWW-Authenticate: Basic realm="Access to the site"

■ 12. HTTP 헤더 - 엔티티 헤더

■ 12.1 Content-Encoding

• Content-Encoding 헤더는 메시지 본문의 인코딩 방식을 명시합니다. 이는 데이터 압축에 사용됩니다.
• 예: Content-Encoding: gzip

■ 12.2 Content-Language

• Content-Language 헤더는 메시지 본문의 언어를 명시합니다.
• 예: Content-Language: en-US

■ 12.3 Content-Location

• Content-Location 헤더는 요청된 리소스의 또 다른 위치를 명시합니다.
• 예: Content-Location: /index-en.html

■ 12.4 Content-Disposition

• Content-Disposition 헤더는 응답이 브라우저에서 어떻게 처리되어야 하는지(파일 다운로드, 인라인 디스플레이)를 명시합니다.
• 예: Content-Disposition: attachment; filename="filename.jpg"

■ 12.5 Content-Range

• Content-Range 헤더는 요청된 리소스의 특정 범위를 명시합니다.
• 예: Content-Range: bytes 200-1000/6758

■ 13. HTTP 캐시

■ 13.1 캐시의 기본 개념

• 캐시 무효화(Invalidation)
• 리소스가 변경되었을 때, 캐시된 데이터를 무효화하여 최신 데이터를 가져오도록 합니다.

■ 13.2 캐시 제어를 위한 HTTP 헤더

• Cache-Control: 캐시 동작을 제어하는 주요 헤더로, 다음과 같은 지시자를 사용할 수 있습니다.
• no-cache: 캐시된 데이터가 있어도 서버로부터 재검증을 요구합니다.
• no-store: 캐시를 사용하지 않고, 데이터를 저장하지 않습니다.
• max-age: 캐시된 데이터의 유효 기간을 초 단위로 설정합니다.
• must-revalidate: 캐시된 데이터의 유효 기간이 지나면, 서버로부터 재검증을 요구합니다.
• public: 응답이 모든 캐시에서 저장될 수 있음을 나타냅니다.
• private: 응답이 특정 사용자에 대해 저장되며, 공유 캐시에서는 저장되지 않습니다.
 

• ETag: 리소스의 고유한 식별자(해시)를 나타내며, 리소스가 변경되었는지 여부를 확인하는 데 사용됩니다.
• 예: ETag: "34a64df551429fcc55e0d9c5c9d937e0"
 

• Last-Modified: 리소스가 마지막으로 수정된 날짜와 시간을 나타냅니다.
• 예: Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
 

• Expires: 캐시된 데이터의 만료 날짜를 명시하며, 이 시간이 지나면 데이터를 새로 가져와야 합니다.
• 예: Expires: Thu, 01 Dec 1994 16:00:00 GMT

■ 13.3 조건부 요청

• If-Modified-Since
• Last-Modified 헤더와 함께 사용되며, 지정된 날짜 이후에 리소스가 변경된 경우에만 새 데이터를 요청합니다.
• 예: If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

• If-None-Match
• ETag 헤더와 함께 사용되며, 지정된 ETag와 리소스의 ETag가 다를 경우에만 새 데이터를 요청합니다.
• 예: If-None-Match: "34a64df551429fcc55e0d9c5c9d937e0"

■ 13.4 캐시 동작 방식

• 클라이언트는 요청을 보낼 때 If-Modified-Since 또는 If-None-Match 헤더를 사용하여 서버에 조건부 요청을 보냅니다.

• 서버는 리소스가 변경되지 않았으면 304 Not Modified 응답을 반환하여 클라이언트가 캐시된 데이터를 사용하도록 합니다.

• 서버는 리소스가 변경되었으면 새로운 데이터를 보내고, 클라이언트는 캐시를 업데이트합니다.

■ 14. HTTP/2와 HTTP/3

■ 14.1 HTTP/2

• HTTP/2는 HTTP/1.x의 단점을 개선하여 성능을 향상시키기 위한 프로토콜입니다.

• 주요 특징:
• 멀티플렉싱(Multiplexing): 하나의 연결에서 여러 요청과 응답을 동시에 처리할 수 있습니다.
• 헤더 압축: 헤더 데이터를 효율적으로 전송하기 위해 압축하여 전송합니다.
• 서버 푸시(Server Push): 클라이언트가 요청하지 않은 리소스도 서버에서 미리 전송할 수 있습니다.

■ 14.2 HTTP/3

• HTTP/3는 HTTP/2의 성능을 더 개선한 프로토콜로, UDP를 기반으로 하는 QUIC(Quick UDP Internet Connections)를 사용합니다.

• 주요 특징:
• 연결 설정 시간 단축: QUIC을 통해 연결 설정 시간이 크게 단축됩니다.
• 헤더 압축과 멀티플렉싱 기능을 유지하면서도 패킷 손실 시 지연을 줄이는 방식으로 동작합니다.
• TLS 1.3과 통합되어 보안성을 강화합니다.

■ 15. HTTPS

■ 15.1 HTTPS 개요

• HTTPS(Hypertext Transfer Protocol Secure)는 HTTP에 보안 기능을 추가한 프로토콜로, 데이터 전송 시 암호화되어 전달됩니다.

• TLS(Transport Layer Security)를 사용하여 통신 내용을 암호화하고, 데이터의 무결성과 기밀성을 보장합니다.

■ 15.2 HTTPS 동작 방식

• 클라이언트가 서버에 HTTPS 요청을 보내면, 서버는 인증서(Certificate)를 클라이언트에 제공합니다.

• 클라이언트는 서버의 인증서를 검증하고, 세션 키(Session Key)를 생성하여 서버와 공유합니다.

• 이후 모든 통신은 이 세션 키로 암호화되어 전송됩니다.

■ 15.3 HTTPS의 장점

• 데이터 암호화: 전송 중인 데이터를 암호화하여 중간에 도청되는 것을 방지합니다.

• 데이터 무결성: 데이터가 전송 중에 변경되지 않았음을 보장합니다.

• 인증: 서버의 신원을 인증하여 피싱 공격 등을 방지합니다.

■ 15.4 HTTPS의 단점

• 성능: 암호화 및 복호화 작업이 추가되므로, 성능에 약간의 영향을 미칠 수 있습니다.

• 복잡성: 인증서 관리와 설정이 추가적으로 필요합니다.

■ 16. CORS (Cross-Origin Resource Sharing)

■ 16.1 CORS 개요

• CORS는 웹 브라우저에서 발생하는 보안 메커니즘으로, 웹 페이지가 다른 도메인(origin)에서 리소스를 요청할 때 적용됩니다.

• 동일 출처 정책(Same-Origin Policy)은 보안상의 이유로, 브라우저가 다른 도메인에서 리소스를 요청할 때 제한을 가합니다.

• CORS는 이러한 제한을 완화하여 특정 조건 하에 다른 도메인에서 리소스를 요청할 수 있도록 허용합니다.

■ 16.2 CORS 동작 방식

• 클라이언트가 다른 도메인의 리소스를 요청할 때, 브라우저는 자동으로 Preflight Request라는 OPTIONS 요청을 서버에 보냅니다.

• 서버는 이 요청에 대해 Access-Control-Allow-Origin 헤더를 통해 허용된 도메인을 명시하여 응답합니다.

• 클라이언트가 서버의 응답을 확인하고, 허용된 경우에만 실제 요청을 서버에 보냅니다.

■ 16.3 CORS 관련 HTTP 헤더

• Access-Control-Allow-Origin: 서버가 리소스에 접근할 수 있도록 허용할 도메인을 명시합니다.
• 예: Access-Control-Allow-Origin: https://www.example.com

• Access-Control-Allow-Methods: 서버가 허용할 HTTP 메서드를 명시합니다.
• 예: Access-Control-Allow-Methods: GET, POST, PUT

• Access-Control-Allow-Headers: 서버가 허용할 HTTP 헤더를 명시합니다.
• 예: Access-Control-Allow-Headers: Content-Type

• Access-Control-Allow-Credentials: 서버가 자격 증명(Credentials, 예: 쿠키)을 허용하는지 여부를 명시합니다.
• 예: Access-Control-Allow-Credentials: true

• Access-Control-Expose-Headers: 클라이언트가 접근할 수 있는 헤더 목록을 명시합니다.
• 예: Access-Control-Expose-Headers: X-My-Custom-Header

■ 17. REST API 설계 원칙

■ 17.1 REST 개요

• REST(Representational State Transfer)는 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

• REST는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하며, URI를 통해 자원을 명시적으로 식별합니다.

■ 17.2 RESTful API의 특징

• 무상태성(Stateless): 서버는 클라이언트의 상태를 저장하지 않으며, 각 요청은 독립적으로 처리됩니다.

• 자원 기반(Resource-based): 모든 자원은 URI로 식별되며, 자원에 대한 행위는 HTTP 메서드로 표현됩니다.

• 표현(Representation): 클라이언트와 서버는 자원의 상태를 JSON, XML 등 다양한 형태로 표현하여 주고받을 수 있습니다.

• 자기 서술적 메시지(Self-descriptive messages): HTTP 메시지에는 요청의 의미와 목적이 명확하게 표현되어야 합니다.

■ 17.3 URI 설계

• 명사 사용: URI는 자원을 식별하는 데 사용되므로, 명사로 표현됩니다.
• 예: /users, /orders/123

• 슬래시(/)로 계층 관계 표현: URI 경로는 자원의 계층 관계를 표현하는 데 사용됩니다.
• 예: /users/123/orders/456

• 하이픈(-) 사용: URI 가독성을 위해 하이픈을 사용할 수 있습니다.
• 예: /user-orders

• 쿼리 파라미터 사용: 필터링, 정렬 등 추가적인 옵션을 제공할 때 쿼리 파라미터를 사용합니다.
• 예: /users?sort=desc&age=25

■ 18. OAuth

■ 18.1 OAuth 개요

• OAuth는 제3자 애플리케이션이 사용자 리소스에 접근할 수 있도록 허용하는 인증 프레임워크입니다.

• 사용자는 자신의 자격 증명을 제3자 애플리케이션에 직접 제공하지 않고, 인증 서버를 통해 인증을 위임합니다.

■ 18.2 OAuth 동작 방식

• 사용자는 제3자 애플리케이션에 로그인하고, 해당 애플리케이션이 사용자 데이터를 액세스할 수 있도록 권한을 부여합니다.

• 제3자 애플리케이션은 인증 서버로부터 Access Token을 받아, 이를 사용하여 리소스 서버에 요청을 보냅니다.

• 리소스 서버는 Access Token을 검증하고, 유효한 경우 요청된 데이터를 제3자 애플리케이션에 제공합니다.

■ 18.3 OAuth의 주요 개념

• Access Token: 인증된 사용자로부터 받은 권한을 나타내는 토큰으로, 리소스 서버에 대한 액세스를 제공합니다.

• Refresh Token: Access Token이 만료된 경우, 이를 갱신하기 위해 사용되는 토큰입니다.

• Authorization Server: 사용자를 인증하고 Access Token을 발급하는 서버입니다.

• Resource Server: 보호된 자원을 제공하는 서버로, Access Token을 통해 접근할 수 있습니다.