"use strict"; const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0]; const {useMDXComponents: _provideComponents} = arguments[0]; const headings = [{ "data": { "id": "소개", "hProperties": { "id": "소개" } }, "depth": 2, "value": "소개" }, { "data": { "id": "우선-무엇이고-왜일까", "hProperties": { "id": "우선-무엇이고-왜일까" } }, "depth": 2, "value": "우선, 무엇이고 왜일까?" }, { "data": { "id": "oidc-서버-통합", "hProperties": { "id": "oidc-서버-통합" } }, "depth": 2, "value": "OIDC 서버 통합" }, { "data": { "id": "oidc-제공자-찾기", "hProperties": { "id": "oidc-제공자-찾기" } }, "depth": 3, "value": "OIDC 제공자 찾기" }, { "data": { "id": "주체-클라이언트-및-대상", "hProperties": { "id": "주체-클라이언트-및-대상" } }, "depth": 3, "value": "주체, 클라이언트 및 대상" }, { "data": { "id": "1-사용자가-웹-애플리케이션에서-로그인-버튼을-클릭", "hProperties": { "id": "1-사용자가-웹-애플리케이션에서-로그인-버튼을-클릭" } }, "depth": 4, "value": "1. 사용자가 웹 애플리케이션에서 로그인 버튼을 클릭" }, { "data": { "id": "2-사용자가-단일-페이지-애플리케이션-사용", "hProperties": { "id": "2-사용자가-단일-페이지-애플리케이션-사용" } }, "depth": 4, "value": "2. 사용자가 단일 페이지 애플리케이션 사용" }, { "data": { "id": "3-기계-간-통신", "hProperties": { "id": "3-기계-간-통신" } }, "depth": 4, "value": "3. 기계 간 통신" }, { "data": { "id": "요약", "hProperties": { "id": "요약" } }, "depth": 4, "value": "요약" }, { "data": { "id": "토큰", "hProperties": { "id": "토큰" } }, "depth": 3, "value": "토큰" }, { "data": { "id": "다중-대상", "hProperties": { "id": "다중-대상" } }, "depth": 3, "value": "다중 대상" }, { "data": { "id": "코드-교환-요청에서-resource-지정", "hProperties": { "id": "코드-교환-요청에서-resource-지정" } }, "depth": 4, "value": "코드 교환 요청에서 resource 지정" }, { "data": { "id": "갱신-토큰을-사용하여-새-액세스-토큰-얻기", "hProperties": { "id": "갱신-토큰을-사용하여-새-액세스-토큰-얻기" } }, "depth": 4, "value": "갱신 토큰을 사용하여 새 액세스 토큰 얻기" }, { "data": { "id": "클라이언트-자격-증명-부여", "hProperties": { "id": "클라이언트-자격-증명-부여" } }, "depth": 4, "value": "클라이언트 자격 증명 부여" }, { "data": { "id": "api-서비스-보호", "hProperties": { "id": "api-서비스-보호" } }, "depth": 3, "value": "API 서비스 보호" }, { "data": { "id": "주장-확인", "hProperties": { "id": "주장-확인" } }, "depth": 4, "value": "주장 확인" }, { "data": { "id": "권한-부여", "hProperties": { "id": "권한-부여" } }, "depth": 2, "value": "권한 부여" }, { "data": { "id": "마무리-노트", "hProperties": { "id": "마무리-노트" } }, "depth": 2, "value": "마무리 노트" }]; const readingTime = { "minutes": 2, "words": 508, "text": "2 min read" }; const frontmatter = undefined; function _createMdxContent(props) { const _components = { a: "a", blockquote: "blockquote", code: "code", em: "em", h2: "h2", h3: "h3", h4: "h4", li: "li", p: "p", pre: "pre", span: "span", strong: "strong", ul: "ul", ..._provideComponents(), ...props.components }, {Info, LogtoCloudButton, Note} = _components; if (!Info) _missingMdxReference("Info", true); if (!LogtoCloudButton) _missingMdxReference("LogtoCloudButton", true); if (!Note) _missingMdxReference("Note", true); return _jsxs(_Fragment, { children: [_jsxs(_components.h2, { id: "소개", children: ["소개", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#소개", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "중앙 집중식 인증 및 권한 시스템, 즉 ID 액세스 관리(IAM) 또는 ID 제공자(IdP)가 필요한 상황에 직면할 수 있습니다. 때때로 사람들은 고객 IAM 및 워크포스 IAM과 같이 비즈니스를 지정하는 단어를 추가합니다." }), "\n", _jsx(_components.p, { children: "이러한 화려한 이름은 잠시 제쳐두겠습니다. IAM에 대한 필요성은 애플리케이션이 성장하고 있기 때문일 수 있으며, 시작부터 작업을 공급업체에 위임할 계획이 있기 때문일 수 있습니다. 어쨌든 프로젝트에 ID 시스템을 도입해야 할 시점에 도달하고 있습니다." }), "\n", _jsx(_components.p, { children: "OAuth 2.0의 인기를 고려하면 OpenID Connect(OIDC)는 많은 개발자들에게 자연스러운 선택입니다. OIDC는 OAuth 2.0 위에 구축된 인증 계층이기 때문에 OIDC를 처음 접할 때 친숙하게 느낄 수 있습니다. 시작해봅시다!" }), "\n", _jsxs(_components.h2, { id: "우선-무엇이고-왜일까", children: ["우선, 무엇이고 왜일까?", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#우선-무엇이고-왜일까", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.blockquote, { children: ["\n", _jsx(_components.p, { children: "ID 제공자의 개념과 그 중요성을 이미 알고 있다면 이 섹션을 건너뛰어도 좋습니다." }), "\n"] }), "\n", _jsxs(_components.p, { children: ["OIDC 서버 또는 ID 제공자는 사용자 인증 및 권한 관리를 담당하는 중앙 집중식 시스템입니다. ", _jsx(_components.a, { href: "https://blog.logto.io/centralized-identity-system", children: "다중 앱 비즈니스에서 중앙 집중식 ID 시스템이 필요한 이유" }), "에서 논의한 바와 같이, 중앙 집중식 ID 시스템은 여러 가지 이점을 제공합니다."] }), "\n", _jsx(_components.p, { children: "프로젝트가 단순한 웹 애플리케이션으로 시작했고 인증이 내장된 상황을 가정해봅시다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n" }) }), "\n", _jsx(_components.p, { children: "프로젝트가 성장함에 따라 모바일 버전을 도입해야 합니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n A --> C[모바일 애플리케이션]\n" }) }), "\n", _jsx(_components.p, { children: "각 애플리케이션에 대한 계정을 생성해야 한다면 사용자에게 나쁜 경험이 될 것입니다. 웹 애플리케이션부터 시작했기 때문에 모바일 애플리케이션이 인증을 위해 웹 애플리케이션과 통신하도록 합니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n A --> C[모바일 애플리케이션]\n C --> B\n" }) }), "\n", _jsx(_components.p, { children: "이제 새로운 API 서비스가 도입되고 있습니다. 유료 사용자만을 위한 서비스이기 때문에 사용자가 인증되고 서비스에 액세스할 수 있는 권한이 있는지 확인해야 합니다. 이를 달성하기 위해 웹 애플리케이션을 통해 서비스를 프록시할 수 있습니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n A --> C[모바일 애플리케이션]\n C --> B\n B --> D[API 서비스]\n" }) }), "\n", _jsx(_components.p, { children: "또는 서비스에서 웹 애플리케이션과 대화하여 토큰을 사용하여 사용자를 인증하고 토큰을 확인하는 일부 기술을 사용할 수 있습니다. 따라서 모바일 애플리케이션이 서비스를 직접 사용할 수 있습니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n A --> C[모바일 애플리케이션]\n C --> B\n B <--> D[API 서비스]\n C --> D\n" }) }), "\n", _jsx(_components.p, { children: "상황이 복잡해지고 있습니다. 따라서 인증 및 권한 부여 논리를 별도의 서비스로 분리하기로 합니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "graph LR\n A[사용자] --> B[웹 애플리케이션]\n A --> C[모바일 애플리케이션]\n B --> D[API 서비스]\n C --> D\n B --> E[ID 서비스] \n C --> E\n D --> E \n\n subgraph 애플리케이션\n B\n C\n end\n\n subgraph 서비스\n D\n end\n\n subgraph ID\n E\n end\n" }) }), "\n", _jsx(_components.p, { children: "리팩토링 과정은 고통스러울 수 있습니다. 프로젝트에 애플리케이션과 서비스를 더 추가할수록 복잡성이 기하급수적으로 증가할 것이라는 점을 알 수 있습니다. 더욱이, 암호 없는 로그인, 소셜 로그인, SAML 등과 같은 여러 인증 방법을 유지해야 할 수도 있습니다." }), "\n", _jsx(_components.p, { children: "이것이 프로젝트를 확장할 계획이 있을 때 처음부터 ID 제공자를 도입하는 것이 좋다는 이유입니다." }), "\n", _jsx(Note, { children: _jsx(_components.p, { children: "물론, 프로젝트가 충분히 간단하고 당분간 간단하게 유지될 것임을 알고 있는 경우도 있습니다. 필요할 때 이 글을 떠나고 나중에 돌아오실 수 있습니다." }) }), "\n", _jsxs(_components.h2, { id: "oidc-서버-통합", children: ["OIDC 서버 통합", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oidc-서버-통합", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.h3, { id: "oidc-제공자-찾기", children: ["OIDC 제공자 찾기", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#oidc-제공자-찾기", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "시장에는 많은 OIDC 제공자가 있습니다. 요구 사항과 선호도에 따라 하나를 선택할 수 있습니다. 제공자가 OIDC 준수하는 한, 프로젝트에서 동일한 역할을 담당하게 될 것입니다." }), "\n", _jsx(Info, { children: _jsxs(_components.p, { children: [_jsx(_components.a, { href: "https://logto.io", children: "Logto" }), "는 즉시 사용할 수 있는 ID 및 액세스 관리 기능을 갖춘 오픈 소스 OIDC 제공자입니다."] }) }), "\n", _jsxs(_components.h3, { id: "주체-클라이언트-및-대상", children: ["주체, 클라이언트 및 대상", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#주체-클라이언트-및-대상", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["개념을 단순화하기 위해 ", _jsx(_components.em, { children: "주체" }), "는 ", _jsx(_components.em, { children: "클라이언트" }), "를 통해 ", _jsx(_components.em, { children: "대상" }), "에 대한 액세스를 요청하는 엔티티라고 생각할 수 있습니다."] }), "\n", _jsx(Note, { title: "토큰에서 대상(aud)을 찾을 수 없습니다", children: _jsx(_components.p, { children: "대상이 없는 경우, 보통 대상이 OIDC 서버 자체라는 의미입니다." }) }), "\n", _jsx(_components.p, { children: "일반적인 시나리오를 살펴봅시다:" }), "\n", _jsxs(_components.h4, { id: "1-사용자가-웹-애플리케이션에서-로그인-버튼을-클릭", children: ["1. 사용자가 웹 애플리케이션에서 로그인 버튼을 클릭", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#1-사용자가-웹-애플리케이션에서-로그인-버튼을-클릭", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "전통적인 서버 사이드 렌더링 웹 애플리케이션에서 프론트엔드와 백엔드는 결합되어 있습니다. 웹 애플리케이션이 프론트엔드와 백엔드를 모두 제공한다고 가정해봅시다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "주체" }), ": 사용자"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "대상" }), ": OIDC 서버"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "클라이언트" }), ": 웹 애플리케이션"] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["대상이 OIDC 서버라는 것은 직관적이지 않을 수 있습니다. 실제로, 이는 최종 사용자를 위한 SSO(단일 사인 온) 경험을 실현하는 데 중요한 역할을 합니다. ", _jsx(_components.a, { href: "https://blog.logto.io/implicit-flow-is-dead#how-authorization-code-flow-works", children: "승인 코드 플로우" }), "의 간단한 시퀀스 다이어그램을 살펴봅시다:"] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User as 사용자
(주체)\n participant App1 as 웹앱 1
(클라이언트)\n participant App2 as 웹앱 2
(클라이언트)\n participant OIDC as OIDC 서버
(대상)\n\n User ->> App1: 로그인 클릭\n App1 ->> OIDC: 리디렉션
(승인 요청)\n OIDC ->> User: 로그인 페이지 표시\n User ->> OIDC: 로그인\n OIDC ->> App1: `코드`와 함께 리디렉션\n App1 ->> OIDC: `코드`를 사용하여 토큰 교환\n Note over User: 커피 한 잔 마시기\n User ->> App2: 로그인 클릭\n App2 ->> OIDC: 리디렉션\n OIDC ->> OIDC: 유효한 세션 발견\n OIDC ->> App2: `코드`와 함께 리디렉션\n App2 ->> OIDC: `코드`를 사용하여 토큰 교환\n" }) }), "\n", _jsxs(_components.p, { children: [_jsx(_components.code, { children: "코드" }), "는 다양한 토큰(예: 액세스 토큰, ID 토큰 및 갱신 토큰)과 교환할 수 있는 일회용 코드입니다. 지금 이러한 모든 토큰을 이해하지 못해도 괜찮습니다. 앞으로 나아가면서, 더 잘 이해하게 될 것입니다."] }), "\n", _jsx(_components.p, { children: "위의 경우에서 사용자는 다른 애플리케이션으로 전환할 때 다시 로그인할 필요가 없습니다. 사용자가(주체) OIDC 서버(대상)와 이미 인증했기 때문입니다." }), "\n", _jsxs(_components.h4, { id: "2-사용자가-단일-페이지-애플리케이션-사용", children: ["2. 사용자가 단일 페이지 애플리케이션 사용", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#2-사용자가-단일-페이지-애플리케이션-사용", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "단일 페이지 애플리케이션(또는 모바일 애플리케이션)에서 프론트엔드와 백엔드는 분리되어 있습니다. 백엔드는 API 서비스라고 가정해봅시다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "주체" }), ": 사용자"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "대상" }), ": API 서비스"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "클라이언트" }), ": 단일 페이지 애플리케이션(SPA)"] }), "\n"] }), "\n", _jsx(_components.p, { children: "승인 코드 플로우를 사용한 간단한 시퀀스 다이어그램:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant User as 사용자
(주체)\n participant SPA as 단일 페이지 애플리케이션
(클라이언트)\n participant API as API 서비스
(대상)\n participant OIDC as OIDC 서버
(대상)\n\n User ->> SPA: 로그인 클릭\n SPA ->> OIDC: 리디렉션
(승인 요청)\n OIDC ->> User: 로그인 페이지 표시\n User ->> OIDC: 로그인\n OIDC ->> SPA: `코드`와 함께 리디렉션\n SPA ->> OIDC: `코드`를 사용하여 토큰 교환\n User ->> SPA: 보호된 페이지 보기 시도\n SPA ->> API: 액세스 토큰을 사용하여 데이터 요청\n API ->> OIDC: 액세스 토큰 확인\n OIDC ->> API: 확인 완료\n API ->> SPA: 응답 데이터\n" }) }), "\n", _jsxs(_components.p, { children: ["API 서비스는 비인터렉티브이므로 SPA는 API 서비스의 대상을 대상으로 액세스 토큰을 사용해야 합니다(토큰의 ", _jsx(_components.code, { children: "aud" }), ")."] }), "\n", _jsx(_components.p, { children: _jsx(_components.strong, { children: "왜 OIDC 서버가 여전히 대상인가요?" }) }), "\n", _jsx(_components.p, { children: "기술적으로, OIDC 서버를 대상 목록에서 제거할 수 있습니다. 대부분의 경우, OIDC 서버로부터 사용자 정보를 얻어야 하기 때문에(이는 OIDC 서버가 대상이어야 함), 사용자 상호작용이 포함될 때 항상 OIDC 서버를 대상 목록에 포함하는 것이 좋습니다." }), "\n", _jsx(_components.p, { children: _jsx(_components.strong, { children: "잠시만요, 승인을 요청할 때 여러 대상을 가질 수 있다고 말씀하시는 건가요?" }) }), "\n", _jsxs(_components.p, { children: ["정확히 그렇습니다! OIDC가 OAuth 2.0 위에 구축되어 있기 때문에, 승인 요청에서 ", _jsx(_components.a, { href: "https://datatracker.ietf.org/doc/html/rfc8707", children: "RFC 8707: OAuth 2.0을 위한 리소스 지시어" }), "를 활용하여 여러 대상을 지정할 수 있습니다. 그것은 승인과 OIDC 서버 모두의 지원을 필요로 합니다. ", _jsx(_components.a, { href: "https://logto.io", children: "Logto" }), "는 이 기능을 기본적으로 지원합니다."] }), "\n", _jsxs(_components.h4, { id: "3-기계-간-통신", children: ["3. 기계 간 통신", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#3-기계-간-통신", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "서비스 A가 서비스 B를 호출해야 하는 경우를 가정해봅시다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "주체" }), ": 서비스 A"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "대상" }), ": 서비스 B"] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "클라이언트" }), ": 서비스 A"] }), "\n"] }), "\n", _jsxs(_components.p, { children: [_jsx(_components.a, { href: "https://datatracker.ietf.org/doc/html/rfc6749#section-1.3.4", children: "클라이언트 자격 증명 부여" }), "를 사용한 간단한 시퀀스 다이어그램:"] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-mermaid", children: "sequenceDiagram\n participant ServiceA as 서비스 A
(주체 및 클라이언트)\n participant ServiceB as 서비스 B
(대상)\n participant OIDC as OIDC 서버\n\n ServiceA ->> OIDC: 클라이언트 자격 증명으로 액세스 토큰 요청 (토큰 요청)\n OIDC ->> ServiceA: 액세스 토큰\n ServiceA ->> ServiceB: 액세스 토큰으로 데이터 요청\n ServiceB ->> OIDC: 액세스 토큰 확인\n OIDC ->> ServiceB: 확인 완료\n ServiceB ->> ServiceA: 응답 데이터\n" }) }), "\n", _jsx(_components.p, { children: "서비스 B가 서비스 A를 호출해야 할 때, 역할은 단순히 교환됩니다." }), "\n", _jsxs(_components.h4, { id: "요약", children: ["요약", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#요약", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "주체" }), ": 사용자, 서비스 또는 대상을 액세스해야 하는 모든 엔티티가 될 수 있습니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "클라이언트" }), ": 웹 애플리케이션, 모바일 애플리케이션 또는 주체를 대신하여 요청을 시작하거나 행동하는 모든 엔티티가 될 수 있습니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "대상" }), ": 서비스, API 또는 주체에 액세스를 제공하는 모든 엔티티가 될 수 있습니다."] }), "\n"] }), "\n", _jsxs(_components.h3, { id: "토큰", children: ["토큰", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#토큰", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "OIDC로 작업할 때 접할 수 있는 세 가지 유형의 토큰이 있습니다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "액세스 토큰" }), ": 대상을 액세스하는 데 사용됩니다. JWT(제이슨 웹 토큰) 또는 불투명한 토큰(일반적으로 임의의 문자열)이 될 수 있습니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "ID 토큰" }), ": 사용자 정보를 포함하는 OIDC 특화 토큰입니다. 항상 JWT입니다. 클라이언트는 토큰을 디코딩하여 사용자 정보를 얻을 수 있습니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "갱신 토큰" }), ": 액세스 토큰이나 ID 토큰이 만료될 때 새 세트의 토큰을 얻는 데 사용됩니다."] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["이러한 토큰에 대한 자세한 설명은 ", _jsx(_components.a, { href: "https://blog.logto.io/understanding-tokens-in-oidc", children: "OIDC 프로토콜에서 갱신 토큰, 액세스 토큰, ID 토큰 이해하기" }), "를 참조하세요."] }), "\n", _jsxs(_components.p, { children: ["위의 시나리오 1과 2에서 용어 ", _jsx(_components.em, { children: "승인 요청" }), "은 특정 ", _jsx(_components.em, { children: "부여" }), "를 통해 토큰 세트를 얻는 요청을 나타냅니다."] }), "\n", _jsx(Note, { children: _jsxs(_components.p, { children: ["OAuth 2.0 RFC는 용어 ", _jsx(_components.em, { children: "부여" }), "를 사용하지만, 실제로는 전체적인 엔드투엔드 프로세스를 설명하는 데 ", _jsx(_components.em, { children: "플로우" }), "라는 용어를 자주 사용합니다."] }) }), "\n", _jsxs(_components.p, { children: ["모든 것이 원활하게 진행되면, \"", _jsx(_components.code, { children: "코드" }), "를 사용하여 토큰 교환\" 단계에서 토큰 세트가 반환됩니다. 세트에 포함된 사용 가능한 토큰은 복수의 요소, 특히 승인 요청의 ", _jsx(_components.code, { children: "scope" }), " 매개변수에 따라 달라집니다. 단순화를 위해, 모든 토큰이 세트에 포함되어 있다고 가정하겠습니다. 액세스 토큰이 만료되면, 클라이언트는 사용자 상호작용 없이 갱신 토큰을 사용하여 새 세트의 토큰을 얻을 수 있습니다."] }), "\n", _jsx(_components.p, { children: "시나리오 3의 경우, 클라이언트 자격 증명 부여는 액세스 토큰만 반환하기 때문에 더 간단합니다." }), "\n", _jsxs(_components.h3, { id: "다중-대상", children: ["다중 대상", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#다중-대상", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "한 번에 단 하나의 액세스 토큰만 반환된다는 점을 주목할 수 있습니다. 클라이언트가 여러 대상을 액세스해야 할 경우 어떻게 처리할 수 있을까요?" }), "\n", _jsx(_components.p, { children: "두 가지 일반적인 솔루션이 있습니다:" }), "\n", _jsxs(_components.h4, { id: "코드-교환-요청에서-resource-지정", children: ["코드 교환 요청에서 ", _jsx(_components.code, { children: "resource" }), " 지정", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#코드-교환-요청에서-resource-지정", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["클라이언트가 코드를 토큰으로 교환할 때, 요청에 ", _jsx(_components.code, { children: "resource" }), " 매개변수를 지정할 수 있습니다. OIDC 서버는 해당하는 경우 지정된 대상을 위한 액세스 토큰을 반환합니다."] }), "\n", _jsx(_components.p, { children: "다음은 비표준적인 예입니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-http", children: "POST /token HTTP/1.1\nHost: oidc-server.example.com\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=authorization_code\n&code=AUTHORIZATION_CODE\n&client_id=CLIENT_ID\n&client_secret=CLIENT_SECRET\n&resource=API_SERVICE\n" }) }), "\n", _jsxs(_components.p, { children: ["그런 후 OIDC 서버는 ", _jsx(_components.code, { children: "API_SERVICE" }), " 대상을 위한 액세스 토큰을 반환합니다, 만약 applicable 경우."] }), "\n", _jsxs(_components.h4, { id: "갱신-토큰을-사용하여-새-액세스-토큰-얻기", children: ["갱신 토큰을 사용하여 새 액세스 토큰 얻기", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#갱신-토큰을-사용하여-새-액세스-토큰-얻기", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["RFC 8707이 지원되면, 클라이언트는 ", _jsx(_components.code, { children: "resource" }), " 매개변수를 여러 번 사용하여 여러 대상을 지정할 수 있습니다. 이제 클라이언트에 갱신 토큰이 있는 경우, 새 토큰을 갱신할 때 ", _jsx(_components.code, { children: "resource" }), " 매개변수에서 대상을 지정할 수 있습니다."] }), "\n", _jsx(_components.p, { children: "다음은 비표준적인 예입니다:" }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-http", children: "POST /token HTTP/1.1\nHost: oidc-server.example.com\nContent-Type: application/x-www-form-urlencoded\n\ngrant_type=refresh_token\n&refresh_token=REFRESH_TOKEN\n&client_id=CLIENT_ID\n&client_secret=CLIENT_SECRET\n&resource=API_SERVICE\n" }) }), "\n", _jsx(_components.p, { children: "이는 이전 솔루션과 동일한 효과를 가집니다. 한편, 다른 부여된 대상은 향후 토큰 요청에서도 여전히 사용 가능합니다." }), "\n", _jsxs(_components.h4, { id: "클라이언트-자격-증명-부여", children: ["클라이언트 자격 증명 부여", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#클라이언트-자격-증명-부여", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["클라이언트 자격 증명 부여에서도 ", _jsx(_components.code, { children: "resource" }), " 매개변수를 사용하여 대상을 지정할 수 있습니다. 이 부여에서는 여러 대상을 다루는 데 문제가 없습니다. 왜냐하면 다른 대상을 위한 새로운 액세스 토큰을 요청할 때마다 다음 토큰 요청을 간단히 전달할 수 있기 때문입니다."] }), "\n", _jsxs(_components.h3, { id: "api-서비스-보호", children: ["API 서비스 보호", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#api-서비스-보호", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "시나리오 2의 \"API 서비스\"와 시나리오 3의 \"서비스 B\"는 한 가지 공통점을 가지고 있습니다: 그들은 요청이 승인되었는지 확인하기 위해 액세스 토큰을 확인해야 합니다. 액세스 토큰의 형식에 따라 확인 프로세스가 다를 수 있습니다." }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "불투명 토큰" }), ": API 서비스는 토큰을 확인하기 위해 OIDC 서버를 호출해야 합니다. OIDC 서버는 이를 위해 ", _jsx(_components.a, { href: "https://blog.logto.io/oauth2-token-introspection", children: "인스토크스펙션 엔드포인트" }), "를 제공하는 경우가 많습니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.strong, { children: "JWT" }), ": API 서비스는 서명과 토큰의 주장을 확인하여 로컬에서 토큰을 확인할 수 있습니다. OIDC 서버는 서명을 검증하기 위해 API 서비스가 공개 키를 가져올 수 있는 ", _jsx(_components.a, { href: "https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata", children: "JSON 웹 키 세트(JWKS) 엔드포인트" }), " (", _jsx(_components.code, { children: "jwks_uri" }), ")를 제공하는 경우가 많습니다."] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["JWT에 익숙하지 않은 경우 ", _jsx(_components.a, { href: "https://blog.logto.io/what-is-jwt", children: "JSON 웹 토큰(JWT)이란?" }), "를 참조하세요. 사실 서명을 검증하고 주장을 명시적으로 확인할 필요가 없는 경우가 많습니다. 왜냐하면 Node.js 및 웹 브라우저용 ", _jsx(_components.a, { href: "https://github.com/panva/jose", children: "jose" }), "와 같은 많은 라이브러리가 이를 대신해줄 수 있기 때문입니다."] }), "\n", _jsxs(_components.h4, { id: "주장-확인", children: ["주장 확인", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#주장-확인", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "JWT 서명을 검증하는 것 외에도, API 서비스는 항상 토큰의 주장을 확인해야 합니다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsxs(_components.li, { children: [_jsx(_components.code, { children: "iss" }), ": 토큰의 발급자. OIDC의 발급자 URL과 일치해야 합니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.code, { children: "aud" }), ": 토큰의 대상. API 서비스의 대상 값과 일치해야 합니다(보통 유효한 URI)."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.code, { children: "exp" }), ": 토큰의 만료 시간. API 서비스는 만료된 토큰을 거절해야 합니다."] }), "\n", _jsxs(_components.li, { children: [_jsx(_components.code, { children: "scope" }), ": 토큰의 범위(권한). API 서비스는 필요한 범위가 토큰에 있는지 확인해야 합니다."] }), "\n"] }), "\n", _jsxs(_components.p, { children: ["기타 주장, 예를 들어 ", _jsx(_components.code, { children: "sub" }), " (주체) 및 ", _jsx(_components.code, { children: "iat" }), " (발행 시간)도 일부 경우에 중요합니다. 추가 보안 조처가 있는 경우 주장에 맞게 확인하십시오."] }), "\n", _jsxs(_components.h2, { id: "권한-부여", children: ["권한 부여", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#권한-부여", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsxs(_components.p, { children: ["답변되지 않은 질문이 남아 있습니다: ", _jsx(_components.em, { children: "범위" }), " (즉 권한)를 주체에게 부여할 수 있는지 어떻게 결정할 수 있나요?"] }), "\n", _jsx(_components.p, { children: "이 단일 질문은 권한 부여의 완전한 새로운 세계로 이어지며, 이 기사의 범위를 벗어납니다. 간단히 말해, RBAC(역할 기반 접근 제어) 및 ABAC(속성 기반 접근 제어)와 같은 일반적인 방법이 있습니다. 시작하는 데 유용한 자료는 다음과 같습니다:" }), "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: _jsx(_components.a, { href: "https://blog.logto.io/rbac-and-abac", children: "RBAC와 ABAC: 알고 있어야 할 접근 제어 모델" }) }), "\n", _jsx(_components.li, { children: _jsx(_components.a, { href: "https://blog.logto.io/mastering-rbac", children: "Logto에서 RBAC 마스터하기: 종합적인 실제 사례" }) }), "\n"] }), "\n", _jsxs(_components.h2, { id: "마무리-노트", children: ["마무리 노트", _jsx(_components.a, { "aria-hidden": "true", tabIndex: "-1", href: "#마무리-노트", children: _jsx(_components.span, { children: "#" }) })] }), "\n", _jsx(_components.p, { children: "프로젝트에 OIDC 서버를 도입하는 것은 큰 걸음입니다. 이는 프로젝트의 보안성과 확장성을 크게 향상시킬 수 있습니다. 그와 동시에, 개념과 구성 요소 간의 상호작용을 이해하는 데 시간이 걸릴 수 있습니다." }), "\n", _jsx(_components.p, { children: "요구 사항과 선호도에 맞는 좋은 OIDC 제공자를 선택하면 통합 프로세스의 복잡성을 크게 줄일 수 있습니다. 제공자는 대개 OIDC 서버, 권한 부여 메커니즘, SDK 및 미래에 필요할 수 있는 엔터프라이즈 기능을 포함한 전체 패키지를 제공합니다." }), "\n", _jsxs(_components.p, { children: ["이 가이드가 OIDC 서버 통합의 기초를 이해하는 데 도움이 되길 바랍니다. 시작할 OIDC 제공자를 찾고 있다면, 개인적으로 ", _jsx(_components.a, { href: "https://logto.io", children: "Logto" }), "를 추천하고 싶습니다. 개발자를 위한 우리의 ID 인프라입니다."] }), "\n", _jsx(LogtoCloudButton, {})] }); } function MDXContent(props = {}) { const {wrapper: MDXLayout} = { ..._provideComponents(), ...props.components }; return MDXLayout ? _jsx(MDXLayout, { ...props, children: _jsx(_createMdxContent, { ...props }) }) : _createMdxContent(props); } return { headings, readingTime, frontmatter, default: MDXContent }; function _missingMdxReference(id, component) { throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it."); }