(스펙 원본: http://openid.net/specs/openid-authentication-1_1.html)

개요

OpenID 인증은 사용자가 제시한 URL이 본인의 소유임을 증명함으로써 인증을 수행한다. 비밀번호나 전자우편주소와 같이, 어떤 다른 것도 전달하지 않고도 인증 절차를 진행할 수 있다.

OpenID는 완전히 분산되어 있다. 이는 누구나 Consumer 또는 Identity 제공자가 될 수 있으며, 이를 위해 중앙의 권위주체로부터 허가나 등록 또한 받을 필요가 없다는 것을 의미한다. 사용자는 자신이 사용하고 싶은 Identity 제공자를 선택할 수 있고, Identity 제공자를 변경할 경우에도 Identity를 유지할 수 있다.

  OpenID 의 프로토콜은 JavaScript 나 최신브라우저를 요구하지는 않지만, 인증방식상 소위 "AJAX"-스타일 셋업을 깔끔하기 적용할 수 있으며, 최종사용자가 현재 페이지를 떠나지 않고도 인증을 수행할 수도 있다.(물론 보안 이슈는 있다-역자).

  본 OpenID 인증 스펙상에는 사용자 프로파일 정보를 교환하기 위한 어떤 방법도 제공하지 않지만, Consumer 는 해당 OpenID 페이지에 연결된 세만틱한 형식의 문서들 (FOAF, RSS, Atom, vCARD, 등)을 통해서 사용자에 대한 정보를 얻을 수 있다. 또한 프로파일 정보 교환 수단을 제공하기 위해, 현재 OpenID 인증 기반 위에서 확장 스펙들이 작성 중이다.

목차

1.  요구 사항 표시법
2.  용어
3.  개관
    3.1.  HTML 문서를 Identifier 로 바꾸기
        3.1.1.  인증 위임하기
    3.2.  제시된 Identifier 제출하기
    3.3.  Consumer 사이트는 Identifier URL 내용을 구한다
    3.4.  Smart 대 Dumb 모드
    3.5.  Consumer 는 Identifier 를 검증한다
4.  Modes
    4.1.  associate
        4.1.1.  요청 인자들
        4.1.2.  응답 인자들
        4.1.3.  추가 사항
    4.2.  checkid_immediate
        4.2.1.  요청 인자들
        4.2.2.  응답 인자들
        4.2.3.  추가 사항
    4.3.  checkid_setup
        4.3.1.  요청 인자들
        4.3.2.  응답 인자들
        4.3.3.  추가 사항
    4.4.  check_authentication
        4.4.1.  요청 인자들
        4.4.2.  응답 인자들
        4.4.3.  추가 사항
5.  보안 고려 사항
Appendix A.  Default Values
Appendix A.1.  Diffie-Hellman P Value
Appendix B.  Error Responses
Appendix C.  Key-Value Format
Appendix D.  Limits
Appendix E.  Misc
6.  Normative References
§  Authors' Addresses

1. 요구 사항 표시

이 문서의 요구 사항 수준을 정확히 표현하기 위해 한글 표현 이외에도, 영문 키워드들 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 을 [RFC2119] (Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” .) 에 정의된 의미로 괄호안에 추가 표시 한다.

2. 용어

최종 사용자 (End User):

Consumer 에게 자신의 아이덴티티를 증명하고자 하는 실제 사람.

Identifier:

Identifier 는 단지 하나의 URL 이다. 전체 OpenID 인증 프로토콜의 흐름은 최종 사용자가 하나의 URL 을 소유했음을 증명하는 것에 관한 것이다.

제시된 Identifier (Claimed Identifier):

Consumer 에 의해 아직 검증되지 않았지만, 최종 사용자가 자신의 것이라고 말하는 Identifier.

검증된 Identifier (Verified Identifier):

최종 사용자가 Consumer 에게 자신의 것임을 증명한 Identifier.

Consumer:

제시한 Identifier가 최종 사용자의 소유인지 검증하고 싶은 웹 서비스.

Identity 제공자 (Identity Provider):

또는 "IdP" 나 "서버" 로도 불린다. 제시한 Identifier가 최종 사용자의 소유임을 암호학적으로 증명받기 위해 Consumer 가 접속하는 OpenID 인증 서버이다. 최종 사용자가 어떻게 IdP에서 인증받는지에 대한 내용은 OpenID 인증 스펙의 범위를 벗어난다 (역주: 따라서 IdP 에 따라서 다르다).

User-Agent:

최종 사용자의 웹브라우저. 특별한 플러그인이나 자바스크립트는 필요없다.

3. 개관

3.1. HTML 문서를 Identifier 로 바꾸기

Identifier를 처리하는 Identity 제공자를 Consumer에게 알리기 위해, 최종 사용자는 반드시 자신의 URL(역주: 최종 사용자의 Identifier URL) 에 위치한 HTML 문서의 HEAD 섹션에 markup 을 추가해야 한다. 이 HTML 문서의 호스트가 최종 사용자의 Identity 제공자가 되어야 할 필요는 없다(NOT REQUIRED); 그 Identifier URL 과 Identity 제공자는 완전히 분리된 서비스일 수 있다.

최종 사용자의 Identiifer 로 http://example.com/ 을 사용하고 Identity 제공자로 http://openid.example.com 을 사용하려면,  Identifier URL 을 가져올때 전송되는 HTML 문서의 HEAD 섹션에 다음 태그가 추가 될 것이다.

<link rel="openid.server" href="http://openid.example.com/">

3.1.1. 인증 위임하기

만일 최종 사용자의 호스트가  Identity 제공자를 구동할 수 없거나, 최종 사용자가 다른 호스트에서 운영되는 Identity 제공자를 사용하고자 한다면, 그들의 인증을 위임할 필요가 있다. 예를 들어, 최종 사용자는 자신의 웹사이트, http://www.example.com/, 를 자신의 Identifier로 사용하기를 원하지만 Identity 제공자를 운영할 수단이 없거나 운영하고 싶지 않을 수 있다.

만일 최종 사용자가 LiveJournal 계정을 하나 가지고 있고(사용자 "exampleuser" 이라 하자),  LiveJournal 이 OpenID Identity 제공자를 보유하여  최종 사용자가 http://exampleuser.livejournal.com/ 이라는 Identifier를 제어함을 보증한다면, 최종 사용자들은 자신들의 인증을 LiveJournal 의 Identity 제공자에게 위임할 수 있을 것이다.

즉, 최종사용자는 그들의 Identifier 로 www.example.com 을 사용하지만 Consumer 들이 실제로는 http://www.livejournal.com/openid/server.bml 에 위치한 Identity 제공자를 통해 http://exampleuser.livejournal.com/ 라는 Identifier를 검증토록 하기 위해, 최종사용자의 Identifier URL (www.example.com)을 가져올 때 전송될 HTML 문서의 HEAD 섹션에 다음 태그들을 추가해야 한다.

<link rel="openid.server" href="http://www.livejournal.com/openid/server.bml">

<link rel="openid.delegate" href="http://exampleuser.livejournal.com/">

이제, Consumer 가 해당 태그를 인식하면, http://www.livejournal.com/openid/server.bml 에게 그 최종 사용자가 exampleuser.livejournal.com 인지 여부를 질의한다. 이 과정에서 www.example.com 는 전혀 언급하지 않는다.

이 방식의 주요 장점은 최종 사용자가 자신 Identifier 를 여러 해 동안 유지할 수 있다는 것이다; 심지어 서비스들이 새로 나오고 또 사라지더라도 위임하는 Identity 제공자를 바꾸면서 같은 Identifier 를 계속 유지할 수 있다.

3.1.2. 중요 사항

• 명시된 openid.server URL 은 질의 파라미터들을 포함할 수도 있으며(MAY), 추가 파라미터를 붙일 때는 기존 파라미터들이 제대로 유지되어야 한다. 예를 들어, 이미 '?' 표시가 있다면 두번째 '?' 표시는 생략되야 한다(MUST)(역주: 'http://example.com/openid?param1=asdf'에 추가 파라미터인 '?param2=asdf' 를 붙일 때. 'http://example.com/openid?param1=asdf&param2=asdf'가 되어야 한다.)
• openid.server 와 openid.delegate URL 은 반드시(MUST) 절대 경로 형식의 URL 이어야 한다. Consumer 는 상대 경로 형식의 URL 을 해석하려고 시도하면 안된다(MUST NOT).
• openid.server 와 openid.delegate URL 은 &,<,>,"  이외의 엔터티들은 포함하지 말아야 한다(MUST NOT). 기타 HTML 문서에서 유효하지 않은 문자나 문서의 문자인코딩(character encoding) 으로 표현될 수 없는 문자들은 반드시 [RFC2396] (Berners-Lee, T., “Uniform Resource Identifiers (URI): Generic Syntax,” .) 의 기술을 따라 %xx 방식으로 escape 되야만 한다 (MUST).

3.2. 제시된 Identifier 제출하기

위 예제에서, 최종 사용자는 OpenID 인증을 지원하는 Consumer 사이트를 방문한다. Consumer 는 최종 사용자에게 Identifier URL 입력을 위한 폼입력란을 제시한다.

예를 들면:

          ----------------------------------

          |[logo]example.com               | [Login Button]

          ----------------------------------

3.2.1. 중요 사항

• 모든 Consumer 는 최종 사용자가 Identifier URL 을 입력하는 폼입력란 시작에 OpenID 로고이미지 를 표시할 것을 권장한다(RECOMMENDED).
• 최종 사용자는 그들의 Identifier URL 에 반드시 "http://" 로 시작하거나 '/' 로 끝낼 필요는 없다 (NOT REQUIRED). Consumer 는 반드시(MUST) Identifier URL 을, 모든 redirect 들을 따라가는 등, 정규화(canonicalize) 하여야 한다. 최종 URL 에 주목하자. 이 최종, 정규화된 URL 이 바로 최종 사용자의 Identifier 이다.
• 폼 입력란의 이름은 "openid_url" (역주: OpenID 2.0 버전의 "openid_identifier" 를 권장함) 을 권장하며(RECOMMENDED), 따라서 전자상거래 사이트들의 "address1", "address2" 같은 관습처럼 사용자 브라우저가 최종 사용자 Identifier URL 을 자동 완성 할 수 있을 것이다.

3.3. Consumer 사이트는 Identifier URL 내용을 가져온다

이제 Consumer 사이트는 최종 사용자가 제시한 Identifier 에 있는 문서를 읽어들인다. Consumer 는 HEAD 섹션을 파싱해서 "openid.server" 선언과 선택적으로 "openid.delegate" 선언을 가져온다.

3.3.1. 중요 사항

• 최종 사용자가 악의적일 수 있으므로 Consumer 를 내부 네트웤, 소위 늪(tarpit) 등, 에 접속시키려고 할 수도 있다. 이런 종류의 공격에 방어하기 위해 LWPx: : ParanoidAgent 같은 paranoid HTTP 라이브러리 사용을 권장한다(RECOMMENDED).
• Consumer 들은 반드시(MUST) 위임 (인증 위임하기)을 지원을 구현해야 한다.

3.4. Smart 대 Dumb 모드

OpenID 인증은 다른 성능의 Consumer 들을 수용하기 위해서 "smart mode" 와 "dumb mode" 를 지원한다. Smart Consumer 는 시작할 때 좀 더 많은 작업을 수행함으로서 나중에 적은 동작을 하지만, 상태 정보를 로컬 캐시로 유지할 필요가 있다. Dumb Consumer 는 상태를 전혀 유지하지 않지만, 한번의 HTTP 요청을 별도로 요구한다.

3.4.1. Smart 모드의 중요 사항

• Consumer가 사전에 공유 보안 값을 하나 캐시하고 있지 않다면, 먼저 associate 요청 (associate) 을 최종 사용자의 Identity 제공자에게 보내서 공유 보안 값을 하나 요청하길 권장한다(RECOMMENDED). 이 공유 보안 값은 만료될 때 까지 이후 Identity 확인 요청에서 HMAC-SHA1 키값으로 사용되어야 한다 (SHOULD).
• 이 공유 보안 값은 평문(plain-text) 이나 Diffie-Hellman 협상된 보안 값(Diffie-Hellman-negotiated secret)으로 암호화되어 전달될 수 있다. Dffie-Hellman은 accociate mode 에서만 사용할 수 있다. checkid_immediate 모드와 checkid_setup 모드는 Consumer 가 이미 공유 보안 값을, 어떻게 획득했건 간에, 하나 가지고 있다고 가정한다.

3.5. Consumer 는 Identifier 를 검증한다

이 Consumer 는 이제 Identity 제공자의 checkid_immediate (또는 checkid_setup) URL 에 대한 URL 을 하나 구성하여 User-Agent 를 그곳으로 보낸다.

User-Agent 를 해당 URL로 보냄으로써, 최종 사용자의 쿠키를 비롯한 모든 로그인 증명들이 그들의 신뢰하는 Identity 제공자에게 전송된다. 이 Identity 제공자는 자신의 작업을 수행하고, 전달된 openid.return_to URL 에 자신의 응답을 추가하여 User-Agent 를 원래의 Consumer 에게 돌려 보낸다.

4. Modes

4.1. associate

• 설명: Consumer 와 Identity Provider 간에 하나의 공유 보안 값을 정한다.
• HTTP method: POST
• 순서: Consumer -> IdP -> Consumer

4.1.1. 요청 인자들

• openid.mode

  값: "associate"

• openid.assoc_type

  값: 선호되는 association type

  기본값: "HMAC-SHA1"

  Note: 현재는 기본 값 하나만 지원

• openid.session_type

  값: 공백 또는 "DH-SHA1"

  기본값: 공백. (평문)

  Note: 이 공유 보안 값을 암호화 하려면 DH-SHA1 모드를 사용할 것을 권장한다

• openid.dh_modulus

  값: base64(btwoc(p))

  Note: 기본 p 값은 Appendix A.1 (Diffie-Hellman P Value) 을 참조하라.

• openid.dh_gen

  값: base64(btwoc(g))

  기본값: g = 2

  Note: DH-SHA1 session_type 을 사용할 때만 이용한다. openid.dh_modulus 값이 지정되면 이 값은 반드시 지정되어야 한다.

• openid.dh_consumer_public

  값: base64(btwoc(g ^ x mod p))

  Note: DH-SHA1 session_type 을 사용할 때는 반드시 필요하다.(REQUIRED)

4.1.2. 응답 인자들

Response format: Key-Value Pairs

• assoc_type

  값: 결과 핸들의 association type.

  Note: 현재 유일한 모드는 HMAC-SHA1 이며, 모든 Consumer 들은 반드시 지원해야 한다(MUST). 캐싱할때 Consumer 는 반드시 하나의 assoc_handle 에 그 보안값과 assoc_type 를 모두 매핑해야 한다(MUST).

• assoc_handle

  값: 이후 처리(transaction) 에 제공될 association 핸들.

  Note: Consumer 는 해당 expires_in 값 이후에는 이 핸들을 사용하면 안된다 (MUST NOT).

• expires_in

  값: 이 association 핸들이 유효한 시간(초), 10진수로 표시.

• session_type

  값: 이 Provider 가 선택한 암호화 모드. 공백, 생략, 또는 ""DH-SHA1" 일 수 있다(MAY).

• dh_server_public

  값: base64(btwoc(g ^ y mod p))

  Description: DH-SHA1 사용시, Provider 의 Diffie-Hellman public key (Rescorla, E., “Diffie-Hellman Key Agreement Method,” .) [RFC2631].

• enc_mac_key

  값: base64(SHA1(btwoc(g ^ (xy) mod p)) XOR secret(assoc_handle))

  Description: DH-SHA1 사용시, 암호화된 공유 보안값.

• mac_key

  값: base64(secret(assoc_handle))

  Description: DH-SHA1 미사용시, 평문으로된(plaintext) 공유 보안값.

4.1.3. 추가 사항

• Consumer 가 서버에 DH-SHA1 암호화를 요청했지만, 평문으로된 보안값을 받을 수도 있다. 만약 이것이 곤란하다면, 그 핸들을 사용하는 대신 그 Identity Provider 와는 dumb mode 를 사용하라.
  만약 누군가 그 평문으로된 보안값을 훔쳤다해도, 해당 association 핸들을 이용한 쿼리를 결코 받지 않을 것이므로, 문제가 되지 않는다. 만일 Identity Provider가 DH-SHA1을 사용할 수 없다면, 아마 어떤 식으로든 제한되있겠지만, Dumb 모드를 사용하는 것이 속도는 좀 느려지지만 여전히 안전하다.
• 만약 IdP가 서버 private key 를 1 <= y < p-1 로 선택한다면, 공유 DH-SHA1 보안값은 g ^ xy mod p = (g ^ x) ^ y mod p = (g ^ y) ^ x mod p. 좀더 자세한 사항은 Crypt::DH docs.
• 기본 mac_key 는 반드시 (MUST) hash 함수, H 의 출력 과 같은 길이여야 한다, 이경우 DH-SHA1 용 160 비트 (20 바이트).
• 만약 IdP 가 DH-SHA1 을 지원하지 않는다면, 그 IdP 는 요청의 DH-SHA1 관련 필드들을 무시하고 비 DH-SHA1 요청과 똑같이 처리할 것이다.
• DH-SHA1 를 사용할 때, 결과 키는 binary string 으로 취급되어야 한다(SHOULD).
• 모든 정수는 big-endian signed two's complement 로 표현되고, Base64 로 인코딩된다. 즉, btwoc 는 bigint 를 입력받아 그것의 가장 짧은 big-endian two's complement 표기를 출력하는 함수이다.

4.2. checkid_immediate

• 설명: 최종사용자가 제시된 Identifier 를 소유하고 있는지 Identity Provider 에게 묻고, 즉각적인 "예" 또는 "답변 불가" 응답을 받는다.
• HTTP method: GET
• 순서: Consumer -> User-Agent -> IdP -> User-Agent -> Consumer

4.2.1. 요청 인자들

• openid.mode

  값: "checkid_immediate"

• openid.identity

  값: 제시된(Claimed) Identifier

• openid.assoc_handle

  값: 앞의 associate 요청에서 받은 assoc_handle 값.

  Note: 선택적임; association 핸들이 제공되지 않거나 IdP가 유효하지 않다고 느낄 경우, consumer는 반드시 check_authentication을 사용해야 한다(MUST).

• openid.return_to

  값: Provider 가 User-Agent 를 가급적(SHOULD) 되돌려 보내야 하는 URL.

• openid.trust_root

  값: Provider 가 최종 사용자에게 신뢰여부를 확인해야(SHALL) 할 URL.

  기본: return_to URL

  선택: 최종 사용자가 승인하기 위해 실제로(SHALL) 보게 되는 URL 이어야 한다.

4.2.2. 응답 인자들

Response format: query string arguments

4.2.2.1. 항상 보내는 것

• openid.mode

  값: "id_res"

4.2.2.2. 입증(assertion) 실패시 보내는 것

• openid.user_setup_url

  값: 입증(asssertion)을 위해 필요한 일들을 사용자가 할 수 있도록 User-Agent 를 보내는 URL.

4.2.2.3. 긍정적 확답시 보내는 것

• openid.identity

  값: 검증된(Verified ) Identifier

• openid.assoc_handle

  값: 불투명한(Opaque) association 핸들로 서명을 위한 HMAC 키를 찾기 위해 사용된다.

• openid.return_to

  값: 요청 메시지에서 보낸 return_to URL 파라미터로 Provider가 수정하기 전에 복사한 것.

• openid.signed

  값: 콤마로 분리된, 서명된 필드들 목록.

  Note: 서명된 필드명들의 "openid." 은 생략한다. 예를 들면, "mode,identity,return_to".

• openid.sig

  값: base64(HMAC(secret(assoc_handle), token_contents)
  Note: token_contents는 키-값 형식의 문자열로, 응답 메시지에 포함된 모든 서명된 키와 값을 가리킨다. 이 값은 openid.signed 필드에 있는 순서와 반드시 동일하게 위치되어야 한다(MUST). consumer는 서명을 체크하기 전에 token_contents를 재생성 해야한다(SHALL). Appendix D (Limits)을 참조.

• openid.invalidate_handle

  값: 선택적임; 요청 메시지에서 보내진 association 핸들로서, provider가 받아들이지 않거나 인식하지 못할 경우에 보낸다.

4.2.3. 추가 사항

• 이 방식은 "AJAX"-스타일의 셋업에 주로 사용된다. 제시 Identifier 를 검사하기 위한 좀더 전통적인 방식은 checkid_setup (checkid_setup)이다.
• Identity Provider 는 가급적 자신이 직접 관리/생산하는 URL 들만 입증해 주어야 한다(SHOULD). 만약 최종 사용자가 Identity Provider 영역밖의 URL들에 대한 인증을 원한다면, 반드시 (MUST) 위임 (인증 위임하기) 을 이용해야 한다.
• openid.return_to URL 은 원래 있던 query string 을 포함할 수 있으며(MAY), Provider 는 response parameter 들을 붙일 때 그것을 반드시(MUST) 유지 시켜줘야 한다. OpenID Consumer 는 replay 공격을 막기위해 가급적 Consumer 시각 (Consumer-local timestamp)으로 직접 서명한 일회용 보안값(nonce)을 openid.return_to URL 파라미터로 추가해야 한다(SHOULD). 그 세부 사항은 Consumer 몫이다.
  하지만, openid.return_to URL 이 Identity Provider 에 의해 서명되었기 때문에 Consumer 는 엉뚱한 제3자가 맞지 않는 openid.return_to URL 과 서명을 보낸 것은 아닌지 확인할 수 있다.
• Identity Provider 가 제공된 assoc_handle 을 어떤 이유에서건 거부하거나 인식하지 못했다면, 자체생성한 것을 대신 사용하고 원래 제공된 것은 openid.invalidate_handle 값으로 되돌려보내서 Consumer 가 더이상 그 핸들을 사용하지 못하도록 지시한다. 그러면 Consumer 는 가급적 (SHOULD) 그 핸들을 check_authentication (check_authentication) 요청에 함께 보내서 정말 그것이 더 이상 올바른 것이 아닌지 검증해야 한다.
• Identifier 입증이 실패한다면, IdP는 openid.user_setup_url 을 제공해서 거기서 최종 사용자가 입증을 위해서 필요한 것들, 로그인, 승인 설정 등을 할 수 있게 한다. 서버는 필요한 어떠한 것도 암시하지 않는 URL 을 제공하여, Consumer 가 입증 실패의 이유에 대해서 전혀 알 수 없게 해야 한다(SHOULD).
  IdP 처리는 결국에는, checkid_setup 처럼, "id_res" 또는 "cancel" 답변과 함께 최종 사용자를 openid.return_to URL 로 돌려보내야 한다(SHOULD).
• openid.return_to URL 은 반드시(MUST) openid.trust_root 의 하위 URL 이어야 하며, 아니면 IdP 는 오류를 내야한다(SHOULD). 즉, URL scheme 과 포트는 같아야 한다(MUST). 경로부분이 있다면 openid.trust_root 값과 같거나 하위경로여야 하며, 도메인은 반드시 같거나, openid.trust_root 값이 http://*.example.com 처럼 와일드카드(*) 를 포함하고 있으면 매치되야 한다. 와일드카드는 오직 호스트명에만 가능하다(SHALL). IdP 는 가급적 http://*.com/ 이나 http://*.co.uk/ 같은 요청으로 부터 사용자를 보호해야 한다.
• 응답에 IdP 의 서명은 반드시(MUST) openid.identity 와 openid.return_to 를 포함해야 한다.

4.3. checkid_setup

• 설명: IdP 에게 최종 사용자가 제시된 Identifier 를 소유하고 있는지 묻고, 응답을 위해 기꺼이 기다린다. Consumer 는 User-Agent 를 IdP 에게 잠시 넘기며 IdP 는 "yes" 나 "cancel" 응답을 돌려준다.
• HTTP method: GET
• 순서: Consumer -> User-Agent -> [IdP -> User-Agent ->]+ Consumer

4.3.1. 요청 인자들

• openid.mode

  값: "checkid_setup"

• openid.identity

  값: 제시된(Claimed) Identifier

• openid.assoc_handle

  값: 앞의 associate 요청에서 받은 assoc_handle 값.

  Note: 선택적임; association 핸들이 제공되지 않거나 IdP가 유효하지 않다고 느낄 경우, consumer는 반드시 check_authentication을 사용해야 한다(MUST).

• openid.return_to

  값: Provider 가 User-Agent 를 되돌려 보내야 하는(SHOULD) URL.

• openid.trust_root

  값: Provider 가 최종 사용자에게 신뢰 여부를 확인해야(SHALL) 할 URL.

  기본: return_to URL

  선택: 최종 사용자가 승인하기 위해 실제로(SHALL) 보게 되는 URL 이어야 한다.

4.3.2. Respone Parameters

Response format: query string arguments

4.3.2.1. 항상 보내는 것

• openid.mode

  값: "id_res" 또는 "cancel"

4.3.2.2. 긍정적 확답에 보내는 것

• openid.identity

  값: 검증된(Verified ) Identifier

• openid.assoc_handle

  값: 불투명한(Opaque) association 핸들로 서명을 위한 HMAC 키를 찾기 위해 사용된다.

• openid.return_to

  값: 요청 메시지에서 보낸 return_to URL 파라미터로 Provider가 수정하기 전에 복사한 것.

• openid.signed

  값: 콤마로 분리된, 서명된 필드들 목록.

  Note: 서명된 필드명들의 "openid." 은 생략한다. 예를 들면, "mode, identity, return_to".

• openid.sig

  값: base64(HMAC(secret(assoc_handle), token_contents)

  Note: token_contents는 키-값 형식의 문자열로, 응답 메시지에 포함된 모든 서명된 키와 값을 가리킨다. 이 값은 openid.signed 필드에 있는 순서와 반드시 동일하게 위치되어야 한다(MUST). consumer는 서명을 체크하기 전에 token_contents를 재생성 해야한다(SHALL). Appendix D (Limits)을 참조.

• openid.invalidate_handle

  값: 선택적임; 요청 메시지에서 보내진 association 핸들로서, provider가 받아들이지 않거나 인식하지 못할 경우에 보낸다.

4.3.3. 추가 사항

• 응답에 IdP 의 서명은 반드시(MUST) openid.identity 와 openid.return_to 를 포함해야 한다.
• 대개의 경우, Consumer 가 cancel 모드 응답을 받지는 않을 것이다; 사용자는 그냥 나가거나 브라우저에서 back 버튼을 눌러버릴 것이다. 그러나 만약 돌아온다면 Consumer 는 가급적 진행중이던 곳으로 가야한다(SHOULD). cancle 모드의 경우에는, 나머지 응답 인자들은 생략된다.

4.4. check_authentication

• 설명: IdP 에게 메시지가 올바른지 묻는다. 상태가 없는 Dumb 모드 Consumer 를 위해 또는 invalidate_handle 응답을 검증할 때 사용한다.
  주의: 상태없는 association 핸들을 가진 서명만 검증한다. IdP 는 누군가와 공유된 보안값을 가지는 association 핸들용 서명은 결코 검증하면 안된다(MUST NOT). IdP 는 상태없는 핸들과 상태있는(associated) 핸들을 구별해야만 하며(MUST), 상태없는 핸들에 대해서만 check_authentication 서비스를 해야한다.
• HTTP method: POST
• 순서: Consumer -> IdP -> Consumer

4.4.1. 요청 인자들

• openid.mode

  값: "check_authentication"

• openid.assoc_handle

  값: checkid_setup 이나 checkid_immediate 응답의 association 핸들.

• openid.sig

  값: consumer 가 검증하길 원하는 checkid_setup이나 checkid_immediate 요청의 서명.

• openid.signed

  값: consumer 가 서명을 검증 하려는 checkid_setup이나 checkid_immediate 요청에 있는 서명된 필드들 목록.

• openid.*

  값: consumer는 반드시 openid.signed 목록에 있는 모든 openid.* 응답 파라미터를 전송해야 하며(MUST), 이 목록은 checkid_setup이나 checkid_immediate 요청에서 얻은 것으로, provider로부터 받은 값을 그대로 사용해야 한다.

• openid.invalidate_handle

  값: 선택적임: invalidate_handle로 반환된 association 핸들.

4.4.2. 응답 인자들

Response format: Key-Value Pairs

• openid.mode

  값: "id_res"

• is_valid

  값: "true" 또는 "false"

  설명: Boolean; 서명이 유효한지 여부.

• invalidate_handle

  값: 불투명한(opaque) association 핸들

  설명: 존재한다면, consumer는 반환된 association 핸들을 캐시에서 지워야(uncache) 한다(SHOULD).

4.4.3. 추가 사항

• IdP는 에러 복구 및 상태를 스스로 유지할 수 없는 dumb consumer를 위해 이 모드를 구현해야 한다(MUST). 하지만 이 기능은 대부분 필요없기 때문에 최대한 적게 사용하길 권한다(RECOMMANDED). 그럼에도 불구하고 당신이 Consumer 라이브러리를 직접 개발할 경우에는, 이 기능이 디버깅 과정에서 유용하게 활용된다.
• 만일 checkid_setup이나 checkid_immediate 요청에서 invalidate_handle 응답을 수신했다면, 이는 IdP가 해당 association 핸들을 인식하지 못했음을 의미하며, 아마도 분실해서 자체 핸들을 선택한 것이다.
  따라서, IdP가 사용하는 공유 보안값을 가지고 있지 않기 때문에, Consumer는 dumb 모드로 대체해야 함을 뜻한다. 이 check_authentication 요청을 처리하는 과정에서, IdP의 invalidate_handle 응답을 함께 전달하면 해당 요청이 실제로 누락/조작되었는지 검사될 것이다.
• openid.* 쿼리 값을 이용해 서명 검증할 때, openid.mode 값은 반드시 "id_res"로 변경되어야 한다.

5. 보안 고려 사항

• OpenID 인증 프로토콜이 주로 HTTP를 대상으로 하지만, 추가적인 보안을 위해서 HTTPS가 사용될 수 있다. HTTPS 는 associate 모드에 사용되어 man in the middle, DNS, 피싱(phishing) 공격 등에 방어를 돕도록 권고된다 (RECOMMENDED).
• Consumer는 최종 사용자가 OpenID로 로그인할 때, IFrame이나 popup을 사용해서는 안된다 (SHOULD NOT).

Appendix A. Default Values

Appendix A.1. Diffie-Hellman P Value

1551728981814736974712322577637155\ 3991572480196691540447970779531405\ 7629378541917580651227423698188993\ 7278161526466314385615958256881888\ 8995127215884267541995034125870655\ 6549803580104870537681476726513255\ 7470407658574792912915723345106432\ 4509471500722962109419434978392598\ 4760375594985848253359305585439638443

Appendix B. Error Responses

이 섹션은 프로토콜/런타임 오류에 속하는 것으로, 인증 오류는 아니다. 인증 오류들은 프로토콜에 명시된다.

• 정해진 에러 코드가 없음; 단지 구조화되지 않은 오류 텍스트.
• 잘못된 인수로 GET 요청을 한 경우, 유효한 openid.return_to URL 이 있다면, IdP는 openid.mode=error, openid.error=Error+Text 를 붙여서 User-Agent 를 거기로 이동시켜야 한다(SHALL).
• 잘못된 인수로 GET 요청을 한 경우, 유효한 openid.return_to URL이 없다면, IdP는 임의의 content-type 과 에러 메시지 와 함께 "400 Bad Request" 를 반환하여야 한다(SHALL).
• 인수 없이 GET 요청을 한 경우, IdP는 200 text/html 응답에 "This is an OpenID server endpoint. For more information, see http://openid.net/" 라는 에러 메시지를 보여주어야 한다(SHALL).
• 잘못된 인수 혹은 인수 없이 POST 요청을 한 경우, IdP는 400 Bad Request 응답 코드와 함께 "error"가 유일한 키이고 값으로 에러 문장이 들어간 Key-Value 응답 포맷을 반환해야(SHALL). 이 경우 IdP는 원할 경우 임의의 키들을 추가할 수 있다.

Appendix C. Key-Value Format

Lines of:

• 어떤 키: 어떤 값
• 콜론(: )앞 뒤에 공백이 있어서는 안된다(MUST NOTE)
• Newline 문자는 반드시 유닉스-형식으로, ASCII 문자 10("\n") 만 이어야 한다(MUST).
• Newline 은 라인들 사이는 물론 각 라인의 끝에 위치해야 한다(MUST BE).
• MIME 타입은 명시하지 않았으나, text/plain 을 권고한다(RECOMMENED).
• 문자열 인코딩은 반드시 UTF-8 이어야 한다(MUST).

Appendix D. Limits

• Identifier URL: 최대 255 바이트
• IdP URL: consumer가 추가한 URL 인수까지 합해 최대 2047 바이트. 원본 endpoint URL 자체는 이보다 작게 유지되어야 한다(SHOULD).
• return_to URL: IdP가 추가한 URL 인수까지 합해 최대 2047 바이트. return_to URL 자체는 이보다 작게 유지되어야 한다(SHOULD).
• assoc_handle: 255 문자 이하, ASCII 코드 33-126 사이(포함해서)의 문자들로만 구성됨(즉, 출력 가능한 비공백 문자들).

Appendix E. Misc

• 시간은 반드시 w3c 포맷을 따르며, "Z"로 표시되고, UTC 시간대에 있어야만 한다. 예를 들면, 2005-05-15T17:11:51Z

6. Normative References

Authors' Addresses