OpenIDが果たす役割を知る：デジタル・アイデンティティ技術最新動向（3）（2/2 ページ）

» 2012年09月20日 18時00分公開

[ritou，OpenID Foundation Japan]

OpenIDの利用事例

　それでは、実際にOpenIDが利用されているサービスを見てみましょう。

　OpenID 2.0のRPの1つに、「iKnow!」という語学学習サービスがあります。このサービスでは、既存のID／パスワード認証、Twitter／FacebookのOAuthを用いたユーザー認証、OpenIDの認証という3つの方法を利用しています。

　ログイン画面の右側にある「外部サービスのIDでログイン」の部分にはmixi、Yahoo! JAPAN、Google、NTTといったサービスのアイコンが並んでいます。

画面1　iKnow!のログイン画面にはOPのアイコンが並ぶ

　並んでいるアイコンは国内のOPで、クリックするとOpenID 2.0のフローが始まります。これ以外のOPを利用したい場合は、「上記以外のOpenID」というリンクをクリックすることで入力フォームが表示されます。

　例えば「Mixi」というアイコンをクリックすると、iKnow!からmixiに認証リクエストが送られます。mixiは属性情報として「ニックネーム」を提供しており、iKnow!は拡張仕様によりその値を要求します。ユーザー認証の後、「ユーザー識別子としてのOpenID」と「ニックネーム」をiKnow!に渡すことについて同意を求められます。

画面2　mixiの同意画面

　同意をすると、ユーザーはmixiからiKnow!に戻されます。この時、ユーザー識別子を含む認証情報と属性情報（ニックネーム）が渡されます。iKnow!は受け取ったユーザー識別子を用いて、すでにアカウントを持っているかどうかを判定します。新規ユーザーと判断された場合、登録画面が表示されます。

画面3　新規ユーザー登録画面でmixiから受け取ったニックネームを利用

　ここでは、mixiから取得した「ニックネーム」を名前の入力フォームの初期値として利用しています。新しいサービスを使う際、プロフィール情報として他のサービスで利用しているものと同じ値を設定することがよくあります。属性情報交換、提供のための拡張仕様を実装したOPを利用することで、ユーザー認証だけでなく新規アカウント登録時の敷居をさらに下げられます。

OpenIDとOAuthとの関係

　OpenID 2.0とOAuth 1.0の仕様は、同時期に策定されました。ユーザーから見た画面遷移もほぼ同じであるため、開発者の間でそれぞれの機能が比較されるようになりました。

　OpenID 2.0では一度の実装で複数のOPに対応でき、新たなOPが増えた場合もコストをかけずに対応が可能です。第1回の説明にあったように、OAuth 1.0でもプロフィール情報を取得できるAPIが提供されることで、既存のユーザーかどうかの判定ができます。

　一方、ユーザー認証を実装でき、その上サービス独自のAPIを利用できることから、OAuthはOpenIDよりも優れているという声もあります。しかし、OAuthではOpenIDのように認証結果の定義や認証ポリシーの指定方法がありません。また、OAuthでは開発者がアプリケーションを登録し、それぞれのドキュメントにそってAPIアクセスの部分を作り込む必要があります。

　いずれにせよ2つのプロトコルにおける最大の課題は、OpenID 2.0の認証結果とOAuth 1.0のアクセス権限の付与が同時に行えないという点です。

　GoogleやアメリカのYahoo!は、早い段階からOpenID 2.0のOP対応を行いつつ、OAuth 1.0対応のAPIも実装していました。しかし、それぞれの機能を利用するには別々にユーザーの同意をとる必要がありました。

　この課題を解決するために、OpenID 2.0のOPでありOAuth 1.0のService Providerであるサービスから認証結果とアクセス権限の付与を同時にやりとりする方法が、OpenID OAuth Extensionとして提案されました。これは、OpenID 2.0の仕様でやりとりされる認証結果にOAuth 1.0のトークンを含むというものです。ただ、両者を組み合わせることにより実装も複雑になってしまうほか、OAuth部分はそれぞれのAPIに合わせて個別に作り込む必要があります。

　そのため、あまり多くのサービスに実装されているわけではありませんが、mixiではGmailのアドレス帳から友達を検索するフローでこの拡張機能をRP側として実装しています。

画面4　mixiはOpenID 2.0とOAuth 1.0を組み合わせた拡張仕様を利用している

OpenID 2.0の課題と最新仕様

　OpenID 2.0を実装するサービスが増えるにつれ、上述のOAuthとの連携以外にも仕様面で課題が見えてきました。

　最も影響が大きかったものは、日本のモバイル環境における問題です。スマートフォンが普及する前の携帯電話のブラウザでは、「URL長の制限からGETでOpenIDのリクエスト／レスポンスが送れない」「POSTではJavaScriptが利用できないためにフォームを挟む必要があり、余計なクリックが発生してしまう」との声がありました。

　その他、仕様の複雑さが課題として取り上げられたり、インターネットに接続できる機器の増加に伴い、Webアプリケーション以外でも動作するシンプルな仕様が求められるようになりました。

　IETF WGにてOAuth 2.0の仕様策定が始まったころ、OIDFでも次世代OpenIDの仕様策定が始まっていました。

　OAuth 2.0ではWebアプリケーション以外のクライアントアプリケーションに対するアクセス権限の付与も想定されています。HTTPSを利用することで署名を必要としないシンプルな仕様は、2011年のドラフト段階から採用するサービスが現れました。

　一方、次世代OpenIDに当たるOpenID Connectは、OpenID 2.0からリクエスト／レスポンスを引き継ぐことをせず、OAuth 2.0をベースにして、これまで足りなかった以下のような機能を拡張しています。

認証結果のやりとり
統一的な属性情報の提供
OP探索、動的なRP登録
RPに戻った後のセッション管理

　それぞれの機能については次回紹介しますが、OAuth 2.0に触れたことのある開発者にとって、OpenID Connectを実装するための学習コストはそれほど高くありません。OpenID Connectの登場により、OpenIDとOAuthの特性の違いやどちらを使うべきかという悩みはなくなるでしょう。