JP2021082004A - 認可サーバー、システム、システムの方法、および認可サーバーのプログラム - Google Patents

Abstract

【課題】 クライアントの認可要求と認可操作が独立している構成において、ユーザーは再認可操作を行うことができる。【解決手段】 認可サーバーがユーザーからの認可結果を受信した後、再認可を行える期限を設け、期限がくるまで待ち処理を行いその後アクセストークンの発行を行う。【選択図】 図７

Description

本発明は、リソースにアクセスする権限が委譲されたことに応じてアクセストークンを発行する認可サーバー、システム、システムの方法、および認可サーバーのプログラムに関する。

ウェブシステムにおいてＯＡｕｔｈ２．０による権限委譲の仕組みが実現されている。特許文献１ではシステム連携を設定する際、ユーザーはクライアントと認可サーバーの両方をウェブブラウザで操作し、認可操作を行うことでユーザーの権限をクライアントに委譲することを開示している。クライアントは、委譲されたユーザーの権限を用いてユーザーのリソースにアクセスでき、システム連携が実現する。ＯＡｕｔｈ２．０でユーザーの権限をクライアントに委譲するためには、ユーザーがクライアントにウェブブラウザでアクセスすることが必要になる。

特許５６２３２３４号公報

従来の手法では、ユーザーがクライアントに権限委譲するための操作を行うことで権限委譲のフローが開始された。しかし、ＩｏＴデバイスの普及やスマートフォンのような携帯端末の普及により、クライアントが自律的に権限委譲の要求を行うと権限委譲のフローが開始され、ユーザーが物理的および／またはシステム的に離れたところで認可操作を行う形態が新たに考えられる。

しかしながら、この形態の場合、ユーザーは一度行った認可操作を訂正したくとも、クライアントの認可要求とユーザーの認可操作が独立してしまうためユーザー側から再認可操作を行うことができなくなる懸念がある。そこで、本願発明の目的は、クライアントの認可要求とユーザーの認可操作が独立している形態において、ユーザーは再認可操作を行うことが可能な仕組みを提供することにある。

本実施形態に係る認可サーバーは、ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、前記クライアントから認可開始リクエストを受信する受信手段と、前記受信手段により認可開始リクエストが受信されたことに応じて、認可確認リクエストの送信先となるユーザー端末を特定する特定手段と、特定されたユーザー端末に対して認可確認リクエストを送信し、応答として認可確認の結果を受信し、再認可が可能な期間まで前記認可確認の結果を一時的に記憶する認可手段と、再認可が可能な期間を超えたことに応じて一時的に記憶されている前記認可確認の結果に応じたアクセストークンの発行の制御を行い、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ前記アクセストークンを送信する発行手段と、を有することを特徴とする。

クライアントの認可要求とユーザーの認可操作が独立している形態において、ユーザーは再認可操作を行うことができる仕組みを提供する。

コンピュータの構成図 システムのネットワーク構成図 権限移譲システムの機能ブロック図 認可開始リクエストおよび認可確認リクエストフロー アクセストークン発行フロー 権限委譲システムのシーケンス図 権限委譲システムにおける再認可処理のシーケンス図 再認可処理に関するフローチャート 認可確認画面 認可履歴画面のフローチャート 実施例２における認可開始リクエストで送付される情報 実施例２における認可結果受信のフローチャート 実施例２におけるアクセストークンレスポンスフローチャート 実施例２における認可履歴描画のフローチャート

［実施例１］
以下、本発明を実施するための形態について図面を用いて説明する。図１は、本発明を実施するための一実施形態に係る情報処理装置の構成を示す図である。図１において、情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、通信インタフェース１０７を備えている。また、情報処理装置内の各構成要素はシステムバス１０１を介して互いに接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）から構成される。

記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３がある。図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなども使用されることがある。

本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭ（不図示）から読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。

ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置に対する動作指令等を行う。ポインティングデバイス１１６は、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。

通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等があり、有線であっても無線であっても構わない。また、通信インタフェース１０７は、ローカルプリンタ１１８などの他デバイスとの通信も行う。

図２は、本実施形態に係る権限移譲システムのネットワーク構成図である。図２に図示されるサーバー、クライアント、ユーザー端末はいずれも、図１で示した装置の構成を備えているものとする。ただし、図１の構成に限定するものではなく、他の機能を備えている場合や、単体のコンピュータに限らないラックマウント型のシステムであっても構わない。また、後述の全ての説明において、特に断りのない限りサーバーやクライアントの実行の主体はＣＰＵ１０２であり、ソフトウェア上の主体は記憶装置１０４に保管されたプログラムである。

図２において、コンピュータネットワーク２００には、認可サーバー２０１、リソースサーバー２０２、クライアント２０３、および、ユーザー端末２０４が接続されている。ユーザー端末２０４の形態としては、例えば、スマートフォンやタブレット端末等のような携帯可能なコンピュータや、クライアントパーソナルコンピュータ等がある。コンピュータネットワーク２００には、ＬＡＮ、ＷＡＮ、インターネット等があり、有線であっても無線であっても構わない。

本実施形態において、ユーザー端末２０４は、コンピュータネットワーク２００を通じて認可サーバー２０１と通信を行い、クライアント２０３はコンピュータネットワーク２００を通じて認可サーバー２０１やリソースサーバー２０２と通信を行う。ユーザー端末２０４は、データを受信するとＷｅｂブラウザあるいは専用のクライアントアプリケーションが取得したデータをクライアント端末のディスプレイ装置１１４に表示する。

図３は本実施の形態に係る権限移譲システムの機能ブロック図である。図３（Ａ）はクライアント２０３、図３（Ｂ）は認可サーバー２０１、図３（Ｃ）はリソースサーバー２０２、図３（Ｄ）はユーザー端末２０４の機能ブロックを示す。クライアント２０３は認可開始リクエスト発行部３３１、アクセストークン要求部３３３、アクセストークン管理部３３４、リソースアクセス部３３２を持つ。認可サーバー２０１は認可リクエスト管理部３１１、認可確認リクエスト送信先解決部３１２、認可確認部３１３、アクセストークン発行部３１４を持つ。リソースサーバー２０２はリソース管理部３２１を持つ。ユーザー端末２０４は認可操作受付部３４１、認可結果送信部３４２、認可履歴管理部３４３、画面表示部３４４を持つ。

認可サーバー２０１の認可リクエスト管理部３１１は、クライアント２０３の認可開始リクエスト発行部３３１の要求に従い、認可開始リクエストを処理する。ここで認可開始リクエストにはクライアント２０３がアクセスしようとするリソースのリソース情報、リソースに対して行う処理の種別、クライアント情報などが含まれる。認可確認リクエスト送信先解決部３１２は認可開始リクエストに含まれるリソース情報、処理種別、クライアント情報などを用いて、認可確認リクエストの送信先となるユーザー端末を決定する。認可確認部３１３は認可確認リクエスト送信先解決部３１２で決定されたユーザー端末２０４に対して認可確認リクエストを行う。ユーザー端末２０４を利用するユーザーが認可操作を行うと、クライアント２０３は認可サーバー２０１からアクセストークンを取得できるようになり、アクセストークンを使ってリソースサーバーにアクセスできるようになる。

ＯＡｕｔｈ２．０と同様、クライアント２０３は、実施例１のプロトコルフローを開始する以前に認可サーバー２０１に登録されていなければならない。クライアント２０３を認可サーバー２０１に登録させるため、認可サーバー２０１はクライアント２０３登録者との対話を伴うＨＴＭＬ登録フォーム（不図示）を提供する。また、本実施例のクライアント２０３の登録においては、クライアント２０３と認可サーバー２０１の間に直接的なやりとりは必須ではない。例えば、クライアント２０３自身あるいはサードパーティーが発行したアサーションの使用や、認可サーバー２０１のセキュアなチャネルを使用したクライアント２０３をディスカバリーで、クライアント２０３を認可サーバー２０１へ登録することもできる。

実施例１において認可サーバー２０１にクライアント２０３を登録する場合、クライアント２０３の登録者は、クライアントタイプ（ＯＡｕｔｈ２．０定義の“Ｃｏｎｆｉｄｅｎｔｉａｌ”）、アプリケーション名、サービス名、ロゴイメージ、利用規則を指定する。また登録の際、クライアント２０３に対して認可サーバー２０１はクライアント識別子とクライアントＳｅｃｒｅｔを発行する。クライアント２０３は発行されたクライアント識別子とクライアントＳｅｃｒｅｔを認可開始リクエスト発行部３３１に記憶しておく。

また、認可サーバー２０１は、クライアント２０３から受信した情報を認可確認リクエスト送信先解決部３１２内のクライアント登録テーブル（表１）に登録する。

さらに、ユーザー端末２０４は、実施例１のプロトコルフローを開始する以前に、認可サーバー２０１に登録されていなければならない。ユーザー端末２０４を認可サーバー２０１に登録させるため、認可サーバー２０１はユーザー端末２０４登録者との対話を伴うＨＴＭＬ登録フォーム（不図示）を提供する。

また、実施例１のユーザー端末２０４の登録において、ユーザー端末２０４と認可サーバー２０１の間に直接的なやりとりは必須ではない。例えば、ユーザー端末２０４が発行したアサーションを使用したり、認可サーバー２０１がセキュアなチャンネルを使用してユーザー端末２０４のディスカバリーを行ったりすることで、ユーザー端末２０４を登録することもできる。ユーザー端末は複数登録が可能である。

登録の際、ユーザー端末２０４に対して認可サーバー２０１は、各々端末ＩＤと端末Ｓｅｃｒｅｔを発行する。クライアント２０３は発行された端末ＩＤと端末Ｓｅｃｒｅｔを認可操作受付部３４１に記憶しておく。実施例１において、認可サーバー２０１にユーザー端末２０４を登録する場合、ユーザー端末２０４の登録者は以下の情報を指定する。ユーザー端末情報（後述の認可確認リクエストを通知する通信のエンドポイント）、サービス名、アプリケーション名（共にクライアント２０３の登録の際に指定したもの）、ユーザー識別子（ユーザー名）である。

ユーザー端末２０４登録の際に、登録内容は、図３（Ｂ）で示される認可サーバー２０１の認可確認リクエスト送信先解決部３１２内のユーザー端末登録テーブル（表２）に登録される。

実施例１において、ユーザー端末２０４の情報は、ユーザー端末情報“１９２．１６８．０．１”、端末ＩＤ“Ｄｅｖｉｃｅ＿１”、端末Ｓｅｃｒｅｔ“ｗｗｗｗｗｗ”、クライアント識別子“Ｃｌｉｅｎｔ＿１”、アプリケーション名“Ａｐｐ＿１”、サービス名“Ｓｅｒｖ＿１”、ユーザー識別子“ｕｓｅｒ＿Ａ”である。また、表２には別のユーザー端末として、ユーザー端末情報“１９２．１６８．０．２”、端末ＩＤ“Ｄｅｖｉｃｅ＿２”、端末Ｓｅｃｒｅｔ“ｚｚｚｚｚｚｚｚｚ”、クライアント識別子“Ｃｌｉｅｎｔ＿１”、アプリケーション名“Ａｐｐ＿１”、サービス名“Ｓｅｒｖ＿１”、ユーザー識別子“ｕｓｅｒ＿Ｂ”が登録されている。

図４（Ａ）はクライアント２０３が認可サーバー２０１に対し認可開始リクエストを行うフローである。本フローはクライアント２０３がリソースサーバー２０２上のリソースへのアクセスに先立ち、アクセストークンが必要になった際に開始される。

ステップＳ４０１で認可開始リクエスト発行部３３１は、クライアント識別子、操作対象のリソース識別子、スコープおよび対象となるユーザーを特定するためのヒント情報を含む認可開始リクエストを、認可サーバー２０１に対して送信する。ここで各用語について補足する。スコープとは、リソースのアクセス範囲を示すもので、例えば、リソースであるデータを取得したい場合は“ｇｅｔ−ｄａｔａ”、取得以外に編集などのそれ以外のアクセスを行いたい場合は“ｇｅｔ−ａｌｌ”を指定することになる。対象となるユーザーを特定するためのヒント情報は、ユーザー識別子を示す。またヒント情報は、過去ユーザーに対して発行されたＩＤトークン、ユーザーのメールアドレス、ユーザー識別子のいずれかの情報であってもよい。

ステップＳ４０２で認可開始リクエスト発行部３３１は、認可サーバー２０１からレスポンスを受信する。このレスポンスには、認可サーバー２０１が発行した認可リクエスト識別子が含まれる。ステップＳ４０３で認可開始リクエスト発行部３３１は、ステップＳ４０２で受信したレスポンスに含まれる認可リクエスト識別子を、ステップＳ４０１の操作対象リソースおよびスコープとともに記憶してフローを終了する。

表３はクライアント２０３が記憶する認可リクエスト管理テーブルの例である。

表３ではリソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ−ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に紐付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対しては、“ａｃｔｋ１１１２２２３３３”で示されるアクセストークンを取得済みであることを示す。ここでリソース識別子が示すリソースは、ファイルシステム上の１つのファイルを示してもよく、データベース上の特定のレコードを示してもよい。またそれらの集合を示してもよい。

図４（Ｂ）は認可サーバー２０１における認可開始リクエストの受信フローである。本フローは認可サーバー２０１がクライアント２０３から認可開始リクエストを受信することで開始される。

ステップＳ４１１で認可リクエスト管理部３１１は、クライアント２０３から認可開始リクエストを受け付ける。ここで認可開始リクエストには、クライアント２０３のクライアント識別子と、クライアント２０３が操作対象としているリソース識別子と、クライアント２０３が要求するスコープと、クライアント２０３が要求するヒント情報が含まれる。

ステップＳ４１２で認可リクエスト管理部３１１は、ステップＳ４１１で受信した認可開始リクエストに対応する認可リクエスト識別子を生成する。ステップＳ４１３で認可リクエスト管理部３１１は、ステップＳ４１２で生成した認可リクエスト識別子に、認可リクエストの情報を紐付けて記憶する。ここで認可リクエストの情報とは、ステップＳ４１１で受信したクライアント識別子、操作対象のリソース識別子、スコープと、ヒント情報を含む。

表４は認可リクエスト管理部３１１が記憶する認可確認状況管理テーブルの例である。

表４では、クライアント識別子“Ｃｌｉｅｎｔ＿１”で示されるクライアントが、リソース識別子“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”で示されるリソースに対し、スコープ“ｇｅｔ−ｄａｔａ”で行った認可開始リクエストが、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”に紐付けて記憶されている。また認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”にはヒント情報としてユーザー識別子“ｕｓｅｒ＿Ａ”が紐付けられているが、これはリソース“／ｄａｔａｌａｋｅ／ｉｏｔ００１０／ｄａｔａ”のリソース所有者がユーザー識別子“ｕｓｅｒ＿Ａ”であることを示している。なお認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”の認可結果が“（空欄）”となっているのは、ユーザーがまだ認可操作を行っていないことを示している。それに対し認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”の認可結果は“ａｐｐｒｏｖｅｄ”で、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿４４４４４”の認可結果は“ｄｉｓａｐｐｒｏｖｅｄ”である。これらはそれぞれ、ユーザーが認可を行ったことと、認可を拒否したことを示す認可確認の結果である。ステップＳ４１６で認可リクエスト管理部３１１は、ステップＳ４１１の応答として、ステップＳ４１４で生成した認可リクエスト識別子をクライアント２０３に返し、フローを終了する。

図４（Ｃ）は認可サーバー２０１における認可確認リクエストを行うフローである。本フローはステップＳ４１３で認可リクエストの情報を記憶したことを受けて開始される。ステップＳ４２１で認可確認部３１３は、ステップＳ４１３で記憶した認可リクエスト識別子に紐付くクライアント識別子を取得する。

ここで、ステップＳ４１３で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くクライアント識別子は“Ｃｌｉｅｎｔ＿１”、ヒント情報は“ｕｓｅｒ＿Ａ”である。ステップＳ４２２で認可確認部３１３は、ステップＳ４２１で取得したクライアント識別子とヒント情報から認可確認リクエストを行うユーザー端末を特定する。例えば、認可確認部３１３はクライアント識別子“Ｃｌｉｅｎｔ＿１”とヒント情報“ｕｓｅｒ＿Ａ”に紐づくユーザー端末として、認可確認リクエスト送信先解決部３１２内の表２ユーザー端末登録テーブルよりユーザー端末２０４を特定する。また、認可確認リクエストを通知する通信のエンドポイントは“１９２．１６８．０．１”であることが分かる。

ステップＳ４２３で認可確認部３１３は、ステップＳ４１３で記憶した認可リクエスト識別子に紐付くクライアント識別子およびスコープを取得する。ステップＳ４１３で記憶した認可リクエスト識別子が“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿１２３４５”であれば、紐付くクライアント識別子およびスコープは“Ｃｌｉｅｎｔ＿１”および“ｇｅｔ−ｄａｔａ”である。

ステップＳ４２４で認可確認部３１３は、ステップＳ４２２で特定したユーザー端末２０４に対し、ステップＳ４２３で取得したクライアント識別子およびスコープを含めて認可確認リクエストを送信する。なお認可確認リクエストの送信方法は、ユーザー端末２０４のエンドポイントを指定した通信方法でもよいし、ＭＱＴＴをはじめとするＰＵＳＨ通知を用いた方法や、その他の方法でもよいが、本実施例では認可エンドポイントを指定した直接通信とする。ユーザー端末２０４の画面表示部３４４は、後述の図９（Ｂ）に示すような認可確認画面を表示し、端末のユーザーに認可を求める。

ステップＳ４２５で認可確認部３１３は、ステップＳ４２４で送信した認可確認リクエストの応答として、ユーザー端末２０４から認可結果を受信する。ステップＳ４２６で認可確認部３１３は、ステップＳ４２５で受信した認可結果を、ステップＳ４１５で記憶した認可リクエスト識別子に紐付けて記憶してフローを終了する。表４では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対し認可されたことを示す“ａｐｐｒｏｖｅｄ”が記憶されている。以上がクライアントから権限委譲要求を行いユーザーにより認可操作されるまでのフローである。ＯＡｕｔｈ２．０と異なるのは、クライアントがユーザーの指示なく自律的に認可要求を行う点と、認可操作を行うユーザーはクライアントを操作する意思はなく、あくまで認可操作を行うか否かの意思決定にのみ関わるという点である。

図５（Ａ）は本実施の形態に係る、認可サーバー２０１がクライアント２０３に認可完了通知を行うフローである。本フローはステップＳ４２６で認可結果を記憶したことを受けた後で開始される。ステップＳ５０１で認可確認部３１３は、ステップＳ４２６で記憶した認可リクエスト識別子を取得する。ステップＳ５０２で認可確認部３１３は、ステップＳ５０１で取得した認可リクエスト識別子に紐付くクライアントの接続先情報であるクライアントエンドポイントを取得する。

表５はクライアント識別子とクライアントエンドポイントの対応を管理する、クライアント管理テーブルの例である。

表５では、クライアント識別子“Ｃｌｉｅｎｔ＿１”のクライアントエンドポイントが、“１０．０．０．１”であることを示している。ステップＳ５０３で認可確認部３１３は、ステップＳ５０２で取得したクライアントエンドポイントに対し、ユーザーが認可したことを通知し、フローを終了する。なおここでクライアントエンドポイントに通知する内容は、ステップＳ５０１で取得した認可リクエスト識別子でもよく、またユーザーの認可に対応して発行したアクセストークンでもよい。アクセストークンを発行する際は後述の図５（Ｃ）に示されるようなフローを実行する。

図５（Ｂ）は本実施の形態に係る、クライアント２０３が認可サーバー２０１にアクセストークンリクエストを行うフローである。本フローはクライアント２０３が認可サーバー２０１からステップＳ５０３の認可完了通知を受けて開始される。または本フローは、クライアント２０３が、定期的に実行してもよい。

ステップＳ５１１でアクセストークン要求部３３３は、アクセストークンリクエストを行う認可リクエスト識別子を決定する。ここで本フローが定期的に実行される場合には、認可リクエスト識別子は、表３に示される認可リクエスト管理テーブルでアクセストークン未取得のものから選ばれる。また本フローが認可サーバー２０１からの通知を受けて開始される場合は、認可サーバー２０１からの通知に含まれる認可リクエスト識別子が用いられる。ステップＳ５１２でアクセストークン要求部３３３は、ステップＳ５１１で決定した認可リクエスト識別子を指定して、認可サーバー２０１に対してアクセストークンリクエストを行う。ステップＳ５１３でアクセストークン管理部３３４は、ステップＳ５１２の応答として受信したアクセストークンを記憶してフローを終了する。表３では、認可リクエスト識別子“ａｕｔｈ＿ｒｅｑ＿ｉｄ＿９８７６５”に対して取得できた、アクセストークン“ａｃｔｋ１１１２２２３３３”を記憶している様子を示す。

図５（Ｃ）は本実施の形態に係る、認可サーバー２０１がアクセストークンを発行するフローである。本フローは認可サーバー２０１がクライアント２０３からアクセストークンリクエストを受信したことで開始される。

ステップＳ５２１でアクセストークン発行部３１４は、クライアント２０３から受信したアクセストークンリクエストから、認可リクエスト識別子を取得する。ステップＳ５２２でアクセストークン発行部３１４は、アクセストークン発行可否を判断する。ステップＳ５２３でアクセストークン発行部３１４は、ステップＳ５２２の結果、アクセストークンを発行可能であると判断されたか確認する。

アクセストークンを発行可能と判断された場合はステップＳ５２４に遷移する。またアクセストークンを発行不可能と判断された場合はステップＳ５２５に遷移する。ステップＳ５２４でアクセストークン発行部３１４は、ステップＳ５２１で取得した認可リクエスト識別子に紐付けられたユーザー識別子およびスコープに対応するアクセストークンを発行する。また発行したアクセストークンをクライアント２０３に送信しフローを終了する。

表６はアクセストークン発行部３１４で発行されたアクセストークンを管理する、アクセストークン管理テーブルの例である。

表６では、ユーザー“ｕｓｅｒ＿ａｂｃｄｅ”がスコープ“ｇｅｔ−ｄａｔａ”の権限委譲を行ったことを示すアクセストークンが、アクセストークン識別子“ａｃｔｋ１１１２２２３３３”として発行されていることを示す。なお、ステップＳ５２４でクライアント２０３に返すアクセストークンはアクセストークン識別子だけでもよく、またアクセストークン識別子に加えユーザー識別子およびスコープを含む構造化されたデータでもよい。ステップＳ５２５でクセストークン発行モジュール３５４は、アクセストークンを発行できないことをクライアント２０３に通知してフローを終了する。

図５（Ｄ）は実施例１に係るアクセストークン発行可否判断を行うステップＳ５２２の詳細フローである。ステップＳ５３１でアクセストークン発行部３１４は、表４の認可確認状況管理テーブルを参照し、指定された認可リクエスト識別子に対応する認可結果を確認する。ステップＳ５３２でアクセストークン発行部３１４は、ステップＳ５３１の確認した認可結果が、認可されていることを表しているか判断する。認可されていることを表していた場合はステップＳ５３３に遷移し、その他の場合はステップＳ５３４に遷移する。ステップＳ５３３でアクセストークン発行部３１４は、アクセストークンを発行可能と判断してフローを終了する。ステップＳ５３４でアクセストークン発行部３１４は、アクセストークンを発行不可能と判断してフローを終了する。

図６は権限委譲システムのシーケンス図である。クライアント２０３は認可サーバー２０１に対し認可開始リクエストを行い、応答として認可リクエスト識別子を取得する（Ｓ１）。認可開始リクエストはステップＳ４０１およびステップＳ４１１に対応する。

認可サーバー２０１はリソース所有者の解決をすると、リソース所有者に紐付けられたユーザー端末２０４に対し認可確認リクエストを行う（Ｓ２）。ユーザー端末２０４では後述の図９（Ｂ）に示すような認可確認画面が表示され、端末のユーザーが認可操作を行う。ユーザーが認可操作を行うと、ユーザー端末２０４は認可サーバー２０１に認可結果を送信する（Ｓ３）。Ｓ２はステップＳ４２４に、Ｓ３はステップＳ４２５に、それぞれ対応する。

認可サーバー２０１が認可結果を受信した後、クライアント２０３が認可の完了とその内容を知る必要があるが、認可完了の通知には、クライアント２０３が認可サーバー２０１に確認する方法と認可サーバー２０１がクライアント２０３に通知する方法がある。前者の場合、クライアント２０３が定期的に認可サーバー２０１にアクセストークンリクエストを送信し（Ｓ４）、その応答として認可サーバー２０１が認可結果を返す。

この際、Ｓ３で許可が返されている場合、認可サーバーはリソースサーバーへのアクセストークンを発行して返し、Ｓ３で拒否が返されている場合は拒否されたことを示す結果を返す。なお、クライアント２０３は定期的にＳ４のリクエストを送信するため、未だＳ３の認可結果が返されていない場合があるが、この場合は引き続き確認を継続する旨の結果を返す。後者は認可サーバー２０１がクライアント２０３に認可結果通知を送信する（Ｓ４’）。

後者のケースはクライアント２０３が認可完了通知を受信するためのエンドポイントを持っている場合に行える方法となる。認可結果の内容は前者と同じで、許可された場合はアクセストークンを発行して渡し、拒否された場合は拒否されたことを示す結果を返す。Ｓ４はステップＳ５１２およびステップＳ５２１に、Ｓ４’はステップＳ５０３にそれぞれ対応する。クライアント２０３は、Ｓ４もしくはＳ４’で受信したアクセストークンを利用してリソースサーバー２０２にアクセスを行う（Ｓ５）。

このように、クライアント２０３とは物理的、システム的に離れたユーザーがクライアント２０３に権限委譲を行うことが可能となる。しかし、物理的、システム的に離れたことによって、認可を行うユーザーが再認可することができない課題が発生している。なぜなら、ユーザー端末２０４とクライアント２０３が密に連携しておらず疎であるため、ユーザー端末２０４を操作するユーザーはクライアント２０３を操作することも、ユーザー端末２０４からクライアント２０３へ再認可の要求を送ることも叶わないからである。

だが、ユーザーは認可操作を行なった後、認可操作を訂正したいと考える可能性もありうる。また、ユーザー端末、とりわけスマートフォンのような小型の端末では、情報の表示領域が少なく操作パネルも小さいため、ユーザーの認識違いによるミスや操作ミスが起こる可能性も高くなる。そのため、認可操作を再び行えるようにする必要性が出てくる。

図７は権限委譲システムにおける再認可処理のシーケンス図である。ユーザー端末２０４が認可サーバー２０１に認可結果を送信する（Ｓ３）ところまでは図６と同様である。ここで、ユーザーが認可結果を訂正したい場合、ユーザーは図９（Ｄ）に示すような再認可確認画面で再認可の操作を行うことができる。ユーザーが再認可操作を行うと、ユーザー端末２０４は認可サーバー２０１に再認可結果を送信する（Ｓ３’）。再認可結果の内容は認可結果と同様である。なお、図６では、認可サーバー２０１における再認可結果受信（Ｓ３’）のエンドポイントを認可結果受信（Ｓ３）と分けているが、共通にする実装であってもよい。

シーケンス図のフローは図７の通りであるが、クライアント２０３がアクセストークンを使って行う処理は実施後の取り消しが難しい場合も想定される。従って、認可サーバー２０１がクライアント２０３への認可完了通知を待つ必要があるケースも考えられる。

表７は、表４で示した認可リクエスト管理部３１１が記憶する認可確認状況管理テーブルに、認可期限を追加した例である。

表７の一行目では、認可結果が“ｄｉｓａｐｐｒｏｖｅｄ”となっており、ユーザーからの認可結果が拒否であったことを示しているが、一方、認可期限である２０１９年１０月８日１０時３２分４８秒までは再認可が可能であることを示している。認可期限前にユーザーから再認可の指示を受信した場合、認可結果は更新される。つまり、ユーザーの認可操作の結果である認可結果は認可期限までバッファリングされる。ポイントは、バッファリングされている認可結果に基づく処理は実行されないという点である。たとえユーザーが認可したとしても、バッファリングされている間はアクセストークンが発行されない。

表７の３行目は、未だ認可結果を受信していない状態となっているが、認可期限も設定されていない。これは認可期限が再認可待ちの時間を考慮して設定されることを想定したもので、認可を受信してから再認可期限を算出して設定するためである。なお、認可期限の設定に関して認可結果を受信する前、例えば、認可リクエストを受信した時点で認可期限を設ける実装であってもよい。また、認可期限の間隔に関しては認可サーバー２０１の認可リクエスト管理部３１１に予め設定された値によって決定する実装や、クライアント２０３から認可開始リクエスト時に受信する実装などがあってもよい。さらに、認可期限は認可結果（Ｓ３）の応答で、ユーザー端末２０４に渡され、ユーザー端末の認可確認画面でも利用される。

図８は再認可処理に関するフローチャートである。図８のフローチャートは認可サーバー２０１の認可確認部３１３、アクセストークン発行部３１４で実行される。図８（Ａ）は、図７の認可結果の受信（Ｓ３）および再認可結果受信（Ｓ３’）のフローチャートで、図４（Ｃ）で説明した認可結果の受信（Ｓ４２５）部分からのフローを示している。

認可サーバー２０１の認可確認部３１３は、認可結果を受信すると該当する認可リクエスト識別子に紐付く情報に認可結果を保存する（Ｓ４２６）。そしてさらに、該当する認可リクエスト識別子に紐付く情報に認可期限が設定されているかを確認し（Ｓ８０１）、認可期限が設定されていない場合は、再認可が可能な期間を取得する（Ｓ８０２）。再認可が可能な期間は認可サーバー２０１の認可リクエスト管理部３１１に予め設定された値によって決定する実装や、クライアント２０３から認可開始リクエスト時に受信する実装などがあってもよい。そして、現在日時から再認可可能な期限となる日時を算出した上で（Ｓ８０３）、該当する認可リクエスト識別子の情報に期限を設定する（Ｓ８０４）。例えばＳ８０２で取得した値が３分であり、現在日時が２０１９年１０月８日１０時２９分４８秒であったとすると、期限は２０１９年１０月８日１０時３２分４８秒となる。つまり、認可結果は２０１９年１０月８日１０時３２分４８秒までバッファリングされる。なお、再認可を許容しない場合には、期限には現在日時が設定される。

次に、認可サーバー２０１の認可確認部３１３は、完了通知が図７のＳ４’で示す認可サーバー２０１側からクライアント２０３に通知するＰＵＳＨ型の方法かどうかを確認する（Ｓ８０５）。そしてＰＵＳＨ型の通知であれば、期限タイマーイベントを作成する（Ｓ８０６）。期限タイマーイベントは、期限の日時になった際にイベントを発行するもので、期限がきた時に認可サーバー２０１が図７のＳ４’で示す認可完了通知を行うために作成される。そして認可サーバー２０１は認可結果を受信した旨と共に、認可期限をユーザー端末２０４に返す（Ｓ８０７）。

図８（Ｂ）は、図７のアクセストークンリクエスト（Ｓ４）を受信した際の認可サーバー２０１のアクセストークンレスポンスフローチャートである。図５（Ｃ）で説明したアクセストークンリクエストに該当する認可リクエスト識別子の情報を取得する（Ｓ５２１）部分からのフローを示している。該当する認可リクエスト識別子に紐付く情報を取得したら、認可結果が設定されているかを確認し（Ｓ８１１）、認可結果がない場合は未だ認可結果がきていないことをクライアント２０３に通知する（Ｓ８１２）。

認可結果が設定されている場合は再認可期限を越えているかどうかを確認する（Ｓ８１３）。ここで、期限を越えていなかった場合、未だ認可結果がきていないことを通知して（Ｓ８１２）、ユーザーからの再認可確認を待つ。期限を越えていた場合は図５で示したように、認可結果を確認し（Ｓ５３１）、許可された場合（Ｓ５３２）はアクセストークンを発行して返し（Ｓ５２４）、拒否された場合はその旨を通知する（Ｓ５２５）。なお、図７のＳ４’で示した認可サーバー２０１からクライアント２０３へ認可完了通知を返す方法に関しては、図８（Ａ）のＳ８０６で説明したイベントによって認可完了通知処理が開始される。

図９はユーザー端末２０４で行う認可確認画面である。図９（Ａ）は認可確認リスト画面、図９（Ｂ）は認可確認画面、図９（Ｃ）は認可履歴画面、図９（Ｄ）は再認可確認画面である。ユーザー端末２０４上に認可確認を行うためのソフトウェアがインストールされており、ソフトウェアの画面を起動すると、図９（Ａ）の認可確認リスト画面が表示される。

図９（Ａ）は認可確認リスト画面で、図７のＳ２で示す認可確認リクエストで受信した認可確認項目をリスト表示する。９０１は認可確認項目の一つで、受信日時、リソース情報など認可対象がわかる情報を表示している。リソース情報に関しては、表７で示しめしたリソース情報をそのまま全部または一部表示する実装の他、リソースに対してユーザーが名前を設定して表示するような実装であってもよい。認可確認項目９０１の右端にある“＞”は、図９（Ｂ）で示す認可確認画面へ遷移するリンクである。９０２は、認可確認リスト画面と図９（Ｃ）の認可履歴画面とを切替えるタブで選択されているタブがハイライトされている。

図９（Ｂ）は認可確認画面で、この画面で認可確認を行う。ＩＤ９１１は認可リクエスト識別子を示しており、認可する対象を一意に特定することができる。なお、ＩＤ９１１下の情報欄に関しては特に詳細は記載しないが、ユーザーが認可リクエストを識別するための補足情報をクライアント２０３や認可サーバー２０１から受信し表示するような実装が考えられる。許可ボタン９１２は認可確認に対して許可することを指示し、拒否ボタン９１３は認可を不許可とすることを指示するボタンである。ユーザーは、許可ボタン９１２または拒否ボタン９１３を押下することで認可操作を行うと、認可結果送信部３４２によって、図７のＳ３で示した認可結果の送信が行われる。

図９（Ｃ）は認可履歴画面で、過去の認可履歴をリストで参照することができる。図９（Ｂ）で認可確認を行うと、認可履歴管理部３４３に履歴として保存され、過去の認可履歴を参照することができるようになる。９２１は認可履歴の一つで、認可確認を行った日時、リソースなど認可対象がわかる情報、認可結果を表示している。認可履歴９２１の右端にある“＞”は、図９（Ｄ）で示す再認可確認画面へ遷移するリンクである。９２２も認可履歴の一つで表示される書誌情報は認可履歴９２１と同じであるが、グレー表示されると共に再認可確認画面へ遷移するリンクは表示されない。これは、対象となる認可確認項目の認可期限が切れたため、再認可操作が行えないことを示している。なお、認可履歴画面のリストに関しては対象となるリソースに絞る等のフィルタリング機能を持った実装があってもよい。

図９（Ｄ）は再認可確認画面である。表示される情報は図９（Ｂ）の認可確認画面と同様であるが、再認可期限９３１を表示している。９３２は認可操作を行うボタンで、前回の認可確認で行った操作が拒否であったため、再認可では前回の操作を取り消す許可ボタンが表示される。逆に、前回の認可確認で行った操作が許可であった場合、認可操作ボタン９３２は拒否ボタンが表示される。なお、再認可確認画面でも図９（Ｂ）のように許可ボタンと拒否ボタン両方を表示する実装であってもよい。

再認可確認画面で認可確認を再度行うと、認可結果送信部３４２によって、図７のＳ３’で示した認可結果の送信が行われる。再認可確認は期限内であれば何度でもユーザーは再認可の操作ができる実装であってよいし、再認可操作の回数に制限を設ける実装であってもよい。例えば、クライアント２０３から送信される認可開始リクエストにその回数を含めることでクライアント２０３からの要求で回数を指定することなどが考えられる。さらに、許可あるいは拒否のどちらかが行われたら再認可できなくなるといった制限を設ける実装であってもよい。

図１０（Ａ）は、図９（Ｃ）で述べた認可履歴画面のフローチャートである。本フローチャートはユーザー端末２０４で実行される。ソフトウェアの画面を起動すると、図９（Ａ）の認可確認リスト画面が表示されるが、そこで画面切替えタブ９０２で図９（Ｃ）の認可履歴画面に切替えられたところから処理が開始される（Ｓ１００１）。

まず、画面表示部３４４は、認可履歴管理部３４３から認可履歴を取得する（Ｓ１００２）。そして、取得した履歴の中から期限が過ぎていない認可履歴すなわち再認可操作が可能な履歴について（Ｓ１００３）、期限となる日時から現在日時を差し引いて残時間の算出を行う（Ｓ１００４）。そして、期限に達した際に起動するタイマーイベントを作成する（Ｓ１００５）。次に画面表示部３４４は、ユーザー端末２０４のディスプレイ装置１１４に図９（Ｃ）で述べた認可履歴画面を表示する（Ｓ１００６）。

認可履歴画面では、図９（Ｃ）で述べたように、再認可操作が可能な認可履歴は図９（Ｄ）の再認可確認画面へのリンクを表示し、認可期限を過ぎた認可履歴はリンクを表示しない。その後は画面操作やＳ１００５で作成した期限イベントを待ち（Ｓ１００７）、イベントを受信したらその内容に応じた処理を実施する（Ｓ１００８）。期限イベントを受信した場合は認可履歴画面を描画して表示内容を更新する（Ｓ１００９）。画面を更新したことによって、画面表示において、期限に達した認可履歴から再認可確認画面へのリンクがなくなる。イベント受信で図９の９２１にある認可履歴リスト項目のリンクをクリックしたイベントを受信した場合、選択された認可履歴の項目の再認可確認画面へ遷移する（Ｓ１０１０）。図９の９０２で説明した認可確認タブをクリックしたイベントを受信した場合、認可確認リスト画面へ遷移する（Ｓ１０１１）。

図１０（Ｂ）は、図１０（Ａ）内の認可履歴描画のサブフローチャートである。認可履歴の数分内容を確認し（Ｓ１０２１）、期限が過ぎているかどうかを判定（Ｓ１０２２）、期限が過ぎていなければ再認可画面へ遷移するリンクを入れたリスト項目を表示する（Ｓ１０２３）。期限を過ぎていた場合は再認可画面へ遷移するリンクは入れずにリスト項目を表示する（Ｓ１０２４）。

以上、実施例１では、ユーザーが認可操作を訂正したい場合あるいは認識違いによるミスや操作ミスが起こった場合に、認可確認の再操作を行うことが可能となる。

［実施例２］
実施例１では認可サーバー２０１で認可確認の再操作を可能とする時間だけ待ち処理を行う実施例を示した。しかし、再認可を許容するかどうか、待ち処理による応答の遅延を許容するかどうかは、クライアント２０３がリソースサーバー２０２に対して行う処理内容に関係すると考えられる。例えば、対面での商品購入の決済に端末を使った認可フローを行うようなケースでは、待ち処理を行う必要はない。そのため、認可サーバー２０１が待ち処理を行うと、クライアント２０３にとっては不都合な場合もある。

そのような課題が考えられる場合、クライアント２０３が認可開始リクエストを行う際（Ｓ４０１）に再認可を許容するかどうか、応答期限はどのくらいか、といった指示を含めることができるようにする実装も必要となる。なお、実施例２においても権限委譲システムにおける再認可処理のシーケンスは実施例１と同様であり、説明を省略している部分は実施例１と同じ構成や処理となる。

図１１は認可開始リクエストで送付される情報を示している。“ｓｃｏｐｅ”は、クライアント２０３がリソースサーバー２０２に対して行う処理に必要となる権限範囲を示し、“ｈｉｎｔ”はヒント情報を示す。“ｒｅｔｒｙ”は、再認可が可能かどうかを示す。ｔｒｕｅであれば再認可は可能、ｆａｌｓｅであれば再認可は不可能となる。なお、実施例２では再認可可否の値を示したが再認可の回数などを指定するような実装であってもよい。“ｅｘｐｉｒｅｓ＿ｉｎ”は認可の期限を示し、１８００の場合は１８００秒以内に認可を行う必要があることを示す。なお、図１１には上記の４項目を例示しているが、これに限らなくてもよい。例えば、図７のＳ４’で認可完了通知を出す場合にはクライアントのエンドポイントの情報を含める必要があったり、ユーザー端末等で表示するためのメッセージ文字列を含めたりする実装であってもよい。

表８は、表７で示した認可リクエスト管理部３１１が記憶する認可確認状況管理テーブルに、クライアント２０３から渡される再認可の可否や応答期限といった指示を保管する領域を追加したものである。表７で示したクライアント識別子、リソース、スコープは省略している。

表８の一行目では、再認可が“ｔｒｕｅ”となっており、再認可可能であることを示す。また応答期限が“１８００”となっており、認可サーバー２０１からの認可完了通知まで１８００秒待つことが可能な指示となっている。認可サーバー２０１は、認可リクエストを受信すると現在日時に応答期限を加えた日時を認可期限に設定する。ただし、図７のＳ４で示したアクセストークンリクエストに対して認可完了通知を応答する場合、クライアントからのポーリング間隔も考慮して認可期限を設定する必要がある。次のポーリングまでの間隔は認可開始リクエストＳ１やアクセストークンリクエストＳ４の応答で指定することはできるが、処理のオーバヘッドも考慮して少し短く設定するような実装も考えられる。Ｓ４’のように認可サーバー２０１からクライアント２０３に応答を返す場合であっても、処理のオーバヘッドも考慮して少し短く設定するような実装が考えられる。

表８の二行目では、再認可が“ｆａｌｓｅ”となっており、再認可を許容しないリクエストであることを示す。また応答期限が“３００”となっており、認可サーバー２０１からの認可完了通知まで３００秒待つことが可能な指示となっている。すなわち、この認可期限は再認可のための期限ではなく、最初の認可までの期限となる。例えば、対面での商品購入の決済に端末を使った認可フローを行うようなケースでは、待ち処理を行う必要はなく、応答も即座に返されるため応答期限は短く設定されている。認可サーバー２０１は、認可リクエストを受信すると現在日時に応答期限を加えた日時を認可期限に設定する。また、再認可が不可であるため、認可サーバー２０１は、図７のＳ３でユーザー端末２０４から認可結果を受信すると、受信したときの日時を認可期限に設定する。再認可が可能な期間は認可確認の結果はバッファリングされアクセストークンの発行制御はすぐには行われない。

表８の三行目では、再認可が“ｆａｌｓｅ”となっており、再認可を許容しないリクエストであることを示す。また応答期限は指定されていない。この場合、認可サーバー２０１は、認可リクエストを受信した際に認可期限の設定は行わず、図７のＳ３でユーザー端末２０４から認可結果を受信すると、受信したときの日時を認可期限に設定してもよい。再認可のためのバッファリングは行われないのが三行目の場合の特徴である。なお、表８の二行目と三行目はバッファリングを行うか否かで差異はあるが、どちらもユーザーは再認可することはできない。

表８の四行目では、再認可が“ｔｒｕｅ”、期限は設定されておらず、再認可可能で期限も存在しないことを示す。このようなユースケースは少ないと思われるが、クライアント２０３がリソースサーバー２０２に対して行う処理が何度でも再実行可能な処理であり、特に期限も設定しないケースが考えられる。この場合、認可サーバー２０１は、認可リクエストを受信した際に認可期限の設定は行わず、図７のＳ３でユーザー端末２０４から認可結果を受信しても、認可期限は設定しない。

図１２は実施例２における認可結果受信のフローチャートである。図１２のフローチャートは認可サーバー２０１の認可確認部３１３、アクセストークン発行部３１４で実行される。図１２は、図７の認可結果の受信（Ｓ３）および再認可結果受信（Ｓ３’）のフローチャートで、図４（Ｃ）で説明した認可結果の受信（Ｓ４２５）部分からのフローを示している。

認可サーバー２０１の認可確認部３１３は、認可結果を受信すると該当する認可リクエスト識別子に紐付く情報に認可結果を保存する（Ｓ４２６）。認可サーバー２０１の認可確認部３１３は、完了通知が図７のＳ４’で示す認可サーバー２０１側からクライアント２０３に通知するＰＵＳＨ型の方法かどうかを確認する（Ｓ１２０１）。そして再認可期限が設定されているかどうかを確認する（Ｓ１２０２）。実施例１では再認可期限を設定するフローを説明したが、実施例２では再認可期限が設定されない場合もある。再認可期限が設定されている場合は、対象となる認可リクエスト識別子の完了通知を行うための期限タイマーイベントが既に存在しているかを確認し（Ｓ１２０３）、存在しなければ期限タイマーイベントを作成する（Ｓ１２０４）。完了通知がＰＵＳＨ型で再認可期限が設定されていない場合は、即時に認可完了通知を行うことになる。

認可サーバー２０１のアクセストークン発行部３１４は認可結果を確認する（Ｓ５３１）。許可された場合（Ｓ５３２）はアクセストークンを発行して返し（Ｓ５２４）、拒否された場合はその旨を通知する（Ｓ５２５）。なお、即時に認可完了通知を行うのではなく、認可完了通知を行うためのイベントあるいはキューを作成して、別処理として認可完了通知を行う実装であってもよい。

そして、認可サーバー２０１の認可確認部３１３は前記表８の再認可列の値を参照して、対象となる認可リクエスト識別子の認可が再認可可能かどうかを確認し（Ｓ１２０５）、認可結果を受信した旨と共に、認可期限をユーザー端末２０４に返す（Ｓ１２０６）。また、表８の再認可列で示した再認可が可能かどうかの情報もＳ１２０６でユーザー端末に返してもよい。なお、Ｓ１２０４でタイマーイベントを作成している場合は、タイマーイベントの起動によって認可完了通知処理が開始される。

図１３は、実施例２における図７のアクセストークンリクエスト（Ｓ４）を受信した際の認可サーバー２０１のアクセストークンレスポンスフローチャートである。図１３のフローチャートは認可サーバー２０１のアクセストークン発行部３１４で実行される。図１３のフローチャートは、図５（Ｃ）で説明したアクセストークンリクエストに該当する認可リクエスト識別子の情報を取得する（Ｓ５２１）部分からのフローを示している。

該当する認可リクエスト識別子に紐付く情報を取得したら、認可結果が設定されているかを確認する（Ｓ８１１）。認可結果がない場合、再認可期限を越えていないかどうかを確認し（Ｓ１３０１）、再認可期限を越えていない場合は未だ認可結果がきていないことをクライアント２０３に通知する（Ｓ８１２）。再認可期限を越えていた場合は認可が行われなかったことを通知する（Ｓ１３０２）。実施例１において、再認可期限の設定は認可が一度行われた場合に設定する例を示したが、実施例２では認可開始リクエスト受信時に設定されるため、認可が行われずに期限を越える場合もありうる。

Ｓ８１１で認可結果が設定されている場合は再認可期限を越えているかどうかを確認する（Ｓ８１３）。ここで、期限を越えていなかった場合、未だ認可結果がきていないことを通知して（Ｓ８１２）、ユーザーからの再認可確認を待つ。期限を越えていた場合は図５で示したように、認可結果を確認する（Ｓ５３１）。許可された場合（Ｓ５３２）はアクセストークンを発行して返し（Ｓ５２４）、拒否された場合はその旨を通知する（Ｓ５２５）。

図１４のフローチャートは、図１０（Ｂ）で説明したユーザー端末２０４上の画面表示部３４４で実行される認可履歴描画のフローチャートを、実施例２における再認可処理のフローに対応したものである。Ｓ１０２１からＳ１０２４のステップは図１０と同じであるが、ステップＳ１４０１で期限が設定されているかどうかの判定が行われている。

図８（Ａ）で説明したように、再認可が可能な場合は再認可可能な期間を上乗せした日時を期限に設定し、再認可を許可しない場合は現在日時を期限に設定する実装例を示した。実施例２の再認可処理のフローでは再認可期限が設定されない場合もありうる。期限が設定されない場合は認可サーバー２０１から期限情報は渡されず、履歴情報にも期限が設定されていない状態となる。期限が設定されていない場合、再認可画面へ遷移するリンクを入れたリスト項目を表示する（Ｓ１０２３）。なお、この場合、図９（Ｄ）で示した９３１の期限は表示されない。

また、実施例２では表８の再認可列で再認可が可能かどうかを判断する情報もある。Ｓ１２０６で受信した再認可が可能かどうかの情報を使って、再認可が不可であった場合は、図９（Ｂ）の画面に再認可ができない旨の注記を表示したり、９１２または９１３のボタン押下時に確認のダイアログボックスを表示したりする実装であってもよい。

以上、クライアント２０３側で再認可を許容するかどうか、待ち処理による応答の遅延を許容するかどうかの指示を行うことが可能となる。その結果、例えば対面での商品購入の決済に端末を使った認可フローを行うようなケースでは、待ち処理を行う必要はなくなるのでアクセストークンの発行を早期に行うことができる。その一方で、ユーザーが一度行った認可操作を訂正したいケースでは、再認可ができる。

［その他の実施例］
実施例１および２では、認可結果を一時的に記憶する形態として、ＲＡＭの中に用意された専用記憶領域を使ったバッファリングを説明したが、バッファリングではなくとも一時的に記憶する形態であればどのような記憶方法であっても良い。例えば、永続記憶領域に認可確認の結果を記憶し、後で消去するような一時的な記憶方法が考えられる。

本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

２０１ 認可サーバー
２０２ リソースサーバー
２０３ クライアント
２０４ ユーザー端末

Claims (11)

1. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーであって、
   前記クライアントから認可開始リクエストを受信する受信手段と、
   前記受信手段により認可開始リクエストが受信されたことに応じて、認可確認リクエストの送信先となるユーザー端末を特定する特定手段と、
   特定されたユーザー端末に対して認可確認リクエストを送信し、応答として認可確認の結果を受信し、再認可が可能な期間まで前記認可確認の結果を一時的に記憶する認可手段と、
   再認可が可能な期間を超えたことに応じて一時的に記憶されている前記認可確認の結果に応じたアクセストークンの発行の制御を行い、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ前記アクセストークンを送信する発行手段と、を有することを特徴とする認可サーバー。
2. 前記発行手段は、再認可が可能な期間を超えたことに応じて一時的に記憶されている前記認可確認の結果を確認し、前記アクセストークンを発行しない場合、再認可が可能な期間を超えてから拒否された旨を前記クライアントへ送信することを特徴とする請求項１に記載の認可サーバー。
3. 前記認可手段は、前記クライアントから再認可の指示を受け付けた場合、一時的に記憶している前記認可確認の結果を前記再認可の指示に基づき更新することを特徴とする請求項１または２に記載の認可サーバー。
4. 前記期間は、前記認可確認の結果を受信した日時とあらかじめ設定された値から算出した値、もしくは前記クライアントが送信する前記認可開始リクエストで指定された値によって設定されることを特徴とする請求項１乃至３の何れか１項に記載の認可サーバー。
5. 前記受信手段により受信された認可開始リクエストが再認可は不可能であることを示すリクエストであった場合、前記発行手段は、再認可が可能な期間を超えるのを待たずに前記認可確認の結果に応じたアクセストークンの発行の制御を行うことを特徴とする請求項４に記載の認可サーバー。
6. 前記受信手段により受信された認可開始リクエストが再認可は不可能であることを示すリクエストであった場合、前記認可手段は受信した認可確認の結果を一時的に記憶しないことを特徴とする請求項５に記載の認可サーバー。
7. 前記受信手段により受信された認可開始リクエストが再認可は可能であることを示すリクエストであった場合、認可結果を受信した旨とともに認可期限を前記ユーザー端末へ送信することを特徴とする請求項５または６に記載の認可サーバー。
8. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムであって、
   前記クライアントから認可開始リクエストを受信する受信手段と、
   前記受信手段により認可開始リクエストが受信されたことに応じて、認可確認リクエストの送信先となるユーザー端末を特定する特定手段と、
   特定されたユーザー端末に対して認可確認リクエストを送信する送信手段と、
   前記認可確認リクエストの認可確認項目を表示し、前記認可確認リクエストに対する許可もしくは不許可の指示を受け付ける第１の受付手段と、
   前記認可確認リクエストの応答として認可確認の結果を受信し、再認可が可能な期間まで前記認可確認の結果を一時的に記憶する認可手段と、
   前記認可確認リクエストに対する許可もしくは不許可の指示を受け付けた後、再認可の指示を受け付ける第２の受付手段と、
   再認可が可能な期間を超えたことに応じて一時的に記憶されていた前記認可確認の結果に応じたアクセストークンの発行の制御を行い、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ前記アクセストークンを送信する発行手段と、を有することを特徴とするシステム。
9. 前記第２の受付手段は、再認可が可能な期間を超えた前記認可確認リクエストに対する再認可の指示を受け付けないことを特徴とする請求項８に記載のシステム。
10. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムで実行される方法であって、
    前記クライアントから認可開始リクエストを受信する受信ステップと、
    前記受信ステップにより認可開始リクエストが受信されたことに応じて、認可確認リクエストの送信先となるユーザー端末を特定する特定ステップと、
    特定されたユーザー端末に対して認可確認リクエストを送信する送信ステップと、
    前記認可確認リクエストの認可確認項目を表示し、前記認可確認リクエストに対する許可もしくは不許可の指示を受け付ける第１の受付ステップと、
    前記認可確認リクエストの応答として認可確認の結果を受信し、再認可が可能な期間まで前記認可確認の結果を一時的に記憶するステップと、
    前記認可確認リクエストに対する許可もしくは不許可の指示を受け付けた後、再認可の指示を受け付ける第２の受付ステップと、
    再認可が可能な期間を超えたことに応じて一時的に記憶されていた前記認可確認の結果に応じたアクセストークンの発行の制御を行い、前記アクセストークンを
    発行した場合は前記認可開始リクエストを送信した前記クライアントへ前記アクセストークンを送信する発行ステップと、を含むことを特徴とする方法。
11. ユーザーのリソースを提供するリソースサーバー、前記リソースへアクセスするクライアント、前記クライアントが前記リソースへアクセスすることがユーザーにより許可されたことを示すアクセストークンを発行する認可サーバー、およびユーザー端末とから構成されるシステムにおける前記認可サーバーで実行されるプログラムであって、
    前記クライアントから認可開始リクエストを受信させる受信ステップと、
    前記受信ステップによって認可開始リクエストが受信されたことに応じて、認可確認リクエストの送信先となるユーザー端末を特定させる特定ステップと、
    特定されたユーザー端末に対して認可確認リクエストを送信させ、応答として認可確認の結果を受信させ、再認可が可能な期間まで前記認可確認の結果を一時的に記憶させる認可ステップと、
    再認可が可能な期間を超えたことに応じて一時的に記憶されていた前記認可確認の結果に応じたアクセストークンの発行の制御を行わせ、前記アクセストークンを発行した場合は前記認可開始リクエストを送信した前記クライアントへ前記アクセストークンを送信させる発行ステップと、を含むプログラム。

Images