요약

  • OpenID Authentication 2.0은 이용자가 주장하는 URL과 인증 제공자 안에서 쓰는 계정 식별자를 분리했다. 이용자가 관리하는 URL은 그대로 두고 인증 제공자를 바꿀 수 있는 구조였다.
  • 로그인하는 사이트는 그 URL에서 제공자를 찾아 응답과 대조해야 했다. 또한 URL을 자체 계정의 기준으로 보관해야 제공자가 바뀌어도 같은 사람의 기록을 이어 갈 수 있었다.

로그인 버튼은 작았지만 그 뒤의 소유권 문제는 컸다. 다른 사이트가 나를 알아보는 이름은 누가 정하는가? 2007년 12월 5일 확정된 OpenID Authentication 2.0 규격은 이용자가 제시한 URL을 그 이름으로 삼을 수 있게 했다. 방문한 사이트는 URL에서 인증 제공자를 찾고, 브라우저를 그쪽으로 보낸 뒤, 돌아온 응답을 검증했다. 이용자는 방문한 사이트마다 비밀번호를 건네지 않아도 됐다.

규격은 두 식별자를 분명히 구분했다. Claimed Identifier는 이용자가 방문 사이트에 자기 이름이라고 제시한 값이다. OP-Local Identifier는 인증 제공자 내부에서 이용자를 부르는 값이다. 두 값의 호스트는 달라도 되고, 제공자 내부의 이름을 이용자가 직접 관리하지 못할 수도 있었다. 방문 사이트가 둘을 같은 이름으로 취급하면 제공자를 옮기는 순간 계정의 연속성이 흔들린다.

방법은 웹페이지의 링크에 담겼다. 주장한 URL의 HTML에 rel="openid2.provider" 링크를 두면 인증 제공자의 엔드포인트를 알릴 수 있었다. 선택 항목인 rel="openid2.local_id"는 그 제공자가 쓰는 로컬 식별자를 알려 줬다. 페이지를 관리하는 사람은 제공자 링크를 고치고도 방문 사이트에 제시하는 URL은 유지할 수 있었다. 내 이름은 그대로 두고 비밀번호를 확인하는 사업자만 바꾸는 셈이다.

하지만 주소에 링크가 있다고 아무 응답이나 받아서는 안 됐다. 규격은 방문 사이트, 곧 Relying Party가 주장한 URL의 발견 정보를 확인하고, 응답 속 제공자 엔드포인트와 로컬 식별자가 그 정보와 일치하는지 검증하도록 했다. 앞서 발견 절차를 거치지 않았다면 긍정 응답을 받을 때라도 해야 했다. 이를 생략하면 엉뚱한 제공자가 남의 URL을 대신해 말할 수 있다. URL의 링크가 권한을 주고, 사이트의 대조가 그 권한을 집행했다.

검증 뒤에는 계정 장부가 남았다. 규격은 이용자의 로컬 정보를 저장할 때 주장한 식별자를 열쇠로 쓰라고 권고했다. 제공자가 바뀌어 그쪽 내부 식별자가 달라져도 URL이 같으면 기존 계정으로 돌아갈 수 있기 때문이다. 반대로 제공자 내부 이름을 영구 키로 삼은 사이트라면 이용자가 같은 URL을 들고 와도 새 사람처럼 취급할 수 있었다.

OpenID 1.1과의 호환 규칙도 같은 약점을 드러냈다. 구버전 응답에는 openid.claimed_id가 없었다. 따라서 주장한 URL과 제공자 내부 이름이 다를 때 사이트는 처음 발견에 사용한 URL을 세션 등에 남겨 두어야 했다. 인증 성공이라는 결과만 기억하면 그 성공을 어느 계정에 붙일지 알 수 없었다.

OpenID Foundation의 2007년 12월 5일 발표는 인증 규격과 속성 교환 규격의 확정을 알렸다. 인증 규격이 그린 거래는 명확했다. 이용자는 오래 쓸 이름을 소유하고, 제공자는 신원 확인을 맡고, 방문 사이트는 확인 결과를 자신의 계정에 연결한다. 실제 사이트에서 제공자 이동이 얼마나 순조로웠는지는 그 사이트의 원본 계정 연결 기록으로 판단해야 한다.

원문 자료