내사이트 오픈아이디 요리법

Prepared by Joseph Smarr at Plaxo on July 18, 2007.

이것은 기존에 이미 회원기반을 보유하고 있는 웹사이트에 오픈아이디 (OpenID) 인증을 적용하기 위한 단계별 튜토리얼 가이드 이다. 이것은 새로운 사용자들이 그들이 이미 보유하고 있는 오픈아이디를 가지고 당신 사이트에 가입하여 계정을 만들도록 하는 방법을 설명할 것이다. (역주: 향후 1~2 년 내에 많은 국내 포탈들이 일괄로 오픈아이디를 보급하게 될 것이며, 이 경우, 포탈 사용자들이 쉽게 당신 사이트의 회원이 될 수 있습니다.)  또한, 사이트의 기존 회원들이 그들의 오픈아이디(들)을 그들 계정에 연결시키고 그 오픈아이디로 로그인 할 수 있는 쉬운 방법도 설명할 것이다. 나는 이 가이드를 Internet Identity Workshop 등에서 동료 오픈아이디 개발자들에게 말하면서 만들게 되었으며, 이것으로  Plaxo 의 OpenID 지원 을 구현했다. 나는 또한 참고를 위해서 Plaxo 의 구현에 대한  상세한 스크린샷 을 포스팅 했다. 나는 이 가이드를 Best-practices 로서 따라하기에 명확하고 완결되도록 의도했지만, 의문점이나 어떤 피드백이 있다면 joseph@plaxo.com  로 메일을 보내거나 Plaxo's blog 에 코멘트를 남겨주길 바란다. 이 가이드는 다소 길어보이지만, 바라건데 별 생각없이 끝까지 따라가는 것 만으로도 구현이 될 것이다! :)

개략

나는 당신의 웹사이트에 대해 다음과 같은 것이 있음을 가정한다:

• 각 회원별 레코드들을 가진 회원 데이타베이스

  • 각 회원은 유일한 내부 회원 식별키를 가지고 있다
  • 회원들은 사용자명(또는 이메일주소)과 비밀번호를 이용해서 로그인 한다.
• 새로운 사용자들을 위한 가입 등록 절차와 기본적인 프로필 정보 수집 절차.

• 사용자 인증을 위한 로그인 페이지

  • 내부적으로 당신은 사용자명(또는 이메일주소)과 비밀번호로 인증을 한후, 회원 식별키를 찾아 사이트 내에서 사용한다.

   

• 사용자들이 계정을 관리할 수 있는 설정 페이지

만약 당신의 사이트가 이와 같지 않더라도, 여전히 아래 사항들을 따라갈 수 있다. 그러나 몇몇 섹션은 당신에게 해당사항이 아닐 수도 있다.

당신의 사이트에 추가하게될 대략적인 사항들은 다음과 같다:

1. OpenID 를 당신사이트의 내부 사용자 식별키로 매핑하기 위한 데이타베이스 새 테이블 하나

   • 그것은 다-대-일 관계이다. (각 사용자 계정에는 여러개의 OpenID 들을 가질수 있습니다만, 하나의 OpenID 에 대해서는 오직 한 사용자에 의해서만 제시될 수 있습니다.)
   • 이 테이블은 OpenID 로 사용자들을 찾기위한 전역 레지스트리가 될것입니다, 따라서 일반적으로 당신은 모든 당신의 사용자를 담는 하나의 공유 테이블로 만들어야 합니다.

2. 신규 사용자를 위한 가입 페이지 에 약간의 OpenID 관련 사용자 인터페이스

   • 신규 사용자들은 그들의 오픈아이디 를 입력하고, 그들의 오픈아이디 인증서비스와 인증을 한후, 당신의 가입 절차로 당신 사이트와 공유하기 위해 선택한 프로필 정보들을 가지고 인증된체로 돌아온다.

3. 기존 사용자들을 위한 로그인 페이지에 약간의 OpenID 관련 사용자 인터페이스

   • 본인들 계정에 오픈아이디 를 연결한 사용자들은 그들의 OpenID 를 입력할 것이며, 그들의 오픈아이디 인증서비스와 인증을 한후, 인증된 체로 당신의 로그인페이지로 돌아온다. 당신은 그들의 오픈아이디를 그들의 사이트내 사용자 식별키로 매핑할 수 있고, 따라서 그들이 마치 기존의 사용자명(또는 이메일)과 비밀번호로 로그인한 것처럼 로그인 시킨다.
4. 사용자들이 계정에 연결된 오픈아이디들을 나열,추가,삭제할 수 있는 설정 페이지

당신이 구현할 것들을 요약하면 다음과 같다:

1. 하나의 오픈아이디 데이타베이스 테이블

   • 컬럼: (openid_url, user_id). openid_url 는 텍스트 문자열, user_id 은 현재 당신이 내부 사용자 키로 사용하는 것.
   • openid_url 에 PK (유일함, OpenID 로 사용자들을 검색하기 위해)
   • user_id 에 색인 (특정 사용자 계정에 연결된 모든 OpenID 들을 나열하기 위해)

2. 하나의 웹페이지/CGI , 사용자가 입력한 오픈아이디 를 검색한후 그들의 오픈아이디 인증서비스로 보낸다 (redirect)

   • 입력된 오픈아이디가 이미 당신 사이트의 기존 사용자 소유인지 검색한다.
   • (오픈아이디 라이브러리로) 오픈아이디 인증서비스로 보내어 사용자가 인증할 수 있도록 한다 (세부 사항은 아래에)

3. 하나의 웹페이지/CGI, 사용자의 오픈아이디 인증서비스로 부터의 응답을 처리한다.

   • (오픈아이디 라이브러리로) 응답을 검증한다.
   • 새 사용자들의 경우, 당신의 가입 절차로 보내며 오픈아이디 인증서비스로 부터 보내진 등록정보들로 등록 정보들을 미리 채운다. 또한 당신은 당신의 가입절차를 약간 수정해서 그 사용자들에게는 비밀번호 등록을 하지 않도록 해야할 것이다 (왜냐하면 그들은 이미 그들의 오픈아이디로 인증을 할 것이므로).
   • 기존 사용자들의 경우, (오픈아이디 인증을 처음한 아이디라면) 그들의 계정에 인증된 오픈아이디를 연결해둘 필요가 있으며, 해당되는 사용자키를 찾아서 그들의 계정으로 로그인 시킨다.

    

4. 하나의 웹페이지/CGI, 사용자 계정에 연결된 오픈아이디들을 관리한다.

   • 현재 로그인한 사용자에게 연결된 모든 오픈아이디들을 구해서 나열할 수 있다.
   • 사용자에게 오픈아이디를 추가로 연결할 수 있게 한다. (위에 언급한 절차를 이용한다)
   • 기존의 오픈아이디를 연결을 제거할 수 있게 한다.
5. 사용자 삭제 코드에 코드를 추가 삽입하여, 계정 삭제시 연결된 모든 오픈아이디들을 연결 제거 한다.

바로 시작하기 위해서 다음 리소스들이 필요할 것이다:

• 당신의 프로그래밍 언어로 된 오픈아이디 컨슈머 라이브러리. Plaxo 의 서버는 C++ 로 되있다, 그래서 우리는 libopkele 을 이용했다 (이런 훌륭한 오픈소스 라이브러리를 제공한 Michael 과  Klever 팀원들에게 감사한다!), 그러나 다른 언어로된 라이브러리들 도 많이 있다.
• 몇가지 표준 오픈아이디 이미지들도 있어서, 사용자 인터페이스에 이용한다. 예를 들면 small icon 과 로고들 (small, normal, PDF)
• 테스트를 하기 위한 오픈아이디 인증 서비스들. 몇가지 예를 들면, 한글로는 myID.net, idtail.com, 영문으로는 MyOpenID.com, ClaimID 등이 있다. 또한 당신이 만약  AOL/AIM 스크린명을 가지고 있다면 http://openid.aol.com/SCREENAME 을 오픈아이디로 쓸 수도 있다. 만일 Daum 블로그 계정을 가지고 있다면, 다음 블로그 주소도 오픈아이디로 쓸 수 있다 (먼저 openid.daum.net 에서 설정하기 바란다.)

오픈아이디 컨슈머 지원을 구현하면 다음과 같은 잇점을 즉시 누릴수 있다:

• 이미 오픈아이디를 가진 120 만 (국내 10 만 ~ 100 만, 포탈 오픈아이디 제공 예상) 사용자들이 당신의 사이트에 전보다 훨씬 쉽고 빠르게 가입할 수 있다, 그 이유는 사용자들이 새로운 로그인 아이디와 비밀번호를 만들고 기억할 필요가 없어질 것이기 때문이며, 또한 가입 정보를 자동으로 미리 채울 수 있기 때문이다.
• 당신은 사용자들의 오픈아이디들을 모으기 시작할 수 있고, 따라서 점점더 많은 오픈아이디 지원 서비스들이 늘어감에 따라 당신의 사용자들은 쉽게 당신의 사이트와 연계한 그 서비스들의 장점을 이용할 수 있게 된다.
• 또한, 당신은 온라인 아이덴티티 분야의 유망한 오픈 표준을 지원함으로써 당신의 사용자들에 대한 공헌와 사려깊은 리더쉽을 과시할 수 있을 것이다.

추가로, 오픈아이디 지원이 확산됨에 따라서, 미래에는 다음과 같은 추가적인 잇점들이 당신을 기다리고 있다:

• 당신의 사용자 계정을 다른 사이트의 그 사용자 계정과 자동적으로 연결할 수 있어서 매쉬업들을 위한 정보를 공유할 수 있고, 여러 사이트에 같은 정보를 반복적으로 입력해야 하는 사용자들의 번거로움과 불편과 짜증을 제거할 수 있다.
• 사용자들이 다른 사이트에서의 그들의 정보 변경을 통지받을 수 있어서, 당신의 사이트에 항상 그들의 최신 정보를 유지할 수 있다.
• 다른 사이트로 부터 믿을 만한 사실들을 서명된 체로 받을 수 있으며, 이중에는 연령 검증, 확인된 이메일 주소, 회원여부 확인 등 이외에도 더 있다. (한국에는 실명 인증 확인 등도 해당된다)

구현 상세

1. 오픈아이디 컨슈머 라이브러리를 설치한다

   • 이미 대부분의 프로그래밍 언어로 구현된  오픈아이디 라이브러리들 이 있어서 거의 대부분의 어려운 작업들은 다 처리할 것이다. JanRain 개발팀이 그중 많은 부분을 작성했으며 오픈아이디에 관해서는 엄청 똑똑하고 박식하기 때문에, 만약 좀더 도움이 필요하다면 그들이 좋은 정보원이 된다.
   • 라이브러리에 따라서는, 오픈아이디 인증 사이트와의 연관정보를 저장하기 위한 영구적인 저장소 (persistent store, 파일 또는 DBMS) 를 필요로 할 것이다. 본질적으로 이것은 인증서버/처리기 문자열을 하나의 연관 문자열로의 매핑을 저장하는 것 뿐이다. 당신은 최소한 해당 세션 (오픈아이디 인증을 검증하기 위한) 동안만 연관정보를 저장하면 되지만, 이상적으로는 더 오래동안 그 값을 저장함으로써 매번 그 오픈아이디 인증서비스로 보낼 때 마다 연관을 다시 수립하지 않아도 된다 (그렇게 함을써 훨씬 빠른 처리가 이루어 진다). 당신은 메모리 캐시, 데이타베이스, 이외에도 당신이 이용할 수 있는 다른 어떤 저장소도 이용할 수 있다.

2. 오픈아이디 데이타베이스 테이블을 하나 만든다

   • 다음과 같은 스키마를 이용한다 (이것은 MySQL 에서 작동하지만, 만약 다른 데이타베이스 또는 다른 내부 사용키를 사용하는 경우에도 약간만 변경하면 된다):

     create table user_openids (
     
       openid_url varchar(255) not null,
     
       primary key (openid_url),
     
       user_id int not null,
     
       index (user_id)
     
     );
     

   • 하나의 전역 테이블로 유지해야 당신의 모든 사용자를 OpenID 로 검색할 수 있다 (심지어 당신의 사용자들이 여러 데이타베이스로 분할되어 있는 경우에도).
   • 오픈아이디 URL 들은 대표형식 (canonicalized ) 으로 저장해야 튼튼한 검색이 된다 (그래야, 만약 사용자들이 그들의 오픈아이디를 매번 약간씩 다르게 입력하더라도 그들의 계정에 매핑할 수 있게 된다). 대부분의 오픈아이디 라이브러리들은 대표화 함수를 제공할 것이지만, 요약해 보면 'http://' 가 빠진 경우에 추가해야 하고, 프로토콜과 서버도메인의 문자만 모두 소문자로 변환한다 (그러나, URL 의 나머지 부분은 아니다.), 그래서 예를 들면 "WWW.AOL.COM/myOpenID" 는 "http://www.aol.com/myOpenID" 로 저장되어야만 한다.  또한 URL 의 끝나는 '/' 들은 모두 제거해야 할 수도 있다. (보통, 호스트 바로 뒤의 '/' 는 오히려 붙인다.)

   • 보통 데이타베이스 접근 코드 레이어가 있는 경우, 당신은 아래의 함수들을 당신의 애플리케이션들에 제공해야 한다 (각각에 대해 구현 SQL 들을 대충 제시해 놓았다). 다시 상기시키지만, 오픈아이디를 인자로 받는 모든 함수들은 데이타베이스에서 검색하기 전에 반드시 대표화를 시켜야만 한다.

     • GetUserId(openid_url)
       select user_id from user_openids where openid_url = openid_url
     • GetOpenIDsByUser(user_id)
       select openid_url from user_openids where user_id = user_id
     • AttachOpenID(openid_url, user_id)
       insert into user_openids values (openid_url, user_id)
     • DetachOpenID(openid_url, user_id)
       delete from user_openids where openid_url = openid_url and user_id = user_id
     • DetachOpenIDsByUser(user_id)
       delete from user_openids where user_id = user_id

    

3. 당신의 가입페이지에 오픈아이디 UI 를 추가한다. (참고: 권장표준스타일가이드)

   • 당신의 가입페이지에 오픈아이디 사용자들이 오픈아이디로 가입할 수 있는 부분을 추가하라. UI 의 목표는 오픈아이디 사용자들이 쉽게 당신 사이트의 오픈아이디 지원을 인지하도록 하지만, 오픈아이디가 없는 사용자들도 혼선없이 정상적인 가입을 수행하도록 하는 것이어야 한다. 당신은 가입페이지에 오픈아이디 입력란을 직접 배치할 수도 있고 따로 오픈아이디를 입력하는 오픈아이디 페이지를 두고 링크만 줄 수도 있다.

   • 오픈아이디 입력란은 어디에 두던간에, 커뮤니티 표준의 이름과 스타일을 따라야 한다:

     • 오픈아이디 입력 텍스트 필드의 ID 와 name 속성에는 "openid_identifier" ("openid_url" 은 1.0 국내에서는 지양)  (이것은 플러그인등의 프로그램이 서로 다른 사이트들간에도 쉽게 오픈아이디 입력란은 인식하고 자동화 처리가 가능하게 하는, 단순하지만 강력한 관습입니다. 꼭 지키는 것이 네트웤효과에 편승할 수 있는 방법입니다.)

     • 오픈아이디 입력 텍스트 필등의 배경에는 표준 small OpenID logo 를 다음의 CSS 를 이용해서  깔아줍니다:

       background: #FFFFFF url('/images/openid-icon-small.gif') no-repeat scroll 0pt 50%;
       
       padding-left: 18px;
       

      

   • 당신의 사이트에 오픈아이디가 무엇이며 어떻게 사용할 수 있는지에 대한 간략한 설명을 제공하는 것도 좋은 생각이다 (왜냐하면 호기심에 차서 쭉 둘러보는 사용자들이 아마도 꽤 있을 것이기 때문이다).
   • 오픈아이디 입력란은 포함하는,  이제 구현하게 될 오픈아이디 로그인 CGI 로의 submit 폼을 하나 만들어라.
   • 오픈아이디 인증서비스에 오픈아이디를 제공하고 인증하는 도중에, 당신은 사용자를 약간 다른 가입페이지로 다시 돌려보낼 필요가 있다. 첫째로, 사용자가 등록하려고 하는 오픈아이디를, 권장하건데 사용자가 일관되게 식별할 수 있도록, 오픈아이디 로고를 앞에 달아서 보여주어야 한다. (아래의 샘플 화면을 참고하라). 둘째로,  당신은 절대로 사용자에게 사이트 전용 비밀번호를 요구해서는 안된다, 왜냐하면 사용자들은 오픈아이디로 인증도중일 것이기 때문이다. 따라서, 비밀번호 입력란은 가려야 하며, 당신의 가입 로직이 이것을 허용하도록 한다 (만일 당신 코드가 이것을 필수로 한다면, 임의로 자동 생성된 비밀번호를 채워넣고, 사용자에게는 보이지 않는 방법도 있겠다). [주: 사이트 전용 비밀번호는 이후에 따로 계정 설정 페이지 등에서 입력받는 것도 좋겠지만, 여기서 중요한 점은 오픈아이디 사용자들에게 주는 핵심 가치는 그들이 더이상 그들이 사용하는 모든 사이트에 각각의 비밀번호/인증서를 따로 따로 유지할 필요가 없게 하는 것임을 명심해야 한다.]
   • Plaxso 가입 절차에 어떻게 오픈아이디를 추가했는지를 보여주는 스샷들이다:
     

    

4. 당신의 로그인 페이지에 오픈아이디 UI 를 추가한다

   • 오픈아이디 사용자가 자신의 오픈아이디를 이용하여 로그인 할 수 있는 섹션을 당신의 로그인 페이지에 추가하라. 이것은 오픈아이디와 자신의 계정을 연결한 당신 사이트의 기존 사용자와 새로운 사용자 모두에게 작동하는 것이며, (위에서 본 것과 같은 과정을 이용하여) 이들은 자신의 오픈아이디를 이용하여 로그인 할 수 있을 것이다. 가입페이지에서와 같이, UI는 오픈아이디 사용자에게 지나친 혼동을 주지 않고 나머지 사용자들에게도 혼동을 주지 않도록 균형을 맞추는 것을 목표로 해야 한다. 위에서 본 가입페이지에 적시되어 있는 것처럼 오픈아이디 (로그인)박스에 이름을 붙이고 스타일을 입혀라. 그리고 위와 같이, 오픈아이디 입력란을 감싸고 있는 폼은 당신이 만들고자 하는 로그인 CGI로 전송되어야 한다.
   • 메인 로그인 페이지에 더하여, 홈페이지 어디에나 로그인 UI를 둘 수도 있을 것이다. 전통적인 로그인 옵션을 제공하는 자리에는 어디라도 오픈아이디를 이용하여 로그인 할 수 있는 옵션을 두어야 한다.
   • Plaxo의 로그인 페이지에 어떻게 오픈아이디를 추가했는지를 보여주는 스크린샷을 보자:
     

    

5. 새로운 오픈아이디 로그인 페이지 / CGI 를 만든다.

   • 당신의 CGI는 두 개의 기본적인 입력(쿼리) 파라미터를 받아야 한다:

     • openid_identifier (또는 1.0 스펙은 openid_url ): 사용자가 입력한 오픈아이디 (가입, 로그인, attaching 등을 위한)
     • action_type: 사용자가 수행하고자 하는 작업. 가능한 값들은 login, complete, attach, list 와 delete 등 일 것이다. (만약 당신이 레일즈나 비슷한 시스템을 사용하고 있다면, 이것들은 컨트롤러의 메쏘드가 될 수도 있으며, 따라서 URL 그 자체의 부분일 수 있다.)

   • 로그인 액션 구현하기 (여기로 가입페이지와 로그인 flow에 당신이 추가한 UI가 모두 submit 할 것이다.)

     1. 사용자가 입력한 openid_url을 위에서 기술한 GetUserId 함수를 이용하여 찾는다.

     2. 그 오픈아이디가 이미 당신의 시스템에 attach되어 있다면, 그 사용자가 현재 당신의 사이트에 로그인되어 있는지 확인하라.

        1. 사용자가 로그 인해 있지 않다면, 기존 사용자로 로그인을 시도하는 중인 것이므로, 오픈아이디 인증서비스로 리다이렉트 해야 한다. 이때 (사용자가 새로운 계정을 생성하려하는 것이 아니므로) 오픈아이디 인증서비스에 등록 정보를 요청하지 않도록 플래그를 셋팅한다.
        2. 사용자가 로그인한 상태이고 오픈아이디가 그 사용자의 것이라면 (즉, 오픈아이디가 현재 로그인되어 있는 사용자의 user_id와 매핑되어 있는 경우), 아무것도 할 필요가 없다. (이 사용자는 로그인되어 있고 이미 오픈아이디도 attach되어 있으므로, 오퍼레이션을 수행하지 않는다.) 이 케이스는 경계 케이스가 된다.
        3. 사용자가 로그인한 상태이지만 오픈아이디가 다른 사용자의 것이라면, 이 오픈아이디는 다른 사용자가 소유한 것이라는 에러 메시지를 출력해야 한다. 이때 사용자에게 로그아웃 후, 재시도할 수 있는 옵션을 제공할 수 있다. 이 케이스는 경계 케이스가 된다.
     3. 그 오픈아이디가 당신의 데이터베이스에 없다면 사용자가 새 계정을 생성하려는 것이므로, 오픈아이디 인증서비스로 리다이렉트 해야 하며, 등록 정보를 요청해야한다.
     4. 오픈아이디 인증서비스가 당신의 서비스로 리다이렉트를 통해서 인증 결과를 전달할 때, 서비스는 오픈아이디를 기억해야 할 것이나, 오픈아이디 인증서비스는 오픈아이디를 리턴하지 않을 수도 있다. 따라서 오픈아이디를 세션에 저장해야 한다, 세션이 아니라면 당신의 데이터베이스에 저장할 수도 있으나, 그 데이터베이스는 영속적이고 사용자의 위변조로부터 보호되는 곳(사용자가 위변조할 수 있는 쿠키같은 것이 아닌 곳)이어야 한다.
        (사용자가 입력한 오픈아이디를 저장해야 하는 이유는, 사용자가 자신의 오픈아이디를 보이는 것과는 다르게 타 오픈아이디 인증서비스로 위임(delegate)할 수 있기 때문이다. 예를 들어, 내가 jsmarr.myopenid.com와 같은 다른 오픈아이디로 위임된 URL인 오픈아이디 josephsmarr.com를 사용해서 계정을 생성하려고 한다면, 오픈아이디 인증서비스가 당신의 서비스로 리턴해서 인증을 완료할 때, 서비스는 내가 계정 생성을 위해 사용한 오픈아이디가 jsmarr.myopenid.com가 아니라 josephsmarr.com라는 것을 알아야 한다. 다행히 대부분의 OpenID library는 이것을 처리하게 되겠지만, 당장은 원래 제시된 오픈아이디를 세션에 저장해야 한다. 이 문제는 오픈아이디 2.0 스펙에서 해결될 것이다.)
     5. 오픈아이디 인증서비스가 사용자 인증을 완료한 뒤 리턴할 return_to URL을 생성해라. return_to URL은 당신이 만든 오픈아이디 로그인 CGI의 complete 액션이 될 것이다.
     6. 위에서 사용자가 새로운 계정을 생성하는 것이라고 판단된다면, 오픈아이디 인증서비스에 요청할 등록 정보를 정해야 한다. 대부분의 오픈아이디 인증서비스는 sreg(simple-registration extension) 를 지원한다. sreg란 당신의 서비스에서 필수 또는 선택적으로 사용할 수 있는 일반적인 등록 필드의 목록인데, 이름(full name), 이메일(e-mail), 별명(nickname), 성별(gender), 생년월일(data of birth), 우편번호(postal code), 국가(country), 언어(language), 표준시간대(time zone) 필드를 가진다. 만약 당신이 요청한 sreg 필드에 대해서 사용자가 정보 제공에 동의한다면, 그 정보들을 계정 생성 과정에 미리 채울 수 있으므로, 계정 생성 절차에서 사용자의 불편함을 줄일 수 있다. 만약 당신이 사용하는 오픈아이디 라이브러리가 sreg 파라미터 요청을 기본 지원하지 않는다면, 라이브러리가 sreg 요청에 필요한 일반화된 방법을 포함하고 있는지, 아니면 최악의 경우 오픈아이디 인증서비스로 리다이렉트 요청을 하기 전에 리다이렉트 URL에 당신이 직접 sreg파라미터들을 추가해야하는지 확인해야 한다.
     7. 당신이 사용하는 오픈아이디 라이브러리의 checkid_setup를 호출하여, 사용자의 오픈아이디 인증서비스로 리다이렉트하는 URL을 생성하라. 이때 사용자가 입력한 (대표형식으로 변환된) 오픈아이디와 위에서 생성한 return_to URL을 함께 전달해야 한다. 이와 함께 당신의 사이트에서 필요로 한다면, 전달 받기를 원하는 sreg 필드도 함께 전달하라. 라이브러리에 따라서는 이 함수에서 발생하는 에러를 처리하도록 해야한다. 에러 없이 정상 동작한다면, 이 함수의 결과값은 리다이렉트용 URL이 된다.
     8. 위에서 만들어진 URL로 CGI가 리다이렉트하도록 해라. 원칙상 CGI는 서버측 리다렉트 응답(역주: javascript와 같은 클라이언트측 리다이렉트가 아니라, HTTP protocol의 3xx 응답)을 통해서 리다이렉트되도록 해야한다.
     9. 사용자는 오픈아이디 인증서비스로 리다이렉트 된다. 사용자는 (아직 오픈아이디 인증서비스에 로그인하지 않았다면) 오픈아이디 인증서비스에 로그인하고, 당신의 웹사이트를 신뢰하는지 여부를 결정해야하며, 당신의 웹사이트에서 sreg 정보를 요청했다면 전달할 sreg 값을 입력해야 한다. 이 모든 과정이 완료되면, 당신이 로그인 과정을 완료하기위해 complete 액션을 수행할 수 있도록, 오픈아이디 인증서비스는 당신이 전달한 return_to URL로 사용자를 리다이렉트한다.
        
        
        Plaxo에서 (myopenid.com인 경우) 오픈아이디 인증서비스에 로그인하고, sreg 정보를 전달하는 스크린샷이다:
        

   • complete액션 구현하기 (IDP에 로그인 된 사용자가 redirect되는 페이지 이다.)

     1. IDP가 당신이 제공한 return_to URL로 redirect해 줄때에 여러 추가적인 파라미터를 넘겨줄 것이다. 이런 파라미터들은 당신이 사용자를 신뢰 하는데 도움을 줄 수 있는 정보들을 담고 있다.
        사용하는 라이브러리에 따라 다르겠지만 사용자 검증 함수에 사용하기 위해서 이러한 파라미터들을 모아 둬야 할 필요가 있을것이다.
     2. 세션에서 사용자가 맨처음 입력한 OpenID를 얻어온다. (IDP로 redirect시키기 전에 저장해 뒀다.)
     3. id_res모드로 IDP로 부터 건네 받은 사용자 인증 정보가 정확한지 재차 확인한다. 필요하다면 사용자가 처음 입력한 OpenID도 파라미터와 함께 보낸다. 이 함수는 지금까지의 모든것들이 valid한지 체크할 것이다. 만약 IDP로부터 에러코드를 돌려받는다면 사용자에게 적절한 에러메시지를 보여주기 바란다. 에러코드가 아니라면 이제 당신은 사용자가 입력한 OpenID를 인증된 OpenID로 확인한 것이다.
     4. 부가적으로: OpenID확인작업이 성공적으로 끝난 후에 사용자의 OpenID를 사이트 쿠키에 심어 놓고 싶을 수 있다. 이렇게 하여 사용자가 다음번에 당신의 사이트를 방문하는 경우 OpenID입력란에 사용자의 OpenID를 미리 채워둘 수 있기 때문이다. 여기서 주의해야 할 점은 사용자가 명시적으로 로그아웃을 하는 경우에는 반드시 심어놓았던 쿠키를 지워야 한다는 것이다.

     5. 인증된 OpenID를 GetUserId함수를 이용하여 다시한번 살펴보자. 만약 당신의 DB에서 해당 OpenID를 찾을 수 없다면 이 사용자가 현재 당신의 사이트에 로그인 돼어 있는지 확인하여 이미 존재하는(로그인 한) 계정에 추가하기 바란다. 로그인 되어 있지 않다면 이 OpenID를 이용하여 새로운 계정을 등록하는 절차를 밟아야 할것이다. 우선 계정 생성코드에서 사용할 수 있도록 인증된 OpenID를 세션에 저장한다.(사용자가 처음 입력한 OpenID와 같은 세션변수를 사용하면 안된다. 사용자가 입력한 OpenID와 IDP가 인증해 준 OpenID는 다를 수 있다.)
        그다음 IDP로부터 넘겨받은 간단한 등록 데이타와 함께 사용자를 회원가입 페이지로 redirect시킨다. 이때 IDP로부터 넘겨받은 데이타를 당신의 사이트에서 일반적으로 필요로하는 사이트에 맞게 매핑시켜주어야 할 것이다.

        • 위에서 설명한바와 같이, 사용자 등록 페이지에서는 계정 정보에 오픈아이디를 명확하게 표시해야 하며, 사용자는 자신의 오픈아이디로 로그인 할 것이므로, 당신 사이트의 비밀번호를 요구하지 말아야 한다. 추가적으로, 오픈아이디 인증서비스에서 제공한 모든 등록 정보를 미리 채워둬야 한다. 등록 페이지에서 추가적인(역주: 오픈아이디 인증서비스를 통해서 전달된 등록 정보가 아닌 것) 등록 정보를 요구하거나, 필수 또는 선택적인 필드에 대한 현재의 정책을 그대로 유지하는 것은 아무런 문제가 없다. (오픈아이디 사용은 당신 사이트에서 등록 과정을 가속화시키며, 당신이 요구하는 정보에 대해서 변경을 요구하거나 당신 사이트의 일반적인 행동에 변경을 요구하지는 않는다.) 마지막으로, 사용자가 당신의 사이트에 이미 계정을 가진 사용자인 경우, 그 계정에 오픈아이디를 부여(attach)하는 링크를 달아라. 이 링크는 이미 계정을 가진 사용자가 로그인하지 않은 상태에서 등록되지 않은 오픈아이디를 입력한 경우를 처리해야한다. [이 경우는 일반적인 경우는 아니므로, 자신의 오픈아이디로 당신의 사이트를 처음 사용하는 모든 사용자에게 "계정이 있으시면 로그인 하십시오. 아니면 신규 계정을 발급받으시겠습니까?"라고 묻는 것 보다는, 등록 과정의 시작부분에 작은 링크를 다는 것이 더 좋다.]
        • 사용자가 등록 과정을 완료하고 신규 계정 생성이 완료되면, AttachOpenID 함수를 호출해서 새로 생성한 계정에 인증된 오픈아이디를 부여하라. [사용자 테이블과 오픈아이디 테이블이 서로 다른 데이터베이스에 있고 동일 트랜잭션으로 두 테이블을 접근할 수 없다면, 가끔씩 오픈아이디 부여 실패로 이 계정이 결코 사용될 수 없게 되는 경우가 있을 수 있다. 이것을 100% 방지하기는 힘들지만, 드문 경우이고 사용자는 언제든 계정 생성을 다시 할 수 있으므로, 대부분의 경우 이러한 레이스 컨디션을 무시하고 잘 동작할 것이라 기대해도 무방하다.]
     6. 인증된 오픈아이디가 이미 어떤 계정에 부여된 것이면, 사용자가 예전 방법으로 로그인했을 때와 같이 사용자를 로그인 시키면 된다. (로그인시 사용한 오픈아이디가 부여된 계정이 현재 로그인되어 있는 계정과 다르다면, 로그아웃 처리를 하고 제시된 오픈아이디가 부여된 계정으로 로그인 처리를 해라. 이미 사용자가 그 오픈아이디를 소유한 것이 증명되었으므로, 해당 오픈아이디로 로그인 처리를 하면 된다.)

      

   • attach액션 구현하기 (이미 존재하는 사용자 계정에 OpenID를 추가)

     1. (이 액션은 사용자가 이미 로그인 되어 있으며 새로운 OpenID를 인증받은 경우에 complete액션의 한 부분으로서 호출 된다. 따라서 이 액션이 호출되기 전에 사용자가 로그인 돼어있어야 한다.)
     2. 로그인된 사용자의 계정에 AttachOpenID함수를 이용하여 인증된 OpenID를 추가한다.
     3. 이제 사용자의 계정에 OpenID가 추가되었으며 앞으로 이 OpenID로 로그인이 가능하다는 것을 확인할 수 있는 메시지를 보여준다. 또는 사용자의 계정에 추가된 다른 OpenID리스트를 보여줄 수도 있을 것이다.
        
        Plaxo의 attach 결과 페이지 스크린샷:
        

      

   • list액션 구현하기 (로그인 한 사용자의 계정에 연결된 OpenID를 보여준다.)

     1. 로그인된 사용자여야 한다. (필요하다면 로그인 페이지 이후에 redirect된다)
     2. GetOpenIDsByUser함수를 호출하여 로그인된 사용자의 계정에 연결된 OpenID들을 가져온다.
     3. 가져온 OpenID들을 그것을 삭제할 수 있는 링크와 함께 보여준다. 이 링크는 다음의 delete액션에 openid_url파라미터로 보내서 삭제할 수 있도록 한다.
     4. 다른 OpenID를 추가할 수 있는 링크나 입력란을 제공하도록 한다. 이 링크는 사용자로 하여금 login액션, attach액션을 통과하여 다시 list페이지로 돌아오게 한다. (이역시 로그인 된 사용자를 대상으로 한다)
     5. 만약 당신의 사이트에 환경설정 할 수 있는 페이지가 있다면 "내 OpenID 관리하기"라는 식으로 이 list페이지로 접근할 수 있는 링크를 제공해야 할 것이다.
        
        Plaxo의 환경설정 페이지와 list페이지 스크린샷.
        

      

   • delete액션 구현하기 (사용자 계정에서 OpenID를 삭제한다.)

     1. 로그인된 사용자여야 한다. (필요하다면 로그인 페이지 이후에 redirect된다)
     2. 부가적으로: 사용자가 삭제하려고 하는것이 당신의 사이트에 로그인 할 수 있는(OpenID나 기타 다른 인증방법에 의한 ID를 포함한 - 역자주) 마지막 자격증명인지 확인하라. 만약 사용자가 당신의 사이트에 로그인 하기위한 암호를 설정하지 않았거나 계정에 연결된 마지막 OpenID인 경우에 이것을 삭제해 버린다면 그 사용자 계정은 영원히 잠겨버리게 되는 것이다. 이런 상황을 복구할 수 있는(비밀번호 찾기 등... - 역자주) 뾰족한 방법이 없다면 다음과 같은 에러메시지를 보여주는것이 좋을 것이다. "귀하의 계정에 연결된 마지막 OpenID입니다. 이 OpenID를 삭제하면 더이상 로그인 할 수 없으므로 우선 다른 OpenID를 등록하거나 비밀번호를 등록해 주십시오."
     3. 계속하여 진행하자면, openid_url 파라미터로 넘어온 값으로 DetachOpenID함수를 호출하여 로그인 된 사용자의 계정에 연결된 OpenID를 삭제한다. 파라미터로 넘어온 OpenID가 사용자의 계정에 연결된 OpenID가 아니라면 그냥 에러를 보여주거나 아무 작업도 하지 않아도 될 것이다.
     4. OpenID가 삭제되었으며 더이상 이 OpenID로 사이트에 로그인 할 수 없다는 메시지를 보여준다. 만약 사용자가 이 OpenID를 다시 사용자의 계정에 연결시키고자 한다면 사용자는 다시 인증 프로세스를 거쳐야 할 것이다. OpenID가 삭제되었음을 사용자가 확인할 수 있도록 list액션으로 redirect시켜도 된다.
        
        Plaxo에서 OpenID를 삭제하였을 때의 스크린샷:
        

      

   • 사용자 계정을 삭제할때 계정에 연결된 OpenID를 삭제하는 루틴을 추가하라.

     1. 만약 당신의 사이트에 사용자가 그들의 계정을 삭제(회원탈퇴 - 역자주)하는 것이 가능하다면 해당 계정과 연결된 OpenID를 모두 삭제해 주어야 한다. 왜냐하면 사용자가 다른 계정에 OpenID를 연결시키고 싶어 할 수 있기 때문이다. 계정삭제 루틴에서 DetachOpenIDsByUser함수를 호출하거나 이 함수를 트리거로 등록해두면 될것이다.

      

...and you're done!

여기까지 왔다면 축하한다. 이제 당신의 웹사이트에 오픈아이디를 적용하기 위한 모든 수단을 갖추게 된 것이다. 위의 과정들은 철저하고 완전하지만, 구현에 있어서 아래의 best-practices를 기억해 두는 것이 도움이 된다.

• 페이지에서 사용자의 오픈아이디를 보여줄 때 마다 오픈아이디임을 인지할 수 있도록 작은 오픈아이디 아이콘을 앞에다 두어라. 예로, 위의 가입페이지 스크린샷을 보라. (당신사이트의 유져 인터페이스가 오픈아이디들의 목록을 보여주고 있다는 것이 명백한 목록 페이지는 가능한 예외라 할 수 있겠으나, (오픈아이디 아이콘을 보여준다고 해도) 손해볼 것은 없다!
• 일반적으로, 사용자들의 오픈아이디를 공개적으로 혹은 다른 사용자들에게 표시하기 전에 (옵트-인 방식의) 동의를 구해야 한다. 사용자는 어쩌면 자신의 오픈아이디를 공개적인 식별자로 공유하기를 원할 수도 있겠지만, 기본적으로 개인적인 signing in 방법으로 사용하기를 원하고 그들의 공개 프로필의 한 속성이 되기를 원하지 않는다고 가정해야 한다.
• 오픈아이디 스펙 2.0(곧 완료될 예정이다; 대부분의 사이트는 현재 1.1 버젼을 사용하고 있지만 걱정하지 말라, 오픈아이디 2.0 서버에 맞추기 위해 아무 것도 바꿀 필요가 없다.)로 시작한다면, 사용자들은 joseph.smarr와 같은 i-names 역시 오픈아이디로 이용하여 sign-in할 수 있게 될 것이다. 당신이 이를 구현함에 있어 transparent하기를 바라지만, 앞으로 사용자의 i-names를 공개적으로 표시하기를 계획하고 있다면, = 이나 @로 시작하는 일반적인 별명으로 등록하는 것을 제한하기 시작할 좋을 때이다, 왜냐하면 이런 별명들은 인증된 i-names와 혼동될 수 있기 때문이다. 이미 많은 사이트들은 이런 문자들로 시작하는 닉네임을 불허하고 있지만, 한번 볼 필요가 있다. (i-names와 관계없이 이런 문자들을 제한하고는 있으나, i-names와 관련되어 있음을 알 필요가 있다는 뜻-역자주)
• 오픈아이디는 이미 널리 채택되고 있지만, 웹과 같은 규모에서 사용자 중심의 아이덴티티를 제공할 때의 문제점은 여전히 해결이 진행 중인 것임을 기억하라, 그러니 어떻게 돌아가는 지에 대해 질문이나 피드백이 있으면 말하라! openid.net 과 OpenIDEnabled.com 같은 사이트에 기여하거나, 코멘트을 남기고 블로그에 글을 쓰거나, 혹은 대화에 참여할 수 있는 뭐라도 하라. 웹 상에서의 아이덴티티에 대해 열정적이라면, 당신의 사이트에 오픈아이디 지원을 제공하는 것은 훌륭한 출발점이다. (오픈아이디) 커뮤니티에 지속적인 공헌자가 되는 것은 투자를 지속시키고 사용자로써 우리가 원하는 대로의 웹을 모두 가질 수 있음을 확실하게 하는 데 도움이 될 것이다.