OpenID 그까이꺼(2)

이번에는 Consumer 구현입니다.

지난번에 이야기한 건 Provider편이었죠? 많은 부분 Provider와 겹치므로 슬쩍 새 창으로 띄워서 컨닝해가면서 따라오세요.

역시 마찬가지로 PHP 4.3.0 이상, bcmath나 gmp가 설치되어 있다고 가정하고, MySQL은 InnoDB를 사용합니다.

또한, 이미 OpenID Library가 설치되어있고 경로에 추가되어있다고 가정합니다.

Consumer편은 더 쉽습니다. 설명할 게 없을 정도.

일단, 세션스토어로 MySQL을 사용할 예정이니 Provider편과 마찬가지로 MySQLStore 객체를 만듭시다.

[php]

$connection = DB::connect($dsn);

$store = new Auth_OpenID_MySQLStore($connection, 'setting', 'association', 'nonce');

//$store->createTables();

[/php]

물론, 최초 실행시에는 createTables()를 해줘야합니다.

만약 MySQL대신 다른 Store를 이용하고 싶다면 다른 Store 클래스로 객체를 만드시면 됩니다. Factory 패턴이기 때문에 따로 신경안써줘도 되는건 OO 공부하신 분들이면 다 아실테지요.

[php]

$store = new Auth_OpenID_FileStore($store_path);

[/php]

예를 들어 파일패스를 스토어로 쓰고 싶다면 이렇게 해주면 된다는 말씀.

이제 만들어진 스토어 객체로 Consumer 객체를 만듭시다.

[php]

$consumer = new Auth_OpenID_Consumer($store);

[/php]

일반적인 시나리오에서는, 사용자는 Consumer 사이트에 와서 자신의 OpenID를 Form으로 입력하겠죠. 어쨌거나 인증하고자 하는 OpenID값을 Consumer 객체에 던져주기만 하면 됩니다.

[php]

$openid = $_POST['login_openid']; // 뭐, 예를 들자면.. 이런 식이겠죠:)

$auth_request = $consumer->begin($openid); //오픈아이디 서버와 association을 시도하고 그 결과를 돌려줍니다.

if($auth_request) {

//success;

} else {

//fail;

echo "Authentication Fail";

}

[/php]

$auth_request가 true이면 정상적으로 association이 이루어졌다는 뜻입니다. 만약 false라면 인증에 실패했다는 메시지를 사용자에게 보여주면 되겠죠?

association이 성공적으로 이루어졌다면 이제, 해당 openid에 대한 인증을 시도하면 됩니다.

[php]

$trust_root = 'http://consumer.com';

$process_url = 'http://consumer.com/afterAuth';

$redirect_url = $auth_request->redirectURL($trust_root, $process_url);

header("Location: ".$redirect_url);

[/php]

$trust_root는 Provider에게 이 인증시도가 어떤 Consumer로부터 시도된 것인지 신뢰여부를 판단하게 해주는 일종의 키값이 됩니다. 완벽하진 않지만, trustroot와 인증시도 도메인간에 도메인이 다를 경우 피싱시도로 파악해서 인증을 거부하거나 할 수 있도록 하지요. 반대로, trustroot로 인정된 도메인의 경우에는 따로 지정하지 않는 한, 인증을 자동보장한다거나 하는데 쓰일 수 있겠지요.

$process_url은 OpenID Provider가 인증을 처리하고 난 후 그 결과값을 되돌려받을 Consumer 사이트의 url입니다.

위의 코드가 실행되면, $redirect_url이 되돌려집니다. $redirect_url은 Provider의 인증처리 페이지에 인증 Request를 Get 메쏘드로 전달하는 형태이지요. 즉, 이렇게 만들어진 $redirect_url로 redirect시켜주기만 하면 됩니다.

만약 단순한 인증으로 끝나지 않고, Simple Registration Extension를 이용해 사용자 정보를 얻어오길 원한다면

[php]

$auth_request->addExtensionArg('sreg', 요구필드타입, 요구필드이름리스트);

[/php]

를 redirecURL메쏘드 실행전에 실행시켜주면 됩니다.

요구필드타입은 required/optional이구요, 비록 required라고 해도 Provider에서 반드시 정보를 제공한다는 보장은 없으니(Simple Registration Extension를 지원하지 않거나, 사용자가 정보제공을 거부하거나...), required로 요구한 필드의 되돌아오는 값이 없다해도 에러는 아니라는 점.

그외에, policy_url을 이용해, 어떤 필드들을 왜 요구하는지 설명을 알려줄 수도 있지요.

요구필드로 현재 Simple Registration Extension 에 정의된 필드는,

nickname, email, fullname, dob, gender, postcode, country, language, timezone

의 8 가지인데요, 주의할 점은 각각의 필드의 리턴값은 RFC와 ISO에 정의된 표준 스펙이라는 겁니다. 그러니까, country를 알려달라고 요구해도, "Korea"라든가 "대한민국"같은 형식으로 돌아오지는 않는다는 거지요.

각각의 필드에 대한 스펙 및 Simple Registration Extension에 관한 더 자세한 설명은,

여기를 참고하세요.

에.. 하여튼간에, 실제로 Simple Registration Extension을 이용하려면,

[php]

$auth_request->addExtensionArg('sreg', 'policy_url', 'http://consumer.com/policy');

$auth_request->addExtensionArg('sreg', 'required', 'email');

$auth_request->addExtensionArg('sreg', 'optional', 'nickname');

$auth_request->addExtensionArg('sreg', 'optional', 'gender');

$redirect_url = $auth_request->redirectURL($trust_root, $process_url);

header("Location: ".$redirect_url);

[/php]

처럼 하면 된다는 말씀.

이제 인증 요청이 끝났습니다. redirect를 통해 Provider에게 GET 메쏘드로 인증요청을 했으니 나머지는 Provider와 사용자간에 나름의 과정을 통해 인증여부가 회신되겠지요?

전에 지정해둔 $process_url로 회신이 돌아옵니다.

다음은 $process_url에서 GET으로 돌아온 회신에 대한 처리부분입니다.

[php]

$response = $consumer->complete($_GET);

switch($response->status) {

case Auth_OpenID_CANCEL :

// 사용자가 인증을 취소했을 때의 처리

break;

case Auth_OpenID_FAILURE :

// 무언가의 문제로 인해 인증이 실패했을 때의 처리(인증을 요구한 openid가 없다든가..)

break;

case Auth_OpenID_SUCCESS :

// 인증성공!!

break;

}

[/php]

인증은 모두 끝났습니다. 간단하죠? :)

만약 Simple Registration Extension을 사용했을 경우, 요구했던 필드값들을 구해야겠죠?

[php]

$sreg = $response->extensionResponse('sreg');

echo $sreg['email'];

[/php]

이걸로 진짜 끝.

간단하죠?

그러니까 OpenID 지원하는게 뭐 대단한 것도 아닌거에요. 무슨 코어모듈을 고쳐야 한다거나 하는 작업이 있을리도 없으니까, Consumer 지원하는 건 어려운 일이 아니에요. 물론 Provider가 되려면 좀 더 복잡한 작업이 필요하긴 합니다만, Provider는 많을 필요도 없고요.

OpenID의 의의를 이해하신다면, 별 특징이나 기능도 없는 Provider가 늘어나는 건 그저 사용자들에게 불편만 주고 OpenID의 장점을 전혀 못살리는 멍청한 짓이기도 하지요.

delegation을 이용하면 어떤 Provider를 쓰든 상관없는 거니까요. (오히려 Simple Registration Extension을 지원안하는 Provider라면 편의성이 떨어지는 셈이니 이용에 고민을 해봐야겠지요. 물론 보안문제가 아직 완벽하게 해결된 것은 아니므로 SRE를 믿느냐는 좀 다른 이야기긴 합니다만.)

국내에서 OpenID를 이야기하는 사람들이 많아지긴 했습니다만... 뭐랄까, 실제 개발자들에게는 그런 뜬구름잡는 이야기보다는 간단한 샘플소스에 대한 설명 하나가 더 필요한 시점아닐까 하는 생각이 드네요. 정말로 OpenID를 널리 퍼뜨리게 하고 싶다면요. 혹은, 그냥 기술적 우위를 뽐내는 걸로 만족하는 거라면 또 다른 이야기겠지만요.