JP2020030759A

JP2020030759A - 権限委譲システム、情報処理装置およびその制御方法、並びにプログラム。

Info

Publication number: JP2020030759A
Application number: JP2018157512A
Authority: JP
Inventors: 和也北田; Kazuya Kitada
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2018-08-24
Filing date: 2018-08-24
Publication date: 2020-02-27

Abstract

【課題】認可サーバが署名付きアクセストークンをクライアントに発行した後に、そのアクセストークンの署名に用いた暗号鍵を削除した場合、リソースサーバにおいては該当する公開鍵による検証は無効となってしまう。リソースサーバで署名付きアクセストークンの検証が行えるようにする。【解決手段】署名付きアクセストークンに基づきサービスを提供するリソースサーバ２０４は、署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、無効となった鍵情報を管理する管理手段と、クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、管理手段にて管理する鍵情報に基づいて、クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、検証手段による検証の結果に基づいて、クライアントからの要求に対する応答を行う処理手段を備える。【選択図】図６

Description

本発明は、権限委譲システム、情報処理装置およびその制御方法、並びにプログラムに関する。

近年、ネットワーク上のＷｅｂサービスでは利用者がＷｅｂサービスの利用を認められているかどうかの認証・認可が行われている。また、Ｗｅｂサービスの多様化に伴って、複数のＷｅｂサービスが互いに連携を行い、サービス間で信頼関係を構築し、ユーザの同意のもとにセキュアに最低限必要なユーザの権限を委譲するシステムが必要とされている。そのシステムを構築するフレームワークの仕様の１つとして、ＯＡｕｔｈ２．０が公開されている。ＯＡｕｔｈ２．０では、Ｗｅｂサービスを提供するリソースサーバと、認証・認可を行う認可サーバが別々のサーバとして構成され、認可サーバとリソースサーバが互いに認証・認可情報を授受することで連携し、権限の委譲を可能としている。この認証・認可情報の授受にはアクセストークンが用いられることが一般的である。

トークンの譲渡を受けたシステムがトークンを使用する時点においても確実にトークンの検証をすることができる権限委譲システムについては、例えば、特許文献１のような方法がある。

特開２００７−１４９０１０号公報

しかしながら、認可サーバでアクセストークンの署名に用いられる秘密鍵・公開鍵のペアを削除し、リソースサーバで公開鍵を削除しても、削除した鍵で発行済みのアクセストークンは無効にすることはできない。そのため、発行済みのアクセストークンを持つクライアントがリソースサーバにアクセスしても、リソース取得エラーとなりリソースを取得することができない。さらに、リソースサーバは署名検証に失敗するため、アクセストークンが不正なトークンだと判断し、リソースを要求したクライアントを不正なクライアントと判断してしまう。例えば、認可サーバが署名付きアクセストークンをクライアントに発行した後に、そのアクセストークンの署名に用いた暗号鍵を削除した場合、その情報の通知によりリソースサーバにおいては該当する公開鍵による検証は無効となる。よって、リソースサーバでは署名付きアクセストークンの検証を行っても失敗し、リソースを取得する事ができない。

本発明では、認可サーバで暗号鍵が削除された場合においても、安全性を損なわずに署名付きアクセストークンの検証を行い、クライアントがリソースの取得を可能とすることを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、署名付きアクセストークンを発行する認可サーバと、前記署名付きアクセストークンに基づきサービスを提供するリソースサーバを含む権限委譲システムであって、前記リソースサーバは、署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを前記認可サーバから受け付けた際に、当該無効となった鍵情報を管理する第１の管理手段と、クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記第１の管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段とを有する。

本発明により、安全性を損なうことなく、認可サーバにおいて暗号鍵が削除された場合においても署名付きアクセストークンの検証が正しく行え、クライアントがリソースを取得することが可能となる。

本発明の一実施形態におけるコンピュータの構成内容を示す図。本発明の一実施形態におけるネットワーク構成図。アクセストークン発行と検証のシーケンス図。暗号鍵の削除と公開鍵の再取得のシーケンス図。本発明の一実施形態における認証・認可システムの機能ブロック図。第１の実施形態に係るＪＷＳアクセストークンの発行、検証のシーケンス図。認可サーバのＪＷＳアクセストークン発行処理のフローチャート。リソースサーバのＪＷＳアクセストークン検証処理のフローチャート。第２の実施形態に係るＪＷＳアクセストークン検証処理のフローチャート。第３の実施形態に係る削除鍵情報の問い合わせ処理のシーケンス図。

以下、本発明を実施するための形態について図面を用いて説明する。

［装置構成］
図１は、本発明を実施するための一実施形態に係る情報処理装置のシステム構成の例を示す図である。図１において、情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、及び通信インタフェース１０７を備える。また、情報処理装置内の各構成要素は、システムバス１０１を介して互いに通信可能に接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）やＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３がある。図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなども使用されることがある。

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

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

通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）やＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）、もしくはインターネットのような公衆回線等がある。

［ネットワーク構成］
図２は、本実施形態に係るネットワーク構成の例を示す図である。インターネット２１０には、コンピュータネットワーク２１１、２１２、２１３が接続されており、コンピュータネットワーク２１１には、認可サーバ２０１が接続されている。また、コンピュータネットワーク２１２にはクライアント２０３、コンピュータネットワーク２１３にはリソースサーバ２０４がそれぞれ接続されている。本実施形態においてリソースサーバ２０４は、インターネット２１０を跨いだコンピュータネットワーク上に接続されているが、認可サーバ２０１と同じＬＡＮに存在していてもよい。クライアント２０３は図２のようにコンピュータネットワーク２１２接続されている場合に限らず、コンピュータネットワーク２１１や２１３に接続されていてもよい。

クライアント２０３は認可サーバ２０１からアクセストークンを取得する。また、クライアント２０３は、取得したアクセストークンを使って、リソースサーバ２０４からＷｅｂサービス（以下、「サービス」と略称）の提供を受ける。なお、本実施形態において、認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４はいずれも、図１にて示した情報処理装置の構成を有するものとする。ただし、図１の構成に限定するものではなく、ディスプレイ装置１１４を備えていない、他の機能を備えている等、クライアントとサーバはそれぞれ異なる構成を有してもよいし、それぞれが他の構成でもよい。また、サーバは、単体のコンピュータに限らず、ラックマウント型の複数台のコンピュータで構成されたシステムであっても構わない。

［従来のアクセストークン発行と検証の流れ］
以下、従来技術におけるアクセストークン発行と検証の処理の流れについて説明する。図３は、従来技術における署名付きアクセストークン発行と検証に関するシーケンス図である。図２で説明した認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４間で連携が行われる。まず、リソースサーバ２０４は、認可サーバ２０１に対して後述する署名付きアクセストークンの検証に用いるための公開鍵を要求し、その応答として公開鍵を取得する（Ｓ３０１）。リソースサーバ２０４は、アクセストークンの署名を検証する署名ライブラリ（不図示）を有しており、署名ライブラリは取得した公開鍵を用いて署名の検証を行う。なお、認可サーバ２０１は複数の暗号鍵を保持してもよい。その場合、リソースサーバ２０４は認可サーバ２０１が保持する秘密鍵に対応するすべての公開鍵を取得してよい。Ｓ３０１の処理はリソースサーバ２０４の初回起動時等、クライアント２０３へのリソース提供前に一度行われればよい。

クライアント２０３は、認可サーバ２０１に対して認証情報又は認可コードを渡して署名付きアクセストークンを要求し、その応答として署名付きアクセストークンを取得する（Ｓ３０２）。この時の要求において、認証情報又は認可コードのいずれが用いられるかは、オーナーの違いによって異なる。クライアント２０３が処理を実施するオーナーである場合はクライアント２０３自体が認証を行い、クライアント２０３が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡すことになる。

次に、クライアント２０３は、取得した署名付きアクセストークンを使ってリソースサーバ２０４に対してサービスの提供を要求する（Ｓ３０３）。リソースサーバ２０４は、受け取った署名を元にアクセストークンが適正か否か検証する（Ｓ３０４）。リソースサーバ２０４は、保持する署名ライブラリ（不図示）を用いて署名を検証することで、適正な認可サーバで発行されたアクセストークンであることを確認できる。そして、アクセストークンが適正であればリソースサーバ２０４はリソースを提供するための処理を実行し（Ｓ３０５）、リソースをクライアント２０３に返す。また、アクセストークンが適正でなければ、リソースサーバ２０４は処理（Ｓ３０５）を行わず、もしくは、エラー用の処理を行って、リソース取得エラーをクライアント２０３に返す。

［公開鍵の再取得の流れ］
図４は、認可サーバ２０１で暗号鍵を削除した場合における公開鍵の再取得に関するシーケンス図である。図２で説明した認可サーバ２０１、リソースサーバ２０４間で連携が行われる。認可サーバ２０１は保持している暗号鍵を削除する（Ｓ４０１）。これにより、以降、削除された暗号鍵を用いては署名が行われないこととなる。一方、リソースサーバ２０４には削除された暗号鍵に対応する公開鍵が保持されているため、公開鍵の更新を促す必要がある。そのため、認可サーバ２０１は、暗号鍵が更新された旨をリソースサーバ２０４に通知する（Ｓ４０２）。

次に、リソースサーバ２０４は、更新された公開鍵を認可サーバ２０１に要求し、取得する（Ｓ４０３）。以降は、リソースサーバ２０４は、更新された公開鍵を用いて、クライアント２０３から受信する署名付きアクセストークンを検証する。これにより、例えば認可サーバ２０１が保持している秘密鍵が流出したとしても、その鍵を削除し、リソースサーバ２０４が保持する公開鍵を更新すればよい。具体的には、悪意あるクライアント２０３が流出した鍵で署名されたアクセストークンでリソースサーバ２０４にアクセスしたとしても、リソースサーバ２０４ではそのアクセストークンの検証に必要な公開鍵は既に保持されていない。よって、リソースサーバ２０４側ではアクセストークンの署名検証において適正でないと判断され、その署名は無効となり、リソースの取得を防止することができる。

以上、署名付きアクセストークンの検証および暗号鍵の削除時におけるシーケンスについて説明した。しかし、認可サーバ２０１がアクセストークンをクライアント２０３に発行した後、そのアクセストークンの署名に用いた暗号鍵を削除した場合、リソースサーバ２０４では配布する公開鍵が更新される。その結果、そのアクセストークンの検証では適正でないと判定される。よって、クライアント２０３が正規の手続きを経て取得したアクセストークンを用いてリソースサーバ２０４にアクセスしたにも関わらず、リソースを取得する事ができないという状態が生じうる。

以下、本発明の実施形態に係る構成について説明する。

＜第１の実施形態＞
［アクセストークンおよびアクセストークンに紐付くユーザ情報を格納するＪＷＳ］
本実施形態においては、署名付きのアクセストークンとして、通常のアクセストークンの代わりにアクセストークン情報およびリソースオーナー情報であるアクセストークンに紐付くユーザ情報を格納するＪＷＳ（以降、「ＪＷＳアクセストークン」）を用いる。以下、本実施形態で用いるＪＷＳアクセストークンについて詳述する。

ＯＡｕｔｈ２．０で利用可能なＪＷＳ（ＪＳＯＮＷｅｂＳｉｇｎａｔｕｒｅ）は、ＪＷＴ（ＪＳＯＮＷｅｂＴｏｋｅｎ）で表現されたコンテンツをデジタル署名やＭＡＣｓ（ＭｅｓｓａｇｅＡｕｔｈｅｎｔｉｃａｔｉｏｎＣｏｄｅｓ）により保護して表現する手段である。また、ＪＷＴは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔＯｂｊｅｃｔＮｏｔａｔｉｏｎ）をベースとしたデータ構造を用いたＵＲＬセーフなクレームの表現方法である。ＪＷＳ、ＪＷＴについては、各々ＲＦＣ（ＲＦＣ７５１５（ＪＷＳ）、ＲＦＣ７５１９（ＪＷＴ））として仕様化、公開されている。

本実施形態で使用するＪＷＳアクセストークンに含まれるクレームは、以下である。

表１のクレーム名クラス“ＲｅｇｉｓｔｅｒｅｄＣｌａｉｍ”の各クレームは、ＪＷＴのＲＦＣ７５１９で予め定義されたクレームで以下である。すなわち、ＪＷＴの発行者の識別子“ｉｓｓ”（Ｉｓｓｕｅｒ）、ＪＷＴの主語となる主体の識別子“ｓｕｂ”（Ｓｕｂｊｅｃｔ）、ＪＷＴを利用することが想定された主体の識別子一覧“ａｕｄ”（Ａｕｄｉｅｎｃｅ）、ＪＷＴの有効期限“ｅｘｐ”（ＥｘｐｉｒａｔｉｏｎＴｉｍｅ）、ＪＷＴが有効になる日時“ｎｂｆ”（ＮｏｔＢｅｆｏｒｅ）、ＪＷＴのための一意な識別子“ｉａｔ”（ＩｓｓｕｅｄＡｔ）、“ｊｔｉ”（ＪＷＴＩＤ）を表す。上記“ｅｘｐ”、“ｎｂｆ”、“ｉａｔ”に指定する日時はＩｎｔＤａｔｅで、１９７０−０１−０１Ｔ０：０：０ＺＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表わすＪＳＯＮ数値である。またこれらの“ＲｅｇｉｓｔｅｒｅｄＣｌａｉｍ”の使用は任意である。

“ＲｅｇｉｓｔｅｒｅｄＣｌａｉｍ”に関し、具体的に本実施形態においては、認可サーバ２０１が、“ｉｓｓ”として認可サーバ２０１のＵＲＩ、“ｓｕｂ”としてユーザのＵＵＩＤ（ＵｎｉｖｅｒｓａｌｌｙＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ）、“ａｕｄ”としてリソースサーバ２０４のＵＲＩ、“ｅｘｐ”として本ＪＷＴ発行時から３６００秒、すなわち“ｉａｔ”の値＋３６００、“ｎｂｆ”として本ＪＷＴ発行時、すなわち“ｉａｔ”と同じ値、“ｊｔｉ”として認可トークン情報の認可トークンＩＤを設定する。

表１のクレーム名クラス“ＰｒｉｖａｔｅＣｌａｉｍ”の各クレームは、認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、クライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”を表す。ＪＷＴのＲＦＣ７５１９によると、“ＰｒｉｖａｔｅＣｌａｉｍ”はＪＷＴ発行者と利用者の合意のものとで使用するプライベートクレーム名クラスで、他に定義されたクレーム名と衝突のないことを前提とする。本実施形態では、“ＰｒｉｖａｔｅＣｌａｉｍ”クラスのクレーム名に認可トークン情報（認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、認可トークンクライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”）と、認可トークンに紐付く属性情報（ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、テナントＩＤ”ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”）を持つ。表１のＪＷＳアクセストークンに含まれるクレームの内容や、認可サーバ２０１による発行方法、リソースサーバ２０４における使用方法については後述する。

“ＰｒｉｖａｔｅＣｌａｉｍ”に関し、具体的に本実施形態においては、認可サーバ２０１が、認可情報として“ａｕｔｈｚ：ｓｃｏｐｅｓ”、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”のクレームを設定する。すなわち、“ａｕｔｈｚ：ｓｃｏｐｅｓ”としてリソースサーバが取得を許可するリソースを表すスコープリストを、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”としてリソースサーバにアクセスするクライアントのＩＤを設定する。さらに、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”のトークンに紐付く属性情報として、“ｓｕｂ”に設定したユーザＩＤのユーザの情報を表すクレームを以下のように設定する。すなわち、“ｅｘｔ：ｆｎａｍｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのファーストネーム、“ｅｘｔ：ｌｎａｍｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのラストネーム、“ｅｘｔ：ｌｏｃａｌｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのロケール名、“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”として“ｓｕｂ”に設定したＵＵＩＤのユーザが所属するテナントＩＤ、“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”として“ｓｕｂ”に設定したＵＵＩＤのユーザの電子メールアドレス、“ｅｘｔ：ａｐｐｉｄ”としてクライアントアプリケーションのＩＤであるアプリケーションＩＤを設定する。詳細は後述する。

認可サーバ２０１は、表１のクレームをＪＷＴの仕様であるＲＦＣ７５１９によりＪＳＯＮとしてエンコードする。更に、認可サーバ２０１は、ＪＷＳの仕様であるＲＦＣ７５１５のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表１のクレームのＪＳＯＮ表現、すなわちＪＷＴペイロード）をコンパクトなＵＲＬ−ｓａｆｅ文字列として表現符号化する。本実施形態のＪＷＳアクセストークンは、ＪＷＳコンパクトシリアライゼーション仕様に従い、エンコード済ＪＷＳヘッダー、エンコード済ＪＷＴペイロード、およびエンコード済ＪＷＳ署名を、この順序でピリオド（‘．’）文字を区切り文字として連結した文字列である。

本実施形態においては、ＪＷＳヘッダーとしてＪＷＳの署名に使われる暗号アルゴリズムを識別する“ａｌｇ”（アルゴリズム）を用いる。具体的に本実施形態においては、“ａｌｇ”として“ＲＳ２５６”（ＲＳＡＳＳＡ−ＰＫＣＳ１＿ｖ１＿５ｕｓｉｎｇＳＨＡ−２５６）を用いる。“ＲＳ２５６”文字列は、“ａｌｇ”の値としてＩＡＮＡＪＳＯＮＷｅｂＳｉｇｎａｔｕｒｅａｎｄＥｎｃｒｙｐｔｉｏｎＡｌｇｏｒｉｔｈｍｓレジストリに登録されており、ＪＳＯＮＷｅｂＡｌｇｏｒｉｔｈｍｓ（ＪＷＡ）仕様（ＲＦＣ７５１８）のＳｅｃｔｉｏｎ３．１で定義されている。

なお、本実施形態においてＪＷＳの署名に使われる暗号アルゴリズム“ＲＳ２５６”で使用する秘密鍵・公開鍵の鍵ペアは、認可サーバ２０１が予め生成しておき、後述する暗号鍵管理テーブルで管理する。またＪＷＳの署名を検証する公開鍵は、前述の通りＪＷＳアクセストークンを検証するリソースサーバ２０４の初回起動時に取得しておく。詳細は後述する。

［ソフトウェア構成］
図５（Ａ）は、本実施形態に係る認可サーバ２０１の機能（ソフトウェア構成）の例を示す。テナント管理部５０１、ユーザ管理部５０２、及びクライアント管理部５０３は、それぞれテナント情報の管理、ユーザ情報の管理、クライアント情報の管理を行う。ＪＷＳアクセストークン発行部５０４は、ＪＷＳアクセストークンの発行を行い、発行されたＪＷＳアクセストークンの情報は発行済みＪＷＳアクセストークン管理部５０５に保管される。リソースサーバ情報管理部５０６は、認可サーバ２０１と連携するリソースサーバ２０４に関する情報を管理する。

以下、表２〜表９を用いて、図５（Ａ）に示した認可サーバ２０１の各機能ブロックが管理するデータテーブルについて詳述する。各機能ブロックは、下記の表に示されたデータテーブルに基づいてＪＷＳアクセストークンを発行、検証する。詳細は後述する。

表２、表３は、本実施形態に係る認可サーバ２０１のユーザ管理部５０２が管理するユーザ管理テーブル（表２）、及びユーザ属性管理テーブル（表３）である。

表２のユーザ管理テーブルは、ユーザＩＤ項目、ユーザＩＤの内部表現であるＵＵＩＤ（ＣｌｉｅｎｔＩＤ）項目、ユーザＩＤに対応するパスワードを示すＰａｓｓｗｏｒｄ項目、ユーザ種別を示すＵｓｅｒＴｙｐｅ項目を含んで構成される。認可サーバ２０１は、ＵＵＩＤ（ＣｌｉｅｎｔＩＤ）、Ｐａｓｓｗｏｒｄの情報の組を検証し、正しければ認証情報を生成することで、各ユーザもしくはクライアントを認証する機能（不図示）を備える。

表３のユーザ属性管理テーブルは、ユーザＩＤの内部表現であるＵＵＩＤ項目、ＵＵＩＤのユーザの姓を示すＦｉｒｓｔＮａｍｅ項目、名を示すＬａｓｔＮａｍｅ項目、ロケールを示すＬｏｃａｌｅ項目、同ユーザの所属するテナントを示すＴｅｎａｎｔＩＤ項目、同ユーザの電子メールアドレスを示すＥｍａｉｌ項目、同ユーザの使用できるサービスを示すＳｅｒｖｉｃｅＩＤ項目を含んで構成される。

表４は、本実施形態に係る認可サーバ２０１のクライアント管理部５０３が管理するクライアント管理テーブル（表４）である。

表４のクライアント管理テーブルは、クライアントＩＤを示すＣｌｉｅｎｔＩＤ項目、ＣｌｉｅｎｔＩＤのクライアントのクライアント名を示すＣｌｉｅｎｔＮａｍｅ項目、ＯＡｕｔｈ２．０（ＲＦＣ６７４９）プロトコル等で使用する同クライアントのリダイレクトＵＲＬを示すＲｅｄｉｒｅｃｔＵＲＬ、同クライアントの使用できるサービスを示すＳｅｒｖｉｃｅＩＤ項目を含んで構成される。

表５は、本実施形態に係る認可サーバ２０１のリソースサーバ情報管理部５０６が管理するサービス管理テーブル（表５）である。

表５のサービス管理テーブルは、リソースサーバで提供するリソースに関するサービスを表すサービスＩＤを示すＳｅｒｖｉｃｅＩＤ項目、ＳｅｒｖｉｃｅＩＤに相当するサービスをリソースとして表し、ＯＡｕｔｈ２．０プロトコルなどの認可要求のスコープに指定される内容であるＳｃｏｐｅ項目、ＳｅｒｖｉｃｅＩＤに相当するサービス（リソース）を提供するリソースサーバのＵＲＬを示すＵＲＬ項目を含んで構成される。

表６〜表９は、本実施形態に係る認可サーバ２０１のＪＷＳアクセストークン発行部５０４および発行済みＪＷＳアクセストークン管理部５０５が管理、参照するトークン管理テーブル（表６）、リフレッシュトークン管理テーブル（表７）、トークン属性管理テーブル（表８）、暗号鍵管理テーブル（表９）である。

表６のトークン管理テーブルは、トークンＩＤを示すＴｏｋｅｎＩＤ項目、アクセストークン、認可コードなど、トークンＩＤのトークンタイプを示すＴｏｋｅｎＴｙｐｅ項目、トークンＩＤの有効期限を秒（ｓｅｃ）で示すＥｘｐｉｒａｔｉｏｎＴｉｍｅ項目、ＯＡｕｔｈ２．０プロトコルなどの認可要求のスコープに指定される内容であるＳｃｏｐｅ項目、ＯＡｕｔｈ２．０プロトコルなどで使用するトークンＩＤのＧｒａｎｔＴｙｐｅを示すＧｒａｎｔＴｙｐｅ項目を含んで構成される。

表７のリフレッシュトークン管理テーブルは、ＯＡｕｔｈ２．０プロトコルなどで使用する、リフレシュトークンを管理するテーブルである。リフレッシュトークン管理テーブルは、トークンＩＤを示すＴｏｋｅｎＩＤ項目、トークンＩＤのリフレッシュトークンのＩＤを示すＲｅｆｒｅｓｈＴｏｋｅｎＴｙｐｅ項目、リフレッシュトークンＩＤの有効期限を秒で示すＲｅｆｒｅｓｈＴｏｋｅｎＥｘｐｉｒａｔｉｏｎＴｉｍｅ項目を含んで構成される。

表８のトークン属性管理テーブルは、ＯＡｕｔｈ２．０プロトコルなどで使用する、トークン属性を管理するテーブルである。トークン属性管理テーブルは、トークンＩＤを示すＴｏｋｅｎＩＤ項目、トークンＩＤの発行要求元のクライアントＩＤを示すＣｌｉｅｎｔＩＤ項目、トークンＩＤに紐付くＵＵＩＤを示すＵＵＩＤ項目、クライアントＩＤのアプリケーション（サービス管理テーブル（表５）のサービスＩＤのサービスを利用する）でトークンＩＤを用いるアプリケーションを示すＡｐｐｌｉｃａｔｉｏｎＩＤ項目を含んで構成される。

表９の暗号鍵管理テーブルは、アクセストークンのデジタル署名で使用する、サービスに対して使用する暗号鍵を管理するテーブルである。暗号鍵管理テーブルは、サービスＩＤを示すＳｅｒｖｉｃｅＩＤ項目、サービスＩＤに紐づいてデジタル署名に用いられる鍵の識別子を示すＫｅｙＩＤ項目、デジタル署名で利用されるアルゴリズムを示すＡｌｇｏｒｉｔｈｍ項目、署名生成に用いる秘密鍵を示すＰｒｉｖａｔｅＫｅｙ項目、署名検証に用いる公開鍵を示すＰｕｂｌｉｃＫｅｙ項目を含んで構成される。なお、表９におけるＰｒｉｖａｔｅＫｅｙ項目、ＰｕｂｌｉｃＫｅｙ項目の各値は”＊＊”により省略して記述している。

図５（Ｂ）は、本実施形態に係るリソースサーバ２０４の機能（ソフトウェア構成）の例を示す。リソース管理部５１０は、リソース情報の管理（後述するスコープとリソースの対応関係の定義を含む）を行う。ＪＷＳアクセストークン管理部５１１は、ＪＷＳアクセストークン情報の管理を行う。ＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンの検証を行う。削除鍵情報管理部５１３は、削除された鍵情報の管理を行う。認可サーバ情報管理部５１４は、リソースサーバ２０４と連携する認可サーバ２０１に関する情報を管理する。

表１０は、リソースサーバ２０４の削除鍵情報管理部５１３が管理・参照する削除鍵管理テーブル（表１０）である。

表１０の削除鍵情報管理テーブルは、ＪＷＳアクセストークンの検証で用いる、認可サーバ２０１側で削除された鍵を管理するテーブルである。削除鍵管理テーブルは、認可サーバ２０１で削除された秘密鍵を示すＫｅｙＩＤ項目を含んで構成される。秘密鍵の削除が行われていない場合は削除鍵管理テーブルで管理する項目はないため、テーブルの中身は空となっている。詳細は後述する。

［本実施形態に係るＪＷＳアクセストークン発行と検証の流れ］
図６は、本実施形態に係るＪＷＳアクセストークン発行と検証に関するシーケンス図である。認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４間で連携が行われる。

本実施形態では、ＯＡｕｔｈ２．０における認可コードグラントのフローを用いたＪＷＳアクセストークンの発行と検証について述べる。ＪＷＳアクセストークンの発行と検証については、認可コードグラントだけでなく、ＯＡｕｔｈ２．０にあるクライアントクレデンシャルグラント、リソースオーナーパスワードクレデンシャルグラント、インプリシットグラント等を用いてもよい。これらについては公知の方法を利用可能であるとし、ここでは説明を省略する。

ＯＡｕｔｈ２．０プロトコルにおいては、アクセストークン発行などのフローを開始する前に、クライアント２０３を認可サーバ２０１に登録する。クライアント２０３を認可サーバ２０１に登録する方法は、通常、エンドユーザとの対話を伴うＨＴＭＬ登録フォーム（不図示）を持つことになる。本実施形態においては、予め必要なクライアント２０３は登録されているものとする。クライアント２０３の登録の際、認可サーバ２０１はクライアント２０３に対してクライアントＩＤ、パスワードを発行し、表２のユーザ管理テーブルのＵＵＩＤ（ＣｌｉｅｎｔＩＤ）項目に発行したクライアントを、Ｐａｓｓｗｏｒｄ項目に発行したパスワードを登録する。そして、後述するアクセストークンに付与するＳｃｏｐｅに関連付けられたサービスＩＤの値を、表４のクライアント管理テーブルに登録するものとする。

さらには、ＯＡｕｔｈ２．０の認可コードの取得フローに従い、認可サーバ２０１は、ユーザ管理テーブル（表２）のユーザＩＤに相当するリソースオーナーの認証後、トークン管理テーブル（表６）と、トークン属性管理テーブル（表８）のように認可コードを登録し、クライアント２０３が認可コードを取得する。

リソースサーバ２０４は、前述のように初回起動時に認可サーバ２０１から公開鍵情報を取得しておく。このとき取得する情報としては、表９で示した暗号鍵管理テーブルからＫｅｙＩＤ項目、およびＰｕｂｌｉｃＫｅｙ項目の値を抽出したものである。なお、公開鍵情報の取得はリソースサーバ２０４の起動時以外でもよく、アクセストークンの検証を行う前に取得できていればよいので、取得するタイミングについては特に限定されるものではない。以下、図６におけるフローを詳述する。

クライアント２０３が認可サーバ２０１に、ＯＡｕｔｈ２．０プロトコルの仕様に従い認可コード、各種クレデンシャル（認証情報又は認可コード）を示してアクセストークンの発行を要求する（Ｓ６０１）。認可サーバ２０１は、要求に応じてＪＷＳアクセストークンを発行する（Ｓ６０２）。ここで、図７のフローチャートを利用して本実施形態における認可サーバ２０１によるＪＷＳアクセストークンの発行について説明する。本処理は、例えば、認可サーバ２０１のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。

Ｓ７０１にて、認可サーバ２０１のＪＷＳアクセストークン発行部５０４は、前記ＪＷＳアクセストークン発行の要求を受信する。具体的には、本実施形態の場合、以下のようなＪＷＳアクセストークン発行要求を受信する。ここでの発行要求は一例であり、これに限定するものではない。

POST /token HTTP/1.1
Host: auth.server.example.com
Authorization: Basic NTIzZWUyMGM5ZjM5QDI0NDliYXh0OnBhc3N3b3Jk
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AipziOBeZoQYbJS6WxSbKB
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fredirect

Ｓ７０２にて、ＪＷＳアクセストークン発行部５０４は、上記要求のＡｕｔｈｏｒｉｚａｔｉｏｎヘッダー部にＢａｓｅ６４符号化されて含まれるＣｌｉｅｎｔＩＤおよびパスワードを用いて認証処理を行う。本実施形態の場合、Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダーに含まれるＢａｓｅ６４符号を復号化し、表２のユーザ管理テーブルのＵＵＩＤ（ＣｌｉｅｎｔＩＤ）およびＰａｓｓｗｏｒｄの組と比較して認証する。また、ＯＡｕｔｈ２．０の仕様に従い、ＪＷＳアクセストークン発行部５０４は、表８のトークン属性テーブルを参照し、ＪＷＳアクセストークン要求に含まれる認可コード項目（ｃｏｄｅ＝ＡｉｐｚｉＯＢｅＺｏＱＹｂＪＳ６ＷｘＳｂＫＢ）がＴｏｋｅｎＩＤ項目に存在するか否かを確認する。さらに、ＪＷＳアクセストークン発行部５０４は、ＴｏｋｅｎＩＤに対応するＣｌｉｅｎｔＩＤ項目を確認し、該ＣｌｉｅｎｔＩＤ項目に対応するリダイレクトＩＤを表４のクライアント管理テーブルから検索して、ＪＷＳアクセストークン要求に含まれるリダイレクトＵＲＩ項目（ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ％３Ａ％２Ｆ％２Ｆｃｌｉｅｎｔ％２Ｅｅｘａｍｐｌｅ％２Ｅｃｏｍ％２Ｆｒｅｄｉｒｅｃｔ）に一致するか否かを確認する。

Ｓ７０３にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０２の認証の成否を判定する。認証に失敗したと判定された場合は（Ｓ７０３にてＮＯ）Ｓ７１０へ進み、認証に成功したと判定された場合は（Ｓ７０３にてＹＥＳ）Ｓ７０４へ進む。

Ｓ７０４にて、ＪＷＳアクセストークン発行部５０４は、権限検証を行う。すなわち、ＪＷＳアクセストークン発行部５０４は、表４のクライアント管理テーブルのＣｌｉｅｎｔＩＤに対応するＳｅｒｖｉｃｅＩＤを参照し、さらに表５のサービス管理テーブルのＳｅｒｖｉｃｅＩＤに対応するＳｃｏｐｅが存在するか否かを確認する。

Ｓ７０５にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０４におけるＳｃｏｐｅの存在確認により、ＪＷＳアクセストークン発行要求の権限検証の成否を判定する。ＣｌｉｅｎｔＩＤに対応するＳｃｏｐｅが存在しないと判定された場合（Ｓ７０５にてＮＯ）Ｓ７１０へ進み、権限検証に成功、すなわちＣｌｉｅｎｔＩＤに対応するＳｃｏｐｅが存在したと判定された場合（Ｓ７０５にてＹＥＳ）Ｓ７０６へ進む。

Ｓ７０６にて、ＪＷＳアクセストークン発行部５０４は、クライアント認証、権限検証したクライアントの情報に従ってＪＷＳアクセストークンのペイロードとなるＪＷＴを生成する。本実施形態のＪＷＴは、表１のＪＷＳトークンに含まれるクレームに示したようなクレームを持つ。具体的には、ＪＷＳアクセストークン発行部５０４は、ＪＷＳアクセストークン発行の要求情報、表３〜表５、表９を参照し、表１に示した構成のクレームを以下のように設定する。

まず、ＪＷＳアクセストークン発行部５０４は、ＪＷＳヘッダーとして以下を設定する。Ｓ７０４で参照したＳｅｒｖｉｃｅＩＤに対応する表９のＫｅｙＩＤ項目、Ａｌｇｏｒｉｔｈｍ項目から“ｋｉｄ”：“２”、“ａｌｇ”：“ＲＳ２５６”が設定される。そして、“ｔｙｐ”：“ＪＷＴ”が設定される。

次に、ＪＷＳアクセストークン発行部５０４は、ＪＷＴペイロードとして以下を設定する。ＪＷＴの発行者の識別子“ｉｓｓ”（Ｉｓｓｕｅｒ）として、認可サーバ２０１のＵＲＩ“ｈｔｔｐｓ：／／ａｕｔｈ．ｅｘａｍｐｌｅ．ｃｏｍ”が設定される。ＪＷＴの主語となる主体の識別子“ｓｕｂ”（Ｓｕｂｊｅｃｔ）として、ＪＷＳアクセストークン発行要求に含まれる認可コードに対応するリソースオーナーのＩＤである表１のＵＵＩＤ“１ｃｅ４２ｆ７４−１２２５−４ｃｂｂ−ｂ２３ｆ−ｆ５２５ｄａｂｃ３ｃｆｄ”が設定される。ＪＷＴを利用することが想定された主体の識別子一覧“ａｕｄ”（Ａｕｄｉｅｎｃｅ）として、Ｓ７０４で検証したＳｃｏｐｅに相当するリソースサーバのＵＲＬとして、表５のＵＲＬ項目の“ｈｔｔｐｓ：／／ｓｔｏｒｅ．ｓｒｖ．ｅｘａｍｐｌｅ．ｃｏｍ”が設定される。ＪＷＴの有効期限“ｅｘｐ”（ＥｘｐｉｒａｔｉｏｎＴｉｍｅ）として、本ＪＷＴ発行時から３６００秒、すなわち本実施形態の場合、“ｉａｔ”の値＋３６００である“１４７２７１３４１３”が設定される。“ｎｂｆ”として本ＪＷＴ発行時、すなわち“ｉａｔ”と同じ値“１４７２７０９８１３”が設定される。本ＪＷＳアクセストークンの発行時に、認可トークンを表６のトークン管理テーブルに示すように発行し、“ｊｔｉ”として該認可トークンの認可トークンＩＤ“ｂ２６５２ｆ６ｄ７５ｂ１４ａａ４９ａｄｆｅ８９ｂ８８０８ｂ３３７ｅｆ２７６ｅ８ｄ１３６３４００ｄ９８ｆａｂ１００ｃ７４６３ｄｆ０”が設定される。

次に、ＪＷＳアクセストークン発行部５０４は、ＪＷＴのプライベートクレームを生成する。具体的には、認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、認可トークンクライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”が設定されるが、表３〜表５を参照し、ＪＷＳアクセストークン発行要求のクライアントＩＤ、リソースオーナーＩＤであるユーザＩＤ（ＵＵＩＤ）に紐付く値が設定される。

すなわち、“ａｕｔｈｚ：ｓｃｏｐｅｓ”として表６のＳｃｏｐｅｓ項目である“［ｃｌｉｅｎｔ．ＳｔｏｒｅＳｅｒｖｉｃｅ］”、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”として表４のＣｌｉｅｎｔＩＤ項目の“５２３ｅｅ２０ｃ９ｆ３９＠２４４９ｂａｘｔ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”として表３の“Ｊｏｈｎ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”として表３の“Ｄｏｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”として表３の“ｅｎ＿ＵＳ．ｕｔｆ−８”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”として表３の“１７０ＢＡ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”として表３の“ｊｏｈｎ．ｄｄｏ＠ｅｘａｍｐｌｅ．ｃｏｍ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”として表８のＡｐｐｌｉｃａｔｉｏｎＩＤ項目である“４２ｃ５ａ９６２６０９８４５９ｅ９６ｄ４ｂａｃｄ７３ｃ２９８２３３９２ａ７６ａ０２ｃｃ９４ｄ３６９８５ｂ７ｄｃ０ｄ７９０ｂ９ａ４”が設定される。

まとめると、Ｓ７０６、Ｓ７０７により、下に示す表１１のようにＪＷＴペイロードが指定される。

次に、Ｓ７０８にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０４で参照したＳｅｒｖｉｃｅＩＤに対応する表９のＡｌｇｏｒｉｔｈｍ項目、ＰｒｉｖａｔｅＫｅｙ項目からデジタル署名に用いるアルゴリズムと秘密鍵を決定する。そして、ＪＷＳの仕様であるＲＦＣ７５１５のコンパクトシリアライゼーション仕様に従い、決定したアルゴリズムと秘密鍵を用いてデジタル署名を行う。さらに、ＪＷＳアクセストークン発行部５０４は、デジタル署名されたＪＷＴペイロードをコンパクトなＵＲＬ−ｓａｆｅ文字列として表現符号化（ＢＡＳＥ６４ＵＲＬエンコード）する。

次に、Ｓ７０９にて、ＪＷＳアクセストークン発行部５０４は、エンコード済のＪＷＳヘッダー、エンコード済のＪＷＴペイロード、およびエンコード済のＪＷＳ署名を、この順序でピリオド（‘．’）文字を区切り文字として連結した文字列にして、以下のようなＪＷＳアクセストークンを生成し、ＪＷＳトークンとして発行する。以下のＪＷＳアクセストークンは一部を省略している。そして、本処理フローを終了する。

eyJraWQiOiJrMSIsImFsZyI6IlJTMjU2In0.eyJpc3MiOi(中略)BiOWE0In0.O4TpYbDB(中略)JbPyYk9YhA

Ｓ７１０にて、ＪＷＳアクセストークン発行部５０４は、クライアントにエラーメッセージを返す。例えば、Ｓ７０４にて権限検証が失敗した場合には、ＪＷＳアクセストークン発行部５０４は、権限検証に失敗したとしてエラーメッセージをクライアントに返す。そして、本処理フローを終了する。

ここで図６のシーケンス図に戻る。ここでは、正常にＪＷＳアクセストークンが生成された場合について説明する。

認可サーバ２０１のＪＷＳアクセストークン発行部５０４は、上記のようにＪＷＳアクセストークンを生成すると、以下のようにクライアント２０３に該ＪＷＳアクセストークンを返却する（Ｓ６０３）。

HTTP/1.0 200 OK
Content-Type: application/json
Date: Thu, 15 Sep 2016 07:30:40 GMT
{
“jws_token”:“eyJraWQiOiJrMSIsImFsZyI6IlJTMjU2In0.eyJpc3MiOi(中略)BiOWE0In0.O4TpYbDB(中略)JbPyYk9YhA”
}

Ｓ６０４〜Ｓ６０７は、認可サーバ２０１にて、暗号鍵の削除が行われる場合の処理である。

認可サーバ２０１において暗号鍵の削除が指示されると、ＪＷＳアクセストークン発行部５０４は、暗号鍵管理テーブルから該当する暗号鍵情報を削除する（Ｓ６０４）。例えば、表９におけるＫｅｙＩＤ項目の値が“２”の暗号鍵を削除した場合、暗号鍵管理テーブルは下に示す表１２のようになる。このとき、サービスＩＤ“ＳｔｏｒｅＳｅｒｖｉｃｅ”に対する暗号鍵情報が消失してしまうので、ＪＷＳアクセストークン発行部５０４は新しい暗号鍵を生成し、その情報を暗号鍵管理テーブルに登録する。

さらに、認可サーバ２０１は、暗号鍵が更新された旨をリソースサーバ２０４に通知する（Ｓ６０５）。

リソースサーバ２０４は、認可サーバ２０１からの通知を受け取り、これに伴って、公開鍵情報を認可サーバ２０１に要求し、その応答として更新後の公開鍵情報を取得する（Ｓ６０６）。なお、本実施形態では認可サーバ２０１の通知によりリソースサーバ２０４が公開鍵情報を要求する構成であるが、認可サーバ２０１が通知を行うとともに公開鍵情報を配布する構成でもよく、特に限定されるものではない。

次に、リソースサーバ２０４の削除鍵情報管理部５１３は、予め保持していた公開鍵情報と新しく取得した公開鍵情報とを比較し、消失した“ｋｉｄ”の項目を検出することで、削除鍵管理テーブルを更新する（Ｓ６０７）。具体的には、表１０で示したように、暗号鍵の削除前では削除鍵管理テーブルは空であった。予め保持していた公開鍵情報に含まれる“ｋｉｄ”は“１，２”であったが、新しく取得した公開鍵情報に含まれる“ｋｉｄ”は“１，３”であるため、“ｋｉｄ”が“２”の暗号鍵が削除されたことが検出される。その結果を受けて更新された削除鍵管理テーブルは下に示す表１３のようになる。つまり、削除された暗号鍵を示す”２”が削除鍵管理テーブルに追加され、管理される。

削除鍵管理テーブルの生成後は、リソースサーバ２０４は、予め保持していた公開鍵情報を破棄する。以後、リソースサーバ２０４は、公開鍵情報を取得する毎に、既に保持していた公開鍵情報と新しく取得した公開鍵情報とを比較し、削除鍵管理テーブルを更新していく。なお、本実施形態では、リソースサーバ２０４側で新旧の公開鍵情報を比較することで削除鍵管理テーブルを更新していく構成としたが、認可サーバ２０１が該情報を配布し、リソースサーバ２０４にて保持する構成でもよく、特に限定されるものではない。

次にクライアント２０３は、認可サーバ２０１から先に取得したＪＷＳアクセストークンを使ってリソースサーバ２０４に対してサービスの提供を要求する。具体的には、クライアント２０３はリソース要求のＲＥＳＴＡＰＩ呼び出しなどの際に、ＨＴＴＰのＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダーにＪＷＳアクセストークンを以下のようにセットして利用する（Ｓ６０８）。

Authorization: Bearer eyJraWQiOiJrMSIsImFsZyI6IlJTMjU2In0.eyJpc3MiOi(中略)BiOWE0In0.O4TpYbDB(中略)JbPyYk9YhA

リソース要求ＡＰＩ呼び出しを受けたリソースサーバ２０４は、クライアント２０３から取得したＪＷＳアクセストークンを検証する（Ｓ６０９）。

ＪＷＳアクセストークンの検証の後、リソースサーバ２０４のリソース管理部５１０は必要に応じてリソースの取得処理を行う（Ｓ６１０）。そして、リソース管理部５１０は、リソースの取得処理結果もしくはエラー情報をクライアント２０３に返す（Ｓ６１１）。

図８は、本発明の一実施形態におけるリソースサーバ２０４のＪＷＳアクセストークン検証、応答処理について示したフローチャートである。図６のＳ６０８〜Ｓ６１１の処理に対応する。本処理は、例えば、リソースサーバ２０４のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。

Ｓ８０１にて、リソースサーバ２０４は、クライアント２０３のリソース要求ＲＥＳＴＡＰＩ呼び出し時、上記のようにＨＴＴＰＡｕｔｈｏｒｉｚａｔｉｏｎヘッダーとしてＪＷＳアクセストークンを受信する。

Ｓ８０２にて、ＪＷＳアクセストークンを受信したリソースサーバ２０４のＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンを検証する。ＪＷＳアクセストークンの検証はＲＦＣ７５１５のＡ．２．２仕様に従う。すなわち、ＪＷＳアクセストークン検証部５１２は、該ＪＷＳアクセストークンを、区切り文字であるピリオド（‘．’）文字を基準として、エンコード済ＪＷＳヘッダー、エンコード済ＪＷＴペイロード、およびエンコード済ＪＷＳ署名に分割する。さらにＪＷＳアクセストークン検証部５１２は、分割したＪＷＳヘッダー、ＪＷＴペイロード、ＪＷＳ署名を復号化（ＢＡＳＥ６４ＵＲＬデコード）する。そして、ＪＷＳアクセストークン検証部５１２は、ＪＷＳヘッダーに示されたアルゴリズム（“ａｌｇ”：“ＲＳ２５６”）により、前述した署名ライブラリを用いて保持する公開鍵情報を基にＪＷＳ署名を検証する。

Ｓ８０３にて、ＪＷＳアクセストークン検証部５１２は、Ｓ８０２のＪＷＳ署名検証の成否を判定する。該ＪＷＳ署名検証に成功したと判定した場合（Ｓ８０３にてＹＥＳ）、Ｓ８０４へ進み、次のクレーム情報の検証ステップに進む。該ＪＷＳ署名検証に失敗したと判定した場合（Ｓ８０３にてＮＯ）Ｓ８０８へ進む。

Ｓ８０４にて、ＪＷＳアクセストークン管理部５１１は、復号化、署名検証済みのＪＷＴペイロードのＪＷＴを参照してクレーム情報の取得を行う。ここで取得されるクレーム情報は、図７のＳ７０６、Ｓ７０７で設定した表１１の情報である。次に、ＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンに含まれるクレーム情報のうち、表１１のＲｅｇｉｓｔｅｒｅｄＣｌａｉｍクラスのクレームの検証を行う。

Ｓ８０５にて、ＪＷＳアクセストークン管理部５１１は、ＲｅｇｉｓｔｅｒｅｄＣｌａｉｍ検証の成否を判定する。本実施形態においては、トークンが消費される場所を表す“ａｕｄ”、有効期限を表す“ｅｘｐ”、“ｎｂｆ”について検証が行われる。具体的には、“ａｕｄ”に含まれる文字列のうち、リソースサーバ２０４のＵＲＬが含まれない場合は、ＪＷＳアクセストークン検証部５１２は、受信したＪＷＳアクセストークンが不正であると判定する。この場合、Ｓ８１１へ進む。“ｅｘｐ”が有効期限を過ぎている、もしくは“ｎｂｆ”が現在時刻以降である場合、ＪＷＳアクセストークン検証部５１２は、受信したＪＷＳアクセストークンの有効期限が切れていると判定する。この場合、Ｓ８０７へ進む。上述のいずれでもない場合は、ＪＷＳアクセストークン検証部５１２は、有効なトークンであると判定する。この場合、Ｓ８０６へ進む。

Ｓ８０６にて、リソース管理部５１０はクライアント２０３からのリソース要求ＡＰＩ呼び出しに応じて処理結果（要求リソース）を返す。そして、本処理フローを終了する。

Ｓ８０７にて、リソース管理部５１０は、クライアント２０３に有効期限切れエラーを返却する。有効期限切れエラーは、アクセストークンの有効期限が切れていることを示す。そして、本処理フローを終了する。

Ｓ８１１にて、リソース管理部５１０は、クライアント２０３にトークン不正エラーを返却する。トークン不正エラーは、アクセストークンが不正なものであることを示す。そして、本処理フローを終了する。

Ｓ８０３で該ＪＷＳ署名検証に失敗したと判定した場合、Ｓ８０８にて、ＪＷＳアクセストークン管理部５１１は、削除鍵管理テーブルを参照してＪＷＳアクセストークンの鍵情報について検証を行う。ＪＷＳアクセストークン管理部５１１は、Ｓ８０４と同様に、復号化、署名検証済みのＪＷＳヘッダーを参照してｋｉｄを取得する。ＪＷＳアクセストークン検証部５１２は、取得したｋｉｄと削除鍵情報管理部５１３が所持する削除鍵管理テーブルから、同じｋｉｄが含まれるか検証する。

Ｓ８０９にて、ＪＷＳアクセストークン管理部５１１は、削除鍵検証の成否を判定する。該削除鍵検証に成功したと判定した場合、すなわち、同じｋｉｄが含まれると判定された場合（Ｓ８０９にてＹＥＳ）、Ｓ８０７へ進む。該削除鍵検証に失敗したと判定した場合（Ｓ８０９にてＮＯ）Ｓ８１０へ進む。削除鍵検証が失敗する場合とは、ＪＷＳヘッダーを参照して取得したｋｉｄが削除鍵管理テーブルに含まれていない場合である。これは、本実施形態においては、ＪＷＳアクセストークンに設定されたｋｉｄをリソースサーバ２０４が認可サーバ２０１から取得できていない場合や、そのｋｉｄが認可サーバ２０１にて発行されていないものである場合などが挙げられる。

Ｓ８１０にて、リソース管理部５１０は、クライアント２０３にリソース取得エラーを返却する。リソース取得エラーは、リソースの取得が失敗した旨を示す。そして、本処理フローを終了する。

［ＪＷＳアクセストークンの再取得］
次に、図７のＳ８０７で、リソースサーバ２０４から有効期限エラーを受けたクライアント２０３がＪＷＳアクセストークンを再度取得（再発行）する方法について説明する。有効期限エラーを受けた場合は、ＪＷＳアクセストークンにおいて、トークンの有効期限が切れている、もしくは削除した鍵で署名されたアクセストークンであることがエラーの原因である。よって、クライアント２０３は認可サーバ２０１にアクセストークンの発行を再度要求し、新しいＪＷＳアクセストークンを使用してリソースサーバ２０４にリソースの要求を行う。つまりは、図６のＪＷＳアクセストークンの要求およびリソースの要求の処理シーケンスが再び実行される。

このとき、認可サーバ２０１のＪＷＳアクセストークン発行部５０４では、クライアント２０３からの要求に応じて、“ｋｉｄ”が“３”の暗号鍵を用いてＪＷＳアクセストークンの署名および発行を行う（Ｓ６０２）。前述のＪＷＳアクセストークンによりリソースを要求されたリソースサーバ２０４のＪＷＳアクセストークン検証部５１２は、新しく取得した公開鍵情報に“ｋｉｄ”が“３”の公開鍵が含まれているので、検証が成功する（Ｓ６０９）。その結果、クライアント２０３は要求したリソースを取得することができる。

また、本実施形態において、Ｓ８０９で同じｋｉｄが含まれないと判断された場合にクライアント２０３にリソース取得エラーを返却する構成（Ｓ８０９、Ｓ８１０）としている。この構成により、クライアントはＳ８０５の判定に基づいてエラーを受けた場合とＳ８０９の判定に基づいてエラーを受けた場合とで処理を変える必要がない。つまり、従来技術において実装されている権限委譲システムに本発明を適用する際に、クライアントの実装を変更する必要がない。

以上のように、本実施形態においてＪＷＳアクセストークンの検証を行うことで、以下の効果が期待できる。すなわち、安全性を損なうことなく、認可サーバにおいて暗号鍵が削除された場合においても署名付きアクセストークンの検証が正しく行え、クライアントがリソースを取得することが可能となる。

＜第２の実施形態＞
第１の実施形態では、削除鍵情報を管理しＪＷＳアクセストークンのｋｉｄを検証することで、認可サーバ２０１で暗号鍵が削除された場合においてもクライアント２０３はリソースを取得できる。ここで、認可サーバ２０１で暗号鍵が削除されるたびにリソースサーバ２０４が保持する削除鍵管理テーブルに新たなレコードが追加されていく。そのため、処理が繰り返されることで、削除鍵情報管理部５１３ではテーブルから該当する鍵情報を探索する際の処理コストの増加や、テーブルを格納するための記憶部（例えば、内部メモリ）の圧迫が発生しうる。

そこで、本願発明の第２の実施形態として、リソースサーバ２０４における削除鍵情報管理部５１３の処理コストやメモリ管理コストを低減するための実施形態について説明する。

表１４は、リソースサーバ２０４の削除鍵情報管理部５１３が管理・参照する削除鍵管理テーブルである。

表１４の削除鍵管理テーブルは、ＪＷＳアクセストークンの検証で用いる削除鍵管理テーブル（表１０）に、該削除鍵レコードを削除する時間を示すＤｅｌｅｔｅＴｉｍｅ項目を加えたものである。ＤｅｌｅｔｅＴｉｍｅには、ＪＷＴペイロードにおける“ＲｅｇｉｓｔｅｒｅｄＣｌａｉｍ”クラスの“ｅｘｐ”クレームと同じく、ＩｎｔＤａｔｅで１９７０−０１−０１Ｔ０：０：０ＺＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表わすＪＳＯＮ数値が格納される。

本実施形態に係るＪＷＳアクセストークン発行と検証に関するシーケンスは、第１の実施形態にて図６を用いて述べた構成と同じである。ただし、Ｓ６０７における削除鍵管理テーブルの作成処理において、ＫｅｙＩＤが追加されたレコードに対し、ＤｅｌｅｔｅＴｉｍｅは空にしてテーブルを作成する。その他の処理内容については同じであるので、ここでの説明は省略する。

［ＪＷＳアクセストークン検証および応答処理］
図９は、本実施形態に係るリソースサーバ２０４のＪＷＳアクセストークン検証、応答処理について示したフローチャートである。なお、図８と同様の処理については同じ符号を付与しており、説明は省略する。本処理は、例えば、リソースサーバ２０４のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。

Ｓ８０２でのＪＷＳ署名検証に失敗したと判定した場合（Ｓ８０３にてＮＯ）Ｓ９０１へ進む。Ｓ９０１にて、削除鍵情報管理部５１３は、削除鍵管理テーブルの各レコードのＤｅｌｅｔｅＴｉｍｅと現在時刻をＩｎｔＤａｔｅで表した数値を比較し、現在時刻の方が大きいレコードを削除する。その後、Ｓ８０８に処理を進める。なお、本実施形態ではＳ９０１の処理をＪＷＳアクセストークンの署名検証時に合わせて行う構成としたが、例えば別スレッドで定期的に削除鍵管理テーブルを監視し、その都度本処理を行う構成でもよく、特に限定されるものではない。

Ｓ８０８での削除鍵検証に成功したと判定された場合、すなわち、同じｋｉｄが含まれると判定された場合（Ｓ８０９にてＹＥＳ）Ｓ９０２へ進む。Ｓ９０２にて、削除鍵情報管理部５１３は、削除鍵管理テーブルの該レコードのＤｅｌｅｔｅＴｉｍｅが空か否かを判定する。空であると判定された場合（Ｓ９０２にてＹＥＳ）Ｓ９０３へ進み、空でないと判定された場合（Ｓ９０２にてＮＯ）Ｓ９０４へ進む。

Ｓ９０３にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅＴｉｍｅに所定の時刻を格納する。所定の時刻とは、現在時刻に例えば３６００（秒）を加えた値である。権限委譲システムにおける設計思想等から所定の時刻は予め決定しておく必要がある。この例の場合、ＪＷＳアクセストークンによるアクセスから３６００秒が経過した後には、Ｓ９０１の処理によって削除鍵テーブルの該レコードは削除されることとなる。また、所定の時刻にＪＷＳアクセストークンの有効期限を設定するのもよい。すなわち、復号化及び署名検証済みのＪＷＴペイロードの“ｅｘｐ”クレームが使用される。こうすることで、ＪＷＳアクセストークンの有効期限においてのみ削除鍵の検証が有効となるので、過不足なく削除鍵管理テーブルを管理でき、より望ましい。その後、Ｓ８０７へ処理を進める。

Ｓ９０４にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅＴｉｍｅの値と、前述の所定の時刻とを比較し、所定の時刻の方が大きいか否かを判定する。所定の時刻の方が大きいと判定された場合（Ｓ９０４にてＹＥＳ）Ｓ９０５へ進み、そうでないと判定された場合は（Ｓ９０４にてＮＯ）Ｓ８０７へ進む。

Ｓ９０５にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅＴｉｍｅを所定の時刻に更新する。これにより、有効期限がより後のＪＷＳアクセストークンの検証も有効となる。その後、Ｓ８０７へ処理を進める。

以上、本実施形態において削除鍵管理テーブルの各レコードを所定の時刻をもって削除することで、削除鍵情報管理部５１３の処理コストやメモリ管理コストを低減することができる。

＜第３の実施形態＞
第２の実施形態では、削除鍵管理テーブルの各レコードを所定の時刻をもって削除することで、削除鍵情報管理部５１３処理コストやメモリ管理コストを低減することができる。第１および第２の実施形態では、ＪＷＳアクセストークンの有効期限”ｅｘｐ”は認可サーバ２０１が現在時刻に３６００（秒）を加えた値を設定する構成で説明した。この“ｅｘｐ”であるが、その他にもクライアント２０３がＪＷＳアクセストークン要求時に指定することもできる。また、リソースサーバ２０４が指定することもできる。そのため、同じ暗号鍵で署名されるアクセストークンであっても、個体ごとに有効期限“ｅｘｐ”は異なる。よって、第２の実施形態において削除鍵管理テーブルのレコードを削除したとしても、その後に該暗号鍵で署名されたアクセストークンがリソース要求を行った場合、削除鍵検証で否と判定され、そのアクセストークンはリソースを取得することができない。

例えば、あるクライアントＡが取得したＪＷＳアクセストークンの有効期限“ｅｘｐ”が“１４９６２７９４００”（＝２０１７−０６−０１Ｔ１０：１０：００ＺＵＴＣ）であったとする。一方、別のクライアントＢで取得したＪＷＳアクセストークンの有効期限”ｅｘｐ”が“１４９６２８６０００”（＝２０１７−０６−０１Ｔ１２：００：００ＺＵＴＣ）であったとする。それぞれ同じ暗号鍵で署名されており、認可サーバ２０１において同時刻（＝２０１７−０６−０１Ｔ１０：００：００ＺＵＴＣ）において発行されたものである。この後、“２０１７−０６−０１Ｔ１０：０２：００ＺＵＴＣ”に認可サーバ２０１において該暗号鍵が削除されたとする。

“２０１７−０６−０１Ｔ１０：０５：００ＺＵＴＣ”にクライアントＡがリソースサーバ２０４にリソースを要求した場合、第２の実施形態で説明したように、クライアントＡはリソースを取得できる。そのため、削除鍵管理テーブルにおける該暗号鍵のレコードはクライアントＡの“ｅｘｐ”である２０１７−０６−０１Ｔ１２：１０：００ＺＵＴＣの時刻に削除される。その後、“２０１７−０６−０１Ｔ１１：００：００ＺＵＴＣ”にクライアントＢがリソースサーバ２０４にリソースを同様に要求したとする。この場合、ＪＷＳアクセストークンは有効期限内であるにも関わらず、削除鍵管理テーブルには該暗号鍵のレコードがないため、クライアントＢにはリソース取得エラーが返却されリソースを取得することができない。

そこで、削除された暗号鍵で署名されたアクセストークンが複数ある場合においても、過不足なく削除鍵情報を管理するための実施形態について説明する。

表１５は、認可サーバ２０１の発行済みＪＷＳアクセストークン管理部５０５が管理、参照する発行済みトークン管理テーブルである。

表１５の発行済みトークン管理テーブルは、トークンの署名に使用した秘密鍵を特定するＫｅｙＩＤ項目とトークンの有効期限を示すＥｘｐｉｒａｔｉｏｎＴｉｍｅ項目を含んで構成される。

ＫｅｙＩＤにはＪＷＳアクセストークン発行部５０４が発行したトークンにおけるＪＷＳヘッダーの“ｋｉｄ”が、ＥｘｐｉｒａｔｉｏｎＴｉｍｅには同じく発行したトークンにおけるＪＷＴペイロードの“ｅｘｐ”クレームが格納されている。発行済みＪＷＳアクセストークン管理部５０５は、図６のＳ６０２でＪＷＳアクセストークンを発行した際に、本テーブルに該当する情報を追加していく。さらには、発行済みＪＷＳアクセストークン管理部５０５は、ＪＷＳアクセストークンを発行するたびに、そのトークンの”ｋｉｄ”と同じレコードのＥｘｐｉｒａｔｉｏｎＴｉｍｅを取得する。そして、発行済みＪＷＳアクセストークン管理部５０５は、発行したトークンの“ｅｘｐ”と比較して“ｅｘｐ”の方が大きければＥｘｐｉｒａｔｉｏｎＴｉｍｅをその値に更新する。

［削除鍵情報の問い合わせ処理］
図１０は、本実施形態に係る削除鍵情報の問い合わせ処理について示したシーケンス図である。認可サーバ２０１、リソースサーバ２０４間で連携が行われる。第２の実施形態で説明した、削除鍵管理情報を削除する処理（図９のＳ９０１）が本実施形態では異なる。なお、リソースサーバ２０４のＪＷＳアクセストークン検証・応答のフローチャートは図９と同様であり、同様の処理についての説明は省略する。

Ｓ８０２でのＪＷＳ署名検証に失敗したと判定された場合（Ｓ８０３にてＮＯ）、リソースサーバ２０４の削除鍵情報管理部５１３は、削除鍵管理テーブルの各レコードのＤｅｌｅｔｅＴｉｍｅと現在時刻をＩｎｔＤａｔｅで表した数値を比較し、現在時刻の方が大きいレコードのｋｉｄを取得する。そして、削除鍵情報管理部５１３は、認可サーバ２０１へ取得したｋｉｄを示し、削除の可否の問い合わせを行う（Ｓ１００１）。

認可サーバ２０１の発行済みＪＷＳアクセストークン管理部５０５は、表１５の発行済みトークン管理テーブルを参照し、受信したｋｉｄとテーブルのＫｅｙＩＤが一致するレコードのＥｘｐｉｒａｔｉｏｎＴｉｍｅを取得する。そして、発行済みＪＷＳアクセストークン管理部５０５は、取得したＥｘｐｉｒａｔｉｏｎＴｉｍｅと現在時刻を比較し、どちらが大きいかを判定する。現在時刻より大きいＥｘｐｉｒａｔｉｏｎＴｉｍｅがない場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除許可をリソースサーバ２０４に返す。一方、現在時刻より大きいＥｘｐｉｒａｔｉｏｎＴｉｍｅがある場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除不許可をリソースサーバ２０４に返す（Ｓ１００２）。また、該当するｋｉｄが表１５にない場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除許可をリソースサーバ２０４に返す。例えば、受信ｋｉｄが“２”である場合、表１５を参照することでＥｘｐｉｒａｔｉｏｎＴｉｍｅとして“１４９６２８６０００”が取得される。現在時刻が“２０１７−０６−０１Ｔ１１：００：００ＺＵＴＣ（＝１４９６２８２４００）”である場合、ＥｘｐｉｒａｔｉｏｎＴｉｍｅは現在時刻より大きいので、リソースサーバ２０４には削除不許可が返却される。

リソースサーバ２０４は削除許可情報を受信し、その情報に従い削除鍵情報管理部５１３は削除鍵管理テーブルを更新する（Ｓ１００３）。つまり、リソースサーバ２０４は、削除許可を受信した場合は該レコードを削除し、削除不許可を受信した場合は該レコードを削除しない。そして、図９のＳ８０８へと処理を進める。

以上、本実施形態では、削除鍵管理テーブルの各レコードを削除する場合に認可サーバ２０１に問い合わせを行い、認可サーバ２０１が発行したアクセストークンの有効期限をもって該削除鍵情報の削除判定を行う。これにより、削除された暗号鍵で署名されたアクセストークンが複数ある場合においても、過不足なく削除鍵情報を管理することができる。

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

２０１…認可サーバ、２０３…クライアント、２０４…リソースサーバ、５０４…ＪＷＳアクセストークン発行部、５０５…発行済みＪＷＳアクセストークン管理部、５１１…ＪＷＳアクセストークン管理部、５１２…ＪＷＳアクセストークン検証部、５１３…削除鍵情報管理部

Claims

署名付きアクセストークンを発行する認可サーバと、前記署名付きアクセストークンに基づきサービスを提供するリソースサーバを含む権限委譲システムであって、
前記リソースサーバは、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを前記認可サーバから受け付けた際に、当該無効となった鍵情報を管理する第１の管理手段と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記第１の管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段と
を有することを特徴とする権限委譲システム。
前記第１の管理手段は、前記無効となった鍵情報を用いて署名が行われた署名付きアクセストークンを用いてサービスの要求を受け付けてから所定の時間が経過した後に、当該無効となった鍵情報を削除することを特徴とする請求項１に記載の権限委譲システム。
前記所定の時間は、前記署名付きアクセストークンに対して設定された有効期限に基づいて決定されることを特徴とする請求項２に記載の権限委譲システム。
前記第１の管理手段は、前記無効となった鍵情報を用いて署名が行われた署名付きアクセストークンを用いてサービスの要求を受け付けた場合、前記認可サーバに対し当該無効となった鍵情報の削除の可否を問い合わせ、当該問い合わせの結果に応じて、当該鍵情報を削除するか否かを決定することを特徴とする請求項１に記載の権限委譲システム。
前記リソースサーバは、
前記認可サーバから鍵情報を取得する取得手段と、
前記取得手段にて取得した鍵情報を管理する第２の管理手段と
を更に有し、
前記第２の管理手段は、管理している鍵情報が無効になったことを受け付けた際に、当該鍵情報を削除し、前記第１の管理手段は、前記第２の管理手段にて削除された鍵情報の管理を開始することを特徴とする請求項１乃至４のいずれか一項に記載の権限委譲システム。
前記検証手段による検証において、前記署名付きアクセストークンが前記第１の管理手段にて管理されている鍵情報を用いて署名されていると判定された場合、前記処理手段は、前記クライアントに対し、有効期限切れを示すエラーを返すことを特徴とする請求項１乃至５のいずれか一項に記載の権限委譲システム。
前記クライアントは、前記要求に対する応答として有効期限切れのエラーを受け付けた場合、前記認可サーバに対して、署名付きアクセストークンの再発行を要求することを特徴とする請求項６に記載の権限委譲システム。
前記認可サーバは、
前記クライアントからの要求に応じて、署名付きアクセストークンの発行を行う発行手段と、
前記発行手段にて発行した署名付きアクセストークンの情報を管理する第３の管理手段と
を有することを特徴とする請求項１乃至７のいずれか一項に記載の権限委譲システム。
前記認可サーバは、前記第３の管理手段が管理する鍵情報を前記リソースサーバに提供する提供手段を更に有し、
前記提供手段は、前記第３の管理手段が管理している鍵情報が更新された場合に提供を行うことを特徴とする請求項８に記載の権限委譲システム。
前記発行手段は、前記クライアントから署名付きアクセストークンの再発行の要求を受け付けた場合、前記第３の管理手段にて管理している鍵情報を用いて署名付きアクセストークンを再発行することを特徴とする請求項８または９に記載の権限委譲システム。
署名付きアクセストークンに基づきサービスを提供する情報処理装置であって、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を管理する管理手段と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段と
を有することを特徴とする情報処理装置。
署名付きアクセストークンに基づきサービスを提供する情報処理装置の制御方法であって、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を記憶部にて管理する管理工程と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記記憶部にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証工程と、
前記検証工程による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理工程と
を有することを特徴とする情報処理装置の制御方法。
コンピュータを、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を管理する管理手段、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段
として機能させるためのプログラム。