LWS 1.0 인증 스위트: OpenID Connect

W3C 작업 초안

이 문서에 대한 자세한 정보
이 버전:
https://www.w3.org/TR/2026/WD-lws10-authn-openid-20261015/
최신 게시 버전:
https://www.w3.org/TR/lws10-authn-openid/
최신 편집자 초안:
https://w3c.github.io/lws-protocol/lws10-authn-openid/
이력:
https://www.w3.org/standards/history/lws10-authn-openid/
커밋 이력
편집자:
Jesse Wright (옥스퍼드 대학교)
저자:
Aaron Coburn (Inrupt Inc.)
피드백:
GitHub w3c/lws-protocol (풀 리퀘스트, 새 이슈, 열린 이슈)

초록

이 문서는 Linked Web Storage (LWS) 프로토콜을 위한 OpenID Connect 기반 인증 스위트를 정의하여, LWS 애플리케이션이 OpenID 제공자와 통합할 수 있도록 합니다.

이 문서의 상태

이 섹션은 이 문서가 출판된 시점의 상태를 설명합니다. 현재 W3C 출판물 목록과 이 기술 보고서의 최신 개정판은 다음 W3C 표준 및 초안 색인에서 확인할 수 있습니다.

이것은 비공식 제안입니다.

이 문서는 Linked Web Storage 작업 그룹에서 권고안 트랙을 사용하여 작업 초안으로 출판했습니다.

작업 초안으로 출판되었다고 해서 W3C와 그 회원들의 승인을 의미하지는 않습니다.

이 문서는 초안 문서이며 언제든지 다른 문서로 업데이트, 대체 또는 폐기될 수 있습니다. 이 문서를 진행 중인 작업 이외의 것으로 인용하는 것은 적절하지 않습니다.

이 문서는 W3C 특허 정책에 따라 운영되는 그룹에서 작성했습니다. W3C는 해당 그룹의 산출물과 관련하여 이루어진 모든 특허 공개의 공개 목록을 유지합니다. 해당 페이지에는 특허 공개 지침도 포함되어 있습니다. 개인이 필수 청구항을 포함한다고 믿는 특허에 대해 실제 지식을 가지고 있는 경우, 그 개인은 W3C 특허 정책 섹션 6에 따라 해당 정보를 공개해야 합니다.

이 문서는 2025년 8월 18일 W3C 프로세스 문서의 적용을 받습니다.

1. 소개

OpenID Connect는 웹 기반 인증에 널리 사용되는 메커니즘입니다. 이 인증 스위트는 OpenID 제공자를 Linked Web Storage 준수 애플리케이션과 함께 사용할 수 있는 방법을 설명합니다.

2. 적합성

비규범으로 표시된 섹션뿐 아니라, 이 명세의 모든 작성 지침, 다이어그램, 예제, 참고는 비규범입니다. 이 명세의 그 밖의 모든 것은 규범입니다.

이 문서의 핵심 단어 MUST, MUST NOT, 그리고 SHOULD는 여기에 표시된 것처럼 모두 대문자로 나타날 때, 그리고 오직 그 경우에만 BCP 14 [RFC2119] [RFC8174]에 설명된 대로 해석해야 합니다.

3. 용어

"인가 서버" 및 "클라이언트"라는 용어는 OAuth 2.0 인가 프레임워크 [RFC6749]에서 정의된다.

"OpenID 제공자", "ID 토큰", "최종 사용자" 및 "발급자"라는 용어는 OpenID Connect Core 1.0 [OPENID-CONNECT-CORE]에서 정의된다.

"OpenID Connect 디스커버리"라는 용어는 OpenID Connect 디스커버리 1.0 [OPENID-CONNECT-DISCOVERY]에서 정의된다.

"제어 식별자 문서"라는 용어는 W3C 제어 식별자 1.0 [CID-1.0]에서 정의된다.

"JSON 웹 토큰(JWT)" 및 "클레임"이라는 용어는 JSON 웹 토큰 [RFC7519]에서 정의된다.

"JSON 웹 키(JWK)"라는 용어는 JSON 웹 키 [RFC7517]에서 정의된다.

"에이전트", "인증 자격 증명", 및 "인증 스위트"는 연결된 웹 저장소 프로토콜 [LWS10-CORE]에서 정의된다.

4. 인증 자격 증명 직렬화

OpenID Connect는 최종 사용자를 설명하는 데 사용되는 서명된 ID Token을 생성하기 위한 프로토콜을 정의합니다. ID Token은 서명된 JSON Web Token (JWT)으로 직렬화됩니다. ID Token을 LWS authentication credential로 사용하려면 다음 추가 요구사항이 적용됩니다.

LWS authentication credential이기도 한 예제 ID Token은 아래에 포함되어 있습니다.

{
  "typ": "JWT",
  "kid": "12dbe73a",
  "kty": "EC",
  "alg": "ES256",
  "crv": "P-256"
}
.
{
  "sub": "https://id.example/end-user",
  "iss": "https://openid.example",
  "azp": "https://client.example/17da1b",
  "aud": ["https://client.example/17da1b", "https://as.example"],
  "iat": 1761313600,
  "exp": 1761313900
}
.
signature

5. 인증 자격 증명 검증

ID Token이 LWS 인증 자격 증명으로 유효하려면, 검증자와 발급 당사자 사이에 신뢰 관계가 있어야 한다.

기존 신뢰 관계가 없는 경우, 검증자는 MUST authentication credential의 sub (subject) claim을 역참조해야 합니다. 결과 리소스는 MUST 주체 식별자와 동일한 id 값을 가진 유효한 controlled identifier document [CID-1.0] 형식이어야 합니다.

검증자는 MUST 주체의 controlled identifier document를 사용하여 serviceEndpoint 값이 authentication credential의 iss claim 값과 같고, type 값이 https://www.w3.org/ns/lws#OpenIdProvider와 같은 서비스 객체를 찾아야 합니다. 검증자는 MUST OpenID Connect Discovery를 수행하여 authentication credential에 서명하는 데 사용된 JSON Web Key (JWK)의 공개 부분을 찾아야 합니다. JWT는 MUST OpenID Connect Core Section 3.1.3.7 [OPENID-CONNECT-CORE]에 설명된 대로 검증되어야 합니다.

OpenID Connect를 사용하는 agent의 예제 Controlled Identifier Document는 아래에 포함되어 있습니다.

{
    "@context": [
        "https://www.w3.org/ns/cid/v1"
    ],
    "id": "https://id.example/end-user",
    "service": [{
        "type": "https://www.w3.org/ns/lws#OpenIdProvider",
        "serviceEndpoint": "https://openid.example"
    }]
}

6. 토큰 유형 식별자

authentication credential로 사용되는 ID Token은 권한 부여 서버와 상호작용할 때 MUST urn:ietf:params:oauth:token-type:id_token URI를 사용해야 합니다.

7. 보안 고려사항

이 섹션은 비규범입니다.

"OAuth 2.0 보안을 위한 최신 모범 사례" [RFC9700] 및 "OpenID Connect Core 1.0" 섹션 16 [OPENID-CONNECT-CORE]에 설명된 모든 보안 고려사항은 이 명세에 적용된다.

OpenID 제공자는 인가 서버를 포함하여 제한된 엔터티 집합으로 인증 자격 증명의 대상을 제한하는 메커니즘을 지원해야 한다. 이를 달성하는 한 가지 방법은 OAuth 2.0을 위한 리소스 지시자 [RFC8707]를 사용하는 것이다. 대상 제한이 없는 인증 자격 증명을 보유한 클라이언트는 예를 들어 OAuth 2.0 토큰 교환 [RFC8693]을 사용하여 이 토큰을 동등한 대상 제한 토큰으로 교환해야 한다.

OpenID 제공자는 OAuth 흐름의 인가 응답에 iss 매개변수를 포함하여 "OAuth 2.0 인가 서버 발급자 식별" [RFC9207]을 지원해야 한다.

OpenID 제공자는 RP-Initiated Logout 1.0과 같은 최종 사용자 로그아웃을 지원해야 한다.

인증 자격 증명의 발급자는 클라이언트 식별자를 검증할 책임이 있다. 발급자는 OAuth 클라이언트 ID 메타데이터 문서, OAuth 2.0 클라이언트 ID 접두사 또는 OpenID Federation과 같은 메커니즘을 사용할 수 있다.

OpenID 제공자가 사용자 인증을 위한 메커니즘으로 WebAuthn [WEBAUTHN-3]을 지원하는 것이 권장된다.

8. 개인정보 보호 고려사항

이 섹션은 비규범입니다.

"OpenID Connect Core 1.0" 섹션 17 [OPENID-CONNECT-CORE]에 설명된 모든 개인정보 보호 고려사항은 이 명세에 적용된다.

인증 자격 증명으로 사용되는 ID Token에는 이메일 주소, 이름 또는 기타 프로필 속성과 같이 최종 사용자에 대한 개인 식별 정보를 드러내는 클레임이 포함될 수 있다. OpenID 제공자는 LWS 인증에 필요한 클레임, 즉 sub, iss, azp 및 aud 클레임만 포함하는 ID Token을 발급하고, 명시적으로 요구되지 않는 한 추가적인 신원 속성을 포함하지 않도록 권장된다.

sub(주체) 클레임은 LWS 주체 식별자로 사용되며 검증 중에 역참조될 수 있으므로, 주체 식별자의 선택에는 개인정보 보호에 대한 영향이 있다. 영속적이고 전역적으로 고유한 주체 식별자를 사용하면 검증자와 저장소 서버가 세션과 리소스에 걸쳐 최종 사용자의 활동을 연계할 수 있다. [OPENID-CONNECT-CORE] 섹션 8에 설명된 것과 같이 쌍별 주체 식별자를 지원하는 OpenID 제공자는 제공자 간 연계 가능성을 줄일 수 있지만, LWS 검증 모델에서는 주체 식별자가 제어 식별자 문서로 해석되어야 한다.

검증 프로세스에서는 주체 식별자를 역참조하여 제어 식별자 문서를 가져와야 한다. 이 역참조 작업은 해당 문서의 호스팅 서버에 특정 주체에 대한 자격 증명을 어떤 검증자들이 검증하고 있는지, 액세스 시점과 빈도를 포함하여 드러낼 수 있다. 검증자는 불필요한 네트워크 요청과 그에 따른 메타데이터 유출을 줄이기 위해 제어 식별자 문서를 캐시하도록 권장된다.

클라이언트와 신뢰 당사자는 저장소 서버 또는 인가 서버에 제시된 ID Token을 해당 당사자들이 읽을 수 있다는 점을 유의해야 한다. 대상 제한(aud 클레임을 통한)은 토큰의 대상이 되는 당사자를 제한하지만, 전송 중인 토큰의 내용을 중개자가 읽는 것을 방지하지는 않는다. TLS 사용은 전송 중인 인증 자격 증명을 보호하는 데 필수적이다.

A. 참고 문헌

A.1 규범적 참고 문헌

[CID-1.0]
제어 식별자 v1.0. Michael Jones; Manu Sporny. W3C. 2025년 5월 15일. W3C 권고안. URL: https://www.w3.org/TR/cid-1.0/
[LWS10-CORE]
연결된 웹 스토리지 프로토콜 1.0. W3C. FPWD. URL: https://www.w3.org/TR/lws10-core/
[OPENID-CONNECT-CORE]
정오표 세트 2가 반영된 OpenID Connect Core 1.0 . N. Sakimura; J. Bradley; M. Jones; B. de Medeiros; C. Mortimore. OpenID Foundation. 2023년 12월 15일. 최종판. URL: https://openid.net/specs/openid-connect-core-1_0.html
[OPENID-CONNECT-DISCOVERY]
정오표 세트 2가 반영된 OpenID Connect Discovery 1.0. N. Sakimura; J. Bradley; M. Jones; E. Jay. OpenID Foundation. 2023년 12월 15일. 최종판. URL: https://openid.net/specs/openid-connect-discovery-1_0.html
[RFC2119]
요구 수준을 나타내기 위해 RFC에서 사용하는 핵심어. S. Bradner. IETF. 1997년 3월. 현재 최선의 관행. URL: https://www.rfc-editor.org/info/rfc2119/
[RFC6749]
OAuth 2.0 권한 부여 프레임워크. D. Hardt, 편집자. IETF. 2012년 10월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc6749/
[RFC7517]
JSON 웹 키(JWK). M. Jones. IETF. 2015년 5월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc7517/
[RFC7519]
JSON 웹 토큰(JWT). M. Jones; J. Bradley; N. Sakimura. IETF. 2015년 5월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc7519/
[RFC8174]
RFC 2119 핵심어의 대문자와 소문자 사용에 따른 모호성. B. Leiba. IETF. 2017년 5월. 현재 최선의 관행. URL: https://www.rfc-editor.org/info/rfc8174/

A.2 정보성 참고 문헌

[RFC8693]
OAuth 2.0 토큰 교환. M. Jones; A. Nadalin; B. Campbell, 편집자; J. Bradley; C. Mortimore. IETF. 2020년 1월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc8693/
[RFC8707]
OAuth 2.0용 리소스 지시자. B. Campbell; J. Bradley; H. Tschofenig. IETF. 2020년 2월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc8707/
[RFC9207]
OAuth 2.0 권한 부여 서버 발급자 식별. K. Meyer zu Selhausen; D. Fett. IETF. 2022년 3월. 제안 표준. URL: https://www.rfc-editor.org/info/rfc9207/
[RFC9700]
OAuth 2.0 보안을 위한 현재 최선의 관행. T. Lodderstedt; J. Bradley; A. Labunets; D. Fett. IETF. 2025년 1월. 현재 최선의 관행. URL: https://www.rfc-editor.org/info/rfc9700/
[WEBAUTHN-3]
웹 인증: 공개 키 자격 증명에 액세스하기 위한 API - Level 3. Akshay Kumar; Emil Lundberg; Tim Cappalli; Nina Satragno; Matthew Miller; ㅤ Pascoe. W3C. 2026년 8월 25일. W3C 권고안. URL: https://www.w3.org/TR/webauthn-3/