本報告では2011年下半期のアイデンティティ管理技術に関する動向として、OpenID 仕様の次期バージョンとなる予定のOpenID Connect [1]の概要を紹介する。OpenID Connectは、OpenID 2.0の次期バージョンとなる予定の仕様群である。現在、米国 OIDF（OpenID Foundation）のOpenID AB/Connect ワーキング・グループ[2]にて、仕様策定の議論が進行している。

　現行のOpenID 仕様であるOpenID Authentication 2.0およびOpenID Attribute Exchange 1.0（以下「OpenID 2.0」と表記）は、ふたつのWebサイト間における、Webブラウザを用いたアイデンティティ情報（エンドユーザの認証結果と属性情報）の要求・提供を行うためのプロトコルとして、2007年12月に策定された[3]。現在までに、インターネットサービス事業者（例： Yahoo!、Google、ミクシィ）、携帯通信事業者（例： NTTドコモ、KDDI、ソフトバンク）、ネット決済事業者（例： 楽天（楽天あんしん支払いサービス）、PayPal）などのような、多数のユーザを抱えるWebサイトが、他社WebサイトにID情報を提供するためのAPI（Application Programming Interface）としてOpenIDを採用している。OpenID 2.0仕様では、ID情報を要求するWebサイトをRP（リライング・パーティ）、一方、提供するWebサイトをOP（OpenIDプロバイダ）と称する。同仕様のフロー概要を以下に示す（図1）。

図1：OpenID 2.0のフロー概要

　OpenID 2.0 は実装を容易にするために、ユースケースを「OpenIDプロバイダのID情報を用いた、RPへのログイン／属性提供」に限定した仕様となっている。その結果、以下のような要件を満たすことは、仕様の範囲内では容易ではない（図2）。

図2： OpenID 2.0の課題

• 機能の制限された Web ブラウザへの対応

  　OpenID 2.0 では、ユーザ・エージェントとして一般的なWebブラウザを対象としており、ある程度大きなURL長を処理する能力や、リダイレクト機能などを有する必要がある。そのため、携帯端末などのように機能が制限された環境のWebブラウザでは、OpenID 2.0 プロトコルを処理できない場合がある。



• セキュリティ要件への対応

  　OpenID 2.0 プロトコルでは、Web サイト間でのID情報の要求（認証リクエスト）ならびにその提供（アサーション）は、Webブラウザのリダイレクト機能を用いて、平文のメッセージをやりとりすることにより行われる。そのため、OpenIDプロバイダがRPに対して提供したアサーションの内容が、Webブラウザにおいて露見することになる。
  　またメッセージには改竄防止のために署名を付加するが、Webサイト間での共通鍵を用いるため、認証リクエストやアサーションの否認防止にはならなかった。



• 実装しやすさの改善

  　先に述べた通り、OpenID Authentication 2.0仕様では、Webサイト間でのメッセージ交換に署名を付与することになっており、そのための鍵の交換をWebサイト同士が動的に行う必要がある。
  　Webサイトはこの機能を実装するにあたり、スクラッチからではなく、OpenID 2.0に対応したフレームワークやライブラリを用いることが一般的である。しかし既存システムへのライブラリの導入ができない、広く使われているライブラリが存在しないなどといった制約から、OpenID 2.0 に対応することが難しくなっている場合もあった。



• Web サイトではないアプリケーションに対するID情報の提供

  　OpenID 2.0 が対象とするユースケースはWebサイト間でのID情報の要求・提供であり、スマートフォンにインストールされたネイティブ・アプリケーションや、WebブラウザにダウンロードされたJavaScriptアプリケーションなどの、これらWebサイトではないアプリケーションがRPとなる用途には向いていない。



• サービス連携との組み合わせ

  　近年、APIを提供する事業者が、自社外のサービスやアプリケーションに対し、API へのアクセス権をユーザの同意に基づき認可するユースケースが増えてきており、そのアクセス権許可のプロトコル標準として OAuth[4]が普及してきている。
  　ただしOAuthはあくまでアクセス権限提供のためのものであり、OAuthの認可シーケンスの中で認証結果と属性情報を扱うための規定は含まれていない。OpenIDのシーケンスにOAuthの認可フローを組み合わせ、ID情報の要求・提供とアクセス権委譲を同時に行う「OpenID/OAuth Hybrid」という手法が存在するが [5]、同手法では結局OpenIDとOAuthの双方を実装しなくてはならず複雑なことから、広く利用されるには至っていない。
  　結果的に、独自の「アイデンティティ API」を定義し、OAuthによるアクセス認可を行うサービスが多数存在することになり、APIを利用する側からは、個々の仕様に対応する必要が発生していた。
  　これらの課題に対しOpenIDコミュニティでは、OpenID 2.0 策定以降、OpenID CX（Contract Exchange）[6]やAB（Artifact Binding）[7]などのワーキング・グループをOIDF配下に設置し、仕様の改良を進めてきた。一方 2010 年、これらの活動とは別に、OAuth 2.0をベースとする新たな OpenID仕様「OpenID Connect」の試案がコミュニティの一部から提唱された [8]。
  その後OpenID コミュニティはこの試案に、従前のCXとABの議論を反映し、現在の OpenID Connect仕様の策定を進めている。

(1) 特徴

　OpenID Connect 仕様の主な特徴を以下に示す。

• OAuth 2.0仕様に準拠した上で、ID情報の要求・提供の機能を定義している。これにより、実装の容易性や様々な種類のデバイスへの対応など、OAuth 2.0仕様の特長を引き継ぎながら、後述する「シンプルな認証結果と属性情報の取得」のユースケースであれば、一般的なOAuth 2.0認可+ APIアクセスとほぼ同様のフローによって実現することができる。さらにOAuth 2.0のアクセス権限提供のしくみはそのまま利用可能であるため、ID連携とサービス連携が単一のプロトコルによって処理することができるようになり、実装者の負担軽減にもつながることになる。


• メッセージ形式にJSON（JavaScript Object Notation）[9]を採用し、加えてJWT（JSON Web Token）[10]を活用することにより、公開鍵暗号方式によるメッセージへの署名と暗号化もサポートする。これにより、送信されたメッセージの真正性の保証や、意図しないアサーション露見の防止が可能となる。


• 仕様のモジュール化により、要件に応じてどのように仕様を利用するか（プロファイリング）が容易になっている。これにより、例えば仕様の最小範囲を利用しクライアント側の対応を容易にする、あるいはセッション管理仕様を加えてサービス間でのシングル・サインオンを実現する、そして否認防止や暗号化などを規定し高い保証レベルを実現する、といったように、さまざまな用途への適用が可能となる。

(2) 仕様の構成

　OpenID Connect仕様は、以下より構成されるプロトコル・スイートである（図3）。なお同仕様の記述に従い、OpenID 2.0における RP を、以降は「クライアント」と表記する。

図3：OpenID Connectプロトコル・スイート
（https://openid.net/connect/の図「OpenID Connect Protocol Suite」を元に作成）

• OpenID Connect Messages 1.0 [11]

  エンドポイントおよび関連するメッセージ形式の仕様。



• OpenID Connect Standard 1.0 [12]

  OpenID Connect Messages 1.0のHTTPプロトコルへのバインディング仕様。



• OpenID Connect Basic Client 1.0 [13]

  クライアントとなるWebサイト向けの、理解しやすく実装しやすい、OpenID Connect Standard 1.0 のプロファイル仕様。



• OpenID Connect Dynamic Client Registration 1.0 [14]

  クライアントが、動的に自身の情報をOpenIDプロバイダに登録し、OpenIDプロバイダから必要なクレデンシャルを取得する方法を定義する仕様（オプション）。



• OpenID Connect Discovery 1.0 [15]

  クライアントが、ユーザのOpenIDプロバイダならびにそのOpenIDプロバイダのエンドポイントを発見する方法を定義する仕様（オプション）OpenIDプロバイダが OpenID Connect Discovery 1.0と本仕様に対応することにより、クライアントはエンドユーザの指定した識別子をもとに未知のOpenIDプロバイダを発見し、信頼関係を確立するという、現行のOpenID 2.0と同様の機能を実現できるようになる。



• OpenID Connect Session Management 1.0 [16]

  OpenIDプロバイダ／クライアント間でのユーザ・セッションのライフサイクル管理・同期の方法を定義する仕様（オプション）。



• OAuth 2.0 Multiple Response Type Encoding Practices [17]

  OAuth 2.0 仕様の response_typeパラメータに指定するOpenID Connect特有の値の定義と、その値の扱い方に関するガイダンス。

(3) OpenID Connectのフロー

　OpenID Connectのフローを以下に示す（図4）。基本的にはOAuth 2.0の認可フローに従っており、認可リクエストのパラメータ（scopeや、response_typeなど）に指定する値や、独自のトークン（IDトークン）の追加、トークンを用いたID情報の取得方法などが新たに拡張されている。

図4：OpenID Connectのフロー概要

　OpenID Connectの適用例を以下に挙げる。

(1) シンプルな認証結果と属性情報の取得

　OpenID Connectフローを実行した結果、クライアントは認可サーバから、OpenID Connectが規定する「ID トークン」と、OAuth 2.0の「アクセス・トークン」という、2種類のトークンを得る。クライアントはこれらのトークンをもとに、認証結果と属性情報を取得する。
　まず認証結果（例： ユーザ識別子（user_id）、認証日時（auth_time）など）は、IDトークンに含まれている。IDトークン（id_token）はJWT形式の文字列であり、JWS（JSON Web Signature）によって署名されている。クライアントは自らIDトークンのデコードと署名の検証をするか、もしくは同等の処理を行う外部の「Check IDエンドポイント」にIDトークンを送信し、JSON 形式の認証結果を抽出する。
　次に属性情報は、アクセス・トークンを用いてUserInfoエンドポイントにアクセスし取得する。どの属性情報を要求するかは、クライアントがフロー開始時の認可リクエストのscopeパラメータに、取得したい「クレーム（ここでは、エンドユーザのID情報の種類）」を記述することで指定する。仕様に規定されているクレームはprofile（一般的なユーザ属性）、email（メールアドレス）、address（住所）、phone（電話番号）の4種類であり、これらは複数同時に記述可能である。UserInfoエンドポイントからのレスポンスはJSON形式となる。

(2) 仕様に規定されている以外の属性の取得

　クライアントが規定以外の独自クレームを取得したい場合には、認可リクエストのscopeにそのクレーム名を指定する。さらに要求する属性を指定したい場合には、「リクエスト・オブジェクト」を用いる。
　リクエスト・オブジェクトとは認可サーバへのリクエスト・パラメータをJWT形式にエンコードしたものであり、認可リクエストのパラメータに同オブジェクトそのもの、もしくは同オブジェクトの場所を指定する。

(3) 認証コンテキストの指定

　OpenID Connectでは、クライアントと認可サーバ間での認証コンテキスト(Authentication Context Class Reference）の要求・提供方法を規定している。クライアントは認可サーバへの認可リクエストに際し、リクエスト・オブジェクトに、要求する認証コンテキストを記述する。同様に認可サーバは、エンドユーザの認証結果であるIDトークンに、認証コンテキストを含めて返却する。
　認証コンテキストとして記述可能な値は以下の3種類である。

• "0", "1", "2", "3", "4"
  1 から 4 は、ITU-T X.1254 | ISO/IEC 29115 Entity Authentication Assurance [18] の規定する保証レベル。0は、エンドユーザの認証が同保証レベル1の要件に適合しないことを示す場合に指定。
• 絶対（absolute）URI
• An IANA registry for Level of Assurance (LoA) Profiles [19]に登録されている名称

(4) UserInfoエンドポイントの外部にあるクレームの取得

　OpenIDプロバイダ は、自身以外の外部の「クレーム・プロバイダ」が表明するクレームを、クライアントに提供することができる。提供方法として、外部クレームの実体を含む「集約（aggregated）クレーム」と、外部クレームへの参照（実体を取得するための情報）を含む「分散（distributed）クレーム」のふたつが規定されている。

　OpenID Connect 仕様群のうちOpenID Connect Session Management 1.0を除く仕様が、OIDF会員の投票より、2012年2月16日に実装者ドラフトとして承認された[20]。今後、仕様の最終レビュー、投票を行い、仕様確定に至る見込みである。
　実サービスへの適用状況としては、GoogleやSalesforce.com、VZnetなどが、検討段階の仕様の一部を自社サービスに採り入れている[21][22][23]また2011年12月に開催されたOpenID Summit Tokyoにおいて、楽天、Yahoo! JAPAN、日本経済新聞社などが、自社サービスにOpenID Connectを採用する予定であると表明した[24]。

　OpenID ConnectはOpenID 2.0をOAuth 2.0ベースに作り直すというだけのものではなく、既存のID連携仕様である SAML（Security Assertion Markup Language）[25]やWS-Federation [26]の実世界での適用パターンや、さらには事業者独自のOAuthベースのアイデンティティAPIなどを分析し、仕様化したものとなっている。
　SAMLやWS-Federationの仕様改版の動きがないこと、またOAuth 2.0ベースのアイデンティティAPIとして他に標準となりうる仕様が存在しないことから、今後エンタープライズ分野／コンシューマー向けサービス分野の双方において、OpenID Connect採用の検討が進むものと思われる。

以上