OpenAMのOpenID Connectへの対応：OSSによるアイデンティティ管理（4）（2/3 ページ）
OpenAMは、SAMLをはじめとする多くのフェデレーションプロトコルに対応しています。先日ローンチされたOpenID Connectにもいち早く対応しました。
さまざまな問題点を考慮して生まれた「OpenID Connect」
このような状況下で、各プロトコルの問題点を考慮した新しい仕様の策定が2009年ごろから始まりました。それがこれから説明する「OpenID Connect」です。
OpenID Connectとは
OpenID Connect 1.0は、認可を目的としたプロトコルであるOAuth 2.0をベースに、認証やセッション管理なども実現できるように拡張したプロトコルです。
OAuth 2.0＋（認証、セッション管理など）＝OpenID Connect 1.0
OpenID Connectは、「making simple things simple and complicated things possible（簡単なことは簡単に、複雑なことも可能に）」を設計目標としており、開発者が実装すべき部分はできる限り少なくしながらも、さまざまなタイプのアプリケーションと連携できるような考慮がされています。
一般的なWebアプリケーションだけでなく、ブラウザーベースのJavaScriptやネイティブモバイルアプリケーションとも連携し、SSOができます。また、SAMLがSOAP/XMLを使用した複雑なプロトコルであるのに対して、OpenID ConnectはREST/JSONを使用した開発者にやさしいプロトコルとなっています。
OpenID Connect のアクターには次の3種類があります。
・エンドユーザー：
アプリケーションを利用するユーザーです。
・OpenID Provider（OP）：
エンドユーザーを認証し、そのユーザーの情報を提供するサーバーです。OpenID Connectをサポートする OAuth 2.0認可サーバーといい換えることもできます（以下、「OP」と略します）。
・Relying Party（RP）：
OPにエンドユーザーの認証を委譲するアプリケーションです。Webアプリケーションだけでなく、モバイルアプリケーションなども含まれます。OpenID Connectを利用するOAuth 2.0クライアントと言い換えることもできます（以下、「RP」と略します）。
RPがWebアプリケーションの場合の、OpenID Connectの典型的なフローは、以下のようになります。
まず、エンドユーザーはWebアプリケーションにアクセスします（1）。Webアプリケーションは「○○（OP）でログイン」というようなボタンのある画面を表示します。エンドユーザーがこのボタンをクリックすることで、OpenID Connectで規定されたフローが始まります。WebアプリケーションはエンドユーザーをOPの認可エンドポイント（注2）へとリダイレクトします（認証要求：2）。
注2：エンドポイント（Endpoint）：サービスを提供するURIを意味します。OpenID ConnectのOPは、認証・認可を実行するための認可エンドポイントや、エンドユーザーの情報を取得するためのユーザー情報エンドポイントなどを公開します。
OPはログイン画面を表示し（3）、それに対してエンドユーザーはログインを試行します（4）。このとき、どのような方式でログインさせるか、どのような条件で認証成功とするかはOpenID Connectの仕様では規定されていないので、例えば、OPはエンドユーザーに生体認証を求めることも、Yubikey認証を求めることもできます。認証が成功したら、OPは認可画面を表示し、Webアプリケーションがユーザー情報へアクセスすることへの許可をエンドユーザーに求めます（5）。それに対してエンドユーザーは許可または拒否します（6）。許可を得ると、OPはエンドユーザーをもとのWebアプリケーションへとリダイレクトします（認証応答：7）。認証応答には認可コードが含まれており、これを使ってトークンエンドポイントにアクセスし、アクセストークンとIDトークン（注3）を取得します（8）。必要であれば、アクセストークンを使用して、ユーザー情報エンドポイントからエンドユーザーの属性情報を取得します（9）。
注3：アクセストークンとIDトークン：アクセストークンと同時にIDトークンを受け取ることが、OAuth 2.0と大きく異なる点です。IDトークンには、エンドユーザーごとに一意な値が含まれており、これによりエンドユーザーが認証済みであるかどうかを判定できるようになっています。OpenID Connectでは、性能面やセキュリティを考慮した結果として、2つのトークンを使い分けるようになっています。
一般的にRPがWebアプリケーションの場合は、図2で説明した「認可コードフロー」というフローに従います。RPがネイティブモバイルアプリケーションの場合は、「インプリシットフロー」というフローに従います。ただし、厳密にはアプリケーションがパスワードを秘密にできるかどうか、またOPとRPが直接通信できるかどうかといった観点でどちらを選択するか決定します。
両者のフローには若干の違いがありますが、基本的な部分は同じです。いずれのフローも、OpenID Connect Core 1.0で規定されていますので、詳細に関して知りたい方はそちらを確認してください。
また、このフローでは省略しましたが、OPはエンドユーザーのセッションの有無の確認や、シングルログアウトを行うためのエンドポイントも公開します。これらの仕様はOpenID Connect Session Management 1.0にまとめられています（2014年5月の時点では仕様策定中です）。
【関連記事】
デジタル・アイデンティティ技術最新動向（4）：「OpenID Connect」を理解する
http://www.atmarkit.co.jp/ait/articles/1209/27/news138.html
Copyright © ITmedia, Inc. All Rights Reserved.