사용자 삽입 이미지
Yahoo에서 발급하는 OpenID가 아직은 Beta 수준입니다. Yahoo는 OpenID2.0을 기준으로 만들고 있죠.

혹시 Yahoo의 오픈아이디를 시험해 보실분들은, Textcube 1.6.x가 설치되고 OpenID가 활성화된 곳에 로그인해보시기 바랍니다. Textcube는 OpenID 2.0 스펙으로 발급된 아이디가 소비될 수 있는 발빠른 공간입니다.

2.0을 지원하는 Yahoo OpenID는 openid 쓰는 곳에 yahoo.com 만 쓰면 됩니다. 아직은 Attribute eXchange는 지원하지 않습니다.
신고
  1. 다비드남 2008.05.13 15:57 신고

    오픈아이디에 관심이 많아서 이것 저것 공부하는 중에 들르게 되었습니다. yahoo.com의 2.0 표준으로 인증하는 것을 사용해보니... 그닥 편리한 점은 모르겠네요 ^^

    • 최호진 2008.05.13 19:32 신고

      공부를 하신다니... ;)
      그 표준은, RP에서 편의상 제공하기 위한 용도로 사용하려고 하기 위함입니다.

  2. 다비드남 2008.05.14 09:44 신고

    넵 ^^ 회사에서 Open ID 발급 서비스를 만들려고 하고 있습니다. KT 프로젝트를 용역하는 것인데요. 기획을 위한 개념은 대충 잡았지만... 사실 어떤 새로움을 넣고 싶은데 쉽지 않네요. ^^ 혹시, 좋은 아이디어 있으시면 저를 통해서 구현해 보심이 ^^;;

Textcube.org는 PunBB로 돌아가는 TNF 포럼이 있습니다. 오픈아이디를 지원하도록 고민중에 있습니다만, 단순히 TNF에서만 사용한다면, 뚝딱뚝딱 만들겠지만, 많은 사람들에게 도움이 될 우아한 모습을 생각하려니 여러가지 생각이 떠오르는 군요.
  1. PunBB의 기존 아이디에 한 개 이상의 오픈아이디를 연결한다.
  2. PunBB의 기존 아이디에 강제로 한 개 이상의 오픈아이디를 연결한다.
  3. PunBB의 기존 아이디 시스템은 운영진에게만 발급하고, 일반 회원은 오픈아이디로 사용하도록 한다.
  4. 일반 회원을 오픈아이디로만 사용할 때는 PunBB용 아이디를 하나 선택하도록 한다.
  5. 운영중인 PunBB에서는 최초 로그인할 때 강제로 오픈아이디와 연결하도록 유도한다.
아직 공식적으로는 PunBB 1.3beta상황에서도 OpenID는 지원하지 않습니다만, 잘 만들어서 공개하는 방향으로 해보렵니다.
신고
  1. gofeel 2008.01.30 22:01 신고

    phpbb는 어떨까요 현재 이미 Beta버전 정도의 구현들이 있더라구요...

간만에 OpenID 관련 글하나 써보렵니다.
블로그 주소를 OpenID로 사용하기, 혹은 위임 기능의 동어 반복이지만, OpenID 관점에서 보는 것이 아니라, 일반 블로그관점에서 보는 글입니다.

XFN을 Textcube에 구현해 넣으면서 생각해본 것입니다. 내가 친구로 정한 사람이 내 홈에 방문했을 때, 다른 뭔가를 더 줄 수 있지 않을까? 내가 친구로 정한 사람은 어떻게 확인할 수 있을까? 당연한 결론은 링크를 OpenID로 사용하게 만들고, 그 OpenID로 로그인하게 만드는 것이죠.

기존의 접근은, 오픈아이디를 만들었는데, 이걸로 돌아 다닐 수 있는 사이트는 이러저러한 사이트들이 있고, 그런 사이트에 자신을 구별하는 동일한 방법으로서의 오픈아이디이며, 따라서 왠만하면 블로그 주소로 자신을 구별하는게 어때? 라는 식의 접근이었습니다.

그러나, 반대로 내가 알고 있는 친구는 이 블로그 (혹은 링크)를 소유하고 있는데, 그 친구라는 것을 증명해보라는 접근은 오픈아이디가 정말 필요한 예라고 볼 수 있습니다.

XFN이 분산화되어 있는 SNS를 지원하는데 도움이 되는 포맷 중의 하나입니다. 앞으로 생각이 발전하게 되어 쓸만한 기능으로 발전하게 되면, 오픈아이디에 대한 이런 접근을 UI에서 잘 드러내도록 해보겠습니다.

신고
  1. http://kayflow.myid. 2007.11.13 21:01 신고

    반갑습니다. ㅎㅎ

  2. newschool 2007.11.20 21:24 신고

    감히 말하길, 좋은 아이디어라고 생각합니다.
    xffn과 오픈아이드를 통해 가치가 있는 서비스가 곧 나올거라는 기대가 됩니다. ^^

  3. lunamoth 2007.12.13 01:00 신고

    돌아다니다 http://factoryjoe.com/blog/2007/12/06/oauth-10-openid-20-and-up-next-diso/ (일단 북마킹만;; ) 보게되니 호진님의 이 글이 생각나더군요... ^^;;

  4. http://kayflow.myid. 2008.01.11 10:28 신고

    호진님, 하시는 김에,... 이 건 어떠세요?

    http://openid.or.kr/69

오픈아이디는 URL(정확히는URI와 해당 Dispatcher조합)로 표현된다는 관점에서 우리는 재밌는 것을 실험해 볼 수가 있습니다. 이 실험에 대한 아이디어는 OpenID 세미나로 방문했던  David Recordon(블로그)으로부터 소개 받은 것입니다.

첫번째 실험은 앵커를 이용한 오픈아이디 사용입니다.

http://coolengineer.idtail.com/
이라는 아이디가 있을 때, 보통 한 페이지에 여러 섹션을 두고 그 섹션을 찾아가기 위해애 앵커라는 표현 방식으로 다음과 같이 사용할 수 있습니다.
http://coolengineer.idtail.com/#2
http://coolengineer.idtail.com/#3
http://coolengineer.idtail.com/#private
http://coolengineer.idtail.com/#public
위 URL은 모두 다른 것을나타내지만, 결국 http://coolengineer.idtail.com/ 을 가져오도록되어있습니다. 일종의 위임(delegation)이 일어나는 것으로 생각할 수 있습니다. (물론 link tag에 의한 위임은 일어나지 않습니다.)

위와같이 로그인시도를 할 경우 RP(Relying Party, Consumer site)에서는 각각을 다른아이디로 인식하게 됩니다. 하지만, IdP 쪽에는같은 아이디로 로그인을 하게 됩니다. 물론 IdP에서도 RP에 어떤 식으로 로그인하고 있는지 #뒤의 정보를 포함한 전체 URL이 전달됩니다. 따라서, 서버쪽 라이브러리가 #뒤의 내용을 무시하고 잘 처리해주어야하는데요, 제가 간단히 테스트한 상황으로, php 라이브러리를 사용하는 idtail.com과 ruby 라이브러리를 사용하는 myid.net은 정상적으로 처리하는것을 보았습니다. java나 .net은 살펴보지 않았습니다. (누가 테스트해서 댓글을 좀.)

두번째 실험은 전체 URL 대신 일부만으로 가능하냐입니다.

즉,
coolengineer.idtail.com#2
coolengineer.idtail.com#me2dayonly
이렇게 앞의 'http://'을 떼고, .com 뒤의 # 앞에 '/'을 빼도 되느냐하는 것입니다. 이것은 클라이언트의 URL 정규화 함수의 기능에 들어 있어야하는것입니다. php 라이브러리에서는 예상대로 잘 되는 군요. (누가 다른 클라이언트 라이브러리에서도 테스트해서 댓글을 좀. 부탁합니다.)

세번째 실헝믄 위임주소에서도 가능한가 입니다.

저와 같이 블로그 주소를 오픈아이디로위임하여 사용하는 것에서 실험해볼 수 있습니다.
http://coolengineer.com/#2
잘 됩니다. 즉, RP에서는 다른 오픈아이디로 인식하는 것을 확인하였습니다. 하지만, 제 블로그의 경우에는, 위임을 http://coolengineer.idtail.com/ 에 하기 때문에, IdP 입장에서는 블로그 주소뒤에 #XXX가 어떤 내용인지 알 수가 없더군요. 만약, IdP에서 #을 기반으로하는 기능 확장을 고려한다면, 주소를 위임받아 로그인하는 사람들에게는 어찌할 수 없어보입니다.

정리하자면...

이 기능을 고려하여 사용할 수 있는 것은, IdP의 입장에서는 여러 Persona에 대해서 URL을 부여할 수가 있으며, 각 URL이 다른 오픈아이디로 인식되게 할 수 있다는 것입니다. 또한 사용자도 IdP가 이런 확장을 지원하지 않아도 #XXX를 통해 달라지는 URL을 통해 많은 OpenID를 만들어낼 수가 있다는 것입니다.


신고
  1. Kay 2007.07.20 01:26 신고

    재밌어요. 어디에 쓰면 유용할지 생각을 좀 많이 해야 겠네요. ^^; myID.net 에서는 IDP 차원에서 유용한 ID variation 을 제공할까 합니다. 생각하고 있는 재밌는게 많은데요, 한가지만 소개드리겠습니다. 최근에, myid.net 에 새로 추가된 주소록, 그룹 아이디 기능이 있는데요, 재밌는 것은 모두 '관계' 인증이 공통적인 점입니다.
    이를테면 제가 coolengieer 님을 제 주소록에 등록하고, 'community-friend' 라는 제 개인그룹에 분류하게 되면, coolengieer 님은 'kayflow.myid.net/list/community-friend' 라는 URL 에 소속된 권한이 부여된 것으로 볼 수 있구요. 이 페이지를 openid 화 시키면, openid 로 쓸 수 있습니다. 물론 myid.net 그룹-멤버쉽 인증기능을 쓸 수도 있지만, 오픈아이디만 지원하는 사이트에서는, 제가 위의 분류로 넣어 드린 분들은 모두 위의 아이디로 로그인이 가능해 지는 것이지요 ^^; 일종의 아이디 공유가 됩니다. 게다가 이 url 이 마음에 안들면, delegation 걸면 되지요.
    물론, 아직 제공되는 기능은 아닙니다.

    • 최호진 2007.07.21 02:49 신고

      비슷비슷한 생각들이 자라고 있는 것 같습니다. 별로 사용하지 않을 기능 만드는 엔지니어들만의 생각이 아니어야할텐데요... ;)

    • Kay 2007.07.24 01:17 신고

      태터캠프 후기를 보니 '그룹 오픈아이디' 언급이 있으시던데... ^^; myID.net 그룹도 물론 지원해 주실거죠. --; API 수정의향도 있사오니... 꼭 지원해 주세요. ㅎㅎ

    • 최호진 2007.07.24 10:14 신고

      제 개념을 설명하면서, myid를 언급했었습니다. ^^; 아니면, 설명할때 myid가 제 머리속에 있었던지, 둘중 하나이어요.
      플러그인으로 가능한 방법을 텍스트 큐브에 도입하여 그룹id를 제공하고자하는 서비스들을 만족시켜가는 방향으로 잡으면 될 것 같습니다. 이 논의는 Textcube 2.0에서.. ;)

    • kay 2007.07.25 00:24 신고

      아무려면 어떻습니까. 기왕에 쓸만한 아이디어가, 실제로 세상에 쓰이기만 한다면, 불편한 부분은 다 뜯어 고치겠습니다. ^^;

  2. // 2007.09.14 17:52 신고

    환영

  3. 최호진 2008.01.15 10:27 신고

    본 기능은 OpenID 2.0 스펙에서 ID Recycling 기법에 사용되어 더이상 유효하지 않게 되었음을 알려드립니다.

  4. carpediem 2008.02.22 10:54 신고

    불편한 오픈아이디... 회원관리하기도 짜증 -_-;;

    • 최호진 2008.02.23 01:10 신고

      보안이 들어가면 원래 좀 불편해집니다.

사용자 삽입 이미지
작년에 쓴 에서 아파치 사용자 모임이 다시 준비하고 있다는 것을 쓴 적이 있었는데, 6개월만에 오늘(05-16) 오픈합니다.

한 달전 쯤, 운영자이신 정관진씨를 만나서 OpenID를 지원해보는 것은 어떠냐는 말에, 검토하더니 슥슥슥 넣게 되었습니다.
그동안 회원가입없이 운영해왔는데, 스팸 방지 등의 오남용 사례가 있어서 최소한의 가입을 추진하게 되었다고 합니다. 최소한으로 Email 기반으로만 운영하려다가 OpenID 암초(?)를 만난 덕에 몇 일간 고생끝에 지원하게 되었습니다.

하는 김에, 제가 속한 IDtail.com에서 공동가입을 추진해보았고, OpenID 소개 페이지에서 가입페이지로 바로 이동할 수 있게 하였습니다.

온라인 비영리 커뮤니티 중에서는 처음으로 시작하는 경우이고, 오늘 오픈을 통해서 사용자모임이 확대되어 아파치 웹서비스의 정보가 많이 공유되었으면 합니다. 또한 곳곳에 흩어져 있는 아파치관련 소식들이 한 곳에 모이고, 나아가 전문성 있는 사이트로 더 발전하는 계기가 되었으면합니다.
신고
  1. 준호 2007.05.16 12:27 신고

    최근 정관진씨랑 같이 있는 모습을 본것 같은데 ㅋ

  2. 2007.05.22 19:17 신고

    잘 지내고 있남?
    나는 난데없이 임베디드 리눅스쪽 플그램을 개발하게 됐다 -_-;
    일단 우분투부터 설치하고..;;

  3. 유스티케 2007.05.29 14:36 신고

    이거 신기하네요 ㅡㅡㅋ

  4. 유스티케 2007.05.29 14:38 신고

    요거요거

  5. 유스티케 2007.05.30 11:13 신고

    질문이 있습니다. 먼저 저는 전문가는 아닙니다.. ^^;
    오픈 아이디로 특정 블로그에 로그인 하였을때,
    역시 오픈 아이디를 사용하는 다른 유저의 아이디를 클릭 하였을 경우
    오픈 아이디를 지원하는 타 블로그로 이동한다고 가정해보겠습니다.
    이때 타 블로그에 이동해서 글을 남겨야 할 경우 또 다시 오픈 아이디 로그인
    절차를 거쳐야 하는지요? 아니면 기술적으로 지원이 가능한 부분인가요?

    • 최호진 2007.05.30 12:51 신고

      다시 오픈아이디로 로그인해야합니다.
      블로그간에 이동한다고 하지만, 사실은 전혀 다른 사이트이거든요. 같은 태터툴즈를 쓴다고 하여도 엄연히 신뢰의 문제는 로그인하는 사람이 생각해야만 하기 때문입니다. 여러 사이트를 동시에 지원하는 하나의 사이트와 약간 다른 점이 도메인간의 신뢰 문제입니다.

      그러나! 오픈아이디를 지원하는 1.5 이후의 태터툴즈(텍스트큐브)가 설치된 사이트를 신뢰하는 사이트로 놓을 경우 로그인 시도가 자동으로 일어나게 하는 기능은 구현중에 있습니다. (로그인 상태를 이전하는 것이 아닌 로그인 시도입니다. ^^)

태터툴즈에 OpenID를 설치하다가 안되는 증상중 하나가 다음 웹인사이드용 플러그인이었습니다. ^^;

OpenID 플러그인이 어떻게 할 수 있는 부분이 아니어서 다음웹인사이드용 플러그인을 수정하여 배포합니다. 요기에서 받으세요.
신고
  1. 유마 2007.05.08 21:02 신고

    오, 수정본 나왔네요.. 고마워요~

OpenID와 관련해서 지난번 글 말미에 환상을 품을 만한 실험에 대해 얘기했습니다. 사실, 낚시성 멘트였구요. 환상 정도는 아니지만, 재밌는 실험입니다.

1.
스패머들이 자신의 주소를 숨기기 위해 야후를 사용했던 방식을 이용한 방식으로 신뢰하는 도메인을 야후로 만들어 보겠습니다.

2.
지난 글에서 단일 사용자 로그인을 수행하는 OpenID의 질문중에 세번째로 인증 정보를 전달할 도메인을 확인하는 과정이 있다고 하였습니다. 인증정보를 확인하기 위한 질문까지 가기위해서 로그인사이트(이하 RP; Relying Party;Consumer site)에서는 OpenID를 접수 받고서, OpenID의 발급자(이하 IdP; ID Provider)에게 페이지를 리다이렉트합니다. 대개 사용하시는 분들은, 아이디는 로그인사이트에 넣지만, 비밀번호는 항상 발급자 홈페이지에 넣기 때문에 안심(?)스러운 광경을 연출되는 것을 보게 됩니다.

물론, 연출만이 아니라 모든 인증이 끝난 뒤에도, 실제로 비밀번호는 RP 사이트에 전달되지 않기 때문에 안심이죠.

3.
이렇게 비밀번호를 확인하고 마지막 단계로, RP 사이트에 대한 "신뢰하는 root url"을 보여주게 되고, 이 사이트가 정말 당신이 로그인하고 있는 사이트가 맞는지 확인하는 작업을 수행합니다. 사이트를 1회만 승인하던, 계속 승인하던간에 IdP에서는 RP로 다시 리다이렉트를 하게 됩니다. 이것은 처음 IdP로 건너 올 때, 되돌아갈 위치를 return_to라는 변수에 실어왔기 때문에 가능한 것입니다.

만약, 많은 사람들이 현재 사용하는 me2day나 스프링노트를 항상 승인하도록 설정해둔다면, 사이트에서 오픈아이디를 도입하고자 하는 개발자가 신뢰하는 root url을 me2day 로 해 놓고, 승인 시도를 하게된다면, 마지막 단계없이 로그인 할 수 있지 않겠습니까? 그러나, 이 경우에는 return_to의 url과 신뢰하는 root가 다른 hostname을 갖게 됩니다. 이에 대한 간단한 내용이 사양서의 노트에 기록되어 있지요.
The openid.return_to URL MUST descend from the openid.trust_root, or the Identity Provider SHOULD return an error. Namely, the URL scheme and port MUST match.
즉, 최종적으로 신뢰한 사이트를 돌려 받을 주소(return_to)는 반드시 trust_root로 부터 만들어져야하는 것입니다. 예를 들어,
trust_root=http://www.me2day.net&return_to=http://myservice.org/openid/finish
와 같은 방법으로 앞뒤를 다르게 서비스를 개설할 수 없다는 것입니다.

4.
서문이 너무 길었군요. 다시 처음에 언급한 야후를 이용하여 송신지를 숨기는 스패머들 얘기를 꺼내 보겠습니다. 야후에서 검색을 하고 난 결과 목록에서 원하는 링크를 누르면, 항상 다시 야후로 간다음 목적지로 리다이렉트 됩니다. 편의상 이것을 YR-Hack(Yahoo redirection hack) 이라고 합시다. 아마도, 이 YR핵은 통계를 내거나 클릭 기반의 데이터를 쌓아서 다음 결과에 반영하려고 그런것인지는 잘 모르겠습니다만, 다음과 같은 테스트를 해볼 수 있습니다.
http://rds.yahoo.com/*-http://coolengineer.com/
위와 같이 야후를 이용하여 제 홈에 오는 방법이 가능합니다. 아차!

5.
그럼 신뢰하는 root url을 rds.yahoo.com 혹은 *.yahoo.com 으로 한다면, 야후로 승인받고, 제 홈에 올 수 있다는 얘기 아닙니까. 예를 들면,
trust_root=http://*.yahoo.com/&return_to=http://rds.yahoo.com/*-http://myservice.org/openid/finish
와 같은 형식으로 하면, trust domain을 yahoo로 하고 return_to 에 씌여지는 url이 정상적으로 동작하는 것이라면, 그 앞에 http://rds.yahoo.com/*- 을 붙여주면, myservice.org 서비스에 로그인이 가능하게 됩니다.

자,자, 무슨 얘기인지 차근차근 따져봅시다. YR 핵의 핵심은 rds.yahoo.com 서버가 하는 일은 단지 "*-" 뒤에 있는 페이지로 redirection한다는 것이고, 이 서비스를 이용하면, trust 경로를 yahoo로 할 수 있다는 것인데. 일반적으로 사이트에서 오픈아이디를 지원하려면, 굳이 야후로 할 이유가 없습니다. 그러나, 악의적으로 사이트를 개설하고, 오픈아이디를 로그인 하도록 만들어 놓았는데, 신뢰하는 사이트가 야후로 보인다면? 자신의 신상 정보를 쉽사리 줄 수가 있겠지요. 보안에 취약해지는 부분입니다. 물론, 이런 YR 핵을 이용하여 만든 것들이 얼마나 퍼질지는 모르겠습니다.

6.
자, 환상은 무엇이고 재미는 무엇이란 말입니까?

환상은 분산환경에서 단일 사용자 로그인(SSO)을 구현해 봄직한 구멍이 보인다는 것입니다.지난 글과 서두에 언급한 세번째 질문을 처음가는 사이트라 할 지라도 비슷한 사이트에서 승인처리를 해놓았다면 야후라는 이름으로 승인될 수 있다는 것입니다.

재미는 무엇입니까? 야후 기록만 살펴봐도 어디에 누가 깔려 얼마나 많은 사용자가 로그인하고 있는지 알 수 있다는 것입니다. 분산환경에서 집중화된 로그인 기록!

자, 우리 대화를 YR 핵 대신 서비스를 만드는 사람이 중앙에서 리다이렉션해주는, 이런 비슷한 처리하는 서버를 두는 것으로 바꾸고 생각해봅시다.

환상과 재미가 취약한 보안(?)과 함께 느껴지시나요?

기회가 되면 적용할만한 꺼리와 보안을 고려하여 좀 익은다음 뒷 얘기를 더 해보겠습니다.

신고
  1. 하늘이 2007.04.09 15:51 신고

    오오오오...+_+)=b 흥미진진한 글 잘 읽었습니다!

    • 최호진 2007.04.09 18:56 신고

      너무 감동하시는거 아니에욧! ^^;

      감사합니다. 이렇게 댓글을 달아 주시니 늘 읽던 씨이오 블로그가 갑자기 양방향이 된 듯한 느낌입니다.

  2. 많이 어렵습니다 ;;

  3. 유역비 2007.04.11 11:37 신고

    consumer측에서 OpenID 로그인인 한후에 consumer쪽에서 로그아웃을 하게되면, 보통 세션을 날리는거 같은데요, 그렇게되면, Provider쪽에는 아직 로그인 상태로 남아있어서, 아이디만 알고 OpenID유효한 시간이면, 누구라도 Provider쪽 마이페이지로 접근가능하네요? Provider쪽도 같이 로그아웃 시키는 방법은 없나요?

    • coolengineer 2007.04.11 19:25 신고

      Consumer 는 한 둘이 아니고, 동시에 여러곳에 로그인될 수도 있습니다. 이런 경우라면 아주 복잡해지지 않을까요?
      Provider에서 로그아웃하면 Consumer 사이트들도 모두 로그아웃해야하는 상황도 상상가능하죠...

      사실상, Provider와 Consumer는 인증 외에는 별개의 사이트로 뭔가 주고 받는 것이 전혀 없답니다.

  4. MilKyWAY 2007.04.19 12:44 신고

    히잉.. 어려워요 ㅡㅡ;;

  5. ayo 2007.05.16 12:51 신고

    재미있는 아이디어네요^^ 실험해봐야겠습니다~

    • 최호진 2007.05.16 19:17 신고

      RSS로 먼저 읽고나서 댓글이 달린 것을 알았습니다. ^^
      사실, 곳곳에 깔려 있는 태터툴즈의 싱글 사인온을 궁리하다가 생각해낸 것이었습니다만..
      이렇게 하지 않아야 윤리적인것 같고, 인증 영역에 대한 개념을 해치지 않는 것 같습니다.

  6. komunamu.myid.net 2007.05.17 00:43 신고

    흥미 있는 글 잘 읽었습니다. 미국쪽 사이트에서는 아직 못본 내용인것 같은데 영문으로 올리시는건 어떤지 모르겠습니다. 사용자에게 SP사이트에 대한 신뢰여부를 물을때 CardSpace 처럼 SP 의 Certificate에 대한 Verification 결과를 명확하게 보여주는 기능이 OpenID에 추가되어야 하지 않을까 생각이 드네요. 그럼 너무 무거워지나요?

    • 최호진 2007.05.21 05:22 신고

      비슷한 내용이 논의 된 것을 OpenID 쪽 메일링 리스트에서 읽은 적이 있습니다. 저야 테스트를 해보았으니 정리된 문장이 바로 이해되었는데, 처음 토론하였던 쓰레드는 찾을 생각도 안했군요.

    • 최호진 2007.05.21 05:25 신고

      어쩌면, SP입장에서 Verification당한다고 생각하면, 사용률이 뚝떨어질것 같습니다.
      passport가 그런 결과아니었을까요?

  7. BlueWorld 2007.05.17 11:23 신고

    흥미로운 글이네요 ^^
    문제점은 있는데 해결이 아직 안되었으니 일단 로그인시 조심해야겠네요 ^^

    • 최호진 2007.05.21 05:28 신고

      네, 조심해야하죠. 그러나, 유명(?)한 사이트에서 trust root를 만들때 조심만해주면 사용자 모르게 넘어가는 일은 없을 겁니다. 위의 예에서도 야후가 기본적으로 *.yahoo.com 으로 trust root를 배포한적이 없으면 다른 사이트에서도 모르게 이용할 수는 없겠지요.
      그래도.. yahoo를 사칭할 수 있다는 점에서는 머리굴리는 사람에게는 홀이 보일지도.

  8. 2007.05.31 14:03

    비밀댓글입니다

단일 사용자 로그인(Single Sign On; SSO)은 다음과 같은 상황에서 일어납니다.
  1. 사용자 인증
  2. 인증을 공유할 같은 도메인 혹은 그 서브 도메인의 서버들
  3. 각 서버들은 그 기원이 서로 다른 서비스로 운영됨.
  4. 각 서비스들이 요구하는 사용자 정보는 최소한으로 ID 이며, 그 외에 이메일, 이름 등이 있음.
이를 위해서는
  1. 가장 공통의 인증을 위한 미들웨어 강제로 사용하는 방법이 있을 수 있고,
  2. 웹이라면 쿠키의 서브 도메인에 설정하는 기능을 이용하여, 전달 받은 쿠키를 공유하는 DB 질의를 통해서 접근하는 방법이 있으며
  3. 토큰하나를 캐시나 URL에 인코딩하여 전달한 뒤, 토큰의 진의 여부를 결정해주는 내부 서버를 두어 필요시마다 서버들간 대화를 하게 만들 수도 있고,
  4. 무식하게는 ID와 패스워드가 몰래몰래 네트웍을 날아다니게 만들 수 도 있습니다.`
OpenID는 하나의 사이트에 로그인할 때, 세 번의 질문을 하게 됩니다. 하나는 OpenID를 묻는 것이고, 두번째는 OpenID 자체의 소유여부를 확인하기 위한 비밀번호 등이고, 세번째는 인증정보를 전달할 도메인을 확인하고자함입니다. 대개 두번째 질문은 한 동안은 묻지 않고 유지 됩니다. 세번째도 만약 신뢰하는 사이트라면 묻지 않게 됩니다.

OpenID가 SSO를 구현하는데 사용된다고 합니다만, 이를 위해서는 로그인사이트(Consumer Site; Relying Party)들이 정교한 처리를 해주어야합니다. 몇몇의 서비스를 이용해 보셨지만, 한 사이트를 사용하다가 다른 사이트에 이동하게 되면, 적어도 셋 중 최초 자신의 OpenID는 넣어야 인증이 됩니다.

정교한 처리란, 이 OpenID 마저 다시 넣지 않는 개발이 필요한 것인데, 만약 그 사이트에 두 번째 들어간다면 처음 로그인할 때 쿠키를 설정해놓고 들어 오자마자 쿠키에 씌여 있는 OpenID로 로그인 시도를 할 수 있겠지요. (Jyte.com이 그런 행위를 하는 것 같습니다만, 때에 따라 그렇지 않은 것을 보아서 정확한 구조는 파악 못하였습니다.)

OpenID가 SSO에 사용된다는 것은, 최초 OpenID를 제출하고, 이것의 OpenID의 소유자임을 확인한 브라우져 세션에 대해 "계속 승인"으로 설정한 경우, OpenID를 제출하는 것만으로 로그인이 가능하다는 것을 의미합니다. 따라서, 최초에 제기한 조건들을 충분히 만족하지 않고, 이러한 가장 큰 이유는 로그인하는 서비스들이 모두 분산되어 있는 상황이기 때문입니다. 애초부터, 같은 조직이 아닌 서비스들을 단일 사용자 로그인을 지원한다는 것 자체는 보안상 상당히 취약한 생각입니다.

다음 글에는 환상을 품을 만한 실험 한 결과를 공유해 보겠습니다.

신고
  1. 하늘이 2007.04.08 02:13 신고

    오옷 실험 결과가 기대됩니다. +_+)=b
    (매일 오픈 아이디에 대해서는 눈팅만 해오다가 이제서야 먼가 하나 빤짝 도전해보려는 선량한 시민이랍니다. 흐흣)

한동안 글이 없었습니다. 심신이 피곤하여 긴 글을 쓸 염두가 안나더군요. (미투데이조차.. ^^)

www.idtail.com을 여는 것 때문에 많이 긴장했던것 같습니다. 사이트에는 베타라는 말은 없지만, 사실 팀에선 Open Beta 상태입니다. 요즘엔 베타라는 이름으로 오픈하는 것이 더 부끄(?)러운 모양인지라, 뭔가 부족한 듯한 것이 있다는 거 뻔히 아는데, 베타라는 말까지 달고 있으면, 정말 부끄러울 것 같더군요.

그간 약 150명 가량 등록되어 있는데, 시험삼아라도 가입해주신 여러분들께 감사드리구요. 불편한점 고쳐가며, 여러가지로 회사이미지에 맞는 보안성도 만족하고, 또한 보안이라는 이미지를 확장하는 서비스로 정착할 수 있는 서비스를 만들어가겠습니다.

지난, 미투데이 오픈마루의 번개에서 몇몇 분들께는 4월초에 연다고 말씀을 드렸었는데, 아직까지 이 다음단계는 아이디어 단계에 있습니다. 무한한 가능성이 있는 이 OpenID를 정말 제대로 된 물건이 되게하기 위해서 올해는 여러 실험들이 있으리라 보여지는군요.

많은 서비스들이 오픈아이디로 이어지는 세계를 꿈꾸며.. 이만.

------

제가 이 글을 쓰고, 저희 로고에 Beta가 붙어 있는 것을 보고는 화들짝 내렸습니다만, 이미 RSS로 널리널리 퍼져가고 말았습니다. 12시간 만에 다시 이 댓글을 추가하여 올립니다. 긴장의 끝이 엄청난(?) 사실 왜곡으로 가는 군요. 쩝...

저를 비난하세요.

신고
  1. 건더기 2007.04.17 11:39 신고

    간만에 뵈어서 즐거웠었습니다~~

    안랩 근무하시는지는 요번에 처음 알았어용..

    V3 95부터 계속 정품 갱신하며 쓰는지라 왠지모르게 쿨엔~ 님이 더 반가워보인다는~~ :)

OpenID로 2007년은 시작하고 있습니다. 아마 곳곳에서 기존의 서비스에 이것을 어떻게 붙여볼까 많은 고민들을 하고 계시리라 생각합니다. 이런 고민들을 하겠지요.
  1. 히야, 이거 막 뜨고 있는데, 샘플 보니 구현도 쉬울 것 같애.
  2. 기존 ID를 위한 필드를 작게 잡아 두었는데, URL을 키로 사용한다니 너무 길잖아?
  3. 게다가 기호까지 ID에 들어 있군, 쉽지 않겠어.
  4. 기존 ID에 OpenID를 인증하여 한 번 연결시켜놓으면, 다음에 OpenID로 들어오면 그 ID의 권한을 주면 되잖아?
  5. 그럼 기존 User 테이블에 필드를 하나 추가할까? 아니면 테이블을 하나 더 두어 Join할까?
  6. 사용자 신규 가입시에는 OpenID로 받게하면, 기존 ID 필드에는 랜덤값을 넣는 방향으로 하고, 메뉴 전면에서 그 값은 안보여주면 되지 않을까?
  7. 랜덤값이면 추적하기 힘들어 OpenID의 첫번째 단어로하고 만약 존재하면 1,2,3.. 붙여나가면 될 것 같애.
  8. 만약 신규로 OpenID만으로 가입하여 랜덤 ID로 처리되는 중에 OpenID를 분실했다고 하면 어떻게 하지?
  9. 아니, IdProvider는 그쪽 회원 탈퇴여부를 우리에게 알려주지도 않는데, 우리는 어떻게 이 계정이 휴면되었는지 알 수 있지?
  10. 기존 ID에는 꼭하나의 OpenID만 인증해 둬야하나? 만일 맘에 안드는 OpenID라서 다른 것으로 가입하고 싶다고 불만접수되면 어떻게 하지?
  11. 아예, 기존 ID에 두 개이상의 OpenID를 넣게 해서 자유롭게 사용할 수 있도록 하면, 어떨까? 어차피 AAA 개념상 어떻게든 적절한 Authentication이 일어나면 그 사람임을 기존 ID로 인정하여 접근 권한을 Authorization하는 것 아니겠어?
  12. OpenID로 접근하는 것은 아예 댓글 정도의 부분적인 기능만 제공하는 것은 어떨까? 그 정도면, 사이트도 지원한다고 광고할 수 있을 것이고, 기존 체계를 많이 엎지도 않아도 되는 것 아니겠어?
  13. OpenID로 로그인하겠다고 한 계정은 기존 계정으로는 로그인 못하게 막아야하는 것 아닐까? 굳이 경로를 두 개를 두어 보안 홀이 생기는 것 아냐?
  14. OpenID로 가입유도를 해야하는 것일까? 아니면, 로그인하자마자 바로 사용하게 만들어야할까?
  15. OpenID로 먼저 로그인하게 만들고 미가입 회원인 경우 기존 ID도 만들게 하는 것은 어떨까?
  16. OpenID는 사용자가 제출한 것을 사용해야하는것일까? 아니면 1.0, 2.0 스펙이 말하는대로 사용자가 제출한 URL이 Redirection하는 마지막 URL을 사용해야하는 것일까?
  17. 외부에 노출되지 않게 설계한다면, 어떤 것을 사용해도 좋은것 아닐까? 외부에는 별명정도만 선택하게 만들어거 노출시키면 되지 않나?
  18. 자신의 홈페이지 주소를 OpenID로 사용하였는데, IdP의 OpenID로 로그인 시도하면 이것을 같은 계정으로 받아 줘야하는 걸까, 아니면 다른 계정으로 봐야할까?
  19. 어차피 위임받은 계정인지 알 수 있으니까 둘 다 저장해두고, 이 계정으로 쓴 글들을 다른 사용자들이 조회할 때 두 계정을 모두 볼 수 있도록 하지 뭐.
  20. 검색 페이지에는 openid 를 검색할 수 있게 해야하나 말아야하나.
밑도 끝도 없이 늘어나는 고민입니다. 1 번의 쉬운 유혹이 사람을 잡죠.

글 다쓰고 트랙백 날릴려고 했는데, 이런 링크가 있었군요. 이건 고민이 아니라 "잘했다 칭찬하리라" 를 위한 가이드군요. OpenID 사이트가 늘기전에 "칭찬 받을 짓"에 대한 목록을 미리 만들어 각자의 모습으로 개발하는 것을 막는 것은 중요한 것 같습니다. 어찌, OpenID는 다른 것과 달리 뒤에서 정리하는 것이 아니고, 미리 정리되는 듯한 느낌입니다.
신고
  1. nainu 2007.03.13 10:19 신고

    이런 곳이 있었네요. 북마크해 둬야 겠습니다. 감사합니다. (__)

    • 최호진 2007.03.13 17:39 신고

      이런곳이라함은... 제 블로그를 말씀하신거가 아니라 저 Best Practice를 말하시는거죠? ;)

  2. Kay 2007.03.13 22:00 신고

    거기 Best practice 마저 번역 좀 해주시지요. 영어가 달려서... ㅋㅋ

    • 최호진 2007.03.14 02:51 신고

      다대일관계의 OpenID Url과 일반 사용자 계정

      이후로 번역하였습니다. 켁..... 피자이야기는 그냥 아무거나 바꿀 수 있는 거 같애서 번역 속도를 내기 위해 그냥 작성해 넣었지요.

  3. Kay 2007.03.13 22:11 신고

    #16 redirection 최종 URL 을 claimed ID 로 쓰라고 하네요. 사용자 직관과 좀 어긋날 수도 있겠지만, 일단, 그것을 써야할 듯 합니다. clamied ID 는 사용자가 계속 가져가고 싶은 ID 일 테니까요. 근데, 쿨님 claimed ID 는 http:/...../tt/ 이시네요. 의도한 것이 아니실듯 ㅎㅎ
    #18 사용자 선택이겠지만, 경우에 따라서는 알아도 모른척 해줘야 하지 않을런죠 ㅎㅎ
    #19 사용자가 내세우고 싶지 않은 idP ID 는 몰라주는 게 좋다고 생각합니다. 저는. ㅎㅎ

    ... 고민이 많으시네요. 오픈아이디로 서비스를 많이 준비중이신가 봅니다. ^^

  4. Raymundo 2007.03.14 10:24 신고

    > 1번의 쉬운 유혹이 사람을 잡죠

    동감 100만표입니다. ^^

    제 개인홈페이지로 쓰는 위키에 OpenID 로그인을 가능하게 해볼까 했는데 이건 뭐 필요한 라이브러리 설치부터 제대로 안 되고 있는데다가, 위에 열거하신 문제들이 와르르 뒤따라오는군요. ^^ 좋은 글 잘 읽고 갑니다, 이 글 뿐 아니라 OpenID 태그가 달린 다른 글들과, BP 번역하신 것들도.. :-)

  5. 숏다리영감 2007.03.14 10:57 신고

    안녕하세요. NoSyu.egloos.com의 오픈아이디 설명을 보고, 따라하기 중입니다.
    양해바랍니다..

  6. 2007.03.15 18:26 신고

    저도 그저께 OpenID 세미나를 회사서 해서 들었는데...
    우리나라에서도 활성화되려면 시간좀 걸리겠는걸요~^^

    • 최호진 2007.03.16 01:23 신고

      활성화하자는 의미에서 OpenID로 로그인하여 다시 댓글 남기삼!

  7. gray 2007.03.20 23:51 신고

    덕택에 제 블로그에도 쉽게 openid 를 적용해볼 수 있게 되었습니다.

    감사합니다. =)

  8. 커피소녀 2007.06.12 10:13 신고

    님 글을 통해 저도 다시금 고민해봅니다. 지금 오픈아이디 연동준비중이거든요 ^^
    함께 고민할수있는 님이 있어서 좋네요 ^^

  9. NGIN 2007.08.04 12:04 신고

    안녕하세요..^^
    OpenID 알아보면서 들어와보게 되었습니다~^^
    좋은 글 보고 갑니다.

+ Recent posts