(57)【要約】      （修正有）【課題】認可サーバが署名付きアクセストークンをクライアントに発行した後に、そのアクセストークンの署名に用いた暗号鍵を削除した場合、リソースサーバにおいては該当する公開鍵による検証は無効となってしまう。リソースサーバで署名付きアクセストークンの検証が行えるようにする。【解決手段】署名付きアクセストークンに基づきサービスを提供するリソースサーバ２０４は、署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、無効となった鍵情報を管理する管理手段と、クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、管理手段にて管理する鍵情報に基づいて、クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、検証手段による検証の結果に基づいて、クライアントからの要求に対する応答を行う処理手段を備える。【選択図】図６
2020030759.tif 000002
【特許請求の範囲】
【請求項１】
署名付きアクセストークンを発行する認可サーバと、前記署名付きアクセストークンに基づきサービスを提供するリソースサーバを含む権限委譲システムであって、
前記リソースサーバは、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを前記認可サーバから受け付けた際に、当該無効となった鍵情報を管理する第１の管理手段と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記第１の管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段と
を有することを特徴とする権限委譲システム。
【請求項２】
前記第１の管理手段は、前記無効となった鍵情報を用いて署名が行われた署名付きアクセストークンを用いてサービスの要求を受け付けてから所定の時間が経過した後に、当該無効となった鍵情報を削除することを特徴とする請求項１に記載の権限委譲システム。
【請求項３】
前記所定の時間は、前記署名付きアクセストークンに対して設定された有効期限に基づいて決定されることを特徴とする請求項２に記載の権限委譲システム。
【請求項４】
前記第１の管理手段は、前記無効となった鍵情報を用いて署名が行われた署名付きアクセストークンを用いてサービスの要求を受け付けた場合、前記認可サーバに対し当該無効となった鍵情報の削除の可否を問い合わせ、当該問い合わせの結果に応じて、当該鍵情報を削除するか否かを決定することを特徴とする請求項１に記載の権限委譲システム。
【請求項５】
前記リソースサーバは、
前記認可サーバから鍵情報を取得する取得手段と、
前記取得手段にて取得した鍵情報を管理する第２の管理手段と
を更に有し、
前記第２の管理手段は、管理している鍵情報が無効になったことを受け付けた際に、当該鍵情報を削除し、前記第１の管理手段は、前記第２の管理手段にて削除された鍵情報の管理を開始することを特徴とする請求項１乃至４のいずれか一項に記載の権限委譲システム。
【請求項６】
前記検証手段による検証において、前記署名付きアクセストークンが前記第１の管理手段にて管理されている鍵情報を用いて署名されていると判定された場合、前記処理手段は、前記クライアントに対し、有効期限切れを示すエラーを返すことを特徴とする請求項１乃至５のいずれか一項に記載の権限委譲システム。
【請求項７】
前記クライアントは、前記要求に対する応答として有効期限切れのエラーを受け付けた場合、前記認可サーバに対して、署名付きアクセストークンの再発行を要求することを特徴とする請求項６に記載の権限委譲システム。
【請求項８】
前記認可サーバは、
前記クライアントからの要求に応じて、署名付きアクセストークンの発行を行う発行手段と、
前記発行手段にて発行した署名付きアクセストークンの情報を管理する第３の管理手段と
を有することを特徴とする請求項１乃至７のいずれか一項に記載の権限委譲システム。
【請求項９】
前記認可サーバは、前記第３の管理手段が管理する鍵情報を前記リソースサーバに提供する提供手段を更に有し、
前記提供手段は、前記第３の管理手段が管理している鍵情報が更新された場合に提供を行うことを特徴とする請求項８に記載の権限委譲システム。
【請求項１０】
前記発行手段は、前記クライアントから署名付きアクセストークンの再発行の要求を受け付けた場合、前記第３の管理手段にて管理している鍵情報を用いて署名付きアクセストークンを再発行することを特徴とする請求項８または９に記載の権限委譲システム。
【請求項１１】
署名付きアクセストークンに基づきサービスを提供する情報処理装置であって、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を管理する管理手段と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段と
を有することを特徴とする情報処理装置。
【請求項１２】
署名付きアクセストークンに基づきサービスを提供する情報処理装置の制御方法であって、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を記憶部にて管理する管理工程と、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記記憶部にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証工程と、
前記検証工程による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理工程と
を有することを特徴とする情報処理装置の制御方法。
【請求項１３】
コンピュータを、
署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを受け付けた際に、当該無効となった鍵情報を管理する管理手段、
クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段、
前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、権限委譲システム、情報処理装置およびその制御方法、並びにプログラムに関する。
【背景技術】
【０００２】
近年、ネットワーク上のＷｅｂサービスでは利用者がＷｅｂサービスの利用を認められているかどうかの認証・認可が行われている。また、Ｗｅｂサービスの多様化に伴って、複数のＷｅｂサービスが互いに連携を行い、サービス間で信頼関係を構築し、ユーザの同意のもとにセキュアに最低限必要なユーザの権限を委譲するシステムが必要とされている。そのシステムを構築するフレームワークの仕様の１つとして、ＯＡｕｔｈ２．０が公開されている。ＯＡｕｔｈ２．０では、Ｗｅｂサービスを提供するリソースサーバと、認証・認可を行う認可サーバが別々のサーバとして構成され、認可サーバとリソースサーバが互いに認証・認可情報を授受することで連携し、権限の委譲を可能としている。この認証・認可情報の授受にはアクセストークンが用いられることが一般的である。
【０００３】
トークンの譲渡を受けたシステムがトークンを使用する時点においても確実にトークンの検証をすることができる権限委譲システムについては、例えば、特許文献１のような方法がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１４９０１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、認可サーバでアクセストークンの署名に用いられる秘密鍵・公開鍵のペアを削除し、リソースサーバで公開鍵を削除しても、削除した鍵で発行済みのアクセストークンは無効にすることはできない。そのため、発行済みのアクセストークンを持つクライアントがリソースサーバにアクセスしても、リソース取得エラーとなりリソースを取得することができない。さらに、リソースサーバは署名検証に失敗するため、アクセストークンが不正なトークンだと判断し、リソースを要求したクライアントを不正なクライアントと判断してしまう。例えば、認可サーバが署名付きアクセストークンをクライアントに発行した後に、そのアクセストークンの署名に用いた暗号鍵を削除した場合、その情報の通知によりリソースサーバにおいては該当する公開鍵による検証は無効となる。よって、リソースサーバでは署名付きアクセストークンの検証を行っても失敗し、リソースを取得する事ができない。
【０００６】
本発明では、認可サーバで暗号鍵が削除された場合においても、安全性を損なわずに署名付きアクセストークンの検証を行い、クライアントがリソースの取得を可能とすることを目的とする。
【課題を解決するための手段】
【０００７】
上記課題を解決するために本願発明は以下の構成を有する。すなわち、署名付きアクセストークンを発行する認可サーバと、前記署名付きアクセストークンに基づきサービスを提供するリソースサーバを含む権限委譲システムであって、前記リソースサーバは、署名付きアクセストークンの署名を行う際に用いられる鍵情報が無効になったことを前記認可サーバから受け付けた際に、当該無効となった鍵情報を管理する第１の管理手段と、クライアントから署名付きアクセストークンを用いてサービスの要求を受け付けた際に、前記第１の管理手段にて管理する鍵情報に基づいて、前記クライアントから受け付けた署名付きアクセストークンが有効か否かを検証する検証手段と、前記検証手段による検証の結果に基づいて、前記クライアントからの要求に対する応答を行う処理手段とを有する。
【発明の効果】
【０００８】
本発明により、安全性を損なうことなく、認可サーバにおいて暗号鍵が削除された場合においても署名付きアクセストークンの検証が正しく行え、クライアントがリソースを取得することが可能となる。
【図面の簡単な説明】
【０００９】
【図１】本発明の一実施形態におけるコンピュータの構成内容を示す図。
【図２】本発明の一実施形態におけるネットワーク構成図。
【図３】アクセストークン発行と検証のシーケンス図。
【図４】暗号鍵の削除と公開鍵の再取得のシーケンス図。
【図５】本発明の一実施形態における認証・認可システムの機能ブロック図。
【図６】第１の実施形態に係るＪＷＳアクセストークンの発行、検証のシーケンス図。
【図７】認可サーバのＪＷＳアクセストークン発行処理のフローチャート。
【図８】リソースサーバのＪＷＳアクセストークン検証処理のフローチャート。
【図９】第２の実施形態に係るＪＷＳアクセストークン検証処理のフローチャート。
【図１０】第３の実施形態に係る削除鍵情報の問い合わせ処理のシーケンス図。
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための形態について図面を用いて説明する。
【００１１】
［装置構成］
図１は、本発明を実施するための一実施形態に係る情報処理装置のシステム構成の例を示す図である。図１において、情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、及び通信インタフェース１０７を備える。また、情報処理装置内の各構成要素は、システムバス１０１を介して互いに通信可能に接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３がある。図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなども使用されることがある。
【００１２】
本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭ（不図示）から読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。
【００１３】
ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置に対する動作指令等を行う。ポインティングデバイス１１６は、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。
【００１４】
通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、もしくはインターネットのような公衆回線等がある。
【００１５】
［ネットワーク構成］
図２は、本実施形態に係るネットワーク構成の例を示す図である。インターネット２１０には、コンピュータネットワーク２１１、２１２、２１３が接続されており、コンピュータネットワーク２１１には、認可サーバ２０１が接続されている。また、コンピュータネットワーク２１２にはクライアント２０３、コンピュータネットワーク２１３にはリソースサーバ２０４がそれぞれ接続されている。本実施形態においてリソースサーバ２０４は、インターネット２１０を跨いだコンピュータネットワーク上に接続されているが、認可サーバ２０１と同じＬＡＮに存在していてもよい。クライアント２０３は図２のようにコンピュータネットワーク２１２接続されている場合に限らず、コンピュータネットワーク２１１や２１３に接続されていてもよい。
【００１６】
クライアント２０３は認可サーバ２０１からアクセストークンを取得する。また、クライアント２０３は、取得したアクセストークンを使って、リソースサーバ２０４からＷｅｂサービス（以下、「サービス」と略称）の提供を受ける。なお、本実施形態において、認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４はいずれも、図１にて示した情報処理装置の構成を有するものとする。ただし、図１の構成に限定するものではなく、ディスプレイ装置１１４を備えていない、他の機能を備えている等、クライアントとサーバはそれぞれ異なる構成を有してもよいし、それぞれが他の構成でもよい。また、サーバは、単体のコンピュータに限らず、ラックマウント型の複数台のコンピュータで構成されたシステムであっても構わない。
【００１７】
［従来のアクセストークン発行と検証の流れ］
以下、従来技術におけるアクセストークン発行と検証の処理の流れについて説明する。図３は、従来技術における署名付きアクセストークン発行と検証に関するシーケンス図である。図２で説明した認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４間で連携が行われる。まず、リソースサーバ２０４は、認可サーバ２０１に対して後述する署名付きアクセストークンの検証に用いるための公開鍵を要求し、その応答として公開鍵を取得する（Ｓ３０１）。リソースサーバ２０４は、アクセストークンの署名を検証する署名ライブラリ（不図示）を有しており、署名ライブラリは取得した公開鍵を用いて署名の検証を行う。なお、認可サーバ２０１は複数の暗号鍵を保持してもよい。その場合、リソースサーバ２０４は認可サーバ２０１が保持する秘密鍵に対応するすべての公開鍵を取得してよい。Ｓ３０１の処理はリソースサーバ２０４の初回起動時等、クライアント２０３へのリソース提供前に一度行われればよい。
【００１８】
クライアント２０３は、認可サーバ２０１に対して認証情報又は認可コードを渡して署名付きアクセストークンを要求し、その応答として署名付きアクセストークンを取得する（Ｓ３０２）。この時の要求において、認証情報又は認可コードのいずれが用いられるかは、オーナーの違いによって異なる。クライアント２０３が処理を実施するオーナーである場合はクライアント２０３自体が認証を行い、クライアント２０３が他のオーナーから処理を依頼される場合にはオーナーから受け取った認可コードを渡すことになる。
【００１９】
次に、クライアント２０３は、取得した署名付きアクセストークンを使ってリソースサーバ２０４に対してサービスの提供を要求する（Ｓ３０３）。リソースサーバ２０４は、受け取った署名を元にアクセストークンが適正か否か検証する（Ｓ３０４）。リソースサーバ２０４は、保持する署名ライブラリ（不図示）を用いて署名を検証することで、適正な認可サーバで発行されたアクセストークンであることを確認できる。そして、アクセストークンが適正であればリソースサーバ２０４はリソースを提供するための処理を実行し（Ｓ３０５）、リソースをクライアント２０３に返す。また、アクセストークンが適正でなければ、リソースサーバ２０４は処理（Ｓ３０５）を行わず、もしくは、エラー用の処理を行って、リソース取得エラーをクライアント２０３に返す。
【００２０】
［公開鍵の再取得の流れ］
図４は、認可サーバ２０１で暗号鍵を削除した場合における公開鍵の再取得に関するシーケンス図である。図２で説明した認可サーバ２０１、リソースサーバ２０４間で連携が行われる。認可サーバ２０１は保持している暗号鍵を削除する（Ｓ４０１）。これにより、以降、削除された暗号鍵を用いては署名が行われないこととなる。一方、リソースサーバ２０４には削除された暗号鍵に対応する公開鍵が保持されているため、公開鍵の更新を促す必要がある。そのため、認可サーバ２０１は、暗号鍵が更新された旨をリソースサーバ２０４に通知する（Ｓ４０２）。
【００２１】
次に、リソースサーバ２０４は、更新された公開鍵を認可サーバ２０１に要求し、取得する（Ｓ４０３）。以降は、リソースサーバ２０４は、更新された公開鍵を用いて、クライアント２０３から受信する署名付きアクセストークンを検証する。これにより、例えば認可サーバ２０１が保持している秘密鍵が流出したとしても、その鍵を削除し、リソースサーバ２０４が保持する公開鍵を更新すればよい。具体的には、悪意あるクライアント２０３が流出した鍵で署名されたアクセストークンでリソースサーバ２０４にアクセスしたとしても、リソースサーバ２０４ではそのアクセストークンの検証に必要な公開鍵は既に保持されていない。よって、リソースサーバ２０４側ではアクセストークンの署名検証において適正でないと判断され、その署名は無効となり、リソースの取得を防止することができる。
【００２２】
以上、署名付きアクセストークンの検証および暗号鍵の削除時におけるシーケンスについて説明した。しかし、認可サーバ２０１がアクセストークンをクライアント２０３に発行した後、そのアクセストークンの署名に用いた暗号鍵を削除した場合、リソースサーバ２０４では配布する公開鍵が更新される。その結果、そのアクセストークンの検証では適正でないと判定される。よって、クライアント２０３が正規の手続きを経て取得したアクセストークンを用いてリソースサーバ２０４にアクセスしたにも関わらず、リソースを取得する事ができないという状態が生じうる。
【００２３】
以下、本発明の実施形態に係る構成について説明する。
【００２４】
＜第１の実施形態＞
［アクセストークンおよびアクセストークンに紐付くユーザ情報を格納するＪＷＳ］
本実施形態においては、署名付きのアクセストークンとして、通常のアクセストークンの代わりにアクセストークン情報およびリソースオーナー情報であるアクセストークンに紐付くユーザ情報を格納するＪＷＳ（以降、「ＪＷＳアクセストークン」）を用いる。以下、本実施形態で用いるＪＷＳアクセストークンについて詳述する。
【００２５】
ＯＡｕｔｈ２．０で利用可能なＪＷＳ（ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ）は、ＪＷＴ（ＪＳＯＮ  Ｗｅｂ  Ｔｏｋｅｎ）で表現されたコンテンツをデジタル署名やＭＡＣｓ（Ｍｅｓｓａｇｅ  Ａｕｔｈｅｎｔｉｃａｔｉｏｎ  Ｃｏｄｅｓ）により保護して表現する手段である。また、ＪＷＴは、ＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ  Ｏｂｊｅｃｔ  Ｎｏｔａｔｉｏｎ）をベースとしたデータ構造を用いたＵＲＬセーフなクレームの表現方法である。ＪＷＳ、ＪＷＴについては、各々ＲＦＣ（ＲＦＣ７５１５（ＪＷＳ）、ＲＦＣ７５１９（ＪＷＴ））として仕様化、公開されている。
【００２６】
本実施形態で使用するＪＷＳアクセストークンに含まれるクレームは、以下である。
【００２７】
【表１】
2020030759.tif 000003
【００２８】
表１のクレーム名クラス“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”の各クレームは、ＪＷＴのＲＦＣ７５１９で予め定義されたクレームで以下である。すなわち、ＪＷＴの発行者の識別子“ｉｓｓ”（Ｉｓｓｕｅｒ）、ＪＷＴの主語となる主体の識別子“ｓｕｂ”（Ｓｕｂｊｅｃｔ）、ＪＷＴを利用することが想定された主体の識別子一覧“ａｕｄ”（Ａｕｄｉｅｎｃｅ）、ＪＷＴの有効期限“ｅｘｐ”（Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ）、ＪＷＴが有効になる日時“ｎｂｆ”（Ｎｏｔ  Ｂｅｆｏｒｅ）、ＪＷＴのための一意な識別子“ｉａｔ”（Ｉｓｓｕｅｄ  Ａｔ）、“ｊｔｉ”（ＪＷＴ  ＩＤ）を表す。上記“ｅｘｐ”、“ｎｂｆ”、“ｉａｔ”に指定する日時はＩｎｔＤａｔｅで、１９７０−０１−０１Ｔ０：０：０Ｚ  ＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表わすＪＳＯＮ数値である。またこれらの“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”の使用は任意である。
【００２９】
“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”に関し、具体的に本実施形態においては、認可サーバ２０１が、“ｉｓｓ”として認可サーバ２０１のＵＲＩ、“ｓｕｂ”としてユーザのＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ  Ｕｎｉｑｕｅ  Ｉｄｅｎｔｉｆｉｅｒ）、“ａｕｄ”としてリソースサーバ２０４のＵＲＩ、“ｅｘｐ”として本ＪＷＴ発行時から３６００秒、すなわち“ｉａｔ”の値＋３６００、“ｎｂｆ”として本ＪＷＴ発行時、すなわち“ｉａｔ”と同じ値、“ｊｔｉ”として認可トークン情報の認可トークンＩＤを設定する。
【００３０】
表１のクレーム名クラス“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”の各クレームは、認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、クライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”を表す。ＪＷＴのＲＦＣ７５１９によると、“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”はＪＷＴ発行者と利用者の合意のものとで使用するプライベートクレーム名クラスで、他に定義されたクレーム名と衝突のないことを前提とする。本実施形態では、“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”クラスのクレーム名に認可トークン情報（認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、認可トークンクライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”）と、認可トークンに紐付く属性情報（ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、テナントＩＤ”ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”）を持つ。表１のＪＷＳアクセストークンに含まれるクレームの内容や、認可サーバ２０１による発行方法、リソースサーバ２０４における使用方法については後述する。
【００３１】
“Ｐｒｉｖａｔｅ  Ｃｌａｉｍ”に関し、具体的に本実施形態においては、認可サーバ２０１が、認可情報として“ａｕｔｈｚ：ｓｃｏｐｅｓ”、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”のクレームを設定する。すなわち、“ａｕｔｈｚ：ｓｃｏｐｅｓ”としてリソースサーバが取得を許可するリソースを表すスコープリストを、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”としてリソースサーバにアクセスするクライアントのＩＤを設定する。さらに、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”のトークンに紐付く属性情報として、“ｓｕｂ”に設定したユーザＩＤのユーザの情報を表すクレームを以下のように設定する。すなわち、“ｅｘｔ：ｆｎａｍｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのファーストネーム、“ｅｘｔ：ｌｎａｍｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのラストネーム、“ｅｘｔ：ｌｏｃａｌｅ”として“ｓｕｂ”に設定したＵＵＩＤのユーザのロケール名、“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”として“ｓｕｂ”に設定したＵＵＩＤのユーザが所属するテナントＩＤ、“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”として“ｓｕｂ”に設定したＵＵＩＤのユーザの電子メールアドレス、“ｅｘｔ：ａｐｐｉｄ”としてクライアントアプリケーションのＩＤであるアプリケーションＩＤを設定する。詳細は後述する。
【００３２】
認可サーバ２０１は、表１のクレームをＪＷＴの仕様であるＲＦＣ７５１９によりＪＳＯＮとしてエンコードする。更に、認可サーバ２０１は、ＪＷＳの仕様であるＲＦＣ７５１５のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表１のクレームのＪＳＯＮ表現、すなわちＪＷＴペイロード）をコンパクトなＵＲＬ−ｓａｆｅ文字列として表現符号化する。本実施形態のＪＷＳアクセストークンは、ＪＷＳコンパクトシリアライゼーション仕様に従い、エンコード済ＪＷＳヘッダー、エンコード済ＪＷＴペイロード、およびエンコード済ＪＷＳ署名を、この順序でピリオド（‘．’）文字を区切り文字として連結した文字列である。
【００３３】
本実施形態においては、ＪＷＳヘッダーとしてＪＷＳの署名に使われる暗号アルゴリズムを識別する“ａｌｇ”（アルゴリズム）を用いる。具体的に本実施形態においては、“ａｌｇ”として“ＲＳ２５６”（ＲＳＡＳＳＡ−ＰＫＣＳ１＿ｖ１＿５  ｕｓｉｎｇ  ＳＨＡ−２５６）を用いる。“ＲＳ２５６”文字列は、“ａｌｇ”の値としてＩＡＮＡ  ＪＳＯＮ  Ｗｅｂ  Ｓｉｇｎａｔｕｒｅ  ａｎｄ  Ｅｎｃｒｙｐｔｉｏｎ  Ａｌｇｏｒｉｔｈｍｓ  レジストリに登録されており、ＪＳＯＮ  Ｗｅｂ  Ａｌｇｏｒｉｔｈｍｓ（ＪＷＡ）仕様（ＲＦＣ７５１８）のＳｅｃｔｉｏｎ３．１で定義されている。
【００３４】
なお、本実施形態においてＪＷＳの署名に使われる暗号アルゴリズム“ＲＳ２５６”で使用する秘密鍵・公開鍵の鍵ペアは、認可サーバ２０１が予め生成しておき、後述する暗号鍵管理テーブルで管理する。またＪＷＳの署名を検証する公開鍵は、前述の通りＪＷＳアクセストークンを検証するリソースサーバ２０４の初回起動時に取得しておく。詳細は後述する。
【００３５】
［ソフトウェア構成］
図５（Ａ）は、本実施形態に係る認可サーバ２０１の機能（ソフトウェア構成）の例を示す。テナント管理部５０１、ユーザ管理部５０２、及びクライアント管理部５０３は、それぞれテナント情報の管理、ユーザ情報の管理、クライアント情報の管理を行う。ＪＷＳアクセストークン発行部５０４は、ＪＷＳアクセストークンの発行を行い、発行されたＪＷＳアクセストークンの情報は発行済みＪＷＳアクセストークン管理部５０５に保管される。リソースサーバ情報管理部５０６は、認可サーバ２０１と連携するリソースサーバ２０４に関する情報を管理する。
【００３６】
以下、表２〜表９を用いて、図５（Ａ）に示した認可サーバ２０１の各機能ブロックが管理するデータテーブルについて詳述する。各機能ブロックは、下記の表に示されたデータテーブルに基づいてＪＷＳアクセストークンを発行、検証する。詳細は後述する。
【００３７】
表２、表３は、本実施形態に係る認可サーバ２０１のユーザ管理部５０２が管理するユーザ管理テーブル（表２）、及びユーザ属性管理テーブル（表３）である。
【００３８】
【表２】
2020030759.tif 000004
【００３９】
表２のユーザ管理テーブルは、ユーザＩＤ項目、ユーザＩＤの内部表現であるＵＵＩＤ（Ｃｌｉｅｎｔ  ＩＤ）項目、ユーザＩＤに対応するパスワードを示すＰａｓｓｗｏｒｄ項目、ユーザ種別を示すＵｓｅｒ  Ｔｙｐｅ項目を含んで構成される。認可サーバ２０１は、ＵＵＩＤ（Ｃｌｉｅｎｔ  ＩＤ）、Ｐａｓｓｗｏｒｄの情報の組を検証し、正しければ認証情報を生成することで、各ユーザもしくはクライアントを認証する機能（不図示）を備える。
【００４０】
【表３】
2020030759.tif 000005
【００４１】
表３のユーザ属性管理テーブルは、ユーザＩＤの内部表現であるＵＵＩＤ項目、ＵＵＩＤのユーザの姓を示すＦｉｒｓｔ  Ｎａｍｅ項目、名を示すＬａｓｔ  Ｎａｍｅ項目、ロケールを示すＬｏｃａｌｅ項目、同ユーザの所属するテナントを示すＴｅｎａｎｔ  ＩＤ項目、同ユーザの電子メールアドレスを示すＥｍａｉｌ項目、同ユーザの使用できるサービスを示すＳｅｒｖｉｃｅ  ＩＤ項目を含んで構成される。
【００４２】
表４は、本実施形態に係る認可サーバ２０１のクライアント管理部５０３が管理するクライアント管理テーブル（表４）である。
【００４３】
【表４】
2020030759.tif 000006
【００４４】
表４のクライアント管理テーブルは、クライアントＩＤを示すＣｌｉｅｎｔ  ＩＤ項目、Ｃｌｉｅｎｔ  ＩＤのクライアントのクライアント名を示すＣｌｉｅｎｔ  Ｎａｍｅ項目、ＯＡｕｔｈ２．０（ＲＦＣ６７４９）プロトコル等で使用する同クライアントのリダイレクトＵＲＬを示すＲｅｄｉｒｅｃｔ  ＵＲＬ、同クライアントの使用できるサービスを示すＳｅｒｖｉｃｅ  ＩＤ項目を含んで構成される。
【００４５】
表５は、本実施形態に係る認可サーバ２０１のリソースサーバ情報管理部５０６が管理するサービス管理テーブル（表５）である。
【００４６】
【表５】
2020030759.tif 000007
【００４７】
表５のサービス管理テーブルは、リソースサーバで提供するリソースに関するサービスを表すサービスＩＤを示すＳｅｒｖｉｃｅ  ＩＤ項目、Ｓｅｒｖｉｃｅ  ＩＤに相当するサービスをリソースとして表し、ＯＡｕｔｈ２．０プロトコルなどの認可要求のスコープに指定される内容であるＳｃｏｐｅ項目、Ｓｅｒｖｉｃｅ  ＩＤに相当するサービス（リソース）を提供するリソースサーバのＵＲＬを示すＵＲＬ項目を含んで構成される。
【００４８】
表６〜表９は、本実施形態に係る認可サーバ２０１のＪＷＳアクセストークン発行部５０４および発行済みＪＷＳアクセストークン管理部５０５が管理、参照するトークン管理テーブル（表６）、リフレッシュトークン管理テーブル（表７）、トークン属性管理テーブル（表８）、暗号鍵管理テーブル（表９）である。
【００４９】
【表６】
2020030759.tif 000008
【００５０】
表６のトークン管理テーブルは、トークンＩＤを示すＴｏｋｅｎ  ＩＤ項目、アクセストークン、認可コードなど、トークンＩＤのトークンタイプを示すＴｏｋｅｎ  Ｔｙｐｅ項目、トークンＩＤの有効期限を秒（ｓｅｃ）で示すＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ項目、ＯＡｕｔｈ２．０プロトコルなどの認可要求のスコープに指定される内容であるＳｃｏｐｅ項目、ＯＡｕｔｈ２．０プロトコルなどで使用するトークンＩＤのＧｒａｎｔ  Ｔｙｐｅを示すＧｒａｎｔ  Ｔｙｐｅ項目を含んで構成される。
【００５１】
【表７】
2020030759.tif 000009
【００５２】
表７のリフレッシュトークン管理テーブルは、ＯＡｕｔｈ２．０プロトコルなどで使用する、リフレシュトークンを管理するテーブルである。リフレッシュトークン管理テーブルは、トークンＩＤを示すＴｏｋｅｎ  ＩＤ項目、トークンＩＤのリフレッシュトークンのＩＤを示すＲｅｆｒｅｓｈ  Ｔｏｋｅｎ  Ｔｙｐｅ項目、リフレッシュトークンＩＤの有効期限を秒で示すＲｅｆｒｅｓｈ  Ｔｏｋｅｎ  Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ項目を含んで構成される。
【００５３】
【表８】
2020030759.tif 000010
【００５４】
表８のトークン属性管理テーブルは、ＯＡｕｔｈ２．０プロトコルなどで使用する、トークン属性を管理するテーブルである。トークン属性管理テーブルは、トークンＩＤを示すＴｏｋｅｎ  ＩＤ項目、トークンＩＤの発行要求元のクライアントＩＤを示すＣｌｉｅｎｔ  ＩＤ項目、トークンＩＤに紐付くＵＵＩＤを示すＵＵＩＤ項目、クライアントＩＤのアプリケーション（サービス管理テーブル（表５）のサービスＩＤのサービスを利用する）でトークンＩＤを用いるアプリケーションを示すＡｐｐｌｉｃａｔｉｏｎ  ＩＤ項目を含んで構成される。
【００５５】
【表９】
2020030759.tif 000011
【００５６】
表９の暗号鍵管理テーブルは、アクセストークンのデジタル署名で使用する、サービスに対して使用する暗号鍵を管理するテーブルである。暗号鍵管理テーブルは、サービスＩＤを示すＳｅｒｖｉｃｅ  ＩＤ項目、サービスＩＤに紐づいてデジタル署名に用いられる鍵の識別子を示すＫｅｙ  ＩＤ項目、デジタル署名で利用されるアルゴリズムを示すＡｌｇｏｒｉｔｈｍ項目、署名生成に用いる秘密鍵を示すＰｒｉｖａｔｅ  Ｋｅｙ項目、署名検証に用いる公開鍵を示すＰｕｂｌｉｃ  Ｋｅｙ項目を含んで構成される。なお、表９におけるＰｒｉｖａｔｅ  Ｋｅｙ項目、Ｐｕｂｌｉｃ  Ｋｅｙ項目の各値は”＊＊”により省略して記述している。
【００５７】
図５（Ｂ）は、本実施形態に係るリソースサーバ２０４の機能（ソフトウェア構成）の例を示す。リソース管理部５１０は、リソース情報の管理（後述するスコープとリソースの対応関係の定義を含む）を行う。ＪＷＳアクセストークン管理部５１１は、ＪＷＳアクセストークン情報の管理を行う。ＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンの検証を行う。削除鍵情報管理部５１３は、削除された鍵情報の管理を行う。認可サーバ情報管理部５１４は、リソースサーバ２０４と連携する認可サーバ２０１に関する情報を管理する。
【００５８】
表１０は、リソースサーバ２０４の削除鍵情報管理部５１３が管理・参照する削除鍵管理テーブル（表１０）である。
【００５９】
【表１０】
2020030759.tif 000012
【００６０】
表１０の削除鍵情報管理テーブルは、ＪＷＳアクセストークンの検証で用いる、認可サーバ２０１側で削除された鍵を管理するテーブルである。削除鍵管理テーブルは、認可サーバ２０１で削除された秘密鍵を示すＫｅｙ  ＩＤ項目を含んで構成される。秘密鍵の削除が行われていない場合は削除鍵管理テーブルで管理する項目はないため、テーブルの中身は空となっている。詳細は後述する。
【００６１】
［本実施形態に係るＪＷＳアクセストークン発行と検証の流れ］
図６は、本実施形態に係るＪＷＳアクセストークン発行と検証に関するシーケンス図である。認可サーバ２０１、クライアント２０３、及びリソースサーバ２０４間で連携が行われる。
【００６２】
本実施形態では、ＯＡｕｔｈ２．０における認可コードグラントのフローを用いたＪＷＳアクセストークンの発行と検証について述べる。ＪＷＳアクセストークンの発行と検証については、認可コードグラントだけでなく、ＯＡｕｔｈ２．０にあるクライアントクレデンシャルグラント、リソースオーナーパスワードクレデンシャルグラント、インプリシットグラント等を用いてもよい。これらについては公知の方法を利用可能であるとし、ここでは説明を省略する。
【００６３】
ＯＡｕｔｈ２．０プロトコルにおいては、アクセストークン発行などのフローを開始する前に、クライアント２０３を認可サーバ２０１に登録する。クライアント２０３を認可サーバ２０１に登録する方法は、通常、エンドユーザとの対話を伴うＨＴＭＬ登録フォーム（不図示）を持つことになる。本実施形態においては、予め必要なクライアント２０３は登録されているものとする。クライアント２０３の登録の際、認可サーバ２０１はクライアント２０３に対してクライアントＩＤ、パスワードを発行し、表２のユーザ管理テーブルのＵＵＩＤ（Ｃｌｉｅｎｔ  ＩＤ）項目に発行したクライアントを、Ｐａｓｓｗｏｒｄ項目に発行したパスワードを登録する。そして、後述するアクセストークンに付与するＳｃｏｐｅに関連付けられたサービスＩＤの値を、表４のクライアント管理テーブルに登録するものとする。
【００６４】
さらには、ＯＡｕｔｈ２．０の認可コードの取得フローに従い、認可サーバ２０１は、ユーザ管理テーブル（表２）のユーザＩＤに相当するリソースオーナーの認証後、トークン管理テーブル（表６）と、トークン属性管理テーブル（表８）のように認可コードを登録し、クライアント２０３が認可コードを取得する。
【００６５】
リソースサーバ２０４は、前述のように初回起動時に認可サーバ２０１から公開鍵情報を取得しておく。このとき取得する情報としては、表９で示した暗号鍵管理テーブルからＫｅｙ  ＩＤ項目、およびＰｕｂｌｉｃ  Ｋｅｙ項目の値を抽出したものである。なお、公開鍵情報の取得はリソースサーバ２０４の起動時以外でもよく、アクセストークンの検証を行う前に取得できていればよいので、取得するタイミングについては特に限定されるものではない。以下、図６におけるフローを詳述する。
【００６６】
クライアント２０３が認可サーバ２０１に、ＯＡｕｔｈ２．０プロトコルの仕様に従い認可コード、各種クレデンシャル（認証情報又は認可コード）を示してアクセストークンの発行を要求する（Ｓ６０１）。認可サーバ２０１は、要求に応じてＪＷＳアクセストークンを発行する（Ｓ６０２）。ここで、図７のフローチャートを利用して本実施形態における認可サーバ２０１によるＪＷＳアクセストークンの発行について説明する。本処理は、例えば、認可サーバ２０１のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。
【００６７】
Ｓ７０１にて、認可サーバ２０１のＪＷＳアクセストークン発行部５０４は、前記ＪＷＳアクセストークン発行の要求を受信する。具体的には、本実施形態の場合、以下のようなＪＷＳアクセストークン発行要求を受信する。ここでの発行要求は一例であり、これに限定するものではない。
【００６８】
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
【００６９】
Ｓ７０２にて、ＪＷＳアクセストークン発行部５０４は、上記要求のＡｕｔｈｏｒｉｚａｔｉｏｎヘッダー部にＢａｓｅ６４符号化されて含まれるＣｌｉｅｎｔ  ＩＤおよびパスワードを用いて認証処理を行う。本実施形態の場合、Ａｕｔｈｏｒｉｚａｔｉｏｎヘッダーに含まれるＢａｓｅ６４符号を復号化し、表２のユーザ管理テーブルのＵＵＩＤ（Ｃｌｉｅｎｔ  ＩＤ）およびＰａｓｓｗｏｒｄの組と比較して認証する。また、ＯＡｕｔｈ２．０の仕様に従い、ＪＷＳアクセストークン発行部５０４は、表８のトークン属性テーブルを参照し、ＪＷＳアクセストークン要求に含まれる認可コード項目（ｃｏｄｅ＝ＡｉｐｚｉＯＢｅＺｏＱＹｂＪＳ６ＷｘＳｂＫＢ）がＴｏｋｅｎ  ＩＤ項目に存在するか否かを確認する。さらに、ＪＷＳアクセストークン発行部５０４は、Ｔｏｋｅｎ  ＩＤに対応するＣｌｉｅｎｔ  ＩＤ項目を確認し、該Ｃｌｉｅｎｔ  ＩＤ項目に対応するリダイレクトＩＤを表４のクライアント管理テーブルから検索して、ＪＷＳアクセストークン要求に含まれるリダイレクトＵＲＩ項目（ｒｅｄｉｒｅｃｔ＿ｕｒｉ＝ｈｔｔｐｓ％３Ａ％２Ｆ％２Ｆｃｌｉｅｎｔ％２Ｅｅｘａｍｐｌｅ％２Ｅｃｏｍ％２Ｆｒｅｄｉｒｅｃｔ）に一致するか否かを確認する。
【００７０】
Ｓ７０３にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０２の認証の成否を判定する。認証に失敗したと判定された場合は（Ｓ７０３にてＮＯ）Ｓ７１０へ進み、認証に成功したと判定された場合は（Ｓ７０３にてＹＥＳ）Ｓ７０４へ進む。
【００７１】
Ｓ７０４にて、ＪＷＳアクセストークン発行部５０４は、権限検証を行う。すなわち、ＪＷＳアクセストークン発行部５０４は、表４のクライアント管理テーブルのＣｌｉｅｎｔ  ＩＤに対応するＳｅｒｖｉｃｅ  ＩＤを参照し、さらに表５のサービス管理テーブルのＳｅｒｖｉｃｅ  ＩＤに対応するＳｃｏｐｅが存在するか否かを確認する。
【００７２】
Ｓ７０５にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０４におけるＳｃｏｐｅの存在確認により、ＪＷＳアクセストークン発行要求の権限検証の成否を判定する。Ｃｌｉｅｎｔ  ＩＤに対応するＳｃｏｐｅが存在しないと判定された場合（Ｓ７０５にてＮＯ）Ｓ７１０へ進み、権限検証に成功、すなわちＣｌｉｅｎｔ  ＩＤに対応するＳｃｏｐｅが存在したと判定された場合（Ｓ７０５にてＹＥＳ）Ｓ７０６へ進む。
【００７３】
Ｓ７０６にて、ＪＷＳアクセストークン発行部５０４は、クライアント認証、権限検証したクライアントの情報に従ってＪＷＳアクセストークンのペイロードとなるＪＷＴを生成する。本実施形態のＪＷＴは、表１のＪＷＳトークンに含まれるクレームに示したようなクレームを持つ。具体的には、ＪＷＳアクセストークン発行部５０４は、ＪＷＳアクセストークン発行の要求情報、表３〜表５、表９を参照し、表１に示した構成のクレームを以下のように設定する。
【００７４】
まず、ＪＷＳアクセストークン発行部５０４は、ＪＷＳヘッダーとして以下を設定する。Ｓ７０４で参照したＳｅｒｖｉｃｅ  ＩＤに対応する表９のＫｅｙ  ＩＤ項目、Ａｌｇｏｒｉｔｈｍ項目から“ｋｉｄ”：“２”、“ａｌｇ”：“ＲＳ２５６”が設定される。そして、“ｔｙｐ”：“ＪＷＴ”が設定される。
【００７５】
次に、ＪＷＳアクセストークン発行部５０４は、ＪＷＴペイロードとして以下を設定する。ＪＷＴの発行者の識別子“ｉｓｓ”（Ｉｓｓｕｅｒ）として、認可サーバ２０１のＵＲＩ“ｈｔｔｐｓ：／／ａｕｔｈ．ｅｘａｍｐｌｅ．ｃｏｍ”が設定される。ＪＷＴの主語となる主体の識別子“ｓｕｂ”（Ｓｕｂｊｅｃｔ）として、ＪＷＳアクセストークン発行要求に含まれる認可コードに対応するリソースオーナーのＩＤである表１のＵＵＩＤ“１ｃｅ４２ｆ７４−１２２５−４ｃｂｂ−ｂ２３ｆ−ｆ５２５ｄａｂｃ３ｃｆｄ”が設定される。ＪＷＴ  を利用することが想定された主体の識別子一覧“ａｕｄ”（Ａｕｄｉｅｎｃｅ）として、Ｓ７０４で検証したＳｃｏｐｅに相当するリソースサーバのＵＲＬとして、表５のＵＲＬ項目の“ｈｔｔｐｓ：／／ｓｔｏｒｅ．ｓｒｖ．ｅｘａｍｐｌｅ．ｃｏｍ”が設定される。ＪＷＴの有効期限“ｅｘｐ”（Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ）として、本ＪＷＴ発行時から３６００秒、すなわち本実施形態の場合、“ｉａｔ”の値＋３６００である“１４７２７１３４１３”が設定される。“ｎｂｆ”として本ＪＷＴ発行時、すなわち“ｉａｔ”と同じ値“１４７２７０９８１３”が設定される。本ＪＷＳアクセストークンの発行時に、認可トークンを表６のトークン管理テーブルに示すように発行し、“ｊｔｉ”として該認可トークンの認可トークンＩＤ“ｂ２６５２ｆ６ｄ７５ｂ１４ａａ４９ａｄｆｅ８９ｂ８８０８ｂ３３７ｅｆ２７６ｅ８ｄ１３６３４００ｄ９８ｆａｂ１００ｃ７４６３ｄｆ０”が設定される。
【００７６】
次に、ＪＷＳアクセストークン発行部５０４は、ＪＷＴのプライベートクレームを生成する。具体的には、認可トークンスコープリスト“ａｕｔｈｚ：ｓｃｏｐｅｓ”、認可トークンクライアントＩＤ“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”が設定されるが、表３〜表５を参照し、ＪＷＳアクセストークン発行要求のクライアントＩＤ、リソースオーナーＩＤであるユーザＩＤ（ＵＵＩＤ）に紐付く値が設定される。
【００７７】
すなわち、“ａｕｔｈｚ：ｓｃｏｐｅｓ”として表６のＳｃｏｐｅｓ項目である“［ｃｌｉｅｎｔ．ＳｔｏｒｅＳｅｒｖｉｃｅ］”、“ａｕｔｈｚ：ｃｌｉｅｎｔ＿ｉｄ”として表４のＣｌｉｅｎｔ  ＩＤ項目の“５２３ｅｅ２０ｃ９ｆ３９＠２４４９ｂａｘｔ”、ファーストネーム“ｅｘｔ：ｆｎａｍｅ”として表３の“Ｊｏｈｎ”、ラストネーム“ｅｘｔ：ｌｎａｍｅ”として表３の“Ｄｏｅ”、ロケール名“ｅｘｔ：ｌｏｃａｌｅ”として表３の“ｅｎ＿ＵＳ．ｕｔｆ−８”、テナントＩＤ“ｅｘｔ：ｔｅｎａｎｔｉｄ＠ｒｅｃｍ”として表３の“１７０ＢＡ”、電子メールアドレス“ｅｘｔ：ｅｍａｉｌ＠ｒｅｑ”として表３の“ｊｏｈｎ．ｄｄｏ＠ｅｘａｍｐｌｅ．ｃｏｍ”、アプリケーションＩＤ“ｅｘｔ：ａｐｐｉｄ”として表８のＡｐｐｌｉｃａｔｉｏｎ  ＩＤ項目である“４２ｃ５ａ９６２６０９８４５９ｅ９６ｄ４ｂａｃｄ７３ｃ２９８２３３９２ａ７６ａ０２ｃｃ９４ｄ３６９８５ｂ７ｄｃ０ｄ７９０ｂ９ａ４”が設定される。
【００７８】
まとめると、Ｓ７０６、Ｓ７０７により、下に示す表１１のようにＪＷＴペイロードが指定される。
【００７９】
【表１１】
2020030759.tif 000013
【００８０】
次に、Ｓ７０８にて、ＪＷＳアクセストークン発行部５０４は、Ｓ７０４で参照したＳｅｒｖｉｃｅ  ＩＤに対応する表９のＡｌｇｏｒｉｔｈｍ項目、Ｐｒｉｖａｔｅ  Ｋｅｙ項目からデジタル署名に用いるアルゴリズムと秘密鍵を決定する。そして、ＪＷＳの仕様であるＲＦＣ７５１５のコンパクトシリアライゼーション仕様に従い、決定したアルゴリズムと秘密鍵を用いてデジタル署名を行う。さらに、ＪＷＳアクセストークン発行部５０４は、デジタル署名されたＪＷＴペイロードをコンパクトなＵＲＬ−ｓａｆｅ文字列として表現符号化（ＢＡＳＥ６４  ＵＲＬエンコード）する。
【００８１】
次に、Ｓ７０９にて、ＪＷＳアクセストークン発行部５０４は、エンコード済のＪＷＳヘッダー、エンコード済のＪＷＴペイロード、およびエンコード済のＪＷＳ署名を、この順序でピリオド（‘．’）文字を区切り文字として連結した文字列にして、以下のようなＪＷＳアクセストークンを生成し、ＪＷＳトークンとして発行する。以下のＪＷＳアクセストークンは一部を省略している。そして、本処理フローを終了する。
【００８２】
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”
}
【００８７】
Ｓ６０４〜Ｓ６０７は、認可サーバ２０１にて、暗号鍵の削除が行われる場合の処理である。
【００８８】
認可サーバ２０１において暗号鍵の削除が指示されると、ＪＷＳアクセストークン発行部５０４は、暗号鍵管理テーブルから該当する暗号鍵情報を削除する（Ｓ６０４）。例えば、表９におけるＫｅｙ  ＩＤ項目の値が“２”の暗号鍵を削除した場合、暗号鍵管理テーブルは下に示す表１２のようになる。このとき、サービスＩＤ“ＳｔｏｒｅＳｅｒｖｉｃｅ”に対する暗号鍵情報が消失してしまうので、ＪＷＳアクセストークン発行部５０４は新しい暗号鍵を生成し、その情報を暗号鍵管理テーブルに登録する。
【００８９】
【表１２】
2020030759.tif 000014
【００９０】
さらに、認可サーバ２０１は、暗号鍵が更新された旨をリソースサーバ２０４に通知する（Ｓ６０５）。
【００９１】
リソースサーバ２０４は、認可サーバ２０１からの通知を受け取り、これに伴って、公開鍵情報を認可サーバ２０１に要求し、その応答として更新後の公開鍵情報を取得する（Ｓ６０６）。なお、本実施形態では認可サーバ２０１の通知によりリソースサーバ２０４が公開鍵情報を要求する構成であるが、認可サーバ２０１が通知を行うとともに公開鍵情報を配布する構成でもよく、特に限定されるものではない。
【００９２】
次に、リソースサーバ２０４の削除鍵情報管理部５１３は、予め保持していた公開鍵情報と新しく取得した公開鍵情報とを比較し、消失した“ｋｉｄ”の項目を検出することで、削除鍵管理テーブルを更新する（Ｓ６０７）。具体的には、表１０で示したように、暗号鍵の削除前では削除鍵管理テーブルは空であった。予め保持していた公開鍵情報に含まれる“ｋｉｄ”は“１，２”であったが、新しく取得した公開鍵情報に含まれる“ｋｉｄ”は“１，３”であるため、“ｋｉｄ”が“２”の暗号鍵が削除されたことが検出される。その結果を受けて更新された削除鍵管理テーブルは下に示す表１３のようになる。つまり、削除された暗号鍵を示す”２”が削除鍵管理テーブルに追加され、管理される。
【００９３】
【表１３】
2020030759.tif 000015
【００９４】
削除鍵管理テーブルの生成後は、リソースサーバ２０４は、予め保持していた公開鍵情報を破棄する。以後、リソースサーバ２０４は、公開鍵情報を取得する毎に、既に保持していた公開鍵情報と新しく取得した公開鍵情報とを比較し、削除鍵管理テーブルを更新していく。なお、本実施形態では、リソースサーバ２０４側で新旧の公開鍵情報を比較することで削除鍵管理テーブルを更新していく構成としたが、認可サーバ２０１が該情報を配布し、リソースサーバ２０４にて保持する構成でもよく、特に限定されるものではない。
【００９５】
次にクライアント２０３は、認可サーバ２０１から先に取得したＪＷＳアクセストークンを使ってリソースサーバ２０４に対してサービスの提供を要求する。具体的には、クライアント２０３はリソース要求のＲＥＳＴ  ＡＰＩ呼び出しなどの際に、ＨＴＴＰのＡｕｔｈｅｎｔｉｃａｔｉｏｎヘッダーにＪＷＳアクセストークンを以下のようにセットして利用する（Ｓ６０８）。
【００９６】
Authorization: Bearer eyJraWQiOiJrMSIsImFsZyI6IlJTMjU2In0.eyJpc3MiOi(中略)BiOWE0In0.O4TpYbDB(中略)JbPyYk9YhA
【００９７】
リソース要求ＡＰＩ呼び出しを受けたリソースサーバ２０４は、クライアント２０３から取得したＪＷＳアクセストークンを検証する（Ｓ６０９）。
【００９８】
ＪＷＳアクセストークンの検証の後、リソースサーバ２０４のリソース管理部５１０は必要に応じてリソースの取得処理を行う（Ｓ６１０）。そして、リソース管理部５１０は、リソースの取得処理結果もしくはエラー情報をクライアント２０３に返す（Ｓ６１１）。
【００９９】
図８は、本発明の一実施形態におけるリソースサーバ２０４のＪＷＳアクセストークン検証、応答処理について示したフローチャートである。図６のＳ６０８〜Ｓ６１１の処理に対応する。本処理は、例えば、リソースサーバ２０４のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。
【０１００】
Ｓ８０１にて、リソースサーバ２０４は、クライアント２０３のリソース要求ＲＥＳＴ  ＡＰＩ呼び出し時、上記のようにＨＴＴＰ  ＡｕｔｈｏｒｉｚａｔｉｏｎヘッダーとしてＪＷＳアクセストークンを受信する。
【０１０１】
Ｓ８０２にて、ＪＷＳアクセストークンを受信したリソースサーバ２０４のＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンを検証する。ＪＷＳアクセストークンの検証はＲＦＣ７５１５のＡ．２．２仕様に従う。すなわち、ＪＷＳアクセストークン検証部５１２は、該ＪＷＳアクセストークンを、区切り文字であるピリオド（‘．’）文字を基準として、エンコード済ＪＷＳヘッダー、エンコード済ＪＷＴペイロード、およびエンコード済ＪＷＳ署名に分割する。さらにＪＷＳアクセストークン検証部５１２は、分割したＪＷＳヘッダー、ＪＷＴペイロード、ＪＷＳ署名を復号化（ＢＡＳＥ６４  ＵＲＬデコード）する。そして、ＪＷＳアクセストークン検証部５１２は、ＪＷＳヘッダーに示されたアルゴリズム（“ａｌｇ”：“ＲＳ２５６”）により、前述した署名ライブラリを用いて保持する公開鍵情報を基にＪＷＳ署名を検証する。
【０１０２】
Ｓ８０３にて、ＪＷＳアクセストークン検証部５１２は、Ｓ８０２のＪＷＳ署名検証の成否を判定する。該ＪＷＳ署名検証に成功したと判定した場合（Ｓ８０３にてＹＥＳ）、Ｓ８０４へ進み、次のクレーム情報の検証ステップに進む。該ＪＷＳ署名検証に失敗したと判定した場合（Ｓ８０３にてＮＯ）Ｓ８０８へ進む。
【０１０３】
Ｓ８０４にて、ＪＷＳアクセストークン管理部５１１は、復号化、署名検証済みのＪＷＴペイロードのＪＷＴを参照してクレーム情報の取得を行う。ここで取得されるクレーム情報は、図７のＳ７０６、Ｓ７０７で設定した表１１の情報である。次に、ＪＷＳアクセストークン検証部５１２は、ＪＷＳアクセストークンに含まれるクレーム情報のうち、表１１のＲｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍクラスのクレームの検証を行う。
【０１０４】
Ｓ８０５にて、ＪＷＳアクセストークン管理部５１１は、Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ検証の成否を判定する。本実施形態においては、トークンが消費される場所を表す“ａｕｄ”、有効期限を表す“ｅｘｐ”、“ｎｂｆ”について検証が行われる。具体的には、“ａｕｄ”に含まれる文字列のうち、リソースサーバ２０４のＵＲＬが含まれない場合は、ＪＷＳアクセストークン検証部５１２は、受信したＪＷＳアクセストークンが不正であると判定する。この場合、Ｓ８１１へ進む。“ｅｘｐ”が有効期限を過ぎている、もしくは“ｎｂｆ”が現在時刻以降である場合、ＪＷＳアクセストークン検証部５１２は、受信したＪＷＳアクセストークンの有効期限が切れていると判定する。この場合、Ｓ８０７へ進む。上述のいずれでもない場合は、ＪＷＳアクセストークン検証部５１２は、有効なトークンであると判定する。この場合、Ｓ８０６へ進む。
【０１０５】
Ｓ８０６にて、リソース管理部５１０はクライアント２０３からのリソース要求ＡＰＩ呼び出しに応じて処理結果（要求リソース）を返す。そして、本処理フローを終了する。
【０１０６】
Ｓ８０７にて、リソース管理部５１０は、クライアント２０３に有効期限切れエラーを返却する。有効期限切れエラーは、アクセストークンの有効期限が切れていることを示す。そして、本処理フローを終了する。
【０１０７】
Ｓ８１１にて、リソース管理部５１０は、クライアント２０３にトークン不正エラーを返却する。トークン不正エラーは、アクセストークンが不正なものであることを示す。そして、本処理フローを終了する。
【０１０８】
Ｓ８０３で該ＪＷＳ署名検証に失敗したと判定した場合、Ｓ８０８にて、ＪＷＳアクセストークン管理部５１１は、削除鍵管理テーブルを参照してＪＷＳアクセストークンの鍵情報について検証を行う。ＪＷＳアクセストークン管理部５１１は、Ｓ８０４と同様に、復号化、署名検証済みのＪＷＳヘッダーを参照してｋｉｄを取得する。ＪＷＳアクセストークン検証部５１２は、取得したｋｉｄと削除鍵情報管理部５１３が所持する削除鍵管理テーブルから、同じｋｉｄが含まれるか検証する。
【０１０９】
Ｓ８０９にて、ＪＷＳアクセストークン管理部５１１は、削除鍵検証の成否を判定する。該削除鍵検証に成功したと判定した場合、すなわち、同じｋｉｄが含まれると判定された場合（Ｓ８０９にてＹＥＳ）、Ｓ８０７へ進む。該削除鍵検証に失敗したと判定した場合（Ｓ８０９にてＮＯ）Ｓ８１０へ進む。削除鍵検証が失敗する場合とは、ＪＷＳヘッダーを参照して取得したｋｉｄが削除鍵管理テーブルに含まれていない場合である。これは、本実施形態においては、ＪＷＳアクセストークンに設定されたｋｉｄをリソースサーバ２０４が認可サーバ２０１から取得できていない場合や、そのｋｉｄが認可サーバ２０１にて発行されていないものである場合などが挙げられる。
【０１１０】
Ｓ８１０にて、リソース管理部５１０は、クライアント２０３にリソース取得エラーを返却する。リソース取得エラーは、リソースの取得が失敗した旨を示す。そして、本処理フローを終了する。
【０１１１】
［ＪＷＳアクセストークンの再取得］
次に、図７のＳ８０７で、リソースサーバ２０４から有効期限エラーを受けたクライアント２０３がＪＷＳアクセストークンを再度取得（再発行）する方法について説明する。有効期限エラーを受けた場合は、ＪＷＳアクセストークンにおいて、トークンの有効期限が切れている、もしくは削除した鍵で署名されたアクセストークンであることがエラーの原因である。よって、クライアント２０３は認可サーバ２０１にアクセストークンの発行を再度要求し、新しいＪＷＳアクセストークンを使用してリソースサーバ２０４にリソースの要求を行う。つまりは、図６のＪＷＳアクセストークンの要求およびリソースの要求の処理シーケンスが再び実行される。
【０１１２】
このとき、認可サーバ２０１のＪＷＳアクセストークン発行部５０４では、クライアント２０３からの要求に応じて、“ｋｉｄ”が“３”の暗号鍵を用いてＪＷＳアクセストークンの署名および発行を行う（Ｓ６０２）。前述のＪＷＳアクセストークンによりリソースを要求されたリソースサーバ２０４のＪＷＳアクセストークン検証部５１２は、新しく取得した公開鍵情報に“ｋｉｄ”が“３”の公開鍵が含まれているので、検証が成功する（Ｓ６０９）。その結果、クライアント２０３は要求したリソースを取得することができる。
【０１１３】
また、本実施形態において、Ｓ８０９で同じｋｉｄが含まれないと判断された場合にクライアント２０３にリソース取得エラーを返却する構成（Ｓ８０９、Ｓ８１０）としている。この構成により、クライアントはＳ８０５の判定に基づいてエラーを受けた場合とＳ８０９の判定に基づいてエラーを受けた場合とで処理を変える必要がない。つまり、従来技術において実装されている権限委譲システムに本発明を適用する際に、クライアントの実装を変更する必要がない。
【０１１４】
以上のように、本実施形態においてＪＷＳアクセストークンの検証を行うことで、以下の効果が期待できる。すなわち、安全性を損なうことなく、認可サーバにおいて暗号鍵が削除された場合においても署名付きアクセストークンの検証が正しく行え、クライアントがリソースを取得することが可能となる。
【０１１５】
＜第２の実施形態＞
第１の実施形態では、削除鍵情報を管理しＪＷＳアクセストークンのｋｉｄを検証することで、認可サーバ２０１で暗号鍵が削除された場合においてもクライアント２０３はリソースを取得できる。ここで、認可サーバ２０１で暗号鍵が削除されるたびにリソースサーバ２０４が保持する削除鍵管理テーブルに新たなレコードが追加されていく。そのため、処理が繰り返されることで、削除鍵情報管理部５１３ではテーブルから該当する鍵情報を探索する際の処理コストの増加や、テーブルを格納するための記憶部（例えば、内部メモリ）の圧迫が発生しうる。
【０１１６】
そこで、本願発明の第２の実施形態として、リソースサーバ２０４における削除鍵情報管理部５１３の処理コストやメモリ管理コストを低減するための実施形態について説明する。
【０１１７】
表１４は、リソースサーバ２０４の削除鍵情報管理部５１３が管理・参照する削除鍵管理テーブルである。
【０１１８】
【表１４】
2020030759.tif 000016
【０１１９】
表１４の削除鍵管理テーブルは、ＪＷＳアクセストークンの検証で用いる削除鍵管理テーブル（表１０）に、該削除鍵レコードを削除する時間を示すＤｅｌｅｔｅ  Ｔｉｍｅ項目を加えたものである。Ｄｅｌｅｔｅ  Ｔｉｍｅには、ＪＷＴペイロードにおける“Ｒｅｇｉｓｔｅｒｅｄ  Ｃｌａｉｍ”クラスの“ｅｘｐ”クレームと同じく、ＩｎｔＤａｔｅで１９７０−０１−０１Ｔ０：０：０Ｚ  ＵＴＣから指定されたＵＴＣの日付／時刻まで秒の数を表わすＪＳＯＮ数値が格納される。
【０１２０】
本実施形態に係るＪＷＳアクセストークン発行と検証に関するシーケンスは、第１の実施形態にて図６を用いて述べた構成と同じである。ただし、Ｓ６０７における削除鍵管理テーブルの作成処理において、Ｋｅｙ  ＩＤが追加されたレコードに対し、Ｄｅｌｅｔｅ  Ｔｉｍｅは空にしてテーブルを作成する。その他の処理内容については同じであるので、ここでの説明は省略する。
【０１２１】
［ＪＷＳアクセストークン検証および応答処理］
図９は、本実施形態に係るリソースサーバ２０４のＪＷＳアクセストークン検証、応答処理について示したフローチャートである。なお、図８と同様の処理については同じ符号を付与しており、説明は省略する。本処理は、例えば、リソースサーバ２０４のＣＰＵが記憶装置に保持されたプログラムを読み出して実行することにより実現される。
【０１２２】
Ｓ８０２でのＪＷＳ署名検証に失敗したと判定した場合（Ｓ８０３にてＮＯ）Ｓ９０１へ進む。Ｓ９０１にて、削除鍵情報管理部５１３は、削除鍵管理テーブルの各レコードのＤｅｌｅｔｅ  Ｔｉｍｅと現在時刻をＩｎｔＤａｔｅで表した数値を比較し、現在時刻の方が大きいレコードを削除する。その後、Ｓ８０８に処理を進める。なお、本実施形態ではＳ９０１の処理をＪＷＳアクセストークンの署名検証時に合わせて行う構成としたが、例えば別スレッドで定期的に削除鍵管理テーブルを監視し、その都度本処理を行う構成でもよく、特に限定されるものではない。
【０１２３】
Ｓ８０８での削除鍵検証に成功したと判定された場合、すなわち、同じｋｉｄが含まれると判定された場合（Ｓ８０９にてＹＥＳ）Ｓ９０２へ進む。Ｓ９０２にて、削除鍵情報管理部５１３は、削除鍵管理テーブルの該レコードのＤｅｌｅｔｅ  Ｔｉｍｅが空か否かを判定する。空であると判定された場合（Ｓ９０２にてＹＥＳ）Ｓ９０３へ進み、空でないと判定された場合（Ｓ９０２にてＮＯ）Ｓ９０４へ進む。
【０１２４】
Ｓ９０３にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅ  Ｔｉｍｅに所定の時刻を格納する。所定の時刻とは、現在時刻に例えば３６００（秒）を加えた値である。権限委譲システムにおける設計思想等から所定の時刻は予め決定しておく必要がある。この例の場合、ＪＷＳアクセストークンによるアクセスから３６００秒が経過した後には、Ｓ９０１の処理によって削除鍵テーブルの該レコードは削除されることとなる。また、所定の時刻にＪＷＳアクセストークンの有効期限を設定するのもよい。すなわち、復号化及び署名検証済みのＪＷＴペイロードの“ｅｘｐ”クレームが使用される。こうすることで、ＪＷＳアクセストークンの有効期限においてのみ削除鍵の検証が有効となるので、過不足なく削除鍵管理テーブルを管理でき、より望ましい。その後、Ｓ８０７へ処理を進める。
【０１２５】
Ｓ９０４にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅ  Ｔｉｍｅの値と、前述の所定の時刻とを比較し、所定の時刻の方が大きいか否かを判定する。所定の時刻の方が大きいと判定された場合（Ｓ９０４にてＹＥＳ）Ｓ９０５へ進み、そうでないと判定された場合は（Ｓ９０４にてＮＯ）Ｓ８０７へ進む。
【０１２６】
Ｓ９０５にて、削除鍵情報管理部５１３は、該レコードのＤｅｌｅｔｅ  Ｔｉｍｅを所定の時刻に更新する。これにより、有効期限がより後のＪＷＳアクセストークンの検証も有効となる。その後、Ｓ８０７へ処理を進める。
【０１２７】
以上、本実施形態において削除鍵管理テーブルの各レコードを所定の時刻をもって削除することで、削除鍵情報管理部５１３の処理コストやメモリ管理コストを低減することができる。
【０１２８】
＜第３の実施形態＞
第２の実施形態では、削除鍵管理テーブルの各レコードを所定の時刻をもって削除することで、削除鍵情報管理部５１３処理コストやメモリ管理コストを低減することができる。第１および第２の実施形態では、ＪＷＳアクセストークンの有効期限”ｅｘｐ”は認可サーバ２０１が現在時刻に３６００（秒）を加えた値を設定する構成で説明した。この“ｅｘｐ”であるが、その他にもクライアント２０３がＪＷＳアクセストークン要求時に指定することもできる。また、リソースサーバ２０４が指定することもできる。そのため、同じ暗号鍵で署名されるアクセストークンであっても、個体ごとに有効期限“ｅｘｐ”は異なる。よって、第２の実施形態において削除鍵管理テーブルのレコードを削除したとしても、その後に該暗号鍵で署名されたアクセストークンがリソース要求を行った場合、削除鍵検証で否と判定され、そのアクセストークンはリソースを取得することができない。
【０１２９】
例えば、あるクライアントＡが取得したＪＷＳアクセストークンの有効期限“ｅｘｐ”が“１４９６２７９４００”（＝２０１７−０６−０１  Ｔ１０：１０：００Ｚ  ＵＴＣ）であったとする。一方、別のクライアントＢで取得したＪＷＳアクセストークンの有効期限”ｅｘｐ”が“１４９６２８６０００”（＝２０１７−０６−０１  Ｔ１２：００：００Ｚ  ＵＴＣ）であったとする。それぞれ同じ暗号鍵で署名されており、認可サーバ２０１において同時刻（＝２０１７−０６−０１  Ｔ１０：００：００Ｚ  ＵＴＣ）において発行されたものである。この後、“２０１７−０６−０１  Ｔ１０：０２：００Ｚ  ＵＴＣ”に認可サーバ２０１において該暗号鍵が削除されたとする。
【０１３０】
“２０１７−０６−０１  Ｔ１０：０５：００Ｚ  ＵＴＣ”にクライアントＡがリソースサーバ２０４にリソースを要求した場合、第２の実施形態で説明したように、クライアントＡはリソースを取得できる。そのため、削除鍵管理テーブルにおける該暗号鍵のレコードはクライアントＡの“ｅｘｐ”である２０１７−０６−０１  Ｔ１２：１０：００Ｚ  ＵＴＣの時刻に削除される。その後、“２０１７−０６−０１  Ｔ１１：００：００Ｚ  ＵＴＣ”にクライアントＢがリソースサーバ２０４にリソースを同様に要求したとする。この場合、ＪＷＳアクセストークンは有効期限内であるにも関わらず、削除鍵管理テーブルには該暗号鍵のレコードがないため、クライアントＢにはリソース取得エラーが返却されリソースを取得することができない。
【０１３１】
そこで、削除された暗号鍵で署名されたアクセストークンが複数ある場合においても、過不足なく削除鍵情報を管理するための実施形態について説明する。
【０１３２】
表１５は、認可サーバ２０１の発行済みＪＷＳアクセストークン管理部５０５が管理、参照する発行済みトークン管理テーブルである。
【０１３３】
【表１５】
2020030759.tif 000017
【０１３４】
表１５の発行済みトークン管理テーブルは、トークンの署名に使用した秘密鍵を特定するＫｅｙ  ＩＤ項目とトークンの有効期限を示すＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅ項目を含んで構成される。
【０１３５】
Ｋｅｙ  ＩＤにはＪＷＳアクセストークン発行部５０４が発行したトークンにおけるＪＷＳヘッダーの“ｋｉｄ”が、Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅには同じく発行したトークンにおけるＪＷＴペイロードの“ｅｘｐ”クレームが格納されている。発行済みＪＷＳアクセストークン管理部５０５は、図６のＳ６０２でＪＷＳアクセストークンを発行した際に、本テーブルに該当する情報を追加していく。さらには、発行済みＪＷＳアクセストークン管理部５０５は、ＪＷＳアクセストークンを発行するたびに、そのトークンの”ｋｉｄ”と同じレコードのＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅを取得する。そして、発行済みＪＷＳアクセストークン管理部５０５は、発行したトークンの“ｅｘｐ”と比較して“ｅｘｐ”の方が大きければＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅをその値に更新する。
【０１３６】
［削除鍵情報の問い合わせ処理］
図１０は、本実施形態に係る削除鍵情報の問い合わせ処理について示したシーケンス図である。認可サーバ２０１、リソースサーバ２０４間で連携が行われる。第２の実施形態で説明した、削除鍵管理情報を削除する処理（図９のＳ９０１）が本実施形態では異なる。なお、リソースサーバ２０４のＪＷＳアクセストークン検証・応答のフローチャートは図９と同様であり、同様の処理についての説明は省略する。
【０１３７】
Ｓ８０２でのＪＷＳ署名検証に失敗したと判定された場合（Ｓ８０３にてＮＯ）、リソースサーバ２０４の削除鍵情報管理部５１３は、削除鍵管理テーブルの各レコードのＤｅｌｅｔｅ  Ｔｉｍｅと現在時刻をＩｎｔＤａｔｅで表した数値を比較し、現在時刻の方が大きいレコードのｋｉｄを取得する。そして、削除鍵情報管理部５１３は、認可サーバ２０１へ取得したｋｉｄを示し、削除の可否の問い合わせを行う（Ｓ１００１）。
【０１３８】
認可サーバ２０１の発行済みＪＷＳアクセストークン管理部５０５は、表１５の発行済みトークン管理テーブルを参照し、受信したｋｉｄとテーブルのＫｅｙ  ＩＤが一致するレコードのＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅを取得する。そして、発行済みＪＷＳアクセストークン管理部５０５は、取得したＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅと現在時刻を比較し、どちらが大きいかを判定する。現在時刻より大きいＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅがない場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除許可をリソースサーバ２０４に返す。一方、現在時刻より大きいＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅがある場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除不許可をリソースサーバ２０４に返す（Ｓ１００２）。また、該当するｋｉｄが表１５にない場合は、発行済みＪＷＳアクセストークン管理部５０５は、削除許可をリソースサーバ２０４に返す。例えば、受信ｋｉｄが“２”である場合、表１５を参照することでＥｘｐｉｒａｔｉｏｎ  Ｔｉｍｅとして“１４９６２８６０００”が取得される。現在時刻が“２０１７−０６−０１  Ｔ１１：００：００Ｚ  ＵＴＣ（＝１４９６２８２４００）”である場合、Ｅｘｐｉｒａｔｉｏｎ  Ｔｉｍｅは現在時刻より大きいので、リソースサーバ２０４には削除不許可が返却される。
【０１３９】
リソースサーバ２０４は削除許可情報を受信し、その情報に従い削除鍵情報管理部５１３は削除鍵管理テーブルを更新する（Ｓ１００３）。つまり、リソースサーバ２０４は、削除許可を受信した場合は該レコードを削除し、削除不許可を受信した場合は該レコードを削除しない。そして、図９のＳ８０８へと処理を進める。
【０１４０】
以上、本実施形態では、削除鍵管理テーブルの各レコードを削除する場合に認可サーバ２０１に問い合わせを行い、認可サーバ２０１が発行したアクセストークンの有効期限をもって該削除鍵情報の削除判定を行う。これにより、削除された暗号鍵で署名されたアクセストークンが複数ある場合においても、過不足なく削除鍵情報を管理することができる。
【０１４１】
＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１４２】
２０１…認可サーバ、２０３…クライアント、２０４…リソースサーバ、５０４…ＪＷＳアクセストークン発行部、５０５…発行済みＪＷＳアクセストークン管理部、５１１…ＪＷＳアクセストークン管理部、５１２…ＪＷＳアクセストークン検証部、５１３…削除鍵情報管理部
【図１】
2020030759.tif 000018
【図２】
2020030759.tif 000019
【図３】
2020030759.tif 000020
【図４】
2020030759.tif 000021
【図５】
2020030759.tif 000022
【図６】
2020030759.tif 000023
【図７】
2020030759.tif 000024
【図８】
2020030759.tif 000025
【図９】
2020030759.tif 000026
【図１０】
2020030759.tif 000027