「OpenID Connect」を理解する：デジタル・アイデンティティ技術最新動向（4）（2/2 ページ）
いまWebの世界では、さまざまなWebサービスが提供するプラットフォームと、サー ドパーティが提供するアプリケーションがAPIを中心に結び付き、一種の「APIエコノミー」を形成しています。この連載では、そこで重要な役割を果たす「デジタル・アイデンティティ」について理解を深めていきます。
OpenID Connectを構成する仕様一覧
OpenID Connectの最もシンプルな実装として、OAuth 2.0に「ユーザー認証結果と統一的なプロフィール情報の受け渡し」の機能のみを追加した仕様があります。OAuth 2.0のアクセス権限付与フロータイプごとにリクエスト／レスポンスの拡張方法を定義しています。
- Basic Client Profile：OAuth 2.0 Authorization Code Grantを拡張
http://openid.net/specs/openid-connect-basic-1_0.html
- Implicit Client Profile：OAuth 2.0 Implicit Grantを拡張
http://openid.net/specs/openid-connect-implicit-1_0.html
これはちょうど、GoogleやFacebookなどの開発者ドキュメントにある「Server-Side Flow」「Client-side Flow」のような切り分けです。初めてOpenID ConnectのRPを開発する方や、既存のOAuth 2.0のサーバを最小限の改修でOpenID Connectに対応させたい方は、こちらから読んでいただければと思います。
ただし、この2つの仕様には、設計思想にある「難しいことも可能に」の内容が含まれていません。リクエスト内の細かいクレーム指定や認証コンテキストの指定については、次の2つの仕様で定義されています。
- Standard：OAuth 2.0のどのパラメータを拡張するか
http://openid.net/specs/openid-connect-standard-1_0.html
- Messages：Standardで指定されるパラメータの詳細
http://openid.net/specs/openid-connect-messages-1_0.html
Messagesには、「OpenID Connectのこの機能を使いたいときは、（利用するプロトコルに）こんなメッセージを乗せてください」という事柄が定義されており、Standardは、Messagesの内容をHTTPプロトコル（を用いたOAuth 2.0）に落とし込んだ「HTTPバインディング仕様」となります。より複雑なクレーム要求や認証コンテキストの指定についてもこれらの仕様に含まれます。OpenID Connectのコアな機能を完全に理解するためには、これら2つの仕様を読む必要があります。
そして、上述のコアな機能以外にいくつかの関連仕様があります。
- Discovery：メールアドレスやURLからユーザーが利用しているOPを特定する方法
http://openid.net/specs/openid-connect-discovery-1_0.html
- Dynamic Client Registration：動的なRP登録を行う方法
http://openid.net/specs/openid-connect-registration-1_0.html
- Session Management：OP上でユーザーがログアウトしたときにRP側から検知する方法など、セッション管理の方法
http://openid.net/specs/openid-connect-session-1_0.html
OpenIDの特徴である「ユーザーがいつも利用しているOPの指定」を許容するかどうか、Webアプリケーション同士で連携した後のセッション同期機能を提供するかどうかなど、OPは自サービスのポリシーと突き合わせ、実装する機能を決めることになります（注3）。
注3：J本稿掲載後に仕様の統合や分離が行われる可能性もあります。最新の仕様を確認したい方はOpenID Foundationのサイトを確認してください。
OpenID Connect Work Group
モバイルアプリを例にしたフロー紹介
ここでは、OpenID Connectのフローを紹介します。すべての機能を紹介することは難しいため、以下のような状況を想定して説明します。
- RPはスマートフォン上で動作するモバイルアプリケーションである
- RPは新規アカウント登録／ログインにOpenID Connectを利用する
- 利用できるOPを固定せず、ユーザーがいつも利用しているOPに対応する
モバイルアプリケーションの場合、OAuth 2.0ではImplicit Grantを利用します。
Step 0：Discovery & Dynamic Client Registration（OP探索と動的なRP登録）
OpenIDやOAuthの処理の始まりと言えば、ユーザーがあらかじめ用意されているOPのアイコン画像や「○○のIDでログイン」というリンクを選択するのが一般的です。
OpenID 2.0では、ユーザーからOP特定のためのヒントを受けとることで、任意のOPのアカウントを利用できます。RPがOPを特定し、OP識別子や各エンドポイントの情報を取得するまでの一連の手続きを「Discovery」と呼びます。
OpenID Connectでは次の2種類の値をOP特定のためのヒントとして利用できます。
- メールアドレス（例：ritou@openidconnect.info）
- OP URL（例：https://openidconnect.info）
RPがそのOPをまだ一度も利用していなかった場合、何らかの方法でRP情報を登録して、client_idなどを受け取る必要があります。
OpenID ConnectではRP登録用エンドポイントにPOSTリクエストを送ることで動的なRP登録ができます。この登録処理を「Dynamic Client Registration」と呼びます。
今回はモバイルアプリケーションであるため、OPからのレスポンスにはRP識別のための“cient_id”が付与されます。DiscoveryとDynamic Client Registrationにより、RPがOPに認証情報を要求する準備ができました。
Step 1：Authorization Request（認可リクエスト）
RPはOPに認可リクエストを送ります。OAuth 2.0の認可リクエストを次のように拡張します。
- scopeに‘openid’を含むことでOpenID Connectの認可リクエストであることを明示
- scopeに‘profile email’など、必要なクレームに対応した値を含む
- response_typeを‘id_token token’とし、認証イベントの状態を表すIDトークンを要求
リクエストを受け取ったOPは、RPが求めているクレームへのアクセス権限付与についての同意をユーザーに求めます。
Step 2：Authorization Response（認可応答）
ユーザーが同意した場合、OPは認可応答をRPに返します。Implicit Grant TypeではURLのフラグメント部にアクセストークンなどが含まれます。認可リクエストのrequest_typeパラメータにid_tokenを指定したため、IDトークンの文字列もフラグメント部に含まれます。
第2回記事の「OAuth 2.0をセキュアに使うために知っておくべきこと」でNovさんが説明していたように、ID連携のためにImplicit Grantを利用する場合、受け取ったアクセストークンの発行元、発行先などを検証する必要があります。OpenID Connectでは、アクセストークンと一緒に渡されたIDトークンを検証することで、この確認ができます。
Step 3：ID Token Verification（IDトークンの検証）
Step 2で受け取ったIDトークンには、設計思想の項で説明した情報に加え、認可応答として同時に渡されるアクセストークンのハッシュ値が含まれます。このIDトークンの署名を検証し、アクセストークンのハッシュ値を比較することにより、IDトークンとアクセストークンが正しく発行されたことを確認できます。
もし、悪意のあるユーザーやアプリ開発者がアクセストークンの値を置き換えてアクセスしたとしても、ハッシュ値がマッチしないことからそれを検知できます。
OAuth 2.0では一度プロフィールAPIにアクセスしてユーザー識別子を取得し、既存／新規アカウントの判定などを行いますが、OpenID ConnectではIDトークンの中に識別子が含まれる値を利用できます。
Step 4：Accessing to UserInfo Endpoint（UserInfoエンドポイントへのアクセス）
RPは、認可要求のscopeパラメータで指定したクレームを取得するために、UserInfoエンドポイントにアクセスします。UserInfoエンドポイントはOAuth 2.0のProtected Resourceであり、他のAPIと同様にリクエストにはアクセストークンを用います。レスポンスに含まれる標準的なクレームの名前などはすべて仕様で定義されているため、RP開発者はOPごとの違いを気にしながら実装する必要はありません。
ここまでで認証結果とクレームの取得が完了しました。シンプルな実装であればユーザーから見てOAuth 2.0とほぼ同じUXで安全なID連携が実装できるのです。OAuth 2.0を実装されているサービスの担当者には、OpenID Connectへの拡張を検討することを強くお勧めします。
OpenID Connectの現状と今後の予定
2012年9月現在、OpenID Connectは「Feedback on Implementer's Drafts」の段階にあります。ここから「Final Review Period」「Final Voting」を経て「OIDF Standard」としての策定が完了します。
OpenID Connectの仕様策定WGでは、個人開発者や企業による試験的な実装が行われており、定期的に、相互接続性を検証する「Interop」が行われています。Interopでは最新の仕様に合わせたOP／RP向けのテスト一覧が用意されており、各自の実装状況を把握するとともに、相互運用性の確認ができるようになっています。
このInteropには現在、12個のOPと7個のRPが参加しています。私とNovさんもOP／RPを実装して参加しています。細かい仕様変更に柔軟に対応していくことはそれなりに手間がかかりますが、いざ実装してみると、漠然と仕様を眺めただけでは気づかなかった疑問点が出てくることがあります。
複数の開発者が実装を行うことで、メーリングリストで議論された内容がドラフト仕様に反映され、開発者が実装して気づいた点をフィードバック、それを受けてさらに議論が起こる……という効率的なサイクルが回っています。本稿にてOpenID Connectの仕様に興味を持った企業／個人の開発者の方にも、ぜひInteropに参加し、仕様策定に協力いただければと思います。
OpenID Connectはその拡張性の高さから、コンシューマー分野に留まらず、エンタープライズやアカデミックといった分野でも注目され始めています。2011年末に開催された「OpenID Summit TOKYO」でも、いくつかの国内企業がOpenID Connectのサポートを明言しており、この勢いからすると仕様策定時には大きな話題となることは間違いないでしょう。
もし周りに、ID連携の仕組みを独自に設計して開発しようとする案件があれば、一歩立ち止まって、「それ、OpenID Connectでできるんじゃないの？」と疑問を持っていただければと思います。
次回に向けて
さて、次回のテーマはUDIDでおなじみ「デバイス識別子」です。
携帯電話と言えばフィーチャーフォンだった数年前から、ユーザー認証と個体識別には深い関わりがあり、いわゆる「かんたんログイン」の裏に潜むセキュリティ／プライバシーの問題が語られてきました。
次回は、アプリ開発がスマートフォンにシフトした今だからこそ知っておきたいデバイス識別子の扱いについて、Apple社の動向などを踏まえて説明する予定です。モバイルアプリ開発者の方にとっては必見の内容になるでしょう。お楽しみに。
著者プロフィール
▼Ryo Ito（ritou）
OpenID Foundation Japan Evangelist。OpenID Connectのコントリビュータとして仕様策定に関わっている。 業務ではアイデンティティ技術を用いたSNSサービスの強化を検討しており、個人ブログではOpenID／OAuthについて情報発信を行っている。
Copyright © ITmedia, Inc. All Rights Reserved.