検索
連載

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

いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。

PC用表示 関連情報
Share
Tweet
LINE
Hatena
前のページへ |       

OpenIDの利用事例

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

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

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

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

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

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

画面2 mixiの同意画面
画面2 mixiの同意画面

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

画面3 新規ユーザー登録画面でmixiから受け取ったニックネームを利用
画面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を組み合わせた拡張仕様を利用している
画面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の特性の違いやどちらを使うべきかという悩みはなくなるでしょう。

第4回に向けて〜OpenID Connectとは

 本稿ではOpenIDのこれまでの歩みについて振り返りました。次回は仕様策定中のOpenID Connectについて、設計思想からフローまで一気に紹介します。

著者プロフィール

▼Ryo Ito(ritou)

http://d.hatena.ne.jp/ritou/

OpenID Foundation Japan Evangelist。OpenID Connectのコントリビュータとして仕様策定に関わっている。 業務ではアイデンティティ技術を用いたSNSサービスの強化を検討しており、個人ブログではOpenID/OAuthについて情報発信を行っている。


前のページへ |       

Copyright © ITmedia, Inc. All Rights Reserved.

ページトップに戻る