(57)【要約】      （修正有）【課題】認可サーバーへの鍵の追加時に、リソースサーバーに対して鍵の追加の通知を行わずとも、追加された鍵を用いて証明した署名付きトークンの検証をリソースサーバーで行うことが可能となる情報処理装置及び認可システムと検証方法を提供する。【解決手段】情報処理装置は、署名付きトークンを検証するための鍵情報を保持する保持手段と、受信した署名付きトークンを検証するための鍵情報が、保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、鍵情報を保持手段により保持する取得手段と、受信した署名付きトークンを検証するための鍵が保持手段に保持されている場合には、鍵情報により署名付きトークンを検証する検証手段とを有することを特徴とする。【選択図】図７
2020036234.tif 000002
【特許請求の範囲】
【請求項１】
署名付きトークンを検証する情報処理装置であって、
署名付きトークンを検証するための鍵情報を保持する保持手段と、
受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該新たな鍵情報を前記保持手段により保持する取得手段と、
前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証する検証手段と
を有することを特徴とする情報処理装置。
【請求項２】
請求項1に記載の情報処理装置であって、
前記サーバーから前記新たな鍵情報を取得した取得時間を保存する保存手段を更に有し、
前記取得手段は、前記受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、前記受信した署名付きトークンが前記取得時間よりも後に発行されたものである場合に、前記サーバーから前記新たな鍵情報を取得する
ことを特徴とする情報処理装置。
【請求項３】
請求項１に記載の情報処理装置であって、
前記署名付きトークンには更に、前記署名付きトークンの一部を対象とした署名を含み、
前記取得手段はさらに、前記受信した署名付きトークンを検証するための鍵情報が、前記保持手段により保持されていない場合には、前記保持手段により保持する前記鍵情報による前記署名付きトークンの一部の検証が成功した場合に、前記サーバーから前記新たな鍵情報を取得する
ことを特徴とする情報処理装置。
【請求項４】
請求項１に記載の情報処理装置であって、
前記サーバーから前記新たな鍵情報を取得した取得時間を保存する保存手段を更に有し、
前記署名付きトークンには更に、前記署名付きトークンの一部を対象とした署名を含み、
前記取得手段はさらに、前記受信した署名付きトークンを検証するための鍵情報が、前記保持手段により保持されていない場合には、前記保持手段により保持する前記鍵情報による前記署名付きトークンの一部の検証が成功し、かつ、前記受信した署名付きトークンが前記取得時間よりも後に発行されたものである場合に、前記サーバーから前記新たな鍵情報を取得する
ことを特徴とする情報処理装置。
【請求項５】
請求項３又は４に記載の情報処理装置であって、
前記署名付きトークンの一部は、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報である
ことを特徴とする情報処理装置。
【請求項６】
請求項１乃至５のいずれか一項に記載の情報処理装置であって、
前記保持手段は、複数の前記鍵情報をそれぞれの識別情報と関連付けて保持でき、
前記検証手段は、前記署名付きトークンに含まれた、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報に対応する、前記保持手段により保持された前記鍵情報を、前記署名付きトークンを検証するための鍵として用いる
ことを特徴とする情報処理装置。
【請求項７】
請求項１乃至６のいずれか一項に記載の情報処理装置であって、
要求と共に受信した前記署名付きトークンの検証が成功した場合、前記要求に応じてソースを提供する
ことを特徴とする情報処理装置。
【請求項８】
請求項１乃至７のいずれか一項に記載の情報処理装置であって、
前記鍵情報および前記署名付きトークンを提供する前記サーバーと、該サーバーから提供された前記署名付きトークンと共にリソースの要求を送信するクライアントと、に接続されたことを特徴とする情報処理装置。
【請求項９】
請求項１乃至７のいずれか一項に記載の情報処理装置と、
前記鍵情報および前記署名付きトークンを提供する前記サーバーと、
前記サーバーから提供された前記署名付きトークンと共にリソースの要求を送信するクライアントと
を含むことを特徴とする認可システム。
【請求項１０】
請求項９に記載の認可システムであって、
前記サーバーでは、前記鍵情報の追加が行われることを特徴とする認可システム。
【請求項１１】
情報処理装置による署名付きトークンの検証方法であって、
署名付きトークンを検証するための鍵情報を保持手段に保持し、
受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該鍵情報を前記保持手段により保持し、
前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証する
ことを特徴とする検証方法。
【請求項１２】
情報処理装置により署名付きトークンを検証するためのプログラムであって、
署名付きトークンを検証するための鍵情報を保持手段に保持し、前記情報処理装置を、
受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該鍵情報を前記保持手段により保持し、
前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証する
よう機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、例えば署名付きトークンを用いた認可トークン等を検証する情報処理装置及び認可システムと検証方法に関する。
【背景技術】
【０００２】
近年、ネットワーク上のＷｅｂサービスでは利用者がＷｅｂサービスの利用を認められているかどうかの認証が行われる。そして、Ｗｅｂサービスが多様化し、複数のＷｅｂサービスが互いに連携を行うようになるにつれ、Ｗｅｂサービスを提供するリソースサーバーと認証・認可を行う認証・認可サーバーとが別々のサーバーとして構成されるようになってきた。このような構成では、認証・認可サーバーとリソースサーバーが互いに認証・認可情報を授受することで連携している。認証・認可サーバーは認可情報を含むアクセストークンを発行し、クライアントはアクセストークンを利用してリソースサーバーからサービスの提供を受ける。このような認可情報の授受に関する仕様の一つとしてＯＡｕｔｈ２．０等が公開されている。
【０００３】
従来のOAuth仕様の実装においては、クライアントからリソースサーバーが受け取った全てのアクセストークンについて、基本的に、リソースサーバーが認証・認可サーバー（トークンのステートを持つサーバー）に対して、該トークンの検証問い合わせを行うことになる。また一般に、トークンに紐付くユーザー情報についても同様に、リソースサーバーがトークンに紐付くユーザー情報を所有する認可サーバーに情報問い合わせを行うことになる。このように、クライアント、リソースサーバーの台数が増えるに従い、リソースサーバーから認証・認可サーバー（発行済みトークンのトークン情報及びトークンに紐付くユーザー情報を持つサーバー）へのトークン検証、情報問い合わせが増え、認証・認可サーバーの負荷が高くなる。またクライアントから受信した全トークンについて毎回認証・認可サーバーに検証、情報問い合わせをおこなうことにより、リソースサーバーのパフォーマンスが低下することになる。
【０００４】
ところで、認証・認可サーバーで発行するトークンに、予め認可情報（トークンID, スコープ, 有効期限など）およびトークンに紐付く情報（ユーザーID、クライアントID、ユーザー名、メールアドレスなど）を付与し、リソースサーバーがクライアントから受け取ったアクセストークンをリソースサーバー自身で検証できるようにすることが考えられる。上記リソースサーバーの検証は、認証・認可サーバーがトークンに署名を付与してリソースサーバーでそれを検証できるようにすればよい。署名付きトークンの表現方法としては、JWS（JSON Web Signature)を用いることが考えられる。JWSは、JWT（JSON Web Token）で表現されたコンテンツをデジタル署名やMACs（Message Authentication Codes）により保護して表現する手段である。またJWTは、JSON（JavaScript Object Notation（Javaは登録商標））をベースとしたデータ構造を用いたURLセーフなクレームの表現方法である。JWS、JWTについては、各々非特許文献１、非特許文献２にて仕様化され、公開されている。
【０００５】
トークンの譲渡を受けたシステムがトークンを使用する時点においても確実にトークンの検証をすることができる権限管理システムについては、例えば、特許文献１のような方法がある。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００７−１４９０１０号公報
【非特許文献】
【０００７】
【非特許文献１】"JSON Web Signature (JWS) "、[online] M. Jones、J. Bradley、N. Sakimura、2015年5月 ＜URL https://tools.ietf.org/html/rfc7515＞（2018年8月22日検索）
【非特許文献２】"JSON Web Token (JWT)"、[online] M. Jones、J. Bradley、N. Sakimura、2015年5月 ＜URL https://tools.ietf.org/html/rfc7519＞（2018年8月22日検索）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
認証・認可サーバーは秘密鍵と公開鍵のペアを複数所持することもできる。認証・認可サーバーは秘密鍵が流出した場合や、利用している暗号化アルゴリズムが危殆化した際に、新たな鍵を登録して利用する事で、安全性をたかめることができる。また、認可を行うサービスやクライアント毎に異なる秘密鍵を利用する事で、サービス単位で安全性を高めることができる。しかしながら、認証・認可サーバーとリソースサーバーは別個のサーバーで構成されている為、認証・認可サーバーに新しい鍵ペアが登録されても、リソースサーバーはそれを認知できないため、公開鍵を取得できない。そのため、リソースサーバーにより署名付きトークンの検証を行うシステムにおいて、リソースサーバーが保持していない公開鍵に対応する秘密鍵を用いて署名を付与されたアクセストークンが発行されることがあり得る。その場合、リソースサーバーではそのトークンの検証を行えず、クライアントが認証・認可サーバーより発行されたアクセストークンを用いてもリソースサーバーで不正な署名だと判断される。
【０００９】
本発明は上記従来例に鑑みてなされたもので、認証・認可サーバーへの鍵の追加時に、リソースサーバーに対して鍵の追加の通知を行わずとも、追加された鍵を用いて署名した署名付きトークンの検証をリソースサーバーで行うことを可能とすることを目的とする。
【課題を解決するための手段】
【００１０】
上記目的を達成するために本発明は以下の構成を有する。すなわち、本発明の一側面によれば、署名付きトークンを検証する情報処理装置であって、
署名付きトークンを検証するための鍵情報を保持する保持手段と、
受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該鍵情報を前記保持手段により保持する取得手段と、
前記受信した署名付きトークンを検証するための鍵が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証する検証手段と
を有することを特徴とする情報処理装置が提供される。
【発明の効果】
【００１１】
本発明によれば、認可サーバーへの鍵の追加時に、リソースサーバーに対して鍵の追加の通知を行わずとも、追加された鍵を用いて証明した署名付きトークンの検証をリソースサーバーで行うことが可能となる。
【図面の簡単な説明】
【００１２】
【図１】本発明の一実施形態におけるコンピュータの構成内容を示す図
【図２】本発明の一実施形態におけるネットワーク構成図
【図３】アクセストークン発行と検証のシーケンス図
【図４】本発明の一実施形態における認証・認可サーバーの機能ブロック図
【図５】本発明の一実施形態におけるリソースサーバーの機能ブロック図
【図６】本発明の一実施形態における、JWSアクセストークンの発行と検証のシーケンス図
【図７】本発明の実施形態１における、JWSアクセストークン検証のフローチャート
【図８】本発明の実施形態２における、JWSアクセストークン検証のフローチャート
【図９】本発明の実施形態３における、JWSアクセストークン検証のフローチャート
【図１０】本発明の実施形態４における、JWSアクセストークン検証のフローチャート
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための形態について図面を用いて説明する。まず複数の実施形態に供給の構成を説明する。
【００１４】
●システム構成
図１は、本発明を実施するための一実施形態に係る情報処理装置のシステム構成を示す図である。情報処理装置は、サーバーやクライアントなどとして機能するコンピュータである。図１において、情報処理装置は、ＣＰＵ１０２、メモリ１０３、記憶装置１０４、ビデオインタフェース１０５、Ｉｎｐｕｔ／Ｏｕｔｐｕｔ（以下Ｉ／Ｏと略称）インタフェース１０６、通信インタフェース１０７を備えている。また、情報処理装置内の各構成要素はシステムバス１０１を介して互いに接続されている。ＣＰＵ１０２は、システムバス１０１を介して各構成要素を制御したり、データの計算や加工を行ったりする中央処理装置である。メモリ１０３は、データやプログラムを記憶する装置で、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）やＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）から構成される。記憶装置１０４は、記憶されたデータの書き込み／読み出しを行う。記憶装置１０４には、ハードディスクドライブ（ＨＤＤ）１１１、不揮発性のデータソースとして利用されるＤＶＤ−ＲＯＭドライブ１１２、半導体メモリを用いたソリッドステートドライブ（ＳＳＤ）１１３がある。図１には示されていないが、記憶装置１０４として、磁気テープドライブ、フロッピー（登録商標）ディスクドライブ（ＦＤＤ）、ＣＤ−ＲＯＭドライブ、ＣＤ／ＤＶＤ−ＲＡＭドライブ、ＵＳＢフラッシュドライブなども使用されることがある。
【００１５】
本実施形態に係るプログラムは、記憶装置１０４から読み込まれ、メモリ１０３に格納した上で、ＣＰＵ１０２によって実行される。なお、本実施形態ではプログラムを記憶装置１０４から読み込む構成としているが、ＲＯＭ（不図示）から読み込んだり、通信インタフェース１０７を介して外部から読み込んだりする構成としてもよい。
【００１６】
ビデオインタフェース１０５は、ディスプレイ装置１１４への表示出力を制御する。ディスプレイ装置１１４には、ＣＲＴや液晶等の方式を用いたものがある。Ｉ／Ｏインタフェース１０６には、キーボード１１５やポインティングデバイス１１６等の入力装置が接続される。操作者は、キーボード１１５を操作することにより情報処理装置に対する動作指令等を行う。ポインティングデバイス１１６は、ディスプレイ装置１１４上のカーソルを移動させてメニューやオブジェクトの選択や操作等を行う。また、ディスプレイ装置１１４には、タッチパネル等による操作の入力を行えるものもある。この場合、ディスプレイ装置１１４は出力装置と入力装置を兼ねることになる。
【００１７】
通信インタフェース１０７は、コンピュータネットワーク１１７を通して外部機器との通信を行う。接続先のネットワークには、ＬＡＮやＷＡＮ、インターネットのような公衆回線等がある。
【００１８】
なおサーバーについては、ユーザインターフェイスのためのデバイス、たとえばディスプレイ１１４やキーボード１１５、マウス１１などは、インタフェースも含めて、有していなくともよい。
【００１９】
図２は、本実施形態に係るネットワーク構成図である。インターネット２１０には、コンピュータネットワーク２１１、２１２、２１３が接続されており、コンピュータネットワーク２１１には、認証・認可サーバー２０１が接続されている。また、コンピュータネットワーク２１２にはリソースサーバー２０２、コンピュータネットワーク２１３にはクライアント２０３がそれぞれ接続されている。本実施形態においてリソースサーバー２０２は、インターネット２１０を跨いだコンピュータネットワーク上に接続されているが、認証・認可サーバー２０１と同じLANに存在していても良い。クライアント２０３は図２のようにコンピュータネットワーク２１３に接続されている場合に限らず、コンピュータネットワーク２１１や２１２に接続されていてもよい。
【００２０】
クライアント２０３は認証・認可サーバー２０１からアクセストークンを取得する。また、取得したアクセストークンを使って、リソースサーバー２０２からＷｅｂサービス（以下サービスと略称）の提供を受ける。なお、本実施形態において、認証・認可サーバー２０１、リソースサーバー２０２、クライアント２０３はいずれも、図１にて示した情報処理装置の構成を有するものとする。ただし、図１の構成に限定するものではなく、ディスプレイ装置１１４を備えていなかったり、他の機能を備えていていたりしても構わない。また、サーバーは、単体のコンピュータに限らず、ラックマウント型の複数台のコンピュータで構成されたシステムであっても構わない。
【００２１】
●署名付きアクセストークンの発行と検証（従来）
図３において、従来技術におけるアクセストークン発行と検証の流れについて説明する。図３は従来技術における署名付きトークン、例えば署名付きアクセストークン発行と検証に関するシーケンス図である。図２で説明した認証・認可サーバー２０１、クライアント２０３、リソースサーバー２０２間で連携している。ここで署名とはデジタル署名または電子署名を指す。たとえば検証対象のデータに、その対象データを秘密鍵で暗号化したデジタル署名を付して送信すると、その送信先では受信した署名を公開鍵で復号し、復号結果を対象データと比較して一致すれば検証は成功したと判断できる。これは一例であるが、このような要領で署名付きデータは検証される。なお本実施形態の鍵はデジタル情報であり、鍵情報ということもある。また以下の実施形態においては、認証とは例えばＩＤや秘密情報などを用いて、対象（例えばユーザー）の有する権限を確認する手順である。また、認可とは例えば認証された対象の有する権限の他者（例えばクライアントなど）への委譲を確認する手順である。なおこれは一例であってこれに限らない。この認証および認可に関するサービスを提供するサーバーを認証・認可サーバーと呼び、説明においては、提供しているサービスに応じて認証サーバーや認可サーバーと省略することもある。
【００２２】
まず、Ｓ３０１で、リソースサーバー２０２は、認証・認可サーバー２０１に対して公開鍵を要求し、取得する。次に、Ｓ３０２で、クライアント２０３は、認証・認可サーバー２０１に対して認証情報あるいは認可コードを渡して署名付きアクセストークンを要求し、取得する。次に、Ｓ３０３で、クライアント２０３は取得した署名付きアクセストークンを使ってリソースサーバー２０２に対してサービスの提供を要求する。Ｓ３０４で、リソースサーバー２０２は受け取った署名を元にアクセストークンが適正かどうかを検証する。この際に、リソースサーバー２０２は、認証・認可サーバー２０１より取得した公開鍵を用いて署名を検証することで、適正な認証・認可サーバーで発行されたアクセストークンであることを確認できる。そして、Ｓ３０５で、アクセストークンが適正であればリソースサーバー２０２はサービスを提供するための処理を実行し、処理結果をクライアント２０３に返す。なお、Ｓ３０４の検証でアクセストークンが不適正であった場合は、リソースサーバー２０２は処理を行わず、エラーをクライアント２０３に返す。
【００２３】
ここで図３のＳ３０１の公開鍵取得要求においては、リソースサーバー２０２の初期化時など、クライアント２０３へのサービス提供前に一度行うようにすればよい。しかし、Ｓ３０１の公開鍵の取得後に、認証・認可サーバー２０１に新たに秘密鍵・公開鍵のペアが追加されることがある。その場合、認証・認可サーバー２０１が保持しているが、リソースサーバー２０２が保持していない鍵を用いて署名されたアクセストークンがクライアント２０３へ発行される場合がある。その結果、適正なアクセストークンであるにも関わらず、リソースサーバー２０２における署名の検証で不適正なアクセストークンだと判断されてしまう。これを防ぐために、リソースサーバー２０２での署名検証時には、認証・認可サーバー２０１が署名に用いる秘密鍵と対をなす公開鍵をリソースサーバー２０２が保持していなければならない。
【００２４】
ここで、認証・認可サーバー２０１へ新規に秘密鍵・公開鍵のペアが追加される度に認証・認可サーバー２０１からリソースサーバー２０２へ鍵の追加の通知を行うことが考えられる。しかし、通知の送信・受信のシステムを構築し、認証・認可サーバー２０１、リソースサーバー２０２の双方で通知システムに対応しなければならないため、システム全体が複雑化してしまう。また、通知を行ったとしてもリソースサーバーが公開鍵を取得するまでは同様の問題があり、認証・認可サーバー２０１は連携するすべてのリソースサーバーが公開鍵の取得を行ったかを認知する方法がない。以下で説明する対策方法では、認証・認可サーバー２０１からの通知を必要とせず、リソースサーバー２０２が保持していない公開鍵と対の秘密鍵を用いて付与された署名に対しても適正な検証が可能となる。また、リソースサーバー２０２から定期的に認証・認可サーバー２０１へ鍵の更新チェックを行うような構成にした場合でも、以下で説明する対策方法を用いた場合、対策方法を使用しない場合と比べ、更新チェックの間隔を長く設定することが可能となる。尚、以下の対策方法では、リソースサーバー２０２に新規に鍵が追加された場合の対策方法であるため、リソースサーバー２０２が保持していた鍵が削除された場合のみ、リソースサーバー２０２へ通知を行うような構成にしてもよい。以下において、第１の実施形態における上記課題の対応方法について説明する。
【００２５】
［実施形態１］
●ＪＷＳアクセストークン
以下本実施形態で用いる、アクセストークン情報を格納するJWS（以降JWSアクセストークンとする）について詳述する。
【００２６】
ＪＷＳアクセストークンは、ＪＷＳヘッダー、ＪＷＳペイロード、ＪＷＳ署名から構成される。以下に本実施形態にて用いられるＪＷＳアクセストークンの各構成部について説明する。
【００２７】
【表１】
2020036234.tif 000003
【００２８】
表1の値"JWS Header"の各クレームは、JWSのRFC7515で予め定義された"Registered Claim"で、以下のとおりである。なおクレームとは、対象（主体）について主張される情報であり、クレーム名およびクレーム値から成る名前／値ペアとして表される。すなわち、"JWS Header"の各クレームは、JWSの署名に使われる暗号アルゴリズムを識別する"alg" (Algorithm)、JWT型式であることを明示するために"JWT"を記述する"typ" (Type)、JWSを保護するためにどの鍵が使用されたかを示す"kid" (Key ID)を含む。
【００２９】
また、表１の各クレームは、JWTのRFC7519で予め定義された"Registered Claim"で、以下である。すなわち、JWT の発行者の識別子"iss" (Issuer)、JWT の主語となる主体の識別子"sub" (Subject)、JWT を利用することが想定された主体の識別子一覧"aud" (Audience)、JWT の有効期限"exp" (Expiration Time)、JWT が有効になる日時"nbf" (Not Before)、JWT のための一意な識別子"iat" (Issued At)を示す。上記"exp"、"nbt"、"iat"に指定する日時はIntDateで、1970-01-01T0:0:0Z UTCから指定されたUTCの日付/時刻まで秒の数を表わすJSON数値である。これらの"Registered Claim"の使用は任意であるが、本実施形態においてはJWSヘッダーの"kid"、JWSペイロードの"iat"は必須項目として認可サーバーにより設定される。
【００３０】
本実施形態の表１で示されたような内容のJWSアクセストークンを発行する認可サーバーにおいては、表１のクレームをJWTの仕様であるRFC7519によりJSONとしてエンコードし、JWSの仕様であるRFC7515のコンパクトシリアライゼーション仕様に従ってデジタル署名されたコンテンツ（表１のクレームのJSON表現、すなわちJWSペイロード）をコンパクトなURL-safe文字列として表現符号化する。本実施形態のJWSアクセストークンは、JWSコンパクトシリアライゼーション仕様に従い、エンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名を、この順序でピリオド('.')文字を区切り文字として連結した文字列である。以下にJWSヘッダー（"Header"部分）、JWSペイロード（"Payload"部分）、および、エンコード済JWSヘッダー、エンコード済JWSペイロード、およびエンコード済JWS署名を連結したもの（"Encoded"部分）の一例を示す。
【００３１】
Header
{
"alg": "RS256",
"typ": "JWT",
"kid": "3e4aed8ee5914d9e82ca0ae762fc84ef"
}
Payload
{
"iss": "https://auth.example.com",
"sub": "1ce42f74-1225-4cbb-b23f-f525dabc3cfd",
"aud": "[https://print.srv.example.com https://form.srv.example.com]",
"exp": 1472713413,
"nbf": 1472709813,
"iat": 1472709813
}
Encoded
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...(base64 encoded header).eyJpc3MiOiJjbGllbnQwMDEiLCJzdWIiOiJodHRwczovL3h4eC5jb20vIiwiYXVkIjoiaHR0cHM6Ly94eHguY29tL2F1dGhyaXphdGlvbiIsImV4cCI6MTQ3MjcxMDQxMywiaWF0IjoxNDcyNzAwNDEzfQ...(base64 encoded payload).k_SbabNV...(Signature)
【００３２】
●認証・認可サーバーの機能ブロック
図４は、本発明の一実施形態における認証・認可システムの機能ブロック図である。本機能ブロックは認証・認可サーバー２０１で動作する。各ブロックは、例えば認証・認可サーバー２０１のＣＰＵによりメモリに格納されたプログラムを実行することで実現される。クライアント管理部４０１は、クライアント情報の管理を行う。リソースサーバー情報管理部４０２は、認証・認可サーバー２０１と連携するリソースサーバー２０２に関する情報を管理する。秘密鍵・公開鍵ペア管理部４０３は、JWSアクセストークンの署名に用いる鍵の管理を行う。秘密鍵・公開鍵ペア管理部４０３は、リソースサーバー２０２からの要求に基づき、必要な公開鍵をリソースサーバー２０２へ譲渡する。表２は、秘密鍵・公開鍵ペア管理部４０３が管理する秘密鍵・公開鍵ペア管理テーブルである。
【００３３】
【表２】
2020036234.tif 000004
【００３４】
表２の秘密鍵・公開鍵ペア管理テーブルは、秘密鍵・公開鍵ペアを一意に識別するためのKey IDを示すKey ID項目、秘密鍵の詳細を示す秘密鍵項目、公開鍵の詳細を示す公開鍵項目から成る。秘密鍵項目及び公開鍵項目に設定する値は、ファイルでも良いしファイルパスでも良い。
【００３５】
JWSアクセストークン発行部４０４はJWSアクセストークンの発行を行い、発行されたJWSアクセストークンの情報は発行済みJWSアクセストークン管理部４０５に保管される。JWSアクセストークン検証部４０６はJWSアクセストークンが有効かどうか検証する。なお、JWSアクセストークンの検証はリソースサーバーにおいて後述する図５のJWSアクセストークン検証部５０３で行われる。
【００３６】
●リソースサーバーの機能ブロック
図５は、本発明の一実施形態における認証・認可システムの機能ブロック図である。本機能ブロックはリソースサーバー２０２で動作する。各ブロックは、例えばリソースサーバー２０２のＣＰＵによりメモリに格納されたプログラムを実行することで実現される。リソース管理部５０１、JWSアクセストークン管理部５０３、JWSアクセストークン検証部５０４は、それぞれリソース情報の管理、JWSアクセストークン情報の管理、JWSアクセストークンの検証を行う。公開鍵管理部５０２は、認証・認可サーバー２０１より取得した公開鍵の管理を行う。また、必要に応じて認証・認可サーバー２０１に対して公開鍵の取得要求を行い、公開鍵を取得する。表３は、公開鍵ペア管理部４０３が管理する公開鍵管理テーブルである。
【００３７】
【表３】
2020036234.tif 000005
【００３８】
表３の公開鍵管理テーブルは、認証・認可サーバー２０１より取得した公開鍵を管理するテーブルで、公開鍵を一意に識別するためのKey IDを示すKey ID項目、公開鍵の詳細を示す公開鍵項目から成る。秘密鍵項目及び公開鍵項目に設定する値は、ファイルでも良いしファイルパスでも良い。認証・認可サーバー情報管理部５０５は、リソースサーバー２０２と連携する認証・認可サーバー２０１に関する情報を管理する。
【００３９】
●署名付きアクセストークンの発行と検証（実施形態１〜４）
図６は、本発明の一実施形態における認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンス図である。本実施形態ではOAuth2（RFC6749）における認可コードグラントのフローを用いたJWSアクセストークンの発行と検証について述べる。JWSアクセストークンの発行と検証については、認可コードグラントだけでなく、OAuth2（RFC6749）にあるクライアントクレデンシャルグラント、リソースオーナーパスワードクレデンシャルグラント、インプリシットグラント等を用いても良い。
【００４０】
OAuth2 プロトコルにおいては、アクセストークン発行などのフローを開始する前に、クライアントを認証・認可サーバー２０１に登録する。クライアント２０３を認証・認可サーバー２０１に登録する方法は、通常エンドユーザーとの対話を伴うHTML登録フォームを持つことになる（図示せず）。本実施形態においては、予め必要なクライアントは登録されているものとする。
【００４１】
また本実施形態の図６においては、OAuth2（RFC6749）の認可コードフローに従い、認証・認可サーバー２０１は、リソースオーナーの認証後、認可コードを登録し、クライアント２０３が認可コードを取得（図示せず）して以降のフローを詳述する。
【００４２】
Ｓ６０１で、リソースサーバー２０２は認証・認可サーバー２０１に公開鍵の取得要求を出し、認証・認可サーバー２０１が保持するすべての公開鍵を取得する。本実施形態においては、この処理はリソースサーバー２０２初期化処理時に１度だけ行う。
【００４３】
Ｓ６０２で、リソースサーバー２０２は認証・認可サーバー２０１より公開鍵を取得した日時を保存する。この取得日時は、後述する実施形態２や実施形態４におけるＪＷＳアクセストークンの検証フローにて用いられる。そのため本実施形態や実施形態３については必ずしも取得日時を保存しなくともよい。
【００４４】
Ｓ６０３で、認証・認可サーバー２０１は秘密鍵・公開鍵ペア管理部４０３に新規に秘密鍵・公開鍵のペアを追加する。この処理は、認証・認可サーバー２０１の秘密鍵・公開鍵ペア管理部４０３で秘密鍵が流出した場合や、利用している暗号化アルゴリズムが危殆化した場合など、新規鍵ペアが必要な事由が生じた場合に行われる。
【００４５】
Ｓ６０４で、クライアント２０３が認証・認可サーバー２０１に、OAuthプロトコルの仕様に従い認可コード、各種クレデンシャルを示してアクセストークンの発行を要求する。
【００４６】
Ｓ６０５で、認証・認可サーバー２０１は、要求に応じてJWSアクセストークンを発行する。
【００４７】
Ｓ６０６で、認証・認可サーバー２０１のJWSアクセストークン発行部６０４は、Ｓ６０５で発行したＪＷＳアクセストークンをクライアント２０３へ返却する。
【００４８】
Ｓ６０７で、クライアント２０３は、先に取得したJWSアクセストークンを使ってリソースサーバー２０２に対してサービスの提供を要求する。具体的には、クライアント２０３はリソース要求のREST API呼び出しなどの際に、HTTPの AuthenticationヘッダーにJWSアクセストークンをセットして利用する。
【００４９】
Ｓ６０８で、リソースサーバー２０２はクライアント２０３より受信したJWSアクセストークンの検証を行う。本実施形態では、図７のフローチャートを利用してJWSアクセストークンの検証について後で説明する。
【００５０】
Ｓ６０９で、Ｓ６０８での検証の結果、JWSアクセストークンが適正であればリソースサーバー２０２はサービスを提供するための処理を実行する。なおJWSアクセストークンが適正でない場合には、サービスを提供するための処理は実行しない。
【００５１】
Ｓ６１０で、リソースサーバー２０２は、Ｓ６０９の処理を実行した場合には、処理結果をクライアント２０３に返し、Ｓ６０８での検証が失敗した場合には、エラーをクライアント２０３に返す。これをもって図６の認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンスを終了する。
【００５２】
●ソースサーバーによるアクセストークンの検証処理（その１）
図７は、本発明の一実施形態におけるリソースサーバー２０２のJWSアクセストークン検証部５０３における、JWSアクセストークンの検証処理について示したフローチャートである。図７は、図６のＳ６０８におけるリソースサーバー２０２による処理である。
【００５３】
Ｓ７０１で、リソースサーバー２０２のＪＷＳアクセストークン検証部５０４はクライアント２０３より受信したサービス要求からＪＷＳアクセストークンを取得する。取得したＪＷＳアクセストークンのヘッダパラメータに含まれるＫｅｙＩＤ取得し、検証に用いる。
【００５４】
Ｓ７０２で、ＪＷＳアクセストークン検証部５０４はＳ７０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在しない場合Ｓ７０３へ、一致する鍵が存在した場合Ｓ７０５へ遷移する。
【００５５】
Ｓ７０３で、公開鍵管理部５０２は認証・認可サーバー２０１に対しリソースサーバー２０２が所持していない公開鍵の取得を要求する。公開鍵の取得要求には、リソースサーバー２０２で現在所持している公開鍵の情報を含め、認証・認可サーバー２０１が所持する鍵との差分だけを取得してもよいし、認証・認可サーバー２０１が所持する鍵をすべて取得し更新してもよい。
【００５６】
Ｓ７０４で、ＪＷＳアクセストークン検証部５０４はＳ７０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと再び問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在する場合Ｓ７０５へ、一致する鍵が存在しない場合Ｓ７０７へ遷移する。
【００５７】
Ｓ７０５で、ＪＷＳアクセストークン検証部５０４は取得したＪＷＳアクセストークンの署名をもとに、アクセストークンが適正かどうかを検証する。ここではＳ７０４で一致したＫｅｙＩＤを持つ公開鍵を用いて署名を確認することで、適正な認証・認可サーバーで発行されたアクセストークンであることを確認できる。
【００５８】
Ｓ７０６で、ＪＷＳアクセストークンが適正なアクセストークンであったかの判断を行う。適正なアクセストークンと判断された場合はフローを終了し、図６のシーケンスへと戻り、Ｓ６０９の処理を実行する。不適正なアクセストークンだと判断された場合はＳ７０７へ遷移する。
【００５９】
Ｓ７０７で、リソースサーバー２０２はアクセストークンが不適正であると判断し、エラーをクライアント２０３へ返し、図６の認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンス、および図７のアクセストークン検証フローを終了する。すなわち、Ｓ７０７は、検証が失敗した場合の図６のＳ６１０に相当する。
【００６０】
以上により、リソース要求ＡＰＩ呼出しを受けたリソースサーバー２０２のＪＷＳアクセストークン管理部５０３、およびＪＷＳアクセストークン検証部５０４による、ＪＷＳアクセストークンの検証、およびリソースサーバー２０２の検証処理が終了する。
【００６１】
以上のように、本発明のＪＷＳアクセストークンの検証を行うことで、以下の効果を期待できる。すなわち、署名付きトークン（ＪＷＳアクセストークン）に付与された情報には、署名に用いられた鍵を一意に示すＩＤ（ＫｅｙＩＤ）が含まれている。これを本発明の手段に従い、リソースサーバーで署名検証、認可サーバーに公開鍵の問い合わせを行うことで、リソースサーバーで保持していない鍵で署名されたＪＷＳアクセストークンに対しても、リソースサーバーで署名検証を行うことができる。
【００６２】
［実施形態２］
上記実施形態１において、図7のJWSアクセストークン検証フローでは、リソースサーバー２０２が保持していないＫｅｙＩＤで署名されたJWSアクセストークンが受信された場合に、都度認証・認可サーバー２０１に問い合わせを行っていた。本実施形態２では、リソースサーバー２０２から認証・認可サーバー２０１への問合せを行った時間をもとに、認証・認可サーバー２０１への問合せを抑制する実施形態について説明する。
【００６３】
表４は、Ｓ６０２において、リソースサーバー２０２が認証・認可サーバー２０１へ公開鍵の問合せを行った時間を管理する公開鍵問合せ時間管理テーブルである。
【００６４】
【表４】
2020036234.tif 000006
【００６５】
表４の公開鍵問合せ時間管理テーブルは認証・認可サーバー２０１への問合せを行った時間（日時）を示すDate項目、問合せ時に取得した公開鍵の一覧を示すKey IDs項目から成る。問合せ時間は最新の問合せに関する情報だけ管理できれば良いので、新規問い合わせがあった場合は過去の問合せ情報は破棄するようにしてもよい。また、システムの構成によっては問合せ時間のみ管理するようにしてもよい。
【００６６】
実施形態１において、Ｓ６０８でリソースサーバー２０２は図７の手順でクライアント２０３より受信したJWSアクセストークンの検証を行った。本実施形態２では、以下図８のフローチャートを利用してJWSアクセストークンの検証について説明する。
【００６７】
図８は、本発明の実施形態２におけるリソースサーバー２０２のJWSアクセストークン検証部５０３における、JWSアクセストークンの検証処理について示したフローチャートである。
【００６８】
Ｓ８０１で、リソースサーバー２０２のＪＷＳアクセストークン検証部５０４はクライアント２０３より受信したサービス要求からＪＷＳアクセストークンを取得する。取得したＪＷＳアクセストークンのヘッダパラメータに含まれるＫｅｙＩＤ取得し、検証に用いる。
【００６９】
Ｓ８０２で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在しない場合Ｓ８０３へ、一致する鍵が存在した場合Ｓ８０７へ遷移する。
【００７０】
Ｓ８０３で、ＪＷＳアクセストークン検証部５０４は、受信したＪＷＳアクセストークンからアクセストークンの発行時間を取得し、表４の公開鍵問合せ時間管理テーブルで管理されている問合せ時間との比較を行う。公開鍵問合せ時間管理テーブルが保持している問合せ時間は、初期値ではＳ６０２で保持した公開鍵の取得日時となっている。ＪＷＳアクセストークンの発行時間が、公開鍵問合せ時間管理テーブルが保持している問合せ時間よりも後ならばＳ８０４へ、前であればＳ８０９へ遷移する。アクセストークンの発行時間が、認証・認可サーバーに対する、鍵の最後の問合せ時間よりも早いならば、改めて問い合わせたところで、そのアクセストークンを検証できる公開鍵は得られないと判断できる。そこでその場合にはＳ８０９へ遷移すてエラーとする。なお双方の時間が一致した場合、送信遅延を考慮すれば、アクセストークンの発行時間の方が後であると判断してよい。すなわち、この場合、双方の時間が一致した場合も、アクセストークンの発行時間の方が最後の問合せ時間よりも後であると判断してよい。
【００７１】
Ｓ８０４で、公開鍵管理部５０２は認証・認可サーバー２０１に対しリソースサーバー２０２が所持していない公開鍵の取得を要求する。公開鍵の取得要求には、リソースサーバー２０２で現在所持している公開鍵の情報を含め、認証・認可サーバー２０１が所持する鍵との差分だけを取得してもよいし、認証・認可サーバー２０１が所持する鍵をすべて取得し更新してもよい。
【００７２】
Ｓ８０５で、リソースサーバー２０２は認証・認可サーバー２０１への公開鍵の問合せ時間を、鍵のＩＤ（ＫｅｙＩＤ）と関連付けて表４の公開鍵問合せ時間管理テーブルに保持する。これより以前に保持していた問合せ時間は破棄し、最新の問合せ時間のみ保持すればよい。ここで保持された最新の問合せ時間はＳ８０３の比較にて利用される。
【００７３】
Ｓ８０６で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと再び問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在する場合Ｓ８０７へ、一致する鍵が存在しない場合Ｓ８０９へ遷移する。
【００７４】
Ｓ８０７で、ＪＷＳアクセストークン検証部５０４は取得したＪＷＳアクセストークンの署名をもとに、アクセストークンが適正かどうかを検証する。Ｓ８０６で一致したＫｅｙＩＤを持つ公開鍵を用いて署名を確認することで、適正な認証・認可サーバーで発行されたアクセストークンであることを確認できる。
【００７５】
Ｓ８０８で、ＪＷＳアクセストークンが適正なアクセストークンであったかの判断を行う。適正なアクセストークンと判断された場合はフローを終了し、図６のシーケンスへと戻り、Ｓ６０９の処理を実行する。不適正なアクセストークンだと判断された場合はＳ８０９へ遷移する。
【００７６】
Ｓ８０９で、リソースサーバー２０２はアクセストークンが不適正であると判断し、エラーをクライアント２０３へ返し、図６の認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンス、および図８のアクセストークン検証フローを終了する。すなわち、Ｓ８０９は、検証が失敗した場合の図６のＳ６１０に相当する。
【００７７】
以上のように、本実施形態のＪＷＳアクセストークンの検証を行うことで、以下の効果を期待できる。すなわち、署名付きトークン（ＪＷＳアクセストークン）に付与された情報には、ＪＷＳアクセストークンが認証・認可サーバーによって発行された発行時間が含まれている。これを本発明の手段に従い、リソースサーバーから認証・認可サーバーに公開鍵の取得問合せを行った時間と、前記発行時間を比較することで、アクセストークンを検証できる鍵を得られる見込みのない認証・認可サーバーへの問合せを抑制することができる。これにより、リソースサーバーが保持していない鍵で署名されたＪＷＳアクセストークンがクライアントより受信された場合でも、リソースサーバーから認証・認可サーバーへの問合せ回数を削減し、各サーバーのパフォーマンスを向上させることができる。また、悪意のある第３者が連続して不適正なトークンをリソースサーバーへ送信した場合でも、不要な認可サーバーへの問合せを抑制できるため、サーバーへの負荷を軽減できる。
【００７８】
また、Ｓ８０５において、問合せ時間のみを保存し、ＫｅｙＩＤも保持しなくともよい。また、問合せ時間に関連付けて、問合わせにより取得したＫｅｙＩＤを保持していた場合、前回問合せより一定時間は、同一ＫｅｙＩＤの鍵で署名されたＪＷＳアクセストークンが受信されても問合せを行わないようにしてもよい。これにより、認証・認可サーバーへの問合せ回数をより削減できる。
【００７９】
［実施形態３］
上記実施形態１において、図7のJWSアクセストークン検証フローでは、リソースサーバー２０２が保持していないＫｅｙＩＤで署名されたJWSアクセストークンが受信された場合には、その都度、認証・認可サーバー２０１に問い合わせを行っていた。本実施形態３では、認証・認可サーバーによるJWSアクセストークン生成の際に、トークンの一部に署名を付与することで、例えばJWSアクセストークンの署名に用いた鍵を示すKeyID（"kid"JWSヘッダークレーム）に署名を付与することで、認可サーバーへの問合せを抑制する実施形態について説明する。
【００８０】
実施形態１において、JWSアクセストークンに含まれる各クレームにて表１を用いて解説を行った。本実施形態３では、新たに以下のクレームを追加する。
【００８１】
【表５】
2020036234.tif 000007
【００８２】
表５に記載のクレームは、本実施形態で独自に設定するJWSヘッダーのプライベートクレームである。JWSアクセストークン発行部４０４は、S６０５におけるJWSアクセストークンの発行時にJWSアクセストークンに対する署名に用いた鍵のKey IDをJWSヘッダーの"kid"クレームに設定する。その際、JWSアクセストークン発行部４０４は"kid"クレームに設定した文字列に対し署名を生成し、"kid_signature"クレームに設定する。"kid"クレームに対する署名の生成に用いる鍵は秘密鍵・公開鍵ペア管理部４０３に保存されており、JWSアクセストークンに対し付与される署名の生成に用いる鍵とは区別して保持する。前記"kid"クレーム署名に用いた鍵ペアの公開鍵は、S６０１のリソースサーバー２０２からの公開鍵取得要求の際にその他の公開鍵とともに認証・認可サーバー２０１より渡される。
【００８３】
本実施形態では、ＫｅｙＩＤに対する署名をＪＷＳアクセストークンに含めるために、ＪＷＳプライベートヘッダーを定義したが、ＫｅｙＩＤに指定する文字列に対し署名をピリオド('.')文字で連結し、"kid"クレームに設定するようにしてもよい。
【００８４】
実施形態１において、Ｓ６０８でリソースサーバー２０２はクライアント２０３より受信したJWSアクセストークンの検証を図７の手順で行った。本実施形態３では、以下図９のフローチャートを利用してJWSアクセストークンの検証について説明する。
【００８５】
図９は、本発明の実施形態３におけるリソースサーバー２０２のJWSアクセストークン検証部５０３における、JWSアクセストークンの検証処理について示したフローチャートである。
【００８６】
Ｓ９０１で、リソースサーバー２０２のＪＷＳアクセストークン検証部５０４はクライアント２０３より受信したサービス要求からＪＷＳアクセストークンを取得する。取得したＪＷＳアクセストークンのヘッダパラメータに含まれるＫｅｙＩＤ取得し、検証に用いる。
【００８７】
Ｓ９０２で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在しない場合Ｓ９０３へ、一致する鍵が存在した場合Ｓ９０７へ遷移する。
【００８８】
Ｓ９０３で、ＪＷＳアクセストークン検証部５０４は取得したＫｅｙＩＤの署名検証を行い、適正な認可サーバーで設定されたＫｅｙＩＤであることを検証する。具体的には、ＪＷＳアクセストークン検証部５０４は、ＪＷＳアクセストークンのＪＷＳヘッダーに含まれる"kid_signature"クレームを取得し、公開鍵管理部５０２が保持するＫｅｙＩＤ署名用の公開鍵を用いて署名検証を行う。
【００８９】
Ｓ９０４で、リソースサーバー２０２はＳ９０３の署名検証結果で適正な認可サーバーで発行されたＫｅｙＩＤかどうかの判断を行う。適正な認可サーバーで発行されたＫｅｙＩＤだと判断された場合はＳ９０５へ、不適正な認可サーバーで発行されたＫｅｙＩＤだと判断された場合はＳ９０９へ遷移する。
【００９０】
Ｓ９０５で、公開鍵管理部５０２は認証・認可サーバー２０１に対しリソースサーバー２０２が所持していない公開鍵の取得を要求する。公開鍵の取得要求には、リソースサーバー２０２で現在所持している公開鍵の情報を含め、認証・認可サーバー２０１が所持する鍵との差分だけを取得してもよいし、認証・認可サーバー２０１が所持する鍵をすべて取得し最新の状態に更新してもよい。
【００９１】
Ｓ９０６で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと再び問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在する場合Ｓ９０７へ、一致する鍵が存在しない場合Ｓ９０９へ遷移する。
【００９２】
Ｓ９０７で、ＪＷＳアクセストークン検証部５０４は取得したＪＷＳアクセストークンの署名をもとに、アクセストークンが適正かどうかを検証する。Ｓ９０６で一致したＫｅｙＩＤを持つ公開鍵を用いて署名を確認することで、適正な認証・認可サーバーで発行されたアクセストークンであることを確認できる。
【００９３】
Ｓ９０８で、ＪＷＳアクセストークンが適正なアクセストークンであったかの判断を行う。適正なアクセストークンと判断された場合はフローを終了し、図６のシーケンスへと戻り、Ｓ６０９の処理を実行する。不適正なアクセストークンだと判断された場合はＳ９０９へ遷移する。
【００９４】
Ｓ９０９で、リソースサーバー２０２はアクセストークンが不適正であると判断し、エラーをクライアント２０３へ返し、図６の認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンス、および図９のアクセストークン検証フローを終了する。すなわち、Ｓ９０９は、検証が失敗した場合の図６のＳ６１０に相当する。
【００９５】
以上のように、本実施形態のＪＷＳアクセストークンの検証を行うことで、以下の効果を期待できる。すなわち、署名付きトークン（ＪＷＳアクセストークン）に付与された情報には、ＪＷＳアクセストークンに対する署名の他に、ＪＷＳヘッダークレームである"kid"（ＫｅｙＩＤ）に対する署名が含まれている。これを本実施形態の手段に従い、リソースサーバーが保持していないKｅｙＩＤで署名されたＪＷＳアクセストークンが得られた場合に、ＫｅｙＩＤの署名を検証することで、認証・認可サーバーへの問合せを抑制することができる。これにより、リソースサーバーが保持していない鍵で署名されたＪＷＳアクセストークンがクライアントより受信された場合でも、リソースサーバーから認証・認可サーバーへの問合せ回数を削減し、各サーバーのパフォーマンスを向上させることができる。また、悪意のある第３者が連続して不適正なトークンをリソースサーバーへ送信した場合でも、不要な認可サーバーへの問合せを抑制できるため、サーバーへの負荷を軽減できる。
【００９６】
［実施形態４］
実施形態２と実施形態３では、それぞれ実施形態１をベースにしたＪＷＳアクセストークンの検証フローを記載したが、これらの手法を複合させてもよい。本実施形態４では実施形態２におけるトークン発行時間を用いた検証フローと、実施形態３における署名付きＫｅｙＩＤを用いた検証フローを合わせることで、認可サーバーへの問合せを抑制する実施形態について説明する。以下図１０のフローチャートを用いて具体的に説明する。
【００９７】
図１０は、リソースサーバー２０２のJWSアクセストークン検証部５０３における、JWSアクセストークンの検証処理について、本発明の実施形態２及び実施形態３において記述した手法を複合した処理を示したフローチャートである。そこでそれぞれの図のステップに付された符号をそのまま用いている。図１０の検証フローは、まずＳ９０１に遷移する。図９の検証フローと同様にＳ９０１からＳ９０４まで遷移した後、Ｓ９０４のＫｅｙＩＤ検証の結果適正な認可サーバーで発行されたＫｅｙＩＤだと判断された場合、図８のフローにおけるＳ８０３へ遷移する。Ｓ８０３以降のフローは図８における検証フローを行う。Ｓ９０２で、ＪＷＳアクセストークンに設定されているＫｅｙＩＤがリソースサーバーで保有している公開鍵のＫｅｙＩＤと一致した場合は、Ｓ８０７へ遷移し、ＪＷＳアクセストークンの検証を行う。
【００９８】
このように、実施形態２と実施形態３で記載した検証方法を組み合わせることで、効果についてもまたそれぞれの実施形態の効果を組み合わせたものとなる。すなわち、認可サーバーで発行されＫｅｙＩＤを持つＪＷＳアクセストークンに対してもトークン発行時間によるサーバー問い合わせのハンドリングが行える。これにより、より効率的に認可サーバーへの問合せを抑制できる。なお、Ｓ８０３を、Ｓ９０２とＳ９０３との間に移動してもよい。すなわち、本実施形態では、署名付きトークンが、最後の鍵の取得時間よりも早く、かつ、ＫｅｙＩＤすなわち鍵の識別情報の検証が成功すれば、その判定の順序に関わりなくアクセストークンを認可サーバーから取得する。
【００９９】
［他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１００】
２０１  認証・認可サーバー、２０２  リソースサーバー、２０３  クライアント、４０３  秘密鍵・公開鍵ペア管理部、４０４  ＪＷＳアクセストークン発行部、４０５  発行済みＪＷＳアクセストークン管理部、４０６  ＪＷＳアクセストークン検証部、５０３  ＪＷＳアクセストークン管理部、５０４  ＪＷＳアクセストークン検証部
【図１】
2020036234.tif 000008
【図２】
2020036234.tif 000009
【図３】
2020036234.tif 000010
【図４】
2020036234.tif 000011
【図５】
2020036234.tif 000012
【図６】
2020036234.tif 000013
【図７】
2020036234.tif 000014
【図８】
2020036234.tif 000015
【図９】
2020036234.tif 000016
【図１０】
2020036234.tif 000017