JP6929181B2 - デバイスと、その制御方法とプログラム - Google Patents

Description

本発明は、認可サーバーの認可エンドポイントにアクセスするデバイスに関する。

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

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

また、その認可トークンをトークンプロバイダーが取得するために、トークンプロバイダーは認可サーバーに対して認可コード要求を送信する。認可コードとは、認可トークンを認可サーバーから取得するためのトークンであり、認可コード要求はその認可コードを取得するためのリクエストである。

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

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

ユーザー情報はある特定の地域（以下、リージョン）の認可サーバーで管理されている。そのユーザー情報が複数である場合、それらのユーザー情報が同じリージョンの認可サーバーで管理されているとは限らない。具体的には、アプリケーションが複数のリージョンで配布されワールドワイドで使用されている場合、アプリケーションを使用するユーザーのユーザー情報はそのユーザーがいるリージョンの認可サーバーで管理される。そしてユーザー情報が所在する認可サーバーで認可トークンが発行され、発行された認可トークンを検証して、リソースサーバーがアプリケーションにＷｅｂサービスを提供する。ユーザー情報の所在に応じた認可サーバーが認可トークンを発行する理由は、個人情報保護や安全保障等の観点から別のリージョンへのユーザー情報の移動や共有に制限が設けられている場合があるからである。

アプリケーションが複数のリージョンで利用することを想定する。その場合、そのアプリケーションはユーザー情報が所在するリージョンに関する情報（以下、リージョン情報）をトークンプロバイダーに送信する。トークンプロバイダーは受信したリージョン情報に基づいて、認可サーバーに対して認可コード要求を送信する。そのため、認可コード要求を送信する送信先である認可エンドポイントの選択肢が広がる。

トークンプロバイダーは、アプリケーションにより指定されたリージョン情報から認可エンドポイントを特定する必要がある。認可エンドポイントとは、各リージョンに存在する認可サーバーに認可コード要求を送信する送信先を指定するアドレスである。

本願発明は、アプリケーションから受信するリージョン情報に応じて、認可コード要求を送信するための適切な認可エンドポイントのＵＲＬをデバイスが特定することを目的とする。

デバイスによるリソースサーバーへのアクセスをユーザーが許可したことを示す認可トークンであって、前記認可トークンを取得するための認可コードを認可サーバーに発行させるための認可コード要求を、前記認可サーバーに送信する送信手段と、
前記認可コード要求に対応する認可コード応答を前記認可サーバーから受信する受信手段と、を有するデバイスであって、
前記デバイスは、
前記認可サーバーの所在するリージョンを特定する情報であるリージョン情報を取得する取得手段と、
前記取得手段によって取得されたリージョン情報に基づいて、前記認可コード要求の送信先である認可エンドポイントを特定する特定手段と、を更に有し、
前記送信手段は、特定された認可エンドポイントに対して前記認可コード要求を送信し、
前記受信手段は、前記送信手段によって送信された認可コード要求に対応する認可コード応答を受信することを特徴とする。

本願発明を用いることで、アプリケーションから受信するリージョン情報に応じて、認可コード要求を送信するための適切な認可エンドポイントのＵＲＬをデバイスが特定することができる。

本発明の実施形態に係る権限委譲システム。 各種装置のハードウェア構成図。 各種装置が有する機能。 ＯＡｕｔｈ２．０のＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔの処理フロー。 トークンプロバイダー４４０が有する機能。 トークンプロバイダー４４０の動作シーケンス。 実施例１における認可エンドポイント選択の動作を示したフローチャート。 実施例２における認可エンドポイント選択の動作を示したフローチャート。 Ｗｅｂブラウザー４１０、５１０におけるリージョンの入力画面の一例。 実施例１の処理、または実施例２の処理を実行する判定手段の一例。

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

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

認可サーバー２００、２０１はＯＡｕｔｈ ２．０を実現するためのサーバーであり、認証要求の受信や認可コードの発行、管理等の処理を行う。図１では、認可サーバー２００とリソースサーバー３００、認可サーバー２０１とリソースサーバー３０１がＬＡＮ１０１で接続されている形態を示しているが、ＷＡＮ１００を介して接続される構成も可能である。また、認可サーバー２００、２０１はＬＡＮ１０１を介して不図示のデータベースサーバーと接続されており、認可サーバー２００、２０１が自身の機能を実現する際に用いるデータをそのデータベースサーバーに格納するように構成してもよい。図１では認可サーバー２００とリソースサーバー３００、認可サーバー２０１とリソースサーバー３０１をそれぞれ別のサーバーであるものとして説明しているが、同一のサーバー上に両サーバーの機能が構成されている形態でもよい。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

このログインコンテキストはアプリケーション４２０と認証部４３０とトークンプロバイダー４４０で共有される。尚、ログインコンテキストにはローカルユーザー情報のみならず、ローカルユーザー情報に紐付くユーザー情報が所在するリージョン情報も含む形態でもよい。その場合、デバイス４００においてログインコンテキストが生成された際に、アプリケーション４２０と認証部４３０とトークンプロバイダー４４０とでリージョン情報も共有される。共有されたリージョン情報とローカルユーザー情報とに基づいて、認可コード要求を送信する送信先の認可エンドポイントをトークンプロバイダー４４０が特定してもよい。

本実施例ではデバイス４００へのログイン処理についてユーザーが直接デバイス４００を操作してログインする形態で説明するが、Ｗｅｂブラウザー５１０を介してリモートでログインする形態でもよい。その場合、認証部４３０は不図示のログイン画面をＷｅｂブラウザー５１０に応答する。ユーザーはそのログイン画面にローカルユーザーＩＤとローカルユーザーパスワードを入力することでユーザーは認証される。その際、認証部４３０で生成されたログインコンテキストは、アプリケーション４２０と認証部４３０とトークンプロバイダー４４０で共有される。

次に図４を用いてデバイス４００が有するトークンプロバイダーが提供するＯＡｕｔｈ ２．０の処理について、認可サーバー２００、２０１と、リソースサーバー３００、３０１、デバイス４００と、Ｗｅｂブラウザー５１０とを用いて説明する。尚、図４では認可サーバー２０１を例に説明するが、認可サーバー２００の場合でも同様である。本実施例では、トークンプロバイダー４４０が提供する認証認可技術としてＯＡｕｔｈ ２．０を例に説明するが、認可トークンを発行する形態であればＯＡｕｔｈ ２．０以外の形態でもよい。また、図４の後述の説明において、デバイス４００が主体となっている処理は、特に断りがない限りトークンプロバイダー４４０である。

ＯＡｕｔｈ ２．０を実行するための事前操作として、認可サーバー２０１にデバイス４００を登録するための登録要求を行う（Ｓ０．０）。具体的には、デバイス４００の登録要求は認可サーバー２０１の登録エンドポイント（図４ではエンドポイントを「ＥＰ」と記載）に対して送信され、デバイス４００の起動時か、または後述のＳ１．１の認可フローの開始時にデバイス４００が未登録であった場合に開始される。登録要求の方法としては、デバイス４００が能動的に認可サーバー２０１と通信する方法や、ユーザーがＷｅｂブラウザー５１０を介して認可サーバー２０１にアクセスしてデバイス４００を登録する方法が挙げられる。

Ｓ０．０の登録要求には、後述の認可確認画面に表示するためのデバイス名、説明、アイコン画像、および必須パラメーターであるリダイレクトＵＲＩが含まれる。リダイレクトＵＲＩとは、デバイス４００が認可コード応答を送信する送信先を指定するアドレスである。認可コード応答については後述する。デバイス４００の登録要求を受信した認可サーバー２０１はデバイス４００を識別するためのデバイスＩＤと、デバイス４００を認証するための秘匿情報であるデバイスシークレットとを発行し、デバイス４００の登録応答としてデバイス４００に送信する（Ｓ０．１）。認可サーバー２０１は、Ｓ０．１でデバイスＩＤとデバイスシークレットと、Ｓ０．０で受信した各種情報およびリダイレクトＵＲＩとを紐づけて保持する。デバイス４００は、Ｓ０．１で受信したデバイスＩＤとシークレットを保持する。以上がＯＡｕｔｈ ２．０を実行する事前操作であるデバイス４００の登録フローである。

次に、認可サーバー２０１においてユーザーを認証するためのフローを、図４を用いて説明する。ユーザーはデバイス４００にログインする（Ｓ１．０）。デバイス４００の認証部４３０は、ログインしたユーザーを特定するための情報であるログインコンテキストを生成し保持する。生成されたログインコンテキストからログインしたユーザーを特定する情報（ローカルユーザーＩＤ等）を取得する事ができる。ユーザーがＷｅｂブラウザー５１０を介して認可開始のＵＲＩにアクセスすることで、ＯＡｕｔｈ ２．０の認可フローを開始する（Ｓ１．１）。デバイス４００は認可フローを開始するための認可開始ＵＲＩにアクセスされると、認可サーバー２０１の認可エンドポイントに対して認可コード要求を送信する（Ｓ１．２）。認可コード要求には、デバイスＩＤ、リダイレクトＵＲＩ、ｓｔａｔｅパラメーターを含む。

ｓｔａｔｅパラメーターは認可コード要求と認可コード応答とを一意に紐づけるための情報であり、ＣＳＲＦ（ｃｒｏｓｓ−ｓｉｔｅ ｒｅｑｕｅｓｔ ｆｏｒｇｅｒｙ）攻撃や、トークン置換（以下、認可コード置換）攻撃を防ぐために用いられる。そのため、ｓｔａｔｅパラメーターは推測不可能でかつ重複しない値である必要がある。後述の認可コード応答でデバイス４００が受信するｓｔａｔｅパラメーターとＳ１．２の認可コード要求で送信したｓｔａｔｅパラメーターとの一致を検証し、さらに認可コード要求を実行したユーザーを識別するために、デバイス４００で発行されるｓｔａｔｅパラメーターはリダイレクトＵＲＩとログインコンテキストとが紐付いてデバイス４００で管理される。

Ｓ１．２で認可コード要求を受信した認可サーバー２０１は、ユーザーが認可サーバー２０１にログインしていなかった場合、Ｗｅｂブラウザー５１０にユーザーを認証するためのログイン画面を応答する（Ｓ１．３）。ユーザーは、Ｗｅｂブラウザー５１０を介してユーザーＩＤとパスワードを入力し、認可サーバー２０１に対して認証要求を行う（Ｓ１．４）。認証要求を受信した認可サーバー２０１は、Ｓ１．４で受信したユーザーＩＤとパスワードとの紐付け情報が事前に登録されている紐付け情報と一致するかを検証し、一致する場合は認証トークンを発行する。発行された認証トークンはＷｅｂブラウザー５１０のＣｏｏｋｉｅに応答される。

認可サーバー２０１はユーザーに対して、デバイス４００の認可を同意するための認可確認画面をＷｅｂブラウザー５１０に応答する（Ｓ１．５）。ただし、Ｓ１．２で受信したデバイスＩＤとリダイレクトＵＲＩとの組み合わせが、認可サーバー２０１に予め登録されたデバイスＩＤとリダイレクトＵＲＩとの組み合わせと一致しない場合は、Ｗｅｂブラウザー５１０にエラー画面を応答する。これにより、不正なＵＲＩへのリダイレクト（転送）を防ぐことができる。また、認可サーバー２０１ログインしているユーザーが既に同一のデバイスＩＤで認可操作済みであった場合はＳ１．５を省略する事もできる。

ユーザーによる認可操作（Ｓ１．６）の後、認可サーバー２０１は認可コードを発行し、デバイス４００に対して認可コード応答として認可コードとｓｔａｔｅパラメーターを送信する（Ｓ１．７）。具体的には、認可コードとｓｔａｔｅパラメーターとをリダイレクトＵＲＩにクエリパラメーターとして付与し、リダイレクトＵＲＩで指定された宛先に認可コードとｓｔａｔｅパラメーターとをリダイレクトするようにＷｅｂブラウザー５１０に送信する。Ｓ１．７で発行された認可コードは、認可サーバー２０１においてデバイスＩＤ、ユーザーＩＤ、リダイレクトＵＲＬと紐づけて保存される。

リダイレクトＵＲＩに対して認可コード応答を受信したデバイス４００は、認可コード応答に含まれるｓｔａｔｅパラメーターと、デバイス４００が管理するｓｔａｔｅパラメーターとが一致するかを検証する。検証の結果、ｓｔａｔｅパラメーターが一致した場合、デバイス４００は認可サーバー２０１のトークンエンドポイントに対して、デバイス４００が認可トークンを取得するためのトークン要求を送信する（Ｓ２．０）。トークン要求にはデバイスＩＤ、シークレット、Ｓ１．７で取得した認可コード、および、Ｓ１．２で受信したリダイレクトＵＲＩが含まれる。

Ｓ２．０でトークン要求を受信した認可サーバー２０１は、デバイスＩＤとシークレットの組み合わせが予め登録された組み合わせと一致するかを検証する。検証の結果、一致が確認されるとデバイス４００が認証される。さらに認可サーバー２０１は、Ｓ２．０で受信した認可コードを保持しているか、保持している場合にはその認可コードは有効期限内か、認可トークンと紐づいたデバイスＩＤとリダイレクトＵＲＩがＳ２．０のトークン要求で受信したものと一致するか、を検証する。この検証により、Ｓ１．２の認可コード要求を送信したデバイス４００とＳ２．０のトークン要求を送信したデバイス４００とが一致するかを認可サーバー２０１で検証する事ができる。

検証が成功した場合、認可サーバー２０１はデバイス４００に対して認可トークンを発行し、トークン応答としてデバイス４００に応答する（Ｓ２．１）。その際、認可トークンを再取得するためのリフレッシュトークンもデバイス４００に対して発行し、トークン応答として応答する事もできる。デバイス４００は、Ｓ２．１で受信した認可トークンを用いてリソースサーバー３０１が公開するＡＰＩにアクセスすることが可能となる。また、認可トークンを発行した後に、認可サーバー２０１で管理する認可コードを破棄することでリプレイ攻撃を防ぐことが可能となる。

Ｓ２．１のトークン応答にリフレッシュトークンが含まれる場合、デバイス４００においてログインコンテキストとリフレッシュトークンとが紐付けて管理される。それにより、次回以降のＡＰＩへのアクセス時に認可操作（Ｓ１．２〜Ｓ１．７）を実施せずに認可トークンを再度取得する事ができる。具体的には、Ｓ１．１の認可開始を受けた際に、デバイス４００においてユーザーのログインコンテキストとリフレッシュトークンとが紐付いているかを確認する。紐づいていない場合は前述のＯＡｕｔｈ ２．０のフロー（Ｓ１．２以降の処理）を実施する。紐づいている場合は、認可サーバー２０１のトークンエンドポイントに対してリフレッシュ要求を行う（Ｓ２．２）。

リフレッシュ要求はデバイスＩＤ、シークレット、およびリフレッシュトークンを含む。リフレッシュ要求を受信した認可サーバー２０１は、デバイスＩＤ、シークレットの組み合わせがＳ０．１で事前登録されたものと一致するかを検証する。一致が確認されデバイス４００が認証されると、受信したリフレッシュトークンが認可サーバー２０１で保持されているか、保持されている場合はそのリフレッシュトークンは有効期限内か、さらにリフレッシュトークンに紐づいたデバイスＩＤがリフレッシュ要求のものと一致するかを検証する。これらの検証が全て成功した場合、認可サーバー２０１は認可トークンを発行し、デバイス４００にトークン応答として認可トークンを送信する。その際、認可トークンを再取得するために新たなリフレッシュトークンを再発行し、トークン応答と同時にデバイス４００に対して送信する形態も可能である。また、認可サーバー２０１において新たなリフレッシュトークンを発行した後に、認可サーバー２０１でそれまで管理されていたリフレッシュトークンを破棄する事でリプレイ攻撃を防ぐことができる。

以上がＯＡｕｔｈ ２．０におけるＡｕｔｈｏｒｉｚａｔｉｏｎ Ｃｏｄｅ Ｇｒａｎｔの処理フローである。ＯＡｕｔｈ ２．０による処理フローにより、認可サーバー２０１が管理するユーザー情報をデバイス４００に送信する代わりに、認可サーバー２０１が認可トークンを発行し、デバイス４００は発行された認可トークンを用いてリソースサーバー３０１が公開するＡＰＩにアクセスすることができる。

［実施例１］
ユーザー情報はある特定のリージョンの認可サーバーに登録されており、複数のユーザー情報が同じリージョンの認可サーバーで管理されているとは限らない。また、個人情報保護、安全保障等の観点から異なるリージョン間でのユーザー情報の移動や共有が制限される場合がある。

その場合、トークンプロバイダー４４０は複数の認可サーバーの中からアプリケーション４２０が指定したリージョンに対応した認可サーバーを選択し、その認可サーバーに認可コード要求を送信する必要がある。実施例１では、ユーザー情報を管理する認可サーバーをトークンプロバイダー４４０が特定し選択する形態を説明する。

まず、図５を用いて、トークンプロバイダー４４０が有する機能を説明する。トークンプロバイダー４４０は、エンドポイント選択部６１０、トークン取得部６２０、トークン管理部６３０、トークン配布部６４０を有する。

エンドポイント選択部６１０は、ＯＡｕｔｈ ２．０の認可フローにおいて認可サーバー２００、２０１の認可エンドポイントに対する認可コード要求（図４のＳ１．２）を送信する機能である。その際、エンドポイント選択部６１０は、エンドポイント選択部６１０が有するリージョン情報と認可エンドポイントＵＲＬの対応表を用いて、アプリケーション４２０から指定されたリージョンに応じた認可エンドポイントＵＲＬを選択する。エンドポイント選択部６１０が有する対応表の一例を表１に示す。また、本実施例では、認可サーバー２００がリージョン「ＪＰ」に所在し、認可サーバー２０１がリージョン「ＥＵ」に所在するものとする。また、表１に認可エンドポイントが含まれるリージョン「ＧＢ」の認可サーバーは、図１では不図示である。

表１は、「Ｎｏ．」（項目番号）、「リージョン」、「認可エンドポイントＵＲＬ」、「トークンエンドポイントＵＲＬ」のカラムを有し、リージョンを主キーとする。本実施例では「リージョン」として「ＪＰ」と「ＥＵ」が登録され、各リージョンに対して認可エンドポイントＵＲＬとトークンエンドポイントＵＲＬが関連付いて登録されている。表１へのデータ登録は外部のアプリケーション等から実行しても良く、登録の形態は問わない。

トークン取得部６２０はトークンエンドポイントに対してトークン要求（Ｓ２．０）を送信する機能である。トークン取得部６２０は表１を参照して、アプリケーション４２０から指定されたリージョンに対応したトークンエンドポイントにトークン要求を送信する。

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

表２は、「Ｎｏ」、「ローカルユーザーＩＤ」、「リージョン」、「認可トークン」、「リフレッシュトークン」のカラムを有し、ローカルユーザーＩＤとリージョンを主キーとする。リフレッシュトークンは上記で説明した通り、ＯＡｕｔｈ２．０ ＲＦＣ６７４９、６． Ｒｅｆｒｅｓｈｉｎｇ ａｎ Ａｃｃｅｓｓ Ｔｏｋｅｎにある、同じ認可フローを再度使用するための新しいアクセストークンである。表２のテーブルは、図４で示した認可フロー（Ｓ１．０〜Ｓ２．２）が実行されたことで生成され、トークン管理部６３０が管理する。

また、表２では、一つのローカルユーザーＩＤ「Ｌｏｃａｌ＿ｕｓｅｒ１」に対して、複数のリージョン「ＪＰ」と「ＥＵ」が紐付いている。つまり、一つのローカルユーザーＩＤに対して紐付いている複数のユーザー情報がリージョン「ＪＰ」の認可サーバー２００と、リージョン「ＥＵ」の認可サーバー２０１とに格納されていることになる。その場合、ユーザーがアプリケーション４２０においてリージョンを「ＪＰ」または「ＥＵ」に切り替えることで、認可トークンの要求先の認可サーバーを切り替えるものとするが、そのアプリケーション４２０の形態は問わない。

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

表２において、受信したローカルユーザーＩＤとアプリケーション４２０が指定したリージョン情報との組合せが存在しない場合、認可フロー（図４）がまだ実行されていないものと見なされる。そして、エンドポイント選択部６１０は指定されたリージョン情報と表１とを用いてリージョンの認可エンドポイントＵＲＬを特定し、認可エンドポイントＵＲＬで特定される認可サーバー２００から認可トークンとリフレッシュトークンとを取得し、ローカルユーザーＩＤとリージョン情報と共に、トークン管理部６３０（表２）に格納する。以上が、トークンプロバイダー４４０が有する機能である。

次に図６を用いて、アプリケーション４２０がトークンプロバイダー４４０を介して、認可サーバー２００から認可トークンを取得し、取得した認可トークンを用いてリソースサーバー３００、３０１が公開するＡＰＩを実行するまでの処理を説明する。尚、図６の説明において、認可サーバー２００とリソースサーバー３００を用いて説明するが、認可サーバー２０１とリソースサーバー３０１とでも同様の処理が実行される。また、上記で説明済みの処理については、詳細な説明を省略する。

まず、アプリケーション４２０はトークンプロバイダー４４０に対して認可トークン要求を送信する（Ｓ７．１）。具体的には、アプリケーション４２０が認可トークン要求として、ローカルユーザーＩＤとリージョン情報とを送信する。アプリケーション４２０がリージョン情報を取得する形態はいくつか考えられる。例えば、デバイス４００のＷｅｂブラウザー４１０を介して、ユーザーからローカルユーザーＩＤとパスワードを入力する際に、ユーザーがリージョン情報を入力または選択する形態が考えられる。図９にリージョンを選択する画面の一例を示す。図９では、ローカルユーザーＩＤの入力欄として「ユーザーＩＤ」、パスワードの入力欄として「パスワード」、リージョンをプルダウンで選択できる欄として「リージョン」が設けられている。

または、ユーザーによるデバイス４００へのログイン操作の際に生成されたログインコンテキストに、リージョン情報が含まれているかどうかをアプリケーション４２０が判定する形態も考えられる。含まれていると判定された場合は、上記でも説明した通り、ログインコンテキストに含まれるリージョン情報に基づいて、認可エンドポイントを特定する。含まれていないと判定された場合は、Ｗｅｂブラウザー４１０、５１０を介して、ユーザーにリージョンを入力または選択させる画面を提供する。

それ以外の形態で、予めアプリケーション４２０またはＷｅｂブラウザー４１０等に設定されたユーザーの使用言語の情報に基づいて、特定されたリージョン情報をアプリケーション４２０がトークンプロバイダー４４０に送信する形態等も考えられる。

トークンプロバイダー４４０はＳ７．１で受信したローカルユーザーＩＤとリージョン情報から、トークンプロバイダー４４０のトークン管理部６３０が有するトークンデータベース（表２）を用いて、受信したローカルユーザーＩＤとリージョン情報との紐付け情報と一致するレコードを検索する。ローカルユーザーＩＤとリージョン情報との紐付け情報と合致するレコードが存在した場合、ローカルユーザーＩＤとリージョン情報とに紐付く認可トークンをアプリケーション４２０に送信する（Ｓ７．６）。

一致するレコードが存在しなかった場合、トークンプロバイダー４４０は、認可トークン要求で受信したリージョン情報と表１から認可エンドポイントＵＲＬを特定する。特定された認可エンドポイントＵＲＬを用いて図４のＳ１．３〜Ｓ２．１で示した処理を実行して認可サーバー２００から認可トークンを取得する。

Ｓ７．１で認可トークン要求を受信したトークンプロバイダー４４０は、認可サーバー部２１０に認可コード要求を送信する（Ｓ７．２）。Ｓ７．２は図１のＳ１．２と同様の処理であるため、詳細な説明は省略する。認可コード要求を受信した認可サーバー部２１０は、図１のＳ１．３〜Ｓ１．６の処理を実行した後、認可コードをトークンプロバイダー４４０に送信する（Ｓ７．３）。Ｓ７．３は図１のＳ１．７と同様の処理であるため、詳細な説明は省略する。

Ｓ７．３で認可コード応答を受信したトークンプロバイダー４４０は、認可サーバー２００のトークンエンドポイントにトークン要求を送信する（Ｓ７．４）。Ｓ７．４の処理は図１のＳ２．０の処理に相当するので詳細な説明は省略する。トークン要求を受信した認可サーバー部２１０は、トークン応答として認可トークンとリフレッシュトークンとをトークンプロバイダー４４０に送信する（Ｓ７．５）。Ｓ７．５の処理は図１のＳ２．１の処理に相当するので詳細な説明は省略する。

Ｓ７．５の実行後、トークンプロバイダー４４０は、Ｓ７．５で取得した認可トークンとリフレッシュトークンと、Ｓ７．１でアプリケーション４２０から取得したローカルユーザーＩＤとリージョン情報とを、トークンデータベース（表２）に登録する。

Ｓ７．５でトークン応答を受信した後、トークン配布部６４０はアプリケーション４２０に対し、Ｓ７．５で取得した認可トークンを送信する（Ｓ７．６）。認可トークンを取得したアプリケーション４２０は、認可トークンを用いてリソースサーバー部３１０に対してリソース要求を送信する（Ｓ７．７）。以上が、アプリケーション４２０がトークンプロバイダー４４０を用いて、認可サーバー２００から認可トークンを取得し、取得した認可トークンを用いてリソースサーバー３００、３０１が公開するＡＰＩを実行するまでの処理である。

次に、図７を用いて、トークンプロバイダー４４０が認可トークンを取得する際の認可エンドポイントの選択処理を説明する。

まず、トークン配布部６４０は、アプリケーション４２０から認可トークン要求としてローカルユーザーＩＤとリージョン情報を受信する（Ｓ８．１）。今回は、ローカルユーザーＩＤ「Ｌｏｃａｌ＿ｕｓｅｒ２」とリージョン情報「ＪＰ」を認可トークン要求としてトークン配布部６４０が受信したものとして説明する。

トークン管理部６３０はトークンデータベース（表２）を用いて、受信したローカルユーザーＩＤと一致するレコードがないかを確認する（Ｓ８．２）。表２より、予め保存されているレコードと、ローカルユーザーＩＤとリージョン情報との紐付け情報が一致しないことがわかる。一致するレコードがあることが確認されると、そのレコードに含まれる認可トークンをアプリケーション４２０に送信する（Ｓ８．１０）。

レコードがないことが確認されると、エンドポイント選択部６１０は、Ｓ８．１で指定されたリージョンに基づいて、認可エンドポイントＵＲＬを特定するための判定を行う（Ｓ８．３）。具体的には、エンドポイント選択部６１０はエンドポイントＵＲＬデータベース（表１）に基づいて、指定されたリージョン「ＪＰ」と合致する認可エンドポイントを取得し設定する（Ｓ８．４）。今回、認可エンドポイントＵＲＬとして取得したＵＲＬは、表１より「ｈｔｔｐｓ：／／ｊｐ．ｅｘａｍｐｌｅ．ｃｏｍ／ｏａｕｔｈ２／ａｕｔｈｏｒｉｚｅ」である。Ｓ８．１の認可トークン要求で受信するリージョン情報に応じて、Ｓ８．４〜Ｓ８．７のいずれかの処理が実行される。アプリケーション４２０によってリージョンが指定されなかった場合、あるいは指定されたリージョンが表１に含まれていない場合はデフォルトとしてリージョンが「ＧＢ」であるものとしてＳ８．７の処理を実行する。ただし、リージョン「ＧＢ」に所在する認可サーバーは、認可サーバー２００、２０１以外の認可サーバー（図１では不図示）のことである。

トークン取得部６２０は、Ｓ８．４〜Ｓ８．７で特定された認可エンドポイントＵＲＬに対して認可コード要求を送信する（Ｓ８．８）。Ｓ８．８は、図４のＳ１．２（あるいは図６のＳ７．２）に相当する。Ｓ８．８の処理の結果、取得した認可コードを用いて、認可サーバー２００にトークン要求を送信する（Ｓ８．９）。Ｓ８．９は、図４のＳ２．０（あるいは図６のＳ７．４）に相当する。Ｓ８．９の処理の結果、取得した認可トークンをアプリケーション４２０に送信する（Ｓ８．１０）。以上が、トークンプロバイダー４４０が認可トークンを取得する際の認可エンドポイントの選択処理である。

本実施例により、アプリケーション４２０からリージョンを指定された際に、トークンプロバイダー４４０が適切な認可エンドポイントを選択し、指定されたリージョン情報に応じた認可サーバーに対して認可コード要求を送信することができる。

また、本実施例ではアプリケーション４２０からローカルユーザーＩＤを取得する形態で説明したが、Ｓ１．０（図４）でユーザーがデバイス４００にログインした際に認証部４３０で生成されたログインコンテキストから、ローカルユーザーＩＤを特定する形態でもよい。

［実施例２］
実施例１では、個人情報保護、安全保障等の観点から異なる間でのユーザー情報の移動や共有が制限される場合を考慮して、アプリケーション４２０がトークンプロバイダー４４０に対してリージョンを指定する形態を示した。しかし、アプリケーション４２０がリージョンを指定する形態以外にも、予めトークンプロバイダー４４０において固定のリージョンが設定されている形態もある。

実施例２では、認可コードの取得先であるリージョンが固定で設定されているか否かの判定結果に応じて、固定のリージョン情報で特定される認可サーバーに認可コード要求を送信するか、または実施例１の形態を実行するかに切り替える形態を説明する。尚、実施例２で説明を省略した部分は実施例１と同様である。

まず、図８を用いて、トークンプロバイダー４４０が認可サーバーに認可コード要求を送信する処理を説明する。トークン配布部６４０は、アプリケーション４２０から認可トークン要求としてリージョン情報を受信する（Ｓ９．１）。

エンドポイント選択部６１０は、Ｓ９．１で受信したリージョン情報は使用せず、デバイス４００の設置場所に基づいて認可エンドポイントＵＲＬを特定する。具体的にトークンプロバイダー４４０は、デバイス４００のＮＣ２００８に設定されたＩＰアドレスから国コード（ＩＣＡＮＮなどで使用されているｃｃＴＬＤにおける国コード）を取得する（Ｓ９．２）。国コードの取得は、エンドポイント選択部６１０がＩＰアドレスから国コードを特定できるｍａｘｍｉｎｄ社の提供するＧｅｏＩＰデータベースを検索することで実行される。ＧｅｏＩＰデータベースを検索する形態以外にも、デバイス４００のロケール情報に設定された国情報を設置場所の国コードとして取得しても良い。今回は、デバイス４００の設置場所から国コードが「ＦＲ」であるものとする。

エンドポイント選択部６１０はＳ９．２で取得した国コードが、トークンプロバイダー４４０に設定されているリージョン情報と一致するかを判定する（Ｓ９．３）。エンドポイント選択部６１０が有する固定リージョン判定テーブルに基づいて実行される。固定リージョン判定テーブルの一例を表３に示す。

表３は、「Ｎｏ．」（項目番号）、「固定リージョン」、「国コード」（ＩＣＡＮＮなどで使用されているｃｃＴＬＤにおける国コード）のカラムを有するテーブルである。「固定リージョン」は、「国コード」に対してトークンプロバイダー４４０が設定すべきリージョンのことである。エンドポイント選択部６１０は、Ｓ９．２で取得した国コードに対して固定リージョンが存在するかを、固定リージョン判定テーブル（表３）より判定する。存在しない場合はＳ９．８に進み、アプリケーション４２０から指定されたリージョンから認可エンドポイントＵＲＬを取得し設定する（Ｓ９．９〜Ｓ９．１２）。Ｓ９．８とそれ以降の処理（Ｓ９．９〜Ｓ９．１２）は、実施例１の処理内容（図７のＳ８．３〜Ｓ８．７）と同様なので、詳細な説明は省略する。

本実施例では、Ｓ９．２で取得した国コードに対して、表３の固定リージョン判定テーブルに固定リージョン情報が存在するか否かで実施例１の処理に切り替えるか否かを判定したが、その判定方法には限定されない。例えば、トークン配布部６４０がアプリケーション４２０から認可トークン要求を受信した後に、エンドポイント選択部６１０が固定リージョン判定テーブルを有するかどうかを判定（図１０のＳ１０．１）する形態も考えられる。この判定手段は、Ｓ８．１（またはＳ９．１）の処理より前に実行されても良い。Ｓ１０．１で表３が存在すると判定された場合は、実施例２（図８）のＳ９．２以降の処理に進む。Ｓ１０．１で表３が存在しないと判定された場合は、実施例１（図８）のＳ８．２以降の処理に進む。

Ｓ９．３で取得した国コードに対して固定リージョンが存在することを表３で確認された場合、固定リージョン情報とアプリケーション４２０から受信したリージョン情報とを比較する（Ｓ９．４）。比較して一致が確認された場合はＳ９．６に進み、一致が確認できなかった場合はＳ９．５に進む。今回は、Ｓ９．２で取得した国コードが「ＦＲ」なので、表３よりその固定リージョン「ＥＵ」が存在することがわかる。Ｓ９．１で取得したリージョン情報が「ＦＲ」であればＳ９．６に進む。

一方、Ｓ９．１で取得したリージョン情報が「ＣＮ」であれば、トークンプロバイダー４４０の固定リージョン「ＦＲ」と一致しないため、Ｓ９．５に進む。具体的には、トークンプロバイダー４４０はアプリケーション４２０に対してエラー情報を送信する（Ｓ９．５）。エラー情報には、トークンプロバイダー４４０に対して固定で設定された固定リージョン情報と、取得した国コードに基づいて特定されたリージョン情報が一致しなかった旨を含めてもいいが、エラー情報の形態は特に問わない。

Ｓ９．４で一致すると判定された場合、エンドポイント選択部６１０は取得した国コードまたは固定リージョン情報と、エンドポイントＵＲＬデータベース（表１）とを用いて、認可エンドポイントを特定する（Ｓ９．６）。

Ｓ９．６またはＳ９．９〜Ｓ９．１２で認可エンドポイントＵＲＬが特定された後、トークン取得部６２０は、特定された認可エンドポイントＵＲＬに対して認可コード要求を送信する（Ｓ９．７）。

以上が、トークンプロバイダー４４０が認可トークンを取得する際の認可エンドポイントを固定する処理である。

［その他の実施例］
上記の実施例において、リージョン情報が「ＪＰ」と「ＥＵ」（デフォルトのリージョン情報を「ＧＢ」）であるものとして説明したが、リージョン情報の種類やその数は上記で挙げた例に限定されない。

また、上記のフローにおいて、アプリケーション４２０によってリージョンが指定されなかった場合、あるいは指定されたリージョンが表１に含まれていない場合は、デフォルトとして設定されているリージョン情報を用いて処理を進める形態を説明したが、エラー情報を送信して処理を終了する形態でもよい。

上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

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

Claims (14)

1. デバイスによるリソースサーバーへのアクセスをユーザーが許可したことを示す認可トークンであって、前記認可トークンを取得するための認可コードを認可サーバーに発行させるための認可コード要求を、前記認可サーバーに送信する送信手段と、
   前記認可コード要求に対応する認可コード応答を前記認可サーバーから受信する受信手段と、を有するデバイスであって、
   前記デバイスは、
   前記認可サーバーの所在するリージョンを特定する情報であるリージョン情報を取得する取得手段と、
   前記取得手段によって取得されたリージョン情報に基づいて、前記認可コード要求の送信先である認可エンドポイントを特定する特定手段と、を更に有し、
   前記送信手段は、特定された認可エンドポイントに対して前記認可コード要求を送信し、
   前記受信手段は、前記送信手段によって送信された認可コード要求に対応する認可コード応答を受信することを特徴とするデバイス。
2. 前記デバイスは、
   少なくともトークンプロバイダーとアプリケーションとを有し、
   前記トークンプロバイダーは、
   前記取得手段によって前記アプリケーションから前記リージョン情報を取得することを特徴とする請求項１に記載のデバイス。
3. 前記トークンプロバイダーは、
   前記リージョン情報と前記認可エンドポイントとの紐付け情報を有し、
   前記紐付け情報に基づいて、前記認可コード要求を送信するための前記認可エンドポイントを特定する請求項２に記載のデバイス。
4. 前記デバイスが前記リソースサーバーにアクセスするための認可トークンを発行するトークン要求を、前記認可コード応答で受信した前記認可コードとともに前記認可サーバーに送信し、
   送信されたトークン要求に応じて、前記認可トークンを前記認可サーバーから取得する請求項３に記載のデバイス。
5. 前記トークンプロバイダーが有する前記リージョン情報と前記認可エンドポイントとの紐付け情報は、
   前記トークン要求を送信する送信先であるトークンエンドポイントを含み、
   前記トークンエンドポイントに対して前記認可コードとともに前記トークン要求を送信する請求項４に記載のデバイス。
6. 前記トークンプロバイダーは、
   前記ユーザーが許可したことによって、前記デバイスが前記リソースサーバーにアクセスできるように処理する認可フローが実行されたことにより、
   前記アプリケーションにログインしているローカルユーザーを特定する情報であるローカルユーザーＩＤと、前記トークン要求で取得した認可トークンと、前記認可トークンを発行した認可サーバーの所在するリージョンを特定するリージョン情報との紐付け情報で管理し、
   前記アプリケーションから受信した前記リージョン情報とローカルユーザーＩＤが、前記紐付け情報が有する前記リージョン情報とローカルユーザーＩＤと一致するかを判定する判定手段を有し、
   前記判定手段によって一致することが確認された場合は、前記紐付け情報で特定される認可トークンを用いて、前記リソースサーバーが公開するＷｅｂサービスを前記デバイスが利用するためのリソース要求を前記リソースサーバーに送信し、
   前記判定手段によって一致しないことが確認された場合は、前記リージョン情報と前記認可エンドポイントとの紐付け情報と、前記アプリケーションから受信したリージョン情報で特定された認可エンドポイントとを用いて、前記認可サーバーに前記認可コード要求を送信する請求項２乃至５のいずれか一項に記載のデバイス。
7. 前記アプリケーションから受信したリージョン情報が前記紐付け情報に含まれていない場合、または前記アプリケーションからリージョン情報を取得できない場合、
   デフォルトとして設定されたリージョン情報と前記紐付け情報とで特定された認可エンドポイントを用いて、前記認可サーバーに前記認可コード要求を送信する請求項６に記載のデバイス。
8. 前記トークンプロバイダーが、
   前記アプリケーションから受信するリージョン情報に依らずに予め設定されたリージョン情報である固定リージョン情報を有する場合、
   前記アプリケーションから受信したリージョン情報と前記固定リージョン情報とが一致するかを判定し、
   一致すると判定された場合は、前記固定リージョン情報と、前記リージョン情報と前記認可エンドポイントとの紐付け情報とに基づいて前記認可エンドポイントを取得し、取得された認可エンドポイントに対して前記認可コード要求を送信し、
   一致しないと判定された場合は、前記アプリケーションに対してエラー情報を送信する請求項２乃至７のいずれか一つに記載のデバイス。
9. 前記固定リージョン情報は、
   前記デバイスの所在するリージョンを特定する国コードを前記デバイスのＩＰアドレスから取得し、取得された国コードに対して紐付いて管理されている請求項８に記載のデバイス。
10. 前記トークンプロバイダーは、
    前記固定リージョン情報を格納するテーブルである固定リージョン判定テーブルを有するかどうかを判定する第二の判定手段を有し、
    前記第二の判定手段によって前記トークンプロバイダーが有すると判定された場合は、
    前記固定リージョン判定テーブルに格納された固定リージョン情報に基づいて、前記認可エンドポイントを特定し、特定された認可エンドポイントに対して前記認可コード要求を送信し、
    前記第二の判定手段によって前記トークンプロバイダーが有さないと判定された場合は、
    前記アプリケーションから受信したリージョン情報に基づいて、前記認可エンドポイントを特定し、特定された認可エンドポイントに対して前記認可コード要求を送信する請求項８または９に記載のデバイス。
11. 前記リージョン情報は、
    前記ユーザーが前記デバイスにログインする際に指定したリージョン情報、または前記ユーザーが前記デバイスにおいて使用する言語に基づいて特定されたリージョン情報のいずれか一つである請求項１乃至１０のいずれか一つに記載のデバイス。
12. 前記デバイスは、
    前記デバイスに対してローカルユーザーがログインした際にログインコンテキストを生成し、
    前記ログインコンテキストに前記リージョン情報が含まれているかどうかを判定し、
    含まれていると判定された場合は、前記ログインコンテキストに含まれるリージョン情報に基づいて、前記認可コード要求を送信する送信先である認可エンドポイントを特定し、
    含まれていないと判定された場合は、前記ローカルユーザーに対して前記リージョン情報を要求するための入力画面を提供する請求項１乃至１０のいずれか一つに記載のデバイス。
13. コンピュータを、
    デバイスによるリソースサーバーへのアクセスをユーザーが許可したことを示す認可トークンであって、前記認可トークンを取得するための認可コードを認可サーバーに発行させるための認可コード要求を、前記認可サーバーに送信する送信手段と、
    前記認可コード要求に対応する認可コード応答を前記認可サーバーから受信する受信手段と、を有するデバイスとして機能させるためのプログラムであって、
    前記デバイスは、
    前記認可サーバーの所在するリージョンを特定する情報であるリージョン情報を取得する取得手段と、
    前記取得手段によって取得されたリージョン情報に基づいて、前記認可コード要求の送信先である認可エンドポイントを特定する特定手段と、を更に有し、
    前記送信手段は、特定された認可エンドポイントに対して前記認可コード要求を送信し、
    前記受信手段は、前記送信手段によって送信された認可コード要求に対応する認可コード応答を受信することを特徴とするデバイスとして機能させるためのプログラム。
14. デバイスによるリソースサーバーへのアクセスをユーザーが許可したことを示す認可トークンであって、前記認可トークンを取得するための認可コードを認可サーバーに発行させるための認可コード要求を、前記認可サーバーに送信する送信ステップと、
    前記認可コード要求に対応する認可コード応答を前記認可サーバーから受信する受信ステップと、を有するデバイスの制御方法であって、
    前記制御方法は、
    前記認可サーバーの所在するリージョンを特定する情報であるリージョン情報を取得する取得ステップと、
    前記取得ステップによって取得されたリージョン情報に基づいて、前記認可コード要求の送信先である認可エンドポイントを特定する特定ステップと、を更に有し、
    前記送信ステップは、特定された認可エンドポイントに対して前記認可コード要求を送信し、
    前記受信ステップは、前記送信ステップによって送信された認可コード要求に対応する認可コード応答を受信することを特徴とするデバイスの制御方法。

Images