JP7043480B2 - 情報処理システムと、その制御方法とプログラム - Google Patents

Description

本発明は、認可サーバーの認可エンドポイントを特定する情報処理システムと、その制御方法とプログラムに関する。

ＭＦＰなどのクライアントが有するアプリケーションが、同じくクライアントが有するトークンプロバイダーを介して認可サーバーから認可トークンを取得する形態がある。認可トークンとは、認証されたユーザーの認可操作により権限委譲されたクライアントが、リソースサーバーの公開するＡＰＩにアクセスすることを許可した事を示すトークンである。クライアントは認可トークンを用いることで、ＩＤ、パスワード情報、認可情報などのユーザー情報をリソースサーバー、または認可サーバーに受け渡すことなく、リソースサーバーが公開するＡＰＩをアクセスできる。例えばクライアントがＭＦＰであれば、取得した認可トークンを用いてＭＦＰは、リソースサーバーが提供するプリントサービスや帳票サービスなどのＷｅｂサービスを利用し、ＭＦＰはデータの表示、印刷を実行することができる。

認可トークンは、認可サーバーがＯＡｕｔｈ ２．０と呼ばれる標準プロトコルの認可フローＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔを実行することで発行される。具体的には、クライアントがリソースサーバーのＷｅｂサービスを利用することを、Ｗｅｂブラウザーを介してユーザーが認可することで、認可サーバーはトークン要求の送信元であるトークンプロバイダーに対して認可トークンを発行する。トークン要求は、トークンプロバイダーが認可トークンを取得するために、認可サーバーに送信されるリクエストである。

特許文献１には、クライアントが有するアプリケーションが、同じくクライアントが有するトークンプロバイダーを介して認可サーバーから認可トークンを取得するシステムが開示されている。

特開２０１７－１０７３９６

上記でも記載したユーザー情報は、ある特定の地域（以下、リージョン）の認可サーバーで管理されている。複数のユーザーに対応してユーザー情報が複数存在する場合、それらのユーザー情報が１つの認可サーバーで一括管理されているとは限らない。例えば、アプリケーションが複数のリージョンで配布されワールドワイドで使用されている場合、アプリケーションを使用するユーザーのユーザー情報は、そのユーザーがいるリージョンの認可サーバーで管理される。そしてユーザー情報の所在する認可サーバーが、認可トークンを発行する。ユーザー情報の所在に応じた認可サーバーが認可トークンを発行する理由は、個人情報保護や安全保障等の観点から別のリージョンへのユーザー情報の移動や共有に制限が設けられており、移動や共有が制限されたユーザー情報を用いて、ユーザーが認証される。その認証されたユーザーによる認可をきっかけに、認可トークンが発行される。

ユーザーによる認可は、クライアントによる認可リクエストが認可サーバーに送信された結果表示される認可確認画面（後述）を介して行われる。アプリケーションが複数のリージョンで利用されることを想定した場合、その認可リクエストの送信先である認可サーバーの選択肢が広がる。そのため、トークンプロバイダーは、認可リクエストの送信先であり、ユーザー情報の所在する認可サーバーを特定する必要がある。

認可サーバーを特定する方法として例えば、ユーザー操作によりリージョンを指定させる方法がある。しかしその方法では手動操作による煩雑さと、リージョンの選択をユーザー操作に委ねる点でセキュリティ上の問題が生じる。

本発明は、セキュリティを維持しつつ、ユーザー情報が存在する認可サーバーを適切に選択し、選択した認可サーバーが認可トークンを発行することを目的とする。

クライアントとウェブブラウザと複数の認可サーバーと、を含む情報処理システムであって、前記複数の認可サーバーは、前記クライアントがリソースサーバーにアクセスすることを、前記ウェブブラウザを介して許可するユーザーのユーザー情報を管理する第一の認可サーバーであって、前記複数の認可サーバーに含まれる第一の認可サーバーを特定する特定手段を有し、前記複数の認可サーバーに含まれる認可サーバーは、前記クライアントから認可リクエストを受信したことに応じて、前記特定手段によって前記第一の認可サーバーを特定し、特定された前記第一の認可サーバーに対し前記ユーザーを認証する認証リクエストをリダイレクトし、前記第一の認可サーバーは、リダイレクトされた前記認証リクエストを受信したことに応じて前記ユーザーを認証し、認証された前記ユーザーが前記アクセスを許可すると認可レスポンスとして認可トークンを前記クライアントに送信することを特徴とする。

本発明は、セキュリティを維持しつつ、ユーザー情報が存在する認可サーバーを適切に選択し、選択した認可サーバーが認可トークンを発行することができる。

情報処理システムのネットワーク構成を示す図。 各種デバイスのハードウェア構成を示す図。 情報処理システムを構成する各種デバイスのソフトウェア構成を示す図。 トークンプロバイダーが有する機能を示す図。 情報処理システムにおける認可フロー。 クライアント４００におけるトークン要求処理を示すフロー。 認可サーバー２０１におけるトークン応答処理を示すフロー。 ＪＷＴ形式の認可リクエスト（認可Ａｓｓｅｒｔｉｏｎ）のクレームの一例。 ｉｄ＿ｔｏｋｅｎのクレームの一例。 トークン要求（トークンＡｓｓｅｒｔｉｏｎ）のクレームの一例。 ユーザー移動先情報を含むトークン応答の一例。 認可確認画面の一例。 クライアント登録時の処理のフロー。

以下、本発明を実施するための最良の形態について図面を用いて説明する。尚、後述の認可サーバー２００と認可サーバー２０１のどちらでもよい場合は「認可サーバー２００、２０１」と記載し、リソースサーバー３００とリソースサーバー３０１のどちらでもよい場合も「リソースサーバー３００、３０１」と記載する。また、認可サーバー２０１が認可トークンを発行する場合は、認可サーバー２０１で発行された認可トークンを用いてリソースサーバー３０１の公開するＡＰＩがアクセスされるものとする。認可サーバー２００とリソースサーバー３００の関係についても同様である。

［実施例１］
図１を用いて、本発明の実施形態に係る情報処理システムについて説明する。情報処理システムは、図１に示すようなネットワーク構成で実現される。ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）１００はＷＷＷ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）システムによって構築されている。ＷＡＮ１００と各種デバイス２００～５００はＬＡＮ（ＬｏｃａｌＡｒｅａ Ｎｅｔｗｏｒｋ）１０１を介して接続されている。

認可サーバー２００、２０１はＯＡｕｔｈ ２．０を実現するためのサーバーであり、認証要求の受信、管理等の処理を行う。図１では、認可サーバー２００とリソースサーバー３００、認可サーバー２０１とリソースサーバー３０１がＬＡＮ１０１で接続されている形態を示しているが、ＷＡＮ１００を介して接続される構成も可能である。

認可サーバー２００、２０１はＬＡＮ１０１を介して不図示のデータベースサーバーと接続されている。認可サーバー２００、２０１が自身の機能を実現する際に用いるデータは、そのデータベースサーバーに格納されている形態でもよい。本実施例では認可サーバー２００とリソースサーバー３００、認可サーバー２０１とリソースサーバー３０１をそれぞれ別のサーバーであるものとして説明しているが、各種サーバーの物理的構成は問わない。例えば、同一のサーバー上に両サーバーの機能が構成されている形態でもよく、複数のサーバーで一つの認可サーバー、あるいはリソースサーバーの機能を実現する形態でもよい。

リソースサーバー３００と認可サーバー２００（あるいはリソースサーバー３０１と認可サーバー２０１）との所在の形態は、同じリージョン内、あるいは同じシステム内である形態に限定されない。認可サーバー２００で発行された認可トークンをリソースサーバー３００が問い合わせることができれば、所在の形態は問わない。あるいは、リソースサーバー３００が、認可トークンとともに受信した署名情報を検証する形態等でもよい。

クライアント４００としては、例えばプリンターやＭＦＰ、もしくはＰＣやスマートフォン等が挙げられる。端末５００はＷｅｂブラウザー５１０を有し、一例としてはＰＣやスマートフォン等が挙げられる。ユーザーはＷｅｂブラウザー５１０を介して認可サーバー２００、２０１に対するユーザーの認証要求やクライアント４００に対するログイン操作等、各種デバイスの機能を利用することができる。

クライアント４００もＷｅｂブラウザー４１０を備える。ユーザーはＷｅｂブラウザー４１０またはＷｅｂブラウザー５１０を操作して後述の認可操作を実行する。クライアント４００と端末５００はＬＡＮ１０１を介して接続されている。以降、Ｗｅｂブラウザー４１０とＷｅｂブラウザー５１０のどちらで実行するかを問わない場合は、「Ｗｅｂブラウザー４１０、５１０」と称する。

なお、本実施例では、クライアント４００および端末５００と認可サーバー２００とリソースサーバー３００がリージョン「ｊｐ」に所在し、認可サーバー２０１とリソースサーバー３０１がリージョン「ｅｕ」に所在するものとする。本実施例におけるリージョンとは、個人情報保護、安全保障等の観点から域外へのユーザー情報の移動に関して情報技術的、法的などの何らかの制限が存在する地域を示す。

次に図２を用いて、認可サーバー２００、２０１、リソースサーバー３００、３０１およびクライアント４００、端末５００のハードウェア構成を説明する。なお、図２は一般的な情報処理装置のブロック図であり、本実施形態の各種デバイスには一般的な情報処理装置のハードウェア構成やＩａａＳ（Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用できる。図２では、クライアント４００を例に説明するが、リソースサーバー３００、３０１や認可サーバー２００、２０１、端末５００も同様のハードウェア構成を有するものとする。

ＣＰＵ２００１は、ＲＡＭ２００２、ＲＯＭ２００３、外部メモリ２０１１などからプログラムを取り出してプログラムの命令を実行し、クライアント４００の制御を行うユニットである。後述のシーケンスはこのプログラムの命令が実行されることにより実現される。また、ＣＰＵ２００１はシステムバス２００４に接続される各ブロックを制御する。

ＲＡＭ２００２は、ＣＰＵ２００１が命令を実行する際に使用するワークメモリである。ＲＯＭ２００３や外部メモリ２０１１に保存されたＯＳやアプリケーション等のプログラムがＲＡＭ２００２へとロードされ、そのプログラムの命令をＣＰＵ２００１が順次読みだすことで命令を実行する。ＲＯＭ２００３は、アプリケーションプログラムおよびＯＳを含む組込済みプログラム、およびデータ等が記録されている記憶装置である。

ＫＢＣ（キーボードコントローラ）２００５は、ＫＢ（キーボード）２００９や不図示のポインティングデバイスからの入力を制御するユニットである。ＣＲＴＣ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ Ｃｏｎｔｒｏｌｌｅｒ）２００６は、ＣＲＴディスプレイ２０１０の表示を制御するユニットである。ＤＫＣ（Ｄｉｓｋ Ｃｏｎｔｒｏｌｌｅｒ）２００７は外部メモリ２０１１に対するデータアクセスを制御するユニットである。ＮＣ（ネットワークコントローラ）２００８はＷＡＮ１００やＬＡＮ１０１を介して接続された他のデバイスとの通信制御処理を実行する。なお、ＩａａＳとして提供される仮想的な情報処理装置の場合は、ＫＢＣ２００５やＣＲＴＣ２００６等を備えず、ＮＣ２００８を介して接続される端末が備えるキーボードやＣＲＴディスプレイから操作されるよう構成される。

尚、後述の説明においては、特に断りのない限り、各種デバイスの機能が実行される際のハードウェアの主体はＣＰＵ２００１であり、ソフトウェアの主体はＲＡＭ２００２、ＲＯＭ２００３、外部メモリ２０１１等にインストールされたプログラムであるものとする。

次に図３を用いて、認可サーバー２００、２０１、リソースサーバー３００、３０１、クライアント４００、端末５００が有する機能について説明する。認可サーバー２０１は認可サーバー２００と、リソースサーバー３００はリソースサーバー３０１と同様の機能を有するため、図３の説明ではクライアント４００の説明に加えて、認可サーバー２００とリソースサーバー３００を例に説明する。

認可サーバー２００は、認可サーバー部２１０とＨＴＴＰサーバー部２２０を有する。ＨＴＴＰサーバー部２２０はＷＡＮ１００を介してクライアント４００と端末５００に接続されており、Ｗｅｂブラウザー４１０、５１０や後述のアプリケーション４２０とＨＴＴＰ通信を行う機能である。また、ＨＴＴＰサーバー部２２０はＳＳＬ／ＴＬＳによる通信が可能であり、不図示の証明書ストアを有する。

認可サーバー部２１０はＨＴＴＰサーバー部２２０を介してＷｅｂブラウザー４１０、５１０からの要求を受信し、受信した要求に対する結果を応答する機能である。具体的には、ユーザー認証の要求をＨＴＴＰサーバー部２２０がＷｅｂブラウザー４１０、５１０から受信し、認証が成功したユーザー情報に紐づいた認証トークンを生成する。生成された認証トークンはＷｅｂブラウザー４１０、５１０に通知される。認証トークンとは、ユーザーが認可サーバー２００にログインしている事を示すためのトークン、またはユーザーが認可サーバー２００において認証されているかを検証するためのトークンである。認証トークンを用いることで認可サーバー２００はユーザーを識別することが可能となる。また、認可サーバー部２１０は、認可トークンに署名情報を付与するための秘密鍵を保持するように構成する事もできる。その場合は、この秘密鍵を用いて認可トークンに署名情報を付与し、署名情報付きの認可トークンをクライアント４００に対して発行する。

リソースサーバー３００はリソースサーバー部３１０を有する。リソースサーバー部３１０は、Ｗｅｂサービスを提供するためのＡＰＩを公開する機能である。なお、認可サーバー２００と同様に、ＨＴＴＰサーバー部を備え、ＨＴＴＰサーバー部を介して外部との受送信を実行する形態でもよい。

クライアント４００はＷｅｂブラウザー４１０とアプリケーション４２０と認証部４３０とトークンプロバイダー４４０を有する。Ｗｅｂブラウザー４１０はＷＷＷを利用するためのユーザーエージェントによって実現される機能である。Ｗｅｂブラウザー４１０はユーザーの操作により、認可サーバー２００およびトークンプロバイダー４４０と通信を行う。端末５００が備えるＷｅｂブラウザー５１０もＷｅｂブラウザー４１０と同様の機能である。アプリケーション４２０は、トークンプロバイダー４４０を介して認可サーバー２００から認可トークンを取得する機能である。取得した認可トークンを用いて、アプリケーション４２０はリソースサーバー３００が公開するＡＰＩを利用できる。

トークンプロバイダー４４０は、アプリケーション４２０からの認可トークン要求を受信し、認可サーバー２００と通信を行う事で認可トークンを取得する。ユーザーはＷｅｂブラウザー４１０、５１０を用いて認可サーバー２００およびトークンプロバイダー４４０と通信を行う事で認可操作を行う。

ここで、認可トークン要求は、アプリケーション４２０が認可トークンを取得するためにトークンプロバイダー４４０に対して送信するリクエストである。一方のトークン要求は、トークンプロバイダー４４０が認可トークンを取得するために認可サーバー２００、２０１に対して送信するリクエストである。このように、同じ認可トークンを取得するリクエストであっても、リクエストの受信元と送信先とが異なることでリクエストの呼称を変えていることに留意されたい。

トークンプロバイダー４４０はベンダーデフォルトクレデンシャルとして、トークンプロバイダー４４０自身を証明するためにＸ．５０９形式で定められるクライアント証明書およびその秘密鍵を備える。そして、トークンプロバイダーがクライアント証明書およびその秘密鍵を、認可サーバー２００との通信を確立する際に利用する事で、認可サーバー２００はトークンプロバイダーを認証することができる。

認証部４３０はユーザーを認証するための機能である。ユーザーはクライアント４００の機能を利用するために、クライアント４００における不図示の入力画面においてローカルユーザーＩＤとローカルユーザーパスワードを入力する。入力情報を受信したクライアント４００は、認証部４３０において予め登録されている情報（ローカルユーザーＩＤとローカルユーザーパスワード）と入力された情報とを照合することでユーザーの認証処理を行い、ログインコンテキストを生成する。なお認証処理の形態はこれに留まらず、例えば、ＩＣカードを使った認証や指紋等の生体認証でもよい。

ここでログインコンテキストは、クライアント４００でローカルユーザーを識別するための情報であり、例えば、ローカルユーザーＩＤから構成される。ログインコンテキストは、クライアント４００にローカルユーザーがログインした際にクライアント４００のＯＳ（不図示）において生成され、ログオフした際に消去される。ローカルユーザーのログイン操作でログインコンテキストが生成されることにより、ログイン中のローカルユーザーがアクセス権限を有するＷｅｂページがＷｅｂブラウザー４１０上に公開される。ローカルユーザーのログオフ操作でログインコンテキストが消去されることにより、ローカルユーザーがアクセス権限を有するＷｅｂページを別のユーザーに公開することなく、セキュリティを担保することができる。認証部４３０で生成されたログインコンテキストはアプリケーション４２０と認証部４３０とトークンプロバイダー４４０で共有される。

本実施例では、ユーザーが直接クライアント４００を操作してログインする形態で説明するが、Ｗｅｂブラウザー５１０を介してリモートでログインする形態でもよい。その場合、認証部４３０は不図示のログイン画面をＷｅｂブラウザー５１０に応答する。ユーザーはそのログイン画面にローカルユーザーＩＤとローカルユーザーパスワードを入力することでユーザー情報は認証される。

図４を用いてトークンプロバイダー４４０が有する機能を説明する。トークンプロバイダー４４０は、エンドポイント選択部６１０、トークン取得部６２０、トークン管理部６３０、トークン配布部６４０、クライアント登録部６５０、鍵管理部６６０、Ａｓｓｅｒｔｉｏｎ ＪＷＴ生成部６７０、ｉｄ＿ｔｏｋｅｎ検証部６８０を有する。

エンドポイント選択部６１０は後述の認可フローにおいて、認可エンドポイントに対し認可リクエストを送信する機能である。その際、エンドポイント選択部６１０は全リージョン共通の認可エンドポイントＵＲＬ（以下、全リージョン共通ＵＲＬ）を選択する。全リージョン共通ＵＲＬの一例を表１に示す。

表１は、「Ｎｏ．」（項目番号）と「認可エンドポイントＵＲＬ」のカラムを有し、「認可エンドポイントＵＲＬ」に全リージョン共通ＵＲＬが登録されている。表１への全リージョン共通ＵＲＬの登録は外部のアプリケーション等から実行しても良く、表１への登録の形態は問わない。

トークン取得部６２０は後述の認可フローにおいて、トークンエンドポイントにトークン要求を送信する機能である。トークンエンドポイントは後述のｉｄ＿ｔｏｋｅｎを元に、トークン取得部６２０によって決定される。

トークン管理部６３０は、トークン取得部６２０が取得した認可トークンをローカルユーザーＩＤ毎に管理する機能である。トークン管理部６３０が管理するトークンデータベースの一例を表２に示す。

表２は、「Ｎｏ」、「ローカルユーザーＩＤ」、「リージョン」、「認可トークン」のカラムを有し、ローカルユーザーＩＤを主キーとする。表２は後述の認可フロー（Ｓ１．０～Ｓ２．２）が実行されたことで生成、または更新され、トークン管理部６３０で管理される。ここで、「リージョン」に格納された情報は後述のｉｄ＿ｔｏｋｅｎから取得された情報であり、認可トークンの取得先である認可サーバーのリージョンを示す。

トークン配布部６４０は表２に基づいて、アプリケーション４２０から受信したローカルユーザーＩＤ（認可トークン要求に含まれる）に紐付くリージョン情報と認可トークンを特定し、認可トークンをアプリケーション４２０に送信する機能である。

アプリケーション４２０から受信したローカルユーザーＩＤが表２に存在しない場合、図５の認可フローが実行されていないと判断される。そして、エンドポイント選択部６１０は図５の認可フローを実行し、取得した認可トークンと、ローカルユーザーＩＤ、後述のｉｄ＿ｔｏｋｅｎから取得したリージョン情報をトークン管理部６３０（表２）に格納する。

クライアント登録部６５０は、認可サーバー２００、２０１に対してクライアントをクライアント登録する機能である。鍵管理部６６０はクライアント登録時に取得するＡｓｓｅｒｔｉｏｎ秘密鍵（Ａｓｓｅｒｔｉｏｎ ＪＷＴ 署名用の暗号鍵）を保持する。この鍵は、後述の認可ＡｓｓｅｒｔｉｏｎとトークンＡｓｓｅｒｔｉｏｎに署名する際に用いられる。

また、鍵管理部６６０は、認可サーバー２００、２０１に保持するｉｄ＿ｔｏｋｅｎ秘密鍵（ｉｄ＿ｔｏｋｅｎに署名を付与する暗号鍵）に対応するｉｄ＿ｔｏｋｅｎ公開鍵（ｉｄ＿ｔｏｋｅｎの署名を検証する復号鍵）を予め保持しており、各々の鍵の保持および取得機能を有する。

Ａｓｓｅｒｔｉｏｎ ＪＷＴ生成部６７０は鍵管理部６６０のＡｓｓｅｒｔｉｏｎ秘密鍵を用いて、後述の認可ＡｓｓｅｒｔｉｏｎとトークンＡｓｓｅｒｔｉｏｎを生成する機能である。ｉｄ＿ｔｏｋｅｎ検証部６８０は、鍵管理部６６０のｉｄ＿ｔｏｋｅｎ公開鍵を用いて後述のｉｄ＿ｔｏｋｅｎを検証する機能である。以上が、トークンプロバイダー４４０が有する機能である。

図５、図１３を用いてクライアント登録時のフローと、認可フローを説明する。また、上記で説明済みの処理については、詳細な説明を省略する。

まず、図１３を用いて、クライアント登録時の処理を説明する。ＯＡｕｔｈ ２．０におけるＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔをベースとした本実施例の認証認可フローを実行するための事前操作として、認可サーバー２００にクライアント４００を登録するための登録要求を行う（Ｓ０．０）。具体的には、クライアント４００の登録要求は認可サーバー２００の登録エンドポイント（図５、１３ではエンドポイントを「ＥＰ」と記載）に対して送信され、クライアント４００の起動時か、または後述のＳ１．１の認可フローの開始時にクライアント４００が未登録であった場合に開始される。クライアント登録要求を送信する方法としては、トークンプロバイダー４４０のクライアント登録部６５０が能動的に認可サーバー２００と通信する方法や、ユーザーがＷｅｂブラウザー５１０を介して認可サーバー２００にアクセスしてクライアント４００を登録する方法が挙げられる。

Ｓ０．０のクライアント登録要求には、後述の認可確認画面に表示するためのクライアント名、説明、アイコン画像、および必須パラメーターであるリダイレクトＵＲＩが含まれる。リダイレクトＵＲＩとは、クライアント４００が後述の認可レスポンスを送信する送信先を指定するアドレスである。クライアント４００の登録要求を受信した認可サーバー２００は、クライアント４００を識別するためのクライアントＩＤと、クライアントを認証するために鍵ペア（Ａｓｓｅｒｔｉｏｎ公開鍵、Ａｓｓｅｒｔｉｏｎ秘密鍵）を生成し、クライアント４００の登録応答としてクライアント４００にＡｓｓｅｒｔｉｏｎ秘密鍵を送信する（Ｓ０．１）。Ａｓｓｅｒｔｉｏｎ秘密鍵の送り方については、鍵交換のプロトコルによって暗号化して送信してもよい。

トークンプロバイダー部４４０は鍵管理部６６０にＡｓｓｅｒｔｉｏｎ秘密鍵を保存する。認可サーバー２００はクライアントＩＤとＡｓｓｅｒｔｉｏｎ公開鍵と、Ｓ０．０で取得した各種情報とリダイレクトＵＲＩとを紐づけて保持する。トークンプロバイダー部４４０は、鍵管理部６６０にＳ０．１で受信したクライアントＩＤとＡｓｓｅｒｔｉｏｎ秘密鍵を保持する。

図１３のクライアント登録では、トークンプロバイダー４４０（クライアント４００）と同じリージョン内に存在する認可サーバー２００に対して実行される。その際に生成され、保存されるクライアント４００に関する情報（クライアントＩＤやＡｓｓｅｒｔｉｏｎ公開鍵等）は、認可サーバー２００のみならず、別の認可サーバー（例えば認可サーバー２０１）に対しても共有される。その結果、ユーザー毎に認証要求の送信先（後述のＳ１．５）が異なっても、認可サーバーで共有されているクライアントＩＤやＡｓｓｅｒｔｉｏｎ公開鍵を用いることで、後述のｉｄ＿ｔｏｋｅｎの発行や認可トークンの発行等のやり取りを実行することができる。

以上が認可フローを実行する事前操作であるクライアント登録処理である。

図５を用いて、クライアント登録後の認可フローについて説明する。

ユーザーはクライアント４００にログインする（Ｓ１．０）。クライアント４００の認証部４３０は、ログインしたユーザーを特定するための情報であるログインコンテキストを生成し保持する。生成されたログインコンテキストを用いることで、ログインしたユーザーを特定する情報（ローカルユーザーＩＤ等）をログインコンテキストから取得することができる。

ユーザーがＷｅｂブラウザー５１０を介して認可開始のＵＲＩにアクセスすることで、本実施例のＯＡｕｔｈ ２．０をベースとした認可フローを開始する（Ｓ１．１）。クライアント４００は認可フローを開始するための認可開始ＵＲＩにアクセスされると、認可エンドポイントに対して認可リクエストを送信する（Ｓ１．２）。この認可エンドポイントは、全リージョン共通ＵＲＩを介してアクセスされる。

＜認可エンドポイント＞
ここで、認可エンドポイントの特定方法について説明する。トークンプロバイダー４４０は適切な認可サーバーを選択して認可トークンを取得するために、まず全リージョン共通ＵＲＩに対して認可リクエストを送信する。認可リクエストが送信された結果アクセスされるＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）サーバーには、認可エンドポイントＵＲＬとＩＰアドレスの紐付けデータ（ＤＮＳレコード）が管理されている。Ｗｅｂブラウザーを介して認可サーバーにアクセスする際にはこのＤＮＳサーバーを経由し、ＤＮＳレコードに基づいて全リージョン共通の認可エンドポイントＵＲＬがＩＰアドレスに変換（名前解決）される。その際、Ｇｅｏ Ｒｏｕｔｉｎｇ機能（ＡＷＳの場合はＧｅｏＲｏｕｔｉｎｇ機能）は、認可リクエスト元（クライアント４００）のＩＰアドレスから地理データベースを参照し、適切な認可エンドポイントＵＲＩに変換され、認可リクエスト送信元に送信される。

本実施例では、クライアント４００と認可サーバー２００とが同じリージョン「ｊｐ」に存在する。そのためトークンプロバイダー４４０は、Ｗｅｂブラウザー５１０を介して全リージョン共通ＵＲＩにアクセスした場合、Ｇｅｏ Ｒｏｕｔｉｎｇ機能により同じリージョン「ｊｐ」に存在する認可サーバー２００の認可エンドポイントＵＲＩが返信される。その認可エンドポイントＵＲＩに対してトークンプロバイダー４４０は認可リクエストを送信する。図５に示すＳ１．２は、Ｇｅｏ Ｒｏｕｔｉｎｇ機能により特定された認可エンドポイントＵＲＩに対して認可リクエストが送信された状態を示す。

＜認可リクエスト＞
トークンプロバイダー４４０が送信する認可リクエストについて説明する。トークンプロバイダー４４０が認可リクエストを送信する際、セキュリティ情報（後述のｉｄ＿ｔｏｋｅｎ）の取得依頼も送信する。

認可リクエストはｒｅｓｐｏｎｓｅ＿ｔｙｐｅ、ｃｌｉｅｎｔ＿ｉｄ、ｒｅｄｉｒｅｃｔ＿ｕｒｉ、ｓｔａｔｅパラメーターを含む、署名付きのＪＷＴ形式で表現される。以下、説明の都合上、ＪＷＴ形式の認可リクエストを「認可Ａｓｓｅｒｔｉｏｎ」と称する。認可Ａｓｓｅｒｔｉｏｎは後述のヘッダーとペイロードとを含む。

認可リクエストに対し、Ｓ０．１のクライアント登録応答時に入手したＡｓｓｅｒｔｉｏｎ秘密鍵を用いて付与され、署名アルゴリズムはＪＷＡ（ＲＦＣ７５１８ ＪＳＯＮ Ｗｅｂ Ａｌｇｏｒｉｔｈｍｓ）で規定されるＥＳ２５６（ＥＣＤＳＡ ｕｓｉｎｇ Ｐ－２５６ ｃｕｒｖｅ ａｎｄ ＳＨＡ－２５６ ｈａｓｈ）である。認可Ａｓｓｅｒｔｉｏｎのヘッダーの一例を図８（ａ）に示す。

「ｔｙｐ」はＪＷＴのタイプであり、Ａｓｓｅｒｔｉｏｎ ＪＷＴであることを示す値「Ａｓｓｅｒｔｉｏｎ」が設定されている。「ａｌｇ」は署名アルゴリズムを示し、値「ＥＳ２５６」が設定されている。「ｋｉｄ」は、ＪＷＴの署名検証に用いるＡｓｓｅｒｔｉｏｎ公開鍵とＡｓｓｅｒｔｉｏｎ秘密鍵のＩＤを示す。「ｋｉｄ」に設定される値としては、ＵＵＩＤなどの他にＪＳＯＮ Ｗｅｂ Ｋｅｙ（ＪＷＫ）Ｔｈｕｍｂｐｒｉｎｔ（ＲＦＣ ７６３８）仕様に基づく公開鍵のＴｈｕｍｂｐｒｉｎｔの値等がある。

認可Ａｓｓｅｒｔｉｏｎのペイロードクレームの一例を図８（ｂ）に示す。「ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ」はＯＡｕｔｈ２．０のレスポンスタイプを示し、後述の認可レスポンスでｉｄ＿ｔｏｋｅｎを取得するため、値「ｉｄ＿ｔｏｋｅｎ」が設定されている。

「ｉｓｓ」はＪＷＴの発行者（ｉｓｓｕｅｒ）を識別するための識別子であり、認可Ａｓｓｅｒｔｉｏｎの場合はクライアントＩＤを示すＵＵＩＤが値として設定される。「ｓｕｂ」はユーザー識別子を表し、「ｉｓｓ」と同様にクライアントＩＤを示すＵＵＩＤが入る。「ｉｓｓ」と「ｓｕｂ」は各々ＵＲＬ ＳａｆｅなＢａｓｅ６４形式で表した文字列をエンコードしてＪＷＴ形式の認可リクエストに含める。「ｅｘｐ」は認可Ａｓｓｅｒｔｉｏｎの有効期限、「ｉａｔ」は認可Ａｓｓｅｒｔｉｏｎの発行日時を示し、共にＵｎｉｘ Ｅｐｏｃｈ（１９７０年１月１日（世界標準時））からの経過秒数で表される。

図８（ｂ）のペイロードクレームはさらに、ＯＡｕｔｈ２．０のリダイレクトＵＲＩを示す「ｒｅｄｉｒｅｃｔ＿ｕｒｉ」と、「ｓｔａｔｅ」を含む。「ｓｔａｔｅ」は認可リクエストと認可レスポンスとを一意に紐づけるための情報であり、ＣＳＲＦ（ｃｒｏｓｓ－ｓｉｔｅ ｒｅｑｕｅｓｔ ｆｏｒｇｅｒｙ）攻撃や、トークン置換攻撃を防ぐために用いられる。そのため、ｓｔａｔｅは推測不可能でかつ重複しない値である必要がある。後述の認可レスポンスを受信したクライアント４００は、ｓｔａｔｅの値とＳ１．２の認可リクエストで送信したｓｔａｔｅの値とが一致するかを検証する。認可リクエストを実行したローカルユーザーを識別するために、クライアント４００で発行されるｓｔａｔｅはリダイレクトＵＲＩとログインコンテキストと紐付いて、クライアント４００で管理される。

トークンプロバイダー４４０はＪＷＴ仕様に基づき、図８で示したような認可Ａｓｓｅｒｔｉｏｎを作成する。認可Ａｓｓｅｒｔｉｏｎには先に述べたＡｓｓｅｒｔｉｏｎ秘密鍵を用いてＪＷＴ形式の署名（不図示）が付与される。以上が認可リクエストの説明である。

図５の説明に戻る。Ｓ１．２で認可リクエストを受信した認可サーバー２００は、Ｗｅｂブラウザー５１０に対して全リージョン共通のログイン画面を応答する（Ｓ１．３）。ログイン画面にはｈｉｄｄｅｎフィールドで認可Ａｓｓｅｒｔｉｏｎを含める。ユーザーは、Ｗｅｂブラウザー５１０を介してユーザーＩＤとパスワードを入力し、認可サーバー２００に対して認証要求を行う（Ｓ１．４）。その際、先にログイン画面のｈｉｄｄｅｎフィールドとして受信した認可Ａｓｓｅｒｔｉｏｎを認証要求と同時にＰＯＳＴする。ここで、Ｓ１．４で認可サーバー２００に送信されるユーザーＩＤは、認可サーバーにログインするためのユーザー識別子であり、Ｓ１．０のローカルユーザーＩＤとは異なる。

認可サーバー２００は、ユーザーＩＤの所属リージョン（ユーザーＩＤで特定されるユーザーのユーザー情報を管理する認可サーバーのリージョン）を判定し、適切なリージョンの認可サーバーにログイン画面をリダイレクトする（Ｓ１．５）。異なるリージョンの認可サーバー同士が共有するユーザー所属リージョン表の一例を表３に示す。

ユーザーＩＤ（ハッシュ値）は、ユーザーＩＤ文字列についてｓｈａ２５６アルゴリズムで算出したハッシュ値である。所属リージョンはユーザーＩＤで特定されるユーザーが所属するリージョンである。表３より、「ｕｓｅｒ１＠１１０ＡＡ」（ハッシュ値：ｂ９２７７３６９６１ｃ５２３４６４ａ５５５９９８２ａ５２７ｅｃｃｄ１８２７７ｃｂｅｅｅｃ０９２ｅａ６７９５９９９０２４１ｂｃｃ３）の所属リージョンは「ｊｐ」、「ｕｓｅｒ２＠１１０Ａｂ」（ハッシュ値：８ａｆｅ０ｃａｅ０ｄ１ａ４ｆｂｂ３８０３４８ｆｆ１９９９ａａ１ｄ４０ｅｃｆ８２９ａ７３０ｂ８２ｂｄｃｂ６ａ６２８７９６ｂ５１ｂ２）の所属リージョンは「ｅｕ」、「ｕｓｅｒ３＠１２０ＡＡ」（ハッシュ値：２５ｄａｃ１ｅａｅｃｃ８１６７３ｃｂ６４１５７ｂｅ３８ｂａｂｂ６ａ１３ｂ５３ｂ０２０ｅ２ｄ８８ｄｆｄｃａ７００５４ｃ８４ｃｆ０３）の所属リージョンは「ｊｐ」である。

ユーザー所属リージョン表（表３）はユーザー登録の際に更新され、定期的に全リージョンの認可サーバーで最新データを共有する。ユーザーＩＤはハッシュ値であるため、この値からユーザーＩＤを復元することは一般に不可能である。そのため、ユーザー所属リージョン表（表３）を全リージョンの認可サーバーで共有しても、ユーザー情報を共有していることにはならない。

Ｓ１．５におけるログイン画面のリダイレクトについて説明する。Ｓ１．３の全リージョン共通のログイン画面においてユーザーＩＤ「ｕｓｅｒ２＠１１０Ａｂ」、パスワード「ｐａｓｓｗｏｒｄ」が入力されたものとする。認可サーバー２００は入力されたユーザーＩＤのハッシュ値を算出する。算出したハッシュ値から表３を参照して、ユーザーの所属リージョン「ｅｕ」が特定される。そして、ユーザーＩＤ、パスワード、認証要求でＰＯＳＴされた認可Ａｓｓｅｒｔｉｏｎが、Ｗｅｂブラウザー５１０のＣｏｏｋｉｅに応答され、リージョン「ｅｕ」の認可サーバーである認可サーバー２０１のログインＵＲＬに対し、認証要求としてリダイレクトされる。

本実施例では、表３に格納された所属リージョンから、認可サーバー２０１のログインＵＲＬを特定する形態を示した。具体的には、異なるリージョンの各認可サーバーのログインＵＲＬの型が予め決まっており、その型に対して表３の「所属リージョン」をあてはめることで、各認可サーバーのログインＵＲＬを特定する形態である。本実施例の形態（表３）に限定されず、ユーザーＩＤのハッシュ値に対し認可サーバーのログインＵＲＬを紐付けて管理しておく形態でもよい。

認可サーバー２０１はＳ１．５でリダイレクトされたユーザーＩＤとパスワードとの紐付け情報が事前に登録されている紐付け情報と一致するかを検証し、一致する場合は認証トークンを発行する。発行された認証トークンはＷｅｂブラウザー５１０のＣｏｏｋｉｅに応答される。以上が、ログイン画面のリダイレクトの説明である。

図５の説明に戻る。認可サーバー２０１はユーザーに対して、クライアント４００の認可を同意するための認可確認画面をＷｅｂブラウザー５１０に応答する（Ｓ１．６）。認可確認画面の一例を図１２に示す。認可確認画面１２００は、ユーザーに対して同意を求める内容として、認可の対象となるクライアント４００のクライアント名１２０１、クライアント４００に関する説明１２０２、および、アイコン画像１２０３を有する。さらに認可確認画面１２００は、ユーザーがクライアント４００を認可するための許可ボタン１２０４、認可を拒否するための拒否ボタン１２０５を備える。拒否ボタン１２０５が押下された場合の処理、または許可ボタン１２０４が押下された場合の処理（Ｓ１．７）については後述する。

認可確認画面には、リダイレクトされた認証要求に含まれる認可Ａｓｓｅｒｔｉｏｎ をｈｉｄｄｅｎフィールドとして含む。ただし、認証要求に含まれる認可Ａｓｓｅｒｔｉｏｎの署名を検証した後、認可Ａｓｓｅｒｔｉｏｎに含まれるクライアントＩＤとリダイレクトＵＲＩとの組み合わせが、認可サーバー２０１や別のリージョンの認可サーバーとで共有されたクライアントＩＤとリダイレクトＵＲＩとの組み合わせと一致しない場合は、Ｗｅｂブラウザー５１０に認可確認画面ではなく、エラー画面を応答する。これによりに、ＵＲＬへの不正なリダイレクトを防ぐことができる。また、認可確認画面１２００の拒否ボタン１２０５が押下された場合も、エラー画面がＷｅｂブラウザー５１０に送信される。

認可サーバー２０１にログイン中のユーザーが既に同一のクライアントＩＤで認可操作済みであった場合はＳ１．６とＳ１．７の処理を省略できる。

許可ボタン１２０４が押下されたことで、ユーザーによる認可操作が実行された（Ｓ１．７）後、認可サーバー２０１は、認可操作に含まれる認可Ａｓｓｅｒｔｉｏｎを認可サーバー２０１の認可エンドポイントに対してＰＯＳＴする（Ｓ１．８）。認可サーバー２０１は、認可エンドポイントにＰＯＳＴされた認可Ａｓｓｅｒｔｉｏｎを検証する。ここで認可Ａｓｓｅｒｔｉｏｎを検証する理由としては、認可サーバー２０１にとって外部（Ｗｅｂ ブラウザー５１０）からの指示（今回は認可操作）であるため、認可Ａｓｓｅｒｔｉｏｎの内容が詐称されていないか、認可Ａｓｓｅｒｔｉｏｎを検証する必要がある。

認可Ａｓｓｅｒｔｉｏｎの検証が成功した場合はｉｄ＿ｔｏｋｅｎを生成し、クライアント４００のリダイレクトＵＲＩに対して認可レスポンスとしてｉｄ＿ｔｏｋｅｎを送信する（Ｓ１．９）。つまり、生成されたｉｄ＿ｔｏｋｅｎは、認可サーバー２０１からＷｅｂブラウザー５１０を介して、クライアント４００に送信される。送信する際には、ｉｄ＿ｔｏｋｅｎをリダイレクトＵＲＩのクエリパラメーターとして付与しＷｅｂブラウザー５１０に送信する。それにより、リダイレクトＵＲＩで指定された宛先にｉｄ＿ｔｏｋｅｎをリダイレクトされる。認可サーバー２０１で生成されたｉｄ＿ｔｏｋｅｎは、クライアントＩＤ、ユーザーＩＤ、リダイレクトＵＲＩと紐づいて認可サーバー２０１で保存される。

Ｓ１．８の認可Ａｓｓｅｒｔｉｏｎの検証に失敗した場合は、認可サーバー２０１はＷｅｂブラウザー５１０に対して認可エラーを応答する。

＜ｉｄ＿ｔｏｋｅｎ＞
認可サーバー２０１で生成されるｉｄ＿ｔｏｋｅｎは、認可サーバーによるエンドユーザー認証に関するクレームを含んだセキュリティトークンであり、ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ仕様（ＯｐｅｎＩＤ Ｆｏｕｎｄａｔｉｏｎ ＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ Ｃｏｒｅ １．０）で規定されている。ｉｄ＿ｔｏｋｅｎには、認可トークンの利用先リージョン情報が含まれ、署名付きのＪＳＯＮ Ｗｅｂ Ｔｏｋｅｎ（ＪＷＴ ＲＦＣ７５１８、ＪＷＴ ＲＦＣ７５１５）で表される。一般にｉｄ＿ｔｏｋｅｎには、エンドユーザー認証に関するクレーム群（Ｃｌａｉｍｓ ａｂｏｕｔ ｔｈｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ）と、その他のユーザー属性に関するクレーム群が含まれる。本実施例におけるｉｄ＿ｔｏｋｅｎは、ペイロードクレームに「ｉｓｓ」、「ｓｕｂ」、「ａｕｄ」、「ｅｘｐ」、「ｉａｔ」、「ｎｏｎｃｅ」を含む。

ｉｄ＿ｔｏｋｅｎの署名はｉｄ＿ｔｏｋｅｎ秘密鍵を用いて付与され、署名アルゴリズムはＪＷＡで規定されるＥＳ２５６署名である。ｉｄ＿ｔｏｋｅｎのヘッダーの一例を図９（ａ）に示す。尚、図８で説明済みの部分については説明を省略する。

ｉｄ＿ｔｏｋｅｎのヘッダーは、「ａｌｇ」で示されるｉｄ＿ｔｏｋｅｎの署名アルゴリズム「ＥＳ２５６」と、ｉｄ＿ｔｏｋｅｎの署名検証に用いるｉｄ＿ｔｏｋｅｎ公開鍵・ｉｄ＿ｔｏｋｅｎ秘密鍵のＩＤを示す「ｋｉｄ」を含む。ｋｉｄとしてはＵＵＩＤなどの他に、ＪＳＯＮ Ｗｅｂ Ｋｅｙ（ＪＷＫ）Ｔｈｕｍｂｐｒｉｎｔ（ＲＦＣ ７６３８）仕様に基づく公開鍵のＴｈｕｍｂｐｒｉｎｔの値を用いてもよい。

ｉｄ＿ｔｏｋｅｎのペイロードに存在するユーザー属性に関するクレームの一例を図９（ｂ）に示す。「ｉｓｓ」にはＯｐｅｎＩＤ Ｃｏｎｎｅｃｔ Ｃｏｒｅ １．０の定義により、クエリーとフラグメント部を含まない「ｈｔｔｐｓ：／／」で始まるＵＲＬが設定される。今回は、ｉｄ＿ｔｏｋｅｎの発行者が認可サーバー２０１であるため、認可サーバー２０１を示す「ｈｔｔｐｓ：／／ｅｕ－ａｕｔｈ．ｅｘａｍｐｌｅ．ｃｏｍ」が設定される。

「ａｕｄ」はｉｄ＿ｔｏｋｅｎの発行対象を示し、今回はクライアントＩＤの値が設定される。「ｓｕｂ」と「ａｕｄ」は、各々ＵＲＬ Ｓａｆｅ なＢａｓｅ６４形式で表した文字列となる。「ｎｏｎｃｅ」は主にリプレイアタックを防ぐ目的でｉｄ＿ｔｏｋｅｎに含まれ、ｓｔａｔｅパラメーターの値が設定されている。以上がｉｄ＿ｔｏｋｅｎに関する説明である。

図５の説明に戻る。ｉｄ＿ｔｏｋｅｎの署名付与にはｉｄ＿ｔｏｋｅｎ秘密鍵、ｉｄ＿ｔｏｋｅｎの検証にはｉｄ＿ｔｏｋｅｎ公開鍵が必要である。ｉｄ＿ｔｏｋｅｎ秘密鍵は異なるリージョンの各認可サーバーで予め共有されており、ｉｄ＿ｔｏｋｅｎ公開鍵は予めクライアント４００に保存されているものとする。

Ｓ１．９で認可レスポンスを受信したクライアント４００は、認可レスポンスに含まれるｉｄ＿ｔｏｋｅｎの署名（不図示）を検証し、ｉｄ＿ｔｏｋｅｎに含まれる「ｎｏｎｃｅ」と、クライアント４００が管理する「ｓｔａｔｅ」とが一致するかを判定する。一致すると判定された場合、クライアント４００はｉｄ＿ｔｏｋｅｎの「ｉｓｓ」を参照して、ｉｄ＿ｔｏｋｅｎの発行者である認可サーバー２０１のＵＲＬを取得する。今回は、トークンプロバイダー部４４０のｉｄ＿ｔｏｋｅｎ検証部６８０が、ｉｄ＿ｔｏｋｅｎの「ｉｓｓ」を参照し認可サーバー２０１のＵＲＬ「ｈｔｔｐｓ：／／ｅｕ－ａｕｔｈ．ｅｘａｍｐｌｅ．ｃｏｍ」を取得するものとする。取得した認可サーバー２０１のＵＲＬのホスト名「ｅｕ－ａｕｔｈ」のハイフンより前の文字列「ｅｕ」を参照し、リージョン文字列を認識する。認識されたリージョン文字列は、トークンデータベース（表２）に格納される。

トークンデータベースにはさらに、現在クライアント４００にログインしているローカルユーザーＩＤも格納される。そして、認可サーバー２０１のトークンエンドポイントに対して、認可トークンを取得するためのトークン要求を送信する（Ｓ２．０）。トークン要求はＪＷＴ形式で記載され、以下、認可リクエスト時のＡｓｓｅｒｔｉｏｎ ＪＷＴと区別するために、ＪＷＴ形式のトークン要求を「トークンＡｓｓｅｒｔｉｏｎ」と称する。トークンＡｓｓｅｒｔｉｏｎは、ヘッダーとペイロードとを含む。また、トークンＡｓｓｅｒｔｉｏｎには、クライアントＩＤと、ｉｄ＿ｔｏｋｅｎのｓｕｂクレームから取得したユーザーＩＤと、リダイレクトＵＲＩが含まれる。トークンＡｓｓｅｒｔｉｏｎのヘッダーの一例を図１０（ａ）に示す。

「ｔｙｐ」はＪＷＴのタイプを示し、Ａｓｓｅｒｔｉｏｎ ＪＷＴであることを示す値「Ａｓｓｅｒｔｉｏｎ」が設定されている。署名アルゴリズムを示す「ＥＳ２５６」、ＪＷＴの署名検証に用いるＡｓｓｅｒｔｉｏｎ公開鍵・Ａｓｓｅｒｔｉｏｎ秘密鍵のＩＤを示す「ｋｉｄ」を含む。ｋｉｄとしてはＵＵＩＤなどの他に、ＪＳＯＮ Ｗｅｂ Ｋｅｙ（ＪＷＫ）Ｔｈｕｍｂｐｒｉｎｔ（ＲＦＣ ７６３８）仕様に基づく公開鍵のＴｈｕｍｂｐｒｉｎｔの値を用いてもよい。

トークンＡｓｓｅｒｔｉｏｎのペイロードクレームの一例を図１０（ｂ）に示す。上記で説明済みの部分については、説明を省略する。

「ｒｅｓｐｏｎｓｅ＿ｔｙｐｅ」はＯＡｕｔｈ２．０のレスポンスタイプを示し、「ｉｄ＿ｔｏｋｅｎ」が設定されている。またＯＡｕｔｈ２．０のクライアントＩＤを示す「ｉｓｓ」、ＯＡｕｔｈ２．０のリダイレクトＵＲＩを示す「ｒｅｄｉｒｅｃｔ＿ｕｒｉ」、ユーザー識別子を表す「ｓｕｂ」がペイロードクレームに含まれる。「ｓｕｂ」には、本実施例においては先に取得したｉｄ＿ｔｏｋｅｎに含まれる値が設定される。

トークンプロバイダー４４０は、ＪＷＴ仕様に基づき図１０で示したようなヘッダーやペイロードを含むトークンＡｓｓｅｒｔｉｏｎを作成する。トークンＡｓｓｅｒｔｉｏｎには、クライアント登録応答時に取得したＡｓｓｅｒｔｉｏｎ秘密鍵を用いて付与された署名が含まれる（ＪＷＴの署名部分の詳細については省略する）。

Ｓ２．０でトークン要求を受信した認可サーバー２０１はＡｓｓｅｒｔｉｏｎ公開鍵を用いて、トークンＡｓｓｅｒｔｉｏｎの署名を検証する。さらに認可サーバー２０１は、Ｓ２．０で受信したトークンＡｓｓｅｒｔｉｏｎを解析し、「ｉｓｓ」、「ｓｕｂ」、「ｒｅｄｉｒｅｃｔ＿ｕｒｉ」、「ｉａｔ」、「ｅｘｐ」を取得する。取得した情報の解析により、Ｓ１．２の認可リクエストを送信したクライアント４００とＳ２．０のトークン要求を送信したクライアント４００とが一致するか、認可トークンを要求するユーザーのユーザー情報が認可サーバー２０１に存在するか、を認可サーバー２０１で検証する事ができる。

検証が成功した場合、認可サーバー２０１はクライアント４００に対してトークン応答として、認可トークンを送信する（Ｓ２．１）。トークンプロバイダー４４０のトークン管理部６３０はトークンデータベース（表２）に対し、取得した認可トークンを格納する。

トークンプロバイダー４４０のトークン配布部６４０は、トークン管理部６３０が有するトークンデータベース（表２）から、現在ログイン中のユーザーＩＤを検索し、リージョン情報と認可トークンを取得する。取得したリージョン情報と認可トークンをアプリケーション４２０に送信する（Ｓ３．０）。

アプリケーション４２０は受信した認可トークンとリージョン情報に基づいて、リソースサーバー３０１が公開するＡＰＩにアクセスする（Ｓ３．１）。具体的には、事前にアプリケーションに内蔵されているリージョン毎のリソースサーバーＵＲＬ（不図示）と、トークンプロバイダー４４０から取得したリージョン情報を用いて、リソースサーバー３０１が公開するＡＰＩにアクセスする。本実施例では、ユーザー情報を管理する認可サーバー２０１と同じリージョンｅｕに存在するリソースサーバー３０１に、Ｓ３．１のリソース要求が送信される。

以上が認可フローである。本実施例により、ユーザーの手動操作を介することなく、ユーザー情報が存在する認可サーバーを適切に選択し、選択した認可サーバーが認可トークンを発行することができる。また取得した認可トークンを用いて、ユーザー情報が存在するリージョンのリソースサーバーに対し、リソースを要求することができる。

［実施例２］
実施例２では、認可リクエスト（Ｓ１．２）と認可レスポンス（Ｓ１．９）が正常に終了した後、トークン要求（Ｓ２．０）までの間にユーザーが別のリージョンに移動した場合に、トークン取得を継続する手段を説明する。

具体的には、Ｓ１．２～Ｓ１．９において認可されたユーザーが、出張や引っ越し等で別のリージョンを移動したとする。その際、移動したユーザーのユーザー情報も、移動先のリージョンの認可サーバーに移動させる必要がある。そのユーザー情報を移動させている最中に、ユーザーの移動前にユーザーを認可した認可サーバーに対し、トークン要求が送信される状況を想定する。

まず、図６を用いて、認可レスポンス（Ｓ１．９）からトークン要求（Ｓ２．０）の間に、認可されたユーザー情報が認可サーバー２０１から移動させている際の処理を説明する。図６の処理は、トークンプロバイダー４４０（クライアント４００）が主体で実行されるトークン要求処理である。

トークンプロバイダー４４０は認可サーバー２００に対して認可リクエストを送信する（Ｓ６．０）。本処理は実施例１におけるＳ１．２と同様の処理である。トークンプロバイダー４４０は認可レスポンスを受信する（Ｓ６．１）。本処理は実施例１におけるＳ１．９と同様である。その際、トークンプロバイダー４４０は、認可レスポンスに含まれるｉｄ＿ｔｏｋｅｎを検証する。検証後、認可サーバー２０１のトークンエンドポイントに対して、ＪＷＴ形式のトークン要求（トークンＡｓｓｅｒｔｉｏｎ）を送信し（Ｓ６．２）、それに対するトークン応答を受信する（Ｓ６．３）。トークンプロバイダー４４０はトークン応答を解析し、トークン応答に認可トークンが含まれているかを判定する（Ｓ６．４）。含まれていると判定された後は、実施例１と同様、Ｓ３．０に進む。含まれていないと判定された後は、トークン応答にユーザー移動先情報が含まれているかを判定する（Ｓ６．５）。

ユーザー移動先情報が含まれているトークン応答の一例を図１１に示す。図１１の「ｄｅｓｔｉｎａｔｉｏｎ＿ｕｒｌ」は後述のユーザー移動先情報を元に認可サーバー２０１が判定した、ユーザー情報の移動先である移動先トークンエンドポイントを示す。

Ｓ６．５においてトークン応答にユーザー移動先情報が含まれていると判定された場合、Ｓ６．２の処理に戻り、ユーザー移動先情報で特定される移動先トークンエンドポイントに対してトークン要求を改めて送信する。Ｓ６．２～Ｓ６．５の処理は、トークン応答に「ｄｅｓｔｉｎａｔｉｏｎ＿ｕｒｌ」が含まれる限り、繰り返し実行される。ただし、実行回数がある一定の値を越えた場合や一定の時間が経過した場合に、トークンプロバイダー４４０がエラーを起こして処理を終了する等の形態も可能である。

Ｓ６．５においてトークン応答にユーザー移動先情報が存在しないと判定された場合、トークンプロバイダー４４０はＳ６．０の処理に戻り、認可リクエストを認可サーバー２００に送信する。Ｓ６．５からＳ６．０に戻る処理は、トークン応答にユーザー移動先情報が含まれるまで、繰り返し実行される。ただし、Ｓ６．２へ戻る処理と同様、実行回数や処理時間に制限を設け、超過した場合に、トークンプロバイダー４４０がエラーを起こして処理を終了する等の形態も可能である。以上が図６の処理である。

図７を用いて、トークンプロバイダー４４０からトークン要求を受信した認可サーバー２０１が、トークン応答を送信する処理を説明する。Ｓ２．０と同様に、認可サーバー２０１はトークンエンドポイントにトークンＡｓｓｅｒｔｉｏｎを受信する（Ｓ７．１）。認可サーバー２０１は、Ａｓｓｅｒｔｉｏｎ公開鍵を用いてトークンＡｓｓｅｒｔｉｏｎを検証し、「ｓｕｂ」からユーザー識別子を取得する（Ｓ７．２）。その際、認可サーバー２０１は、取得したユーザー識別子が認可サーバー２０１に存在するか判定する（Ｓ７．３）。存在すると判定された場合は、実施例１のＳ２．１と同様に、認可トークンをトークン応答としてクライアント４００に送信する（Ｓ７．４）。認可サーバー２０１にユーザー識別子が存在しないと判定された場合は、ユーザー識別子がユーザー情報移動先テーブルに存在するかを判定する（Ｓ７．５）。判定の際に参照するユーザー情報移動先テーブルの一例を表４に示す。

ユーザー情報移動先テーブルは、ユーザー識別子と移動先トークンエンドポイントのカラムを有する。移動先トークンエンドポイントは、ユーザー情報を異なるリージョンの認可サーバーに移動した際に、その移送先である認可サーバーのトークンエンドポイントＵＲＬである。

Ｓ７．５においては具体的に、トークンＡｓｓｅｒｔｉｏｎの「ｓｕｂ」に含まれるユーザー識別子「ｄＸＮｌｃｊＪＡＭＴＥｗＱＵＩ」が存在するかを判定する。ユーザー識別子が存在すると判定された場合、対応する移動先トークンエンドポイントを取得して、移動先トークンエンドポイントＵＲＬを「ｄｅｓｔｉｎａｔｉｏｎ＿ｕｒｌ」として記載したトークン応答をトークンプロバイダー４４０に送信する（Ｓ７．６）。「ｄｅｓｔｉｎａｔｉｏｎ＿ｕｒｌ」が、図６の処理で記載した「ユーザー移送先情報」である。

Ｓ７．５においてユーザー識別子が存在しないと判定された場合、認可サーバー２０１はエラー応答をトークンプロバイダー４４０に送信して処理を終了する。

本実施例により、認可されたユーザーのユーザー情報が別の認可サーバーに送信された際にトークン要求が実行されても再度認可することなく、認可トークンを取得するまでの処理を続行させることができる。

［その他の実施例］
上記の実施例では、Ｇｅｏ Ｒｏｕｔｉｎｇ機能を用いることで、トークンプロバイダー４４０（クライアント４００）と地理的に近い認可サーバー２００に、認可リクエストが送信される形態を示した。それは、アクセス時間等を考慮したことによるものだが、ユーザー所属リージョン表（表３）が共有されている認可サーバーであれば、認可リクエストの送信先の決定方法は問わない。

また、本発明の目的は以下の処理を実行することによっても達成される。即ち、上述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体を、システム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）が記憶媒体に格納されたプログラムコードを読み出す処理である。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコード及び該プログラムコードを記憶した記憶媒体は本発明を構成することになる。

２００ 認可サーバー
４２０ クライアントアプリケーション
４４０ トークンプロバイダー部

Claims (8)

1. クライアントとウェブブラウザと複数の認可サーバーと、を含む情報処理システムであって、
   前記複数の認可サーバーは、
   前記クライアントがリソースサーバーにアクセスすることを、前記ウェブブラウザを介して許可するユーザーのユーザー情報を管理する第一の認可サーバーであって、前記複数の認可サーバーに含まれる第一の認可サーバーを特定する特定手段を有し、
   前記複数の認可サーバーに含まれる認可サーバーは、
   前記クライアントから認可リクエストを受信したことに応じて、前記特定手段によって前記第一の認可サーバーを特定し、特定された前記第一の認可サーバーに対し前記ユーザーを認証する認証リクエストをリダイレクトし、
   前記第一の認可サーバーは、
   リダイレクトされた前記認証リクエストを受信したことに応じて前記ユーザーを認証し、認証された前記ユーザーが前記アクセスを許可すると認可レスポンスとして認可トークンを前記クライアントに送信することを特徴とする情報処理システム。
2. 前記第一の認可サーバーは、
   前記クライアントから前記認可トークンを受信すると、前記クライアントが前記リソースサーバーにアクセスするためのアクセストークンを発行することを特徴とする請求項１に記載の情報処理システム。
3. 前記クライアントから前記認可リクエストを受信する認可サーバーは、
   前記クライアントのＩＰアドレスに基づいてＤＮＳサーバーによって特定される認可サーバーであることを特徴とする請求項１または２に記載の情報処理システム。
4. 前記情報処理システムは、
   前記ユーザー情報に基づいて生成された情報と、前記ユーザー情報を管理する前記第一の認可サーバーに関する情報とを管理する第一の管理手段を更に有し、
   前記特定手段は、
   前記第一の管理手段によって管理された情報に基づいて前記第一の認可サーバーを特定することを特徴とする請求項１乃至３のいずれか一項に記載の情報処理システム。
5. 前記ユーザー情報に基づいて生成された情報とはハッシュ値であって、前記第一の認可サーバーに関する情報とは前記第一の認可サーバーのリージョン情報であることを特徴とする請求項４に記載の情報処理システム。
6. 前記認可レスポンスは、
   前記第一の認可サーバーを宛先として示す情報と、前記第一の認可サーバーを宛先として示す情報の署名情報とを含むことを特徴とする請求項１乃至５のいずれか一項に記載の情報処理システム。
7. 前記第一の認可サーバーは、
   前記認可レスポンスに対して前記署名情報を付与するための暗号鍵と、前記署名情報を検証するための復号鍵とを管理する第二の管理手段を更に有する請求項６に記載の情報処理システム。
8. クライアントとウェブブラウザと複数の認可サーバーと、を含む情報処理システムの制御方法であって、
   前記複数の認可サーバーは、
   前記クライアントがリソースサーバーにアクセスすることを、前記ウェブブラウザを介して許可するユーザーのユーザー情報を管理する第一の認可サーバーであって、前記複数の認可サーバーに含まれる第一の認可サーバーを特定する特定ステップを有し、
   前記複数の認可サーバーに含まれる認可サーバーは、
   前記クライアントから認可リクエストを受信したことに応じて、前記特定ステップによって前記第一の認可サーバーを特定し、特定された前記第一の認可サーバーに対し前記ユーザーを認証する認証リクエストをリダイレクトし、
   前記第一の認可サーバーは、
   リダイレクトされた前記認証リクエストを受信したことに応じて前記ユーザーを認証し、認証された前記ユーザーが前記アクセスを許可すると認可レスポンスとして認可トークンを前記クライアントに送信することを特徴とする情報処理システムの制御方法。

Images