OpenIDファウンデーション・ジャパン

OpenID Connect, ふたつのトークンの物語

「なぜ OpenID Connect にはトークンが二種類あるの?」という質問を、たびたびもらいます。そこにはいくつかの設計上の要件があり、わたしたちは仕様策定のなかで議論してきました。

1 - RP (リライング・パーティ) からの要件は、ログイン後のユーザー・インタフェースの簡便なカスタマイゼーションです。

• そこでは、ユーザーへのレスポンスを一秒以下で行うことが求められました。つまり、ユーザー ID を取得するための、IdP へのさらなるラウンドトリップ (問い合わせ) は許されなかったのです。パスワードによる認証に加えて数秒の遅延が発生するようでは、実際に使うことはできないと、多くの RP が考えています。

• Facebook は署名つきリクエスト (signed request) を用いて、ユーザー ID をレスポンスに格納して返却しています。クライアント (RP) は署名を検証し、ユーザー・インタフェースを即座に表示することが可能です。

2 - Salesforce や他の IdP には、既にユーザー情報 (user-info) エンドポイントとその他保護リソースが存在しており、これらに対するアクセスをスコープとしてアクセス・トークンに追加したいと考えています。

• ここでの要件は、異なるアクセス・トークンの形式が強制されることで、既存の実装を変更しなくてはならなくなるようなことは避けたい、ということでした。

3 - T-Mobile 他では、署名つきトークン (signed token) にスコープを含め、エンドポイントに渡しています。

• 彼らの要件は、トークンに必要な情報だけを格納し、保護リソースに渡す、ということです。リソースは第三者に管理されていることもありうるため、ユーザー ID を送信することは、プライバシー情報の漏洩につながりかねません。

4 - Google 他の要件は、Connect が複数種類のクライアント、とくにブラウザ内の Ajax をサポートすることでした。

5 - リソースごとに毎回ユーザーに認可を求めることはできない、ということには、全員が同意しました。

まず、要件 1 を満たすには、RP に対して user_id の入った署名つきトークンを送る必要があり、そして、そのトークンは認可サーバー (Authorization Server) からのレスポンスに含まれていなくてはないことがわかります。
よって、id_token が必要なのです。Facebook には、署名つきリクエスト (signed request) という独自形式のしくみがあります。わたしたちコミュニティは、JWT という、より汎用的でオープンな標準を考案しました。これは署名つきリクエストと似ており、加えて暗号化もサポートします。

OAuth 2.0 の手法のひとつとして、異なる保護リソースに対して複数のトークンを生成することを、ダウンスコーピング (down-scoping) といいます。各リソースごとに、認可リクエストにおいて、複数のスコープを要求するのです。
認可サーバーは、すべてのスコープに対して有効なリフレッシュ・トークン (Refresh Token) を提供します。そしてこのトークンをトークン・エンドポイントに提示し、全てではなく一部のスコープに対する新しいトークンを要求することになります。

ダウンスコーピングにはいくつか問題がありますが、最も大きなものは、これが code フローでしか使えないため、要件 1 と 4 を満たせないということです。

これに対し、いくつかの選択肢があります:

1. id_token をアクセス・トークンとして用いる
2. アクセス・トークンを id_token に含める
3. ふたつのトークンを返却する

id_token をアクセス・トークンとして用いる方法では、要件 2 を満たせませんし、長い期間有効となるアクセス・トークンがセッション・クッキーとなってブラウザーに保管されるかもしれないという、新たなセキュリティ上の懸念が生じます。

アクセス・トークンを id_token に含めるやりかたは、Facebook Connect が選択した方法と同じです。要件 1 と 2 に対してはうまくいきますが、やはりいくつか問題があります。それは、id_token をセッション管理に用いたいと RP が考えた場合です。そのためにはセッション・クッキーに長期間有効なアクセス・トークンを埋め込むことになりますが、id_token のサイズがかなり大きくなってしまいます。要件 3 は満たせたとしても、アクセス・トークンにはその他のユーザー情報を載せることができません。

認可サーバーからのレスポンスとしてふたつのトークンを返却することで、すべての要件を満たすことができます。

•  認証されたユーザーの情報が、アクセス・トークンから切り離される
•  id_token のサイズをかなり小さくすることができる
•  id-token をセッション・クッキーとして用いる場合にも、アクセス・トークンは漏洩しない
•  アクセス・トークンを署名つきトークンにすることができ、さらに必要な情報だけを含めることができる
•  code フローを用いる場合に、引き続きダウンスコーピングを行うことができる
•  id_token をユーザー・セッションの生存期間と結びつけることが可能であり、一方、アクセス・トークンの生存期間とは切り離すことができる
•  ふたつのトークンの受け手 (audience) を分けることができるため、それぞれの受け手に合わせた暗号化を行うことが容易となる

一般的に、 OAuth 2.0 の implicitフローを用いる RP では、あらかじめ登録されたリダイレクト・エンドポイントに認可サーバーから返却されたレスポンスの中から、id_token を取り出します。次に署名を検証し、そこに含まれる user_id を用いて Web ページをカスタマイズする一方、もし必要であればさらに、OAuth 2.0 によって認証されたリクエストを user_info エンドポイントに対して行います。これにより、再度アクセスしてきたユーザーのログイン処理を、RP が許容することのできる時間内に行うことができるようになります。新規ユーザーの場合であっても、比較して少し時間はかかりますが、プロファイル情報を取得することが可能です。

OpenID Connect に関連して、新規の OAuth 2.0 response_type が複数登録されています。これによって、クライアントからの様々な要求を満たすためのトークンの返却方法に、いくつかの選択肢が生まれることになります。

id_token を活用した、セッション管理およびシングル・ログアウト拡張についても、現在検討中です。

トークンを分離することについては、現在 OASIS の SAML WG がセッション・トークン・プロファイルの公開レビューを行っており、おそらくそこで部分的にですが検証が行われることになるでしょう。

トークンをひとつにすることは一見魅力的ですが、たくさんの理由から、わたしたちのユースケースの多くに対してはうまくいきません。わたしも単一の JWT トークンを主張していた一人ですが、結局負けました。

近いうちに、OpenID Connect  の response_typeについて投稿したいと思います。

John B.

(出典: thread-safe.com)

NETWORKWORLD の NSTIC に関する記事

NETWORKWORLD に、米国 NSTIC (National Strategy for Trusted Identities in Cyberspace) に関する二つのコラムが掲載されていたので、紹介しておきます。

Can the Obama Administration fix your identity management problems?  （オバマ政権はID管理に関する問題を解決できるか？）

• オバマ大統領は、NSTIC のドキュメントの冒頭で、ID窃盗やプライバシー侵害を防ぐたために、セキュアじゃないパスワードをなんとかし、オンライン取引をもっと信頼性の高いものにしたいと謳っている。また、これは米国政府の負債削減という意図も。
• NSTIC のワークショップでは、民間のベンダー団体の Open Identity Exchange (OIX) や、Kantara Initiative が参加しており、パイロットプロジェクトが行われる予定。OIX は、OpenID Foundation の姉妹企業。
• OIX のメンバーである Verizon 曰く。NSTIC の目的は、オンラインのビジネスが誰にとっても簡単になること。例えば、Best Buy のサイトで買い物するときに、Verison の ID でログインし、さらに必要であれば、ワンタイムパスワードを携帯電話に発行し、それでアクセスできるようになる。
• Verizon は長年政府に対して PKI の証明書を発行する仕事をしてきたが、今回 Identity Ecosystem を構成するメンバーの一社と、その立場を変えた。

NSTIC director: ‘We’re trying to get rid of passwords’  （NSTIC担当高官 「我々はパスワードを無くすことに注力している」）

• NSTIC の担当官である、Jeremy Grant 曰く。パスワードだけに頼らない高度な認証サービスを提供している民間事業者と作業している。目下、彼らと標準ガイドラインに関して合意を取ることに注力中。
• 17.5百万ドル（約14億円）の予算を今年度 NSTIC のパイロット・プロジェクトとして計上。
• Identity Ecosystem では、発行された ID を監査するが、その基準や仕様については、NIST 自身が書かない。NIST は民間企業がコンセンサスを取れるような標準づくりを支援する立場に徹する。これは、大変なチャレンジだけども。
• NSTIC には政府による中央集権的データベースは存在しない。政府は、NSTIC に認定されたサービスを採用する。但し、そのための監査はやる。
• パスワードというものは脆弱なため、政府は業務をオンライン化できていない。
• OIX の会長である Don Thibeau 曰く。パスワードはセキュアではない。Google をはじめとした OIX のメンバーは、政府の NSTIC プログラムに参加している。
• OIX は OpenID と OAuth の仕様をベースに、インターネット・スケールのアイデンティティ標準を実現しようとしている。
• OIX のメンバーで、NSTIC のパイロットの他に、民間だけでのパイロットも計画。 (Google, AOL, Hotmail 間で)
• NSTIC は新しい考えにもとづいたセキュリティ設計に挑戦しようとしている。

Follow The (OpenID) Money

（このエントリは、US OpenID Foundation の2011/8/5付エントリを翻訳したものです。）

Cloud Identity Conference 期間中で開催された OpenID Summit (PingIdentity 社主催)や、Gartner の Catalyst カンファレンス(Identity Management で最も高名なイベントの一つ) で最もホットな話題は、「エンタープライズのコンシューマーサービス化」でした。OpenID は、技術面の牽引役としてこの話題の中心にあり、エンタープライズ及びコンシューマーの両方の利用ケースにおいてどのような価値を果たすのか議論されました。

ついさっきまでインターネットのほんの片隅にいたのに、今メインストリームへ適用されようとしている OpenID の進化は、インターネット・アイデンティティの世界に革新をもたらしたと、ひょっとすると後に理解されるかもしれません。Salesforce.com の Chuck Mortimore 氏の「Does OpenID work for the Enterprise?（OpenID は企業向けで使えるか？）」というお題のプレゼンテーションを見ると、OpenID のユーザ中心的な発想が、事業者中心的なアーキテクチャーをどのように変化させるか、最前線にいるプレーヤーの大胆な考察が伺えます。

OpenID が流行るか流行らないかを判断するには、”follow the money” いわゆる「お金の匂い」がするかどうか嗅いでおくこと、つまりは、リーダー的企業の動きを追っかけっていればいいでしょう。OAuth 2.0 と同じく、OpenID Connect は、数ある技術標準の中でも、Google と Microsoft、Facebook の三社が好んで技術的関与をしているという点で、類を見ない標準です。

これらの企業や、リライング・パーティがどうしていくのかは、誰も予想出来ないけども、彼らがどこに投資しているのかについては見ておくことができます。関連するカンファレンスやパイロットで、JanRain や PingIdentity のような業界のリーダー的企業が、OpenID プロトコルに対して、数年掛けて数億円の投資を行っているわけです。

このような投資の動きを見てると、今日の Web におけるソーシャルへのログインやシングルサインオン以上の価値がありそうだと判断できます。投資アナリスト達は、世界的に Identity Management ソリューションに大きな需要があると言っていて、Ping Identity や Janrain のような会社は、ファンドからの大規模の投資を受け、このビジネス機会をものにしようとしています。

もちろん不安要素もあるわけで、それはChuck Mortimore 氏が言うような新しいマーケット環境に適応するために、OpenID が過去1、2年ずっと静かだったという点です。だけども、標準というものをつくることは、そんなに簡単ではなく、時間とお金がかかります。業界のリーダー的企業によって率いられるボランタリーのコミュニティは、OpenID のような基本技術を再設計するには、いろいろと配慮する必要があるわけです。

一方で、Symantec や PayPal、Google などの OpenID ファウンデーションのメンバーは、OpenID Summit や様々なイベントを共催し、OpenID の進化について議論し、さまざまな分野でどう適用していくか計画を立てています。OpenID は、将来の確固たる技術的な基盤として、シリコンバレーのある意味寵児になりつつあります。

OpenID Foundation と Google が携わってきた、Account Chooser の仕組みを見てもらえればと思います。これは、分散型の相互運用可能なアイデンティティ・ソリューションの考え方を踏襲しながら、OpenID 技術をマス向けに分かりやすく拡張可能にしたものです。

OpenID が再び流行るかどうかを見極めるためには、どうしたらいいでしょうか。9月12日と13日にカリフォルニアのマウンテンビューの Microsoft のオフィスで実施される「OpenID Summit」にて、OpenIDファウンデーションは、技術的インターロップとテストのためのワークショップを開催します。OpenID Connect に興味を持っている、技術者・開発者向けになります。

ここでは、Webサイトの運営をしている企業が、パスワードを自社で管理するべきでなく、IDプロバイダーとの連携をとるべきである理由について、いろいろと学べるセッションを用意しています。OpenIDの進化が、上昇基調にあるのかないのか是非目で見て確かめて頂ければと思います。乞うご期待！

「信頼フレームワーク最新動向」が開催されました。

7/28に、「信頼フレームワーク最新動向」 ～Open Government, Open Economy, Open Identity～ が実施されました。

■ プレゼンテーション：
「トラストフレームワークの国際動向」
山中進吾（OpenIDファウンデーション・ジャパン）

「US政府のID戦略に関するワークショップ参加報告」
折田明子氏（慶應義塾大学）

■ パネル・ディスカッション：
杉浦宣彦氏（中央大学ビジネススクール 教授）
折田明子氏（慶應義塾大学SFC 特任講師）
下道高志氏（カンターラ・イニシアチブ ジャパン セクレタリー）
高橋伸和氏（日本ベリサイン フェロー）
山中進吾（OpenIDファウンデーション・ジャパン）  

米国のID戦略を中心に、トラストフレームワークの利用者にとってのメリットや新しいガバナンスモデル、過去に存在した仕組みとの比較、ソーシャルネットワークのIDとの関係性など、幅広い内容をカバーしました。

当日の模様はこちら。

「トラストフレームワーク最新動向」 山中 進吾
110728 Trust Framework - Shingo Yamanaka

「US政府のID戦略に関するワークショップ NSTIC Privacy Workshop 参加報告」 折田 明子氏
110728 Trust Framework - Akiko Orita

「Trust に対する取り組みの歴史」 下道 高志氏
110728 Trust Framework - Takashi Shitamichi

「信頼フレームワーク最新動向」高橋 伸和氏
110728 Trust Framework - Hawk Takahashi

Identity Conference #9 に参加してきました。

7/8 に開催された Identity Conference #9 @ mixi本社 にて、@ritou さんより OpenID Connect の最新仕様の紹介がされました。

The Latest Specs of OpenID Connect at #idcon 9

View more presentations from ritou

Ustream の録画はこちら。（OpenID Connect の話は、01:03:40くらいから始まります。）

発表者のプレゼンテーション資料（一部）はこちら。

(1)「OAuth support on mixi Platform」@asyoulike007

(2)「OpenTransactって何？」@nov

(3)「Identity over the Browser (仮)」@bkihara

(4)「OpenID Connect最新仕様（仮）」@ritou （上の資料と同じ）

(5)「SalesforceのID関連について」@mitsuhiro

(6)「番号制度と情報連携基盤について」@gjmtj

加えて、@mad_p さんによるレポート（発表内容の要約）はこちら。

• idcon9レポート - mad-pの日記