特許 7605307 情報処理システム、リソース管理装置、リソース管理方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-12-16

(45)【発行日】2024-12-24

(54)【発明の名称】情報処理システム、リソース管理装置、リソース管理方法及びプログラム

(51)【国際特許分類】

   G06F 21/62 20130101AFI20241217BHJP

   G06F 21/33 20130101ALI20241217BHJP

【ＦＩ】

G06F21/62 309

G06F21/33

【請求項の数】 6

(21)【出願番号】P 2023526690

(86)(22)【出願日】2021-06-08

(86)【国際出願番号】 JP2021021784

(87)【国際公開番号】W WO2022259378

(87)【国際公開日】2022-12-15

【審査請求日】2023-11-01

(73)【特許権者】

【識別番号】000004226

【氏名又は名称】日本電信電話株式会社

(74)【代理人】

【識別番号】110004381

【氏名又は名称】弁理士法人ＩＴＯＨ

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100124844

【弁理士】

【氏名又は名称】石原 隆治

(72)【発明者】

【氏名】鈴木 亮平

(72)【発明者】

【氏名】千田 浩司

(72)【発明者】

【氏名】奥田 哲矢

【審査官】宮司 卓佳

(56)【参考文献】

【文献】国際公開第２０１９／２４０７９３（ＷＯ，Ａ１）

【文献】特開２０１９－２００５１５（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１７／００３４１７２（ＵＳ，Ａ１）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ ２１／６２

Ｇ０６Ｆ ２１／３３

(57)【特許請求の範囲】

【請求項1】

或るリソースを管理するリソース管理装置と、前記リソースへアクセスするアクセス装置と、前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に前記アクセス権限に対応するアクセストークンを前記アクセス装置に発行する認可装置とを含む情報処理システムであって、
前記リソース管理装置は、
前記アクセス装置からの前記アクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、
前記修飾子によって、前記リソースの構造関係、前記リソースが生成された期間、及び前記リソースが生成された場所のうちの１以上が限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、
を有することを特徴とする情報処理システム。

【請求項2】

前記修飾子は、前記アクセストークンが前記アクセス装置へ発行されるまでの前において、前記アクセス装置によって付与される、
ことを特徴とする請求項１記載の情報処理システム。

【請求項3】

前記修飾子は、前記アクセストークンが前記アクセス装置へ発行される前において、前記リソースの所有者によって付与される、
ことを特徴とする請求項１又は２記載の情報処理システム。

【請求項4】

或るリソースを管理するリソース管理装置であって、
前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、
前記修飾子によって、前記リソースの構造関係、前記リソースが生成された期間、及び前記リソースが生成された場所のうちの１以上が限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、
を有することを特徴とするリソース管理装置。

【請求項5】

或るリソースを管理するリソース管理装置が、
前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得手順と、
前記修飾子によって、前記リソースの構造関係、前記リソースが生成された期間、及び前記リソースが生成された場所のうちの１以上が限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行手順と、
を実行することを特徴とするリソース管理方法。

【請求項6】

或るリソースを管理するリソース管理装置に、
前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に認可装置から発行される前記アクセス権限に対応するアクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得手順と、
前記修飾子によって、前記リソースの構造関係、前記リソースが生成された期間、及び前記リソースが生成された場所のうちの１以上が限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行手順と、
を実行させることを特徴とするプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、情報処理システム、リソース管理装置、リソース管理方法及びプログラムに関する。

【背景技術】

【0002】

他者に部分的な権限を委譲するための技術仕様として、ＯＡｕｔｈが知られている（非特許文献１及び非特許文献２）。

【0003】

ＯＡｕｔｈに関するプレイヤ（登場人物）としては、リソースオーナ（ＲＯ）、リソースサーバ（ＲＳ）、リライングパーティ（ＲＰ）、認可サーバ（ＡＳ）が存在する。ＲＯは、データ等のリソースの所有者（オーナ）であり、サードパーティが提供する或るサービスを介して当該リソースを利用するユーザである。ＲＳは、ＲＯのリソースの管理先である（一般的にＡＳとＲＳの管理主体は同一である）。ＲＰは、当該或るサービスを提供するサードパーティである。ＲＰは、当該サービスの提供に際し、ＲＯから権限を委譲され、ＲＳに管理されているリソースに対してＲＯに代わってアクセスを実施する。ＡＳは、リソースに対するアクセス権限についてＲＰへの委譲の実施を行う。

【0004】

具体的には。まず、ＲＯがＲＰのサービスを利用する。その際、ＲＯは、ＡＳとＲＰを連携させることを選択する（ＲＰにアクセスした状態で、ＲＯは、ＲＰとＡＳとの連携を選択する）。ＲＯは、ＲＰからＡＳにリダイレクトされ、ＡＳ上でＲＰとの連携を認可する（権限の委譲を同意する）。その結果、ＲＰは、ＲＳが管理するリソースにアクセスするために必要なアクセストークンを入手することができる。

【0005】

ＯＡｕｔｈにおいて、他者に移譲する権限をｓｃｏｐｅという。ＡＳはどのような権限を委譲できるかを設計し、ＡＰＩリファレンスなどで公開する。ＲＰは、サービスを提供するために利用する権限をＡＰＩリファレンスから選択する。ＲＯは、ＲＰが要求する権限を確認し、同意した場合にＲＰに自身の権限を委譲する。

【先行技術文献】

【非特許文献】

【0006】

【文献】The OAuth 2.0 Authorization Framework (RFC6749)、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc6749＞

【文献】The OAuth 2.0 Authorization Framework: Bearer Token Usage (RFC6750)、［online］、インターネット＜ＵＲＬ：https://tools.ietf.org/html/rfc6750＞

【発明の概要】

【発明が解決しようとする課題】

【0007】

しかしながら、上記の従来技術では、ＡＳが最初に設計したｓｃｏｐｅのみの指定となるため、ＲＰが提供するサービスに必要以上の権限がＲＰに委譲されてしまう可能性が有る。

【0008】

本発明は、上記の点に鑑みてなされたものであって、他者に委譲する権限の範囲の柔軟性を向上させることを目的とする。

【課題を解決するための手段】

【0009】

そこで上記課題を解決するため、或るリソースを管理するリソース管理装置と、前記リソースへアクセスするアクセス装置と、前記リソースに対するアクセス権限の委譲が前記リソースの所有者によって許可された場合に前記アクセス権限に対応するアクセストークンを前記アクセス装置に発行する認可装置とを含む情報処理システムにおいて、前記リソース管理装置は、前記アクセス装置からの前記アクセストークンを伴う前記リソースへのアクセス要求に応じ、当該アクセストークンに対応するアクセス権限の範囲を示す情報として、前記認可装置が予め公開するアクセス権限に対して修飾子が付与された情報を取得する取得部と、 前記修飾子によって、前記リソースの構造関係、前記リソースが生成された期間、及び前記リソースが生成された場所のうちの１以上が限定されたアクセス権限の範囲で前記アクセス要求に応じた処理を実行する実行部と、を有する。

【発明の効果】

【0010】

他者に委譲する権限の範囲の柔軟性を向上させることができる。

【図面の簡単な説明】

【0011】

【図1】本発明の実施の形態における情報処理システムの構成例を示す図である。

【図2】本発明の実施の形態におけるリソースサーバ１０のハードウェア構成例を示す図である。

【図3】本発明の実施の形態における情報処理システムの機能構成例を示す図である。

【図4】アクセストークンの発行時の処理手順の一例を説明するためのシーケンス図である。

【図5】認可サーバ２０との連携の許否をユーザに問い合わせる画面の表示例を示す図である。

【図6】認可サーバ２０との連携の許否をユーザに問い合わせる画面におけるメニューが展開した例を示す図である。

【図7】権限の委譲の可否を問い合わせる画面の表示例を示す図である。

【図8】権限の委譲の可否を問い合わせる画面におけるメニューが展開した例を示す図である。

【図9】ｓｃｏｐｅの大きさ（範囲）を概念的に示す図である。

【図10】アクセストークンの行使時の処理手順の一例を説明するためのフローチャートである。

【発明を実施するための形態】

【0012】

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態における情報処理システムの構成例を示す図である。

【0013】

図１において、ＲＯ端末４０、ＲＰサーバ３０、認可サーバ２０及びリソースサーバ１０は、インターネット等のネットワークを介して接続される。

【0014】

ＲＯ端末４０は、データ等の或るソフトウェアリソース（以下、「対象リソース」という。）の所有者であるとともに、対象リソースへアクセスする或るサービス（以下、「対象サービス」という。）の利用者であるユーザが利用する端末である。例えば、ＰＣ（Personal Computer）、スマートフォン又はタブレット端末等がＲＯ端末４０として利用されてもよい。なお、当該ユーザは、ＯＡｕｔｈにおけるＲＯ（リソースオーナ）に相当する。

【0015】

ＲＰサーバ３０は、対象サービスを提供する１以上のコンピュータである。ＲＰサーバ３０は、対象サービスを提供するために、対象リソースに対してアクセスするための権限の委譲をＲＯから受けるための処理を実行する。当該処理は、ＯＡｕｔｈに準拠する。なお、ＲＰサーバ３０は、ＯＡｕｔｈにおけるＲＰ（リライングパーティ）として機能する。

【0016】

認可サーバ２０は、ＯＡｕｔｈにおけるＡＳとして機能する１以上のコンピュータである。

【0017】

リソースサーバ１０は、対象リソースを記憶及び管理し、ＯＡｕｔｈにおけるＲＳとして機能する１以上のコンピュータである。

【0018】

図２は、本発明の実施の形態におけるリソースサーバ１０のハードウェア構成例を示す図である。図２のリソースサーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

【0019】

リソースサーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

【0020】

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従ってリソースサーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

【0021】

なお、ＲＰサーバ３０、認可サーバ２０及びＲＯ端末４０も図２と同様のハードウェア構成を有してよい。

【0022】

図３は、本発明の実施の形態における情報処理システムの機能構成例を示す図である。図３において、ＲＰサーバ３０は、ＲＰＯＡｕｔｈ部３１及びスコープ判定部３２を有する。これら各部は、ＲＰサーバ３０にインストールされた１以上のプログラムが、ＲＰサーバ３０のＣＰＵに実行させる処理により実現される。

【0023】

認可サーバ２０は、ＡＳＯＡｕｔｈ部２１、スコープ設定部２２及びスコープ検証部２３を有する。これら各部は、認可サーバ２０にインストールされた１以上のプログラムが、認可サーバ２０のＣＰＵに実行させる処理により実現される。

【0024】

リソースサーバ１０は、ＲＳＯＡｕｔｈ部１１及びスコープ解析部１２を有する。これら各部は、リソースサーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

【0025】

以下、情報処理システムが実行する処理手順について説明する。図４は、アクセストークンの発行時の処理手順の一例を説明するためのシーケンス図である。なお、図４の処理手順は、ＯＡｕｔｈに準拠したものである。また、図４においてＲＯ端末４０が実行する処理は、例えば、ＲＯ端末４０にインストールされたＷｅｂブラウザがＲＯ端末４０に実行させる処理である。

【0026】

ステップＳ１０１において、ＲＯ端末４０は、ユーザによる所定の操作に応じ、対象サービスの利用要求をＲＰサーバ３０へ送信する。なお、ユーザは、ＲＰサーバ３０によって認証済みであるとする。したがって、ＲＰサーバ３０は、当該利用要求の要求元のユーザを特定可能であるとする。

【0027】

ＲＰサーバ３０のＲＰＯＡｕｔｈ部３１は、当該利用要求を受信すると、対象サービスに必要なｓｃｏｐｅの値をスコープ判定部３２へ照会する（Ｓ１０２）。ｓｃｏｐｅとは、ＯＡｕｔｈにおけるｓｃｏｐｅをいう。ＯＡｕｔｈにおけるｓｃｏｐｅとは、他者へ委譲される権限をいう。ｓｃｏｐｅに指定可能な値（すなわち、権限の範囲又は種類）は、予め認可サーバ２０によってＡＰＩリファレンスなどで公開される。以下、認可サーバ２０によって予め公開されているｓｃｏｐｅの値のリストを「既定リスト」という。

【0028】

スコープ判定部３２は、ＲＰＯＡｕｔｈ部３１による照会に応じ、対象サービスに必要なｓｃｏｐｅを判定する。スコープ判定部３２による判定は、予め設定され、補助記憶装置１０２等に記憶されている設定情報に基づいて行われる。すなわち、当該設定情報が、対象サービスに必要なｓｃｏｐｅを示す。当該設定情報は、ＯＡｕｔｈについて必要とされる、ＡＳに対するＲＰ自身の登録申請（ＲＰのサービスの開発者のアカウントの登録の申請）時に、ＡＳに対して申請されたｓｃｏｐｅを示す。すなわち、申請には、連携先情報（ＲＰに関する情報）、表示名、連絡先、ユーザから委譲を希望する権限＝ｓｃｏｐｅ等の情報が必要とされる。なお、ＡＳが申請を許可した場合にのみ、ＲＰはＯＡｕｔｈを利用することができる。

【0029】

本実施の形態では、当該設定情報として、既定リストのうちのいずれかのｓｃｏｐｅに係るアクセス権限の範囲を更に限定する内容が設定可能である。既定リストの或る値を更に限定する場合、当該値に対して限定内容を示す識別子（以下、「修飾子」という。）が付与される。修飾子の一例としては、例えば、以下のようなものが考えられる。

【0030】

（ａ）リソースの構造関係（親・子の関係など）に関する修飾子
例えば、リソースが写真の場合、
｛ｓｃｏｐｅ｝．｛ａｌｂｕｍ＿ｎａｍｅ｝
という修飾子が考えられる。ここで、｛ｓｃｏｐｅ｝は、既定リストのいずれかの値であり、「．｛ａｌｂｕｍ＿ｎａｍｅ｝」が修飾子を示す。当該修飾子は、ａｌｂｕｍ＿ｎａｍｅに係る特定のアルバム内の写真のみにアクセスを限定することを意味する。

【0031】

（ｂ）リソースが生成された期間に関する修飾子
例えば、ｓｃｏｐｅ．｛ＹＹＹＹ／ＭＭ／ＤＤ｝
という修飾子が考えられる。当該修飾子は、特定の日付（ＹＹＹＹ／ＭＭ／ＤＤ）に生成されたリソースのみにアクセスを限定することを意味する。
ｓｃｏｐｅ．｛ＹＹＹＹ／ＭＭ／ＤＤ－ＹＹＹＹ／ＭＭ／ＤＤ｝
のように、リソースが生成された期間が限定されてもよい。この際、「ＭＭ／ＤＤ」や「ＤＤ」は省略されてもよい。

【0032】

例えば、「ｐｈｏｔｏ」は、全ての写真へのアクセス権限を示す、既定リストのうちの１つのｓｃｏｐｅであるとすると、「ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」といった設定が可能である。ここで、「．ｓｐａｎ２０２０－２０２１」は、撮影された写真の期間を限定する修飾子を意味する。したがって、「ｓｃｏｐｅ＝ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」は、撮影期間が２０２０年から２０２１年までの写真に対してのみに限定されたアクセス権限を示すことになる。

【0033】

（ｃ）リソースが生成された場所
例えば、｛ｓｃｏｐｅ｝．｛建物名、都道府県名など｝
という修飾子が考えられる。当該修飾子は、特定の場所に関するリソースにのみアクセス権限を限定することを意味する。

【0034】

なお、上記したように、ＲＰの登録申請時にはｓｃｏｐｅの申請が必要であるが、本実施の形態では、修飾子付きのｓｃｏｐｅ（以下、「修飾子付きｓｃｏｐｅ」という。）が申請可能とされ、修飾子付きｓｃｏｐｅが申請されているとする。したがって、スコープ判定部３２は、申請済みの修飾子付きのｓｃｏｐｅをＲＰＯＡｕｔｈ部３１へ応答する（Ｓ１０３）。

【0035】

続いて、ＲＰＯＡｕｔｈ部３１は、当該修飾子付きｓｃｏｐｅを含む認可要求についてのリダイレクト要求をＲＯ端末４０へ応答する（Ｓ１０４）。当該リダイレクト要求の具体的な内容は、例えば、以下の通りである。
「HTTP/1.1 302 Moved Temporarily
Location: https://[ASの認可エンドポイント(公開情報)]/authorize?response_type=code&scope=photo&client_id=...」
このように、本実施の形態では、リダイレクト要求にｓｃｏｐｅがパラメータとして含まれ得る。

【0036】

当該応答を受信したＲＯ端末４０は、ＲＰサーバ３０について認可サーバ２０との連携の許否をユーザに問い合わせる画面を表示する。

【0037】

図５は、認可サーバ２０との連携の許否をユーザに問い合わせる画面の表示例を示す図である。図５が示す画面５１０において、｛｝で囲まれている部分は、実際には具体的なサービス名等によって置き換えられる。画面５１０は、メニュー５１１を含む。メニュー５１１がユーザによってクリックされると、画面５１０の状態は、図６に示すようになる。

【0038】

図６では、リダイレクト要求に含まれている修飾子付きｓｃｏｐｅに対して更に付与する修飾子の候補である、候補５１３及び候補５１４が選択肢として表示されている。斯かる候補は、当該修飾子付きｓｃｏｐｅの元のｓｃｏｐｅに対して付与可能な修飾子の一覧のうち、既に当該ｓｃｏｐｅに付与されている修飾子を除く修飾子であってもよい。ユーザは、自らの意志でＲＰサーバ３０に認可する権限を限定したい場合は、いずれかの候補を選択することで、当該権限に対して当該候補に応じた限定を与えることができる。

【0039】

画面５１０を介して、認可サーバ２０との連携に対して許可を示す操作が行われると、ＲＯ端末４０は、当該リダイレクト要求に応じ、修飾子付きｓｃｏｐｅを含む認可要求を認可サーバ２０へリダイレクトする（Ｓ１０５）。なお、画面５１０を介してユーザによって修飾子の追加が選択された場合（いずれかの修飾子の候補が選択された場合）、当該修飾子付きｓｃｏｐｅは、更に、追加された修飾子が付与されたものとなる。

【0040】

認可サーバ２０のＡＳＯＡｕｔｈ部２１は、リダイレクトされた当該認可要求を受信すると、当該認可要求に含まれるｓｃｏｐｅが修飾子付きｓｃｏｐｅであれば、当該修飾子付きｓｃｏｐｅの検証要求をスコープ検証部２３へ送信する（Ｓ１０６）。スコープ検証部２３は、当該検証要求に応じ、当該修飾子付きｓｃｏｐｅを検証する。例えば、当該ｓｃｏｐｅが修飾子の付与が許可されているｓｃｏｐｅであるか、当該修飾子の値が正しいか等が検証される。すなわち、ｓｃｏｐｅ別に修飾子の付与の可否や、付与可能な修飾子等が予め規定されている。続いて、スコープ検証部２３は、検証結果（ＯＫ又はＮＧ）をＡＳＯＡｕｔｈ部２１へ送信する（Ｓ１０７）。当該検証結果がＯＫであればステップＳ１０８以降が実行され、ＮＧであればステップＳ１０８以降は実行されない。

【0041】

ステップＳ１０８において、ＡＳＯＡｕｔｈ部２１は、従来のＯＡｕｔｈの手順に従ってＲＯ端末４０のユーザ（すなわち、対象リソースのＲＯ）の認証処理を実行する。認証に成功すると、ＡＳＯＡｕｔｈ部２１は、修飾子付きｓｃｏｐｅが示す権限の委譲の可否の問い合わせをＲＯ端末４０へ送信する（Ｓ１０９）。

【0042】

ＲＯ端末４０は、当該問い合わせに応じ、当該権限の委譲の可否を問い合わせる画面を表示する。

【0043】

図７は、権限の委譲の可否を問い合わせる画面の表示例を示す図である。図７が示す画面５２０において、｛｝で囲まれている部分は、実際には具体的なサービス名等によって置き換えられる。画面５２０は、メニュー５２１を含む。メニュー５２１がユーザによってクリックされると、画面５２０の状態は、図８に示すようになる。

【0044】

図８では、当該権限を示す修飾子付きｓｃｏｐｅに対して更に付与する修飾子の候補である、候補５２３及び候補５２４が選択肢として表示されている。斯かる候補は、当該修飾子付きｓｃｏｐｅの元のｓｃｏｐｅに対して付与可能な修飾子の一覧のうち、既に当該ｓｃｏｐｅに付与されている修飾子を除く修飾子であってもよい。ユーザは、自らの当該権限を限定したい場合は、いずれかの候補を選択することで、当該権限に対して当該候補に応じた限定を与えることができる。

【0045】

画面５２０を介して、ＲＰサーバ３０に対する権限の委譲の許可を示す操作が行われると、ＲＯ端末４０は、権限の委譲の許可を示す応答を認可サーバ２０へ送信する（Ｓ１１０）。当該応答には、修飾子付きｓｃｏｐｅも含まれる。当該修飾子付きｓｃｏｐｅは、画面５２０を介してユーザによって修飾子の追加が行われていない場合は、ステップＳ１０９においてＲＯ端末４０へ送信されたものと同じであり、画面５２０を介してユーザによって修飾子の追加が行われている場合は、更に、追加された修飾子が付与されたものである。

【0046】

認可サーバ２０のスコープ設定部２２は、当該応答を受信すると、当該応答に含まれている修飾子付きｓｃｏｐｅをＡＳＯＡｕｔｈ部２１へ設定する（Ｓ１１１）。ＡＳＯＡｕｔｈ部２１は、設定された修飾子付きｓｃｏｐｅが、ステップＳ１０６において検証を受けた修飾子付きｓｃｏｐｅから変更されている場合（修飾子が追加されている場合）には、設定された修飾子付きｓｃｏｐｅの検証要求をスコープ検証部２３へ送信する（Ｓ１１２）。スコープ検証部２３は、当該検証要求に応じ、当該修飾子付きｓｃｏｐｅを検証する。検証の内容は、ステップＳ１０６に応じた検証要求と同じでよい。続いて、スコープ検証部２３は、検証結果（ＯＫ又はＮＧ）をＡＳＯＡｕｔｈ部２１へ送信する（Ｓ１１３）。当該検証結果がＯＫであればステップＳ１１４が実行され、ＮＧであればステップＳ１１４は実行されない。

【0047】

ステップＳ１１４において、ＡＳＯＡｕｔｈ部２１は、ＯＡｕｔｈに規定された手順に従って、対象リソースに対するアクセストークンをＲＳＯＡｕｔｈ部１１に対して発行（送信）する。なお、Ｓ１１４は、アクセストークンをＲＰサーバ３０に発行する手順を意味し、ＯＡｕｔｈのＧｒａｎｔ ｔｙｐｅによって具体的な処理手順を読み替えるものとする。アクセストークンの発行に伴い、ＡＳＯＡｕｔｈ部２１は、当該アクセストークンに対応する修飾子付きｓｃｏｐｅを記憶しておく。アクセストークンに対応する修飾子付きｓｃｏｐｅの記憶方法は、ＯＡｕｔｈにおける、アクセストークンに対応するｓｃｏｐｅの記憶方法に準拠すればよい。

【0048】

ＲＰは、当該アクセストークン（以下、「対象トークン」という。）を行使することで、対象リソースへアクセス可能になる。

【0049】

なお、図４においては、アクセストークンが発行される前の過程における以下の３つのタイミングにおいて、ｓｃｏｐｅを限定することができる（ｓｃｏｐｅに対して修飾子を付与することができる）。

【0050】

（０）ＲＰがＡＳに登録する際のｓｃｏｐｅの提示のタイミング
その結果として、ステップＳ１０３において修飾子付きｓｃｏｐｅが応答される。

【0051】

（１）ユーザがＲＰサーバ３０のサービスを利用する際に、ＲＰサーバ３０側で認可リクエストを行うタイミング
ユーザが、画面５１０を介してｓｃｏｐｅを限定（ｓｃｏｐｅに修飾子を付与）する。

【0052】

（２）ユーザが認可サーバ２０を介してＲＰが提示した権限を認可するタイミング
ユーザが、画面５２０を介してｓｃｏｐｅを限定（ｓｃｏｐｅに修飾子を付与）する。

【0053】

但し、上記の（０）～（２）の全てのタイミングにおいて修飾子の付与が可能とされなければならないことを意図したものではなく、いずれか１以上のタイミングで修飾子の付与が可能とされればよい。

【0054】

なお、上記のように３つのタイミングでｓｃｏｐｅを限定可能とした場合、図９に示されるように、ｓｃｏｐｅの大きさ（範囲）を多段階に限定することができる。

【0055】

次に、アクセストークンの行使について説明する。図１０は、アクセストークンの行使時の処理手順の一例を説明するためのフローチャートである。図１０の処理手順は、例えば、図４のステップＳ１１４に続いて実行される。

【0056】

ステップＳ２０１において、ＲＰＯＡｕｔｈ部３１は、ＯＡｕｔｈに準拠した手順として、対象トークンを伴って対象リソースへのアクセス要求をリソースサーバ１０へ送信する。

【0057】

リソースサーバ１０のＲＳＯＡｕｔｈ部１１は、当該アクセス要求及び対象トークンを受信すると、ＯＡｕｔｈに準拠した手順として、対象トークンに対応するｓｃｏｐｅの問い合わせをＡＳＯＡｕｔｈ部２１へ送信する（Ｓ２０２）。当該問い合わせには対象トークンが含まれる。

【0058】

ＡＳＯＡｕｔｈ部２１は、当該問い合わせに応じ、対象トークンに対応付けられて記憶されているｓｃｏｐｅを含む応答をＲＳＯＡｕｔｈ部１１へ送信する（Ｓ２０３）。本実施の形態では、修飾子付きｓｃｏｐｅが当該応答に含まれる。当該応答の具体的な内容は、例えば、以下の通りである。
「HTTP 200 OK
Content-type:application/json
{ "scope":"scope.{album_name} scope.{YYYY-MM-DD}" ,…}」
すなわち、応答には、対象トークンに対応するｓｃｏｐｅが列挙され、当該ｓｃｏｐｅに修飾子が付与される。

【0059】

ＲＳＯＡｕｔｈ部１１は、当該応答を受信することで、当該応答に含まれている修飾子付きｓｃｏｐｅを取得する。続いて、ＲＳＯＡｕｔｈ部１１は、当該修飾子付きｓｃｏｐｅの意味（権限）の解析要求を、当該修飾子付きｓｃｏｐｅと共にスコープ解析部１２へ送信する（Ｓ２０４）。スコープ解析部１２は、当該解析要求に応じ、当該修飾子付きｓｃｏｐｅの意味を解析し、解析結果として、当該修飾子付きｓｃｏｐｅが意味するアクセス権限を含む応答をＲＳＯＡｕｔｈ部１１へ送信する（Ｓ２０５）。本実施の形態では、修飾子によって限定されたアクセス権限が応答される。例えば、修飾子付きｓｃｏｐｅが「ｓｃｏｐｅ＝ｐｈｏｔｏ．ｓｐａｎ２０２０－２０２１」であれば、撮影期間が２０２０年から２０２１年までの写真についてのみのアクセス権限であることを示す応答が送信される。

【0060】

続いて、ＲＳＯＡｕｔｈ部１１は、当該アクセス権限の範囲内において、ＲＰＯＡｕｔｈ部３１からのアクセス要求に応じた処理（対象リソースへのアクセス）を実行する（Ｓ２０６）。その結果、ＲＰＯＡｕｔｈ部３１の権限が、修飾子に基づいて限定される。

【0061】

続いて、ＲＳＯＡｕｔｈ部１１は、対象リソースへのアクセス結果をＲＰＯＡｕｔｈ部３１へ送信する（Ｓ２０７）。

【0062】

上述したように、本実施の形態によれば、ｓｃｏｐｅに対して修飾子を付与することで、当初のｓｃｏｐｅの権限の範囲を限定することができる。したがって、他者に委譲する権限の範囲の柔軟性を向上させることができる。その結果、サービスに必要な範囲に移譲する権限を限定することができる。

【0063】

また、ユーザが修飾子を付与することができるため、ユーザに有利な権限の限定化が可能となる。その結果、ユーザが意図しない権限の委譲を回避できる可能性を高めることができる。

【0064】

なお、本実施の形態において、リソースサーバ１０は、リソース管理装置の一例である。認可サーバ２０は、認可装置の一例である。ＲＰサーバ３０は、アクセス装置の一例である。ＲＳＯＡｕｔｈ部１１は、取得部及び実行部の一例である。

【0065】

以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

【符号の説明】

【0066】

１０ リソースサーバ
１１ ＲＳＯＡｕｔｈ部
１２ スコープ解析部
２０ 認可サーバ
２１ ＡＳＯＡｕｔｈ部
２２ スコープ設定部
２３ スコープ検証部
３０ ＲＰサーバ
３１ ＲＰＯＡｕｔｈ部
３２ スコープ判定部
４０ ＲＯ端末
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】