OpenIDにかんするさまざまな疑問を解消していく本連載。今回は、OpenIDではどのような流れで認証手続きが行われているのかを解説する。
OpenIDに対応すると、自社のWebサービスにシングルサインオン機能を簡単に実装できると聞きました。ユーザビリティ向上の観点からすぐにでも対応しようと考えていますが、OpenIDでのログインに対応する前に、どのような認証手続きが行われるのかを教えてください。また、注意しておくべきことなどがあれば教えてください。
ご質問の通り、これから展開するサービスにおいてOpenIDでのログインに対応すれば、アカウントに対する認証機能をOpenID Providerに任せることができるので、シングルサインオンを実現できることになります。このようなサービスをOpenIDの世界ではRelying Partyと呼びます。
Relying Partyではユーザーが用いるID(URLまたはXRI)を一意な値として保持する必要があります。この際に用いるのはClaimed Identifierと呼ばれるものにすべきです。Claimed Identifierとは、かみ砕いたいい方をすると、ユーザーが自分のIDとして利用したいと思っているURLのことで、Relying PartyはOpenID Providerと連携することでこのClaimed Identifierが本当にそのユーザーが所有しているかどうかを確認します。この一連の手続きがOpenIDプロトコルにおける認証手続きであり、認証されたClaimed IdentifierはVerified Identifierと呼びます。
以上の手続きを具体的に説明すると次のようになります。
これらを簡潔に説明してしまうと、ユーザーが自分のIDであるURLまたはXRIをRelying Partyが用意したフォームに入力すると、OpenID Provider上にてそのClaimed Identifierの検証を行い、認証結果をRelying Partyが用意したコールバックURLに返してくれます。ユーザーが見える処理はこういった流れですが、実際にはRelying PartyとOpenID Providerとの間で事前の手続きが必要となります。この辺りは各言語で存在するOpenID用のライブラリが解決してくれます。
認証手続きに関してはざっと以上ですが、ユーザーのIDとして先ほどClaimed Identifierを用いるべきだと述べました。Delegateという認証を委譲する仕組みを使うと、Claimed IdentifierとOpenID Providerが認証したVerified Identifierが異なる値の場合があります。Delegateを用いた場合は、ユーザーが使用したいと考えているのはClaimed Identifierであって(OpenID Providerが提供する)Verified Identifierではありません。従ってRelying Partyが一意に認識するべきIDはClaimed Identifierに統一すべきです。
サイボウズ・ラボで研究開発にいそしむPerlハッカー。Perlを中心とした開発のノウハウやネタをShibuya Perl Mongersのイベントで発表するなど講演活動も行う。最近ではOpenIDの実装方法や考察などをブログ「Yet Another Hackadelic」などで書き連ねている。
Copyright © ITmedia, Inc. All Rights Reserved.