JP7228977B2 - 情報処理装置及び認可システムと検証方法 - Google Patents

情報処理装置及び認可システムと検証方法 Download PDF

Info

Publication number
JP7228977B2
JP7228977B2 JP2018162103A JP2018162103A JP7228977B2 JP 7228977 B2 JP7228977 B2 JP 7228977B2 JP 2018162103 A JP2018162103 A JP 2018162103A JP 2018162103 A JP2018162103 A JP 2018162103A JP 7228977 B2 JP7228977 B2 JP 7228977B2
Authority
JP
Japan
Prior art keywords
key information
information
server
signed token
verifying
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018162103A
Other languages
English (en)
Other versions
JP2020036234A5 (ja
JP2020036234A (ja
Inventor
涼 岸本
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to JP2018162103A priority Critical patent/JP7228977B2/ja
Priority to CN201910789691.0A priority patent/CN110875925B/zh
Priority to US16/550,535 priority patent/US11271923B2/en
Publication of JP2020036234A publication Critical patent/JP2020036234A/ja
Publication of JP2020036234A5 publication Critical patent/JP2020036234A5/ja
Application granted granted Critical
Publication of JP7228977B2 publication Critical patent/JP7228977B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Description

本発明は、例えば署名付きトークンを用いた認可トークン等を検証する情報処理装置及び認可システムと検証方法に関する。
近年、ネットワーク上のＷｅｂサービスでは利用者がＷｅｂサービスの利用を認められているかどうかの認証が行われる。そして、Ｗｅｂサービスが多様化し、複数のＷｅｂサービスが互いに連携を行うようになるにつれ、Ｗｅｂサービスを提供するリソースサーバーと認証・認可を行う認証・認可サーバーとが別々のサーバーとして構成されるようになってきた。このような構成では、認証・認可サーバーとリソースサーバーが互いに認証・認可情報を授受することで連携している。認証・認可サーバーは認可情報を含むアクセストークンを発行し、クライアントはアクセストークンを利用してリソースサーバーからサービスの提供を受ける。このような認可情報の授受に関する仕様の一つとしてＯＡｕｔｈ２．０等が公開されている。
従来の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アクセストークンとする）について詳述する。
ＪＷＳアクセストークンは、ＪＷＳヘッダー、ＪＷＳペイロード、ＪＷＳ署名から構成される。以下に本実施形態にて用いられるＪＷＳアクセストークンの各構成部について説明する。
Figure 0007228977000001
表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アクセストークンの署名に用いる鍵の管理を行う。秘密鍵・公開鍵ペア管理部４０３は、リソースサーバー２０２からの要求に基づき、必要な公開鍵をリソースサーバー２０２へ譲渡する。表２は、秘密鍵・公開鍵ペア管理部４０３が管理する秘密鍵・公開鍵ペア管理テーブルである。
Figure 0007228977000002
表２の秘密鍵・公開鍵ペア管理テーブルは、秘密鍵・公開鍵ペアを一意に識別するためのKey IDを示すKey ID項目、秘密鍵の詳細を示す秘密鍵項目、公開鍵の詳細を示す公開鍵項目から成る。秘密鍵項目及び公開鍵項目に設定する値は、ファイルでも良いしファイルパスでも良い。
JWSアクセストークン発行部４０４はJWSアクセストークンの発行を行い、発行されたJWSアクセストークンの情報は発行済みJWSアクセストークン管理部４０５に保管される。JWSアクセストークン検証部４０６はJWSアクセストークンが有効かどうか検証する。なお、JWSアクセストークンの検証はリソースサーバーにおいて後述する図５のJWSアクセストークン検証部５０３で行われる。
●リソースサーバーの機能ブロック
図５は、本発明の一実施形態における認証・認可システムの機能ブロック図である。本機能ブロックはリソースサーバー２０２で動作する。各ブロックは、例えばリソースサーバー２０２のＣＰＵによりメモリに格納されたプログラムを実行することで実現される。リソース管理部５０１、JWSアクセストークン管理部５０３、JWSアクセストークン検証部５０４は、それぞれリソース情報の管理、JWSアクセストークン情報の管理、JWSアクセストークンの検証を行う。公開鍵管理部５０２は、認証・認可サーバー２０１より取得した公開鍵の管理を行う。また、必要に応じて認証・認可サーバー２０１に対して公開鍵の取得要求を行い、公開鍵を取得する。表３は、公開鍵ペア管理部４０３が管理する公開鍵管理テーブルである。
Figure 0007228977000003
表３の公開鍵管理テーブルは、認証・認可サーバー２０１より取得した公開鍵を管理するテーブルで、公開鍵を一意に識別するための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アクセストークンが受信された場合に、都度認証・認可サーバー２０１に問い合わせを行っていた。本実施形態２では、リソースサーバー２０２から認証・認可サーバー２０１への問合せを行った時間をもとに、認証・認可サーバー２０１への問合せを抑制する実施形態について説明する。
表４は、Ｓ６０２において、リソースサーバー２０２が認証・認可サーバー２０１へ公開鍵の問合せを行った時間を管理する公開鍵問合せ時間管理テーブルである。
Figure 0007228977000004
表４の公開鍵問合せ時間管理テーブルは認証・認可サーバー２０１への問合せを行った時間（日時）を示すDate項目、問合せ時に取得した公開鍵の一覧を示すKey IDs項目から成る。問合せ時間は最新の問合せに関する情報だけ管理できれば良いので、新規問い合わせがあった場合は過去の問合せ情報は破棄するようにしてもよい。また、システムの構成によっては問合せ時間のみ管理するようにしてもよい。
実施形態１において、Ｓ６０８でリソースサーバー２０２は図７の手順でクライアント２０３より受信したJWSアクセストークンの検証を行った。本実施形態２では、以下図８のフローチャートを利用してJWSアクセストークンの検証について説明する。
図８は、本発明の実施形態２におけるリソースサーバー２０２のJWSアクセストークン検証部５０３における、JWSアクセストークンの検証処理について示したフローチャートである。
Ｓ８０１で、リソースサーバー２０２のＪＷＳアクセストークン検証部５０４はクライアント２０３より受信したサービス要求からＪＷＳアクセストークンを取得する。取得したＪＷＳアクセストークンのヘッダパラメータに含まれるＫｅｙＩＤ取得し、検証に用いる。
Ｓ８０２で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在しない場合Ｓ８０３へ、一致する鍵が存在した場合Ｓ８０７へ遷移する。
Ｓ８０３で、ＪＷＳアクセストークン検証部５０４は、受信したＪＷＳアクセストークンからアクセストークンの発行時間を取得し、表４の公開鍵問合せ時間管理テーブルで管理されている問合せ時間との比較を行う。公開鍵問合せ時間管理テーブルが保持している問合せ時間は、初期値ではＳ６０２で保持した公開鍵の取得日時となっている。ＪＷＳアクセストークンの発行時間が、公開鍵問合せ時間管理テーブルが保持している問合せ時間よりも後ならばＳ８０４へ、前であればＳ８０９へ遷移する。アクセストークンの発行時間が、認証・認可サーバーに対する、鍵の最後の問合せ時間よりも早いならば、改めて問い合わせたところで、そのアクセストークンを検証できる公開鍵は得られないと判断できる。そこでその場合にはＳ８０９へ遷移すてエラーとする。なお双方の時間が一致した場合、送信遅延を考慮すれば、アクセストークンの発行時間の方が後であると判断してよい。すなわち、この場合、双方の時間が一致した場合も、アクセストークンの発行時間の方が最後の問合せ時間よりも後であると判断してよい。
Ｓ８０４で、公開鍵管理部５０２は認証・認可サーバー２０１に対しリソースサーバー２０２が所持していない公開鍵の取得を要求する。公開鍵の取得要求には、リソースサーバー２０２で現在所持している公開鍵の情報を含め、認証・認可サーバー２０１が所持する鍵との差分だけを取得してもよいし、認証・認可サーバー２０１が所持する鍵をすべて取得し更新してもよい。
Ｓ８０５で、リソースサーバー２０２は認証・認可サーバー２０１への公開鍵の問合せ時間を、鍵のＩＤ（ＫｅｙＩＤ）と関連付けて表４の公開鍵問合せ時間管理テーブルに保持する。これより以前に保持していた問合せ時間は破棄し、最新の問合せ時間のみ保持すればよい。ここで保持された最新の問合せ時間はＳ８０３の比較にて利用される。
Ｓ８０６で、ＪＷＳアクセストークン検証部５０４はＳ８０１で取得したＫｅｙＩＤに一致する鍵が存在するかどうか公開鍵管理部５０２へと再び問い合わせる。取得したＫｅｙＩＤに一致する鍵が存在する場合Ｓ８０７へ、一致する鍵が存在しない場合Ｓ８０９へ遷移する。
Ｓ８０７で、ＪＷＳアクセストークン検証部５０４は取得したＪＷＳアクセストークンの署名をもとに、アクセストークンが適正かどうかを検証する。Ｓ８０６で一致したＫｅｙＩＤを持つ公開鍵を用いて署名を確認することで、適正な認証・認可サーバーで発行されたアクセストークンであることを確認できる。
Ｓ８０８で、ＪＷＳアクセストークンが適正なアクセストークンであったかの判断を行う。適正なアクセストークンと判断された場合はフローを終了し、図６のシーケンスへと戻り、Ｓ６０９の処理を実行する。不適正なアクセストークンだと判断された場合はＳ８０９へ遷移する。
Ｓ８０９で、リソースサーバー２０２はアクセストークンが不適正であると判断し、エラーをクライアント２０３へ返し、図６の認証・認可システムの署名付きアクセストークン発行と検証に関するシーケンス、および図８のアクセストークン検証フローを終了する。すなわち、Ｓ８０９は、検証が失敗した場合の図６のＳ６１０に相当する。
以上のように、本実施形態のＪＷＳアクセストークンの検証を行うことで、以下の効果を期待できる。すなわち、署名付きトークン（ＪＷＳアクセストークン）に付与された情報には、ＪＷＳアクセストークンが認証・認可サーバーによって発行された発行時間が含まれている。これを本発明の手段に従い、リソースサーバーから認証・認可サーバーに公開鍵の取得問合せを行った時間と、前記発行時間を比較することで、アクセストークンを検証できる鍵を得られる見込みのない認証・認可サーバーへの問合せを抑制することができる。これにより、リソースサーバーが保持していない鍵で署名されたＪＷＳアクセストークンがクライアントより受信された場合でも、リソースサーバーから認証・認可サーバーへの問合せ回数を削減し、各サーバーのパフォーマンスを向上させることができる。また、悪意のある第３者が連続して不適正なトークンをリソースサーバーへ送信した場合でも、不要な認可サーバーへの問合せを抑制できるため、サーバーへの負荷を軽減できる。
また、Ｓ８０５において、問合せ時間のみを保存し、ＫｅｙＩＤも保持しなくともよい。また、問合せ時間に関連付けて、問合わせにより取得したＫｅｙＩＤを保持していた場合、前回問合せより一定時間は、同一ＫｅｙＩＤの鍵で署名されたＪＷＳアクセストークンが受信されても問合せを行わないようにしてもよい。これにより、認証・認可サーバーへの問合せ回数をより削減できる。
［実施形態３］
上記実施形態１において、図7のJWSアクセストークン検証フローでは、リソースサーバー２０２が保持していないＫｅｙＩＤで署名されたJWSアクセストークンが受信された場合には、その都度、認証・認可サーバー２０１に問い合わせを行っていた。本実施形態３では、認証・認可サーバーによるJWSアクセストークン生成の際に、トークンの一部に署名を付与することで、例えばJWSアクセストークンの署名に用いた鍵を示すKeyID（"kid"JWSヘッダークレーム）に署名を付与することで、認可サーバーへの問合せを抑制する実施形態について説明する。
実施形態１において、JWSアクセストークンに含まれる各クレームにて表１を用いて解説を行った。本実施形態３では、新たに以下のクレームを追加する。
Figure 0007228977000005
表５に記載のクレームは、本実施形態で独自に設定する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アクセストークンの検証処理について、本発明の実施形態２及び実施形態３において記述した手法を複合した処理を示したフローチャートである。そこでそれぞれの図のステップに付された符号をそのまま用いている。図１０の検証フローは、まずＳ９０１に遷移する。図９の検証フローと同様にＳ９０１からＳ９０４まで遷移した後、Ｓ９０４のＫｅｙＩＤ検証の結果適正な認可サーバーで発行されたＫｅｙＩＤだと判断された場合、図８のフローにおけるＳ８０３へ遷移する。Ｓ８０３以降のフローは図８における検証フローを行う。Ｓ９０２で、ＪＷＳアクセストークンに設定されているＫｅｙＩＤがリソースサーバーで保有している公開鍵のＫｅｙＩＤと一致した場合は、Ｓ８０７へ遷移し、ＪＷＳアクセストークンの検証を行う。
このように、実施形態２と実施形態３で記載した検証方法を組み合わせることで、効果についてもまたそれぞれの実施形態の効果を組み合わせたものとなる。すなわち、認可サーバーで発行されＫｅｙＩＤを持つＪＷＳアクセストークンに対してもトークン発行時間によるサーバー問い合わせのハンドリングが行える。これにより、より効率的に認可サーバーへの問合せを抑制できる。なお、Ｓ８０３を、Ｓ９０２とＳ９０３との間に移動してもよい。すなわち、本実施形態では、署名付きトークンが、最後の鍵の取得時間よりも早く、かつ、ＫｅｙＩＤすなわち鍵の識別情報の検証が成功すれば、その判定の順序に関わりなくアクセストークンを認可サーバーから取得する。
［他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
２０１ 認証・認可サーバー、２０２ リソースサーバー、２０３ クライアント、４０３ 秘密鍵・公開鍵ペア管理部、４０４ ＪＷＳアクセストークン発行部、４０５ 発行済みＪＷＳアクセストークン管理部、４０６ ＪＷＳアクセストークン検証部、５０３ ＪＷＳアクセストークン管理部、５０４ ＪＷＳアクセストークン検証部

Claims (9)

  1. 署名付きトークンを検証する情報処理装置であって、
    署名付きトークンを検証するための鍵情報を保持する保持手段と、
    受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該新たな鍵情報を前記保持手段により保持する取得手段と、
    前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証する検証手段と
    を有し、
    前記署名付きトークンには更に、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報および該識別情報を対象とした署名を含み、
    前記取得手段は、前記保持手段により保持されている鍵情報が、前記受信した署名付きトークンを検証するための鍵情報ではない場合には、前記保持手段により保持する前記鍵情報による前記署名付きトークンの前記識別情報および該識別情報を対象とした署名の検証を行い、当該検証が成功した場合に、前記サーバーから前記新たな鍵情報を取得する
    ことを特徴とする情報処理装置。
  2. 請求項１に記載の情報処理装置であって、
    前記サーバーから前記新たな鍵情報を取得した取得時間を保存する保存手段を更に有し、
    前記取得手段は、前記保持手段により保持する前記鍵情報による前記署名付きトークンの前記識別情報を対象とした署名の検証が成功した場合にはさらに、前記受信した署名付きトークンが、前記鍵情報を取得した前記取得時間よりも後に発行されたものである場合に、前記サーバーから前記新たな鍵情報を取得する
    ことを特徴とする情報処理装置。
  3. 請求項１または２に記載の情報処理装置であって、
    前記保持手段は、複数の前記鍵情報をそれぞれの識別情報と関連付けて保持でき、
    前記検証手段は、前記署名付きトークンに含まれた、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報に対応する、前記保持手段により保持された前記鍵情報を、前記署名付きトークンを検証するための鍵として用いる
    ことを特徴とする情報処理装置。
  4. 請求項１乃至３のいずれか一項に記載の情報処理装置であって、
    要求と共に受信した前記署名付きトークンの検証が成功した場合、前記要求に応じてリソースを提供する
    ことを特徴とする情報処理装置。
  5. 請求項１乃至４のいずれか一項に記載の情報処理装置であって、
    前記鍵情報および前記署名付きトークンを提供する前記サーバーと、該サーバーから提供された前記署名付きトークンと共にリソースの要求を送信するクライアントと、に接続されたことを特徴とする情報処理装置。
  6. 請求項１乃至４のいずれか一項に記載の情報処理装置と、
    前記鍵情報および前記署名付きトークンを提供する前記サーバーと、
    前記サーバーから提供された前記署名付きトークンと共にリソースの要求を送信するクライアントと
    を含むことを特徴とする認可システム。
  7. 請求項６に記載の認可システムであって、
    前記サーバーでは、前記鍵情報の追加が行われることを特徴とする認可システム。
  8. 情報処理装置による署名付きトークンの検証方法であって、
    署名付きトークンを検証するための鍵情報を保持手段に保持し、
    受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該鍵情報を前記保持手段により保持し、
    前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証し、
    前記署名付きトークンには更に、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報および該識別情報を対象とした署名とを含み、
    前記新たな鍵情報を取得する際には、前記保持手段により保持されている鍵情報が、前記受信した署名付きトークンを検証するための鍵情報ではない場合には、前記保持手段により保持する前記鍵情報による前記署名付きトークンの前記識別情報および該識別情報を対象とした署名の検証を行い、当該検証が成功した場合に、前記サーバーから前記新たな鍵情報を取得する
    ことを特徴とする検証方法。
  9. 情報処理装置により署名付きトークンを検証するためのプログラムであって、
    署名付きトークンを検証するための鍵情報を保持手段に保持し、前記情報処理装置を、
    受信した署名付きトークンを検証するための鍵情報が、前記保持手段に保持されていない場合には、鍵情報を提供するサーバーから新たな鍵情報を取得し、該鍵情報を前記保持手段により保持し、
    前記受信した署名付きトークンを検証するための鍵情報が前記保持手段に保持されている場合には、当該鍵情報により前記署名付きトークンを検証し、
    前記署名付きトークンには更に、前記署名付きトークンの署名を生成するために使用した鍵情報の識別情報および該識別情報を対象とした署名とを含み、
    前記新たな鍵情報を取得する際には、前記保持手段により保持されている鍵情報が、前記受信した署名付きトークンを検証するための鍵情報ではない場合には、前記保持手段により保持する前記鍵情報による前記署名付きトークンの前記識別情報および該識別情報を対象とした署名の検証を行い、当該検証が成功した場合に、前記サーバーから前記新たな鍵情報を取得する
    よう機能させるためのプログラム。
JP2018162103A 2018-08-30 2018-08-30 情報処理装置及び認可システムと検証方法 Active JP7228977B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2018162103A JP7228977B2 (ja) 2018-08-30 2018-08-30 情報処理装置及び認可システムと検証方法
CN201910789691.0A CN110875925B (zh) 2018-08-30 2019-08-26 信息处理装置、授权系统及验证方法
US16/550,535 US11271923B2 (en) 2018-08-30 2019-08-26 Information processing apparatus, authorization system, and verification method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018162103A JP7228977B2 (ja) 2018-08-30 2018-08-30 情報処理装置及び認可システムと検証方法

Publications (3)

Publication Number Publication Date
JP2020036234A JP2020036234A (ja) 2020-03-05
JP2020036234A5 JP2020036234A5 (ja) 2021-09-24
JP7228977B2 true JP7228977B2 (ja) 2023-02-27

Family

ID=69640444

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018162103A Active JP7228977B2 (ja) 2018-08-30 2018-08-30 情報処理装置及び認可システムと検証方法

Country Status (3)

Country Link
US (1) US11271923B2 (ja)
JP (1) JP7228977B2 (ja)
CN (1) CN110875925B (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11700121B2 (en) * 2019-09-13 2023-07-11 Amazon Technologies, Inc. Secure authorization for sensitive information
US11610012B1 (en) * 2019-11-26 2023-03-21 Gobeep, Inc. Systems and processes for providing secure client controlled and managed exchange of data between parties
CN111475824B (zh) * 2020-03-23 2023-05-05 深圳前海百递网络有限公司 数据访问方法、装置、设备和存储介质
EP4128175A4 (en) * 2020-03-30 2023-05-24 Telefonaktiebolaget LM ERICSSON (PUBL) VERIFICATION OF ELECTRONIC VOTES IN A VOTING SYSTEM
US11310059B2 (en) * 2020-06-02 2022-04-19 Microsoft Technology Licensing, Llc Ephemeral cryptography keys for authenticating computing services
US11601285B2 (en) * 2020-06-24 2023-03-07 EMC IP Holding Company LLC Securely authorizing service level access to a backup system using a specialized access key
CN114079645B (zh) * 2020-08-13 2022-12-30 花瓣云科技有限公司 注册服务的方法及设备
CN112968889B (zh) * 2021-02-08 2022-10-21 深圳市慧为智能科技股份有限公司 主机权限管理方法、终端、设备及计算机可读存储介质
JP7453179B2 (ja) 2021-04-20 2024-03-19 トヨタ自動車株式会社 認証システム
CN112989426B (zh) * 2021-04-30 2021-08-06 腾讯科技（深圳）有限公司 授权认证方法及装置、资源访问令牌的获取方法
CN115883092A (zh) * 2021-09-23 2023-03-31 西门子股份公司 授权的方法、授权服务器、资源服务器和客户端设备
CN117318975A (zh) * 2023-02-28 2023-12-29 日照云控大数据科技有限公司 适用于企业数据化的智能检索处理方法及系统
CN117331964B (zh) * 2023-12-01 2024-02-27 成都明途科技有限公司 数据查询方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081643A (ja) 2016-11-18 2018-05-24 キヤノン株式会社 認可サーバーおよびその制御方法、プログラム、並びに権限委譲システム
JP2018093407A (ja) 2016-12-05 2018-06-14 キヤノン株式会社 システム、リソースサーバ、システムの制御方法およびプログラム

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5812666A (en) * 1995-03-31 1998-09-22 Pitney Bowes Inc. Cryptographic key management and validation system
US20040205243A1 (en) * 2001-03-09 2004-10-14 Hans Hurvig System and a method for managing digital identities
US7380120B1 (en) * 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7111322B2 (en) * 2002-12-05 2006-09-19 Canon Kabushiki Kaisha Automatic generation of a new encryption key
JP4792944B2 (ja) 2005-11-30 2011-10-12 日本電気株式会社 権限管理システム、トークン検証方法、トークン検証プログラム
US8751815B2 (en) * 2006-10-25 2014-06-10 Iovation Inc. Creating and verifying globally unique device-specific identifiers
CA2716335A1 (en) * 2008-02-22 2009-08-27 Stephen C. Bono Systems and methods for secure workgroup management and communication
US8621598B2 (en) * 2008-03-12 2013-12-31 Intuit Inc. Method and apparatus for securely invoking a rest API
US8862879B2 (en) * 2009-10-13 2014-10-14 Sergio Demian LERNER Method and apparatus for efficient and secure creating, transferring, and revealing of messages over a network
CN102713922B (zh) 2010-01-12 2015-11-25 维萨国际服务协会 用于对验证令牌的任何时候确认的方法
US8719952B1 (en) * 2011-03-25 2014-05-06 Secsign Technologies Inc. Systems and methods using passwords for secure storage of private keys on mobile devices
US8898764B2 (en) * 2012-04-19 2014-11-25 Microsoft Corporation Authenticating user through web extension using token based authentication scheme
US8839376B2 (en) * 2012-06-29 2014-09-16 Cable Television Laboratories, Inc. Application authorization for video services
US20170048700A1 (en) * 2012-08-16 2017-02-16 Mivalife Mobile Technology, Inc. Self-configuring wireless network
WO2014043915A1 (zh) * 2012-09-24 2014-03-27 华为技术有限公司 服务器的管理方法、设备、系统及计算机可读介质
JP2014142732A (ja) * 2013-01-23 2014-08-07 Canon Inc 権限委譲システム
JP6166596B2 (ja) * 2013-06-21 2017-07-19 キヤノン株式会社 認可サーバーシステムおよびその制御方法、並びにプログラム
US9832024B2 (en) 2015-11-13 2017-11-28 Visa International Service Association Methods and systems for PKI-based authentication
CN107659406B (zh) 2016-07-25 2021-06-01 华为技术有限公司 一种资源操作方法及装置
JP2018032085A (ja) * 2016-08-22 2018-03-01 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム
KR102604046B1 (ko) * 2016-11-28 2023-11-23 삼성전자주식회사 전자 기기의 프로그램 관리 방법 및 장치
US11283612B2 (en) * 2017-05-30 2022-03-22 Nec Corporation Information processing device, verification device, and information processing system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2018081643A (ja) 2016-11-18 2018-05-24 キヤノン株式会社 認可サーバーおよびその制御方法、プログラム、並びに権限委譲システム
JP2018093407A (ja) 2016-12-05 2018-06-14 キヤノン株式会社 システム、リソースサーバ、システムの制御方法およびプログラム

Also Published As

Publication number Publication date
US20200076791A1 (en) 2020-03-05
CN110875925B (zh) 2022-07-19
CN110875925A (zh) 2020-03-10
US11271923B2 (en) 2022-03-08
JP2020036234A (ja) 2020-03-05

Similar Documents

Publication Publication Date Title
JP7228977B2 (ja) 情報処理装置及び認可システムと検証方法
US10904234B2 (en) Systems and methods of device based customer authentication and authorization
US11711219B1 (en) PKI-based user authentication for web services using blockchain
US11122028B2 (en) Control method for authentication/authorization server, resource server, and authentication/authorization system
US11095455B2 (en) Recursive token binding for cascaded service calls
KR102390108B1 (ko) 정보 처리 시스템 및 제어 방법
US9185146B2 (en) Service providing system
US20140006781A1 (en) Encapsulating the complexity of cryptographic authentication in black-boxes
WO2019239591A1 (ja) 認証システム、認証方法、アプリケーション提供装置、認証装置、及び認証用プログラム
US20100077208A1 (en) Certificate based authentication for online services
JP2020537218A (ja) デジタル証明書のモバイル認証相互運用性
JP2018092446A (ja) 認証認可システム及び情報処理装置と認証認可方法とプログラム
GB2554082B (en) User sign-in and authentication without passwords
JP2023503607A (ja) 自動デジタル証明書検証のための方法およびデバイス
JP6712707B2 (ja) 複数のサービスシステムを制御するサーバシステム及び方法
JP2020030759A (ja) 権限委譲システム、情報処理装置およびその制御方法、並びにプログラム。
WO2021107755A1 (en) A system and method for digital identity data change between proof of possession to proof of identity
JP2011145754A (ja) シングルサインオンシステムと方法、認証サーバ、ユーザ端末、サービスサーバ、プログラム
CN115242471A (zh) 信息传输方法、装置、电子设备及计算机可读存储介质
KR100993333B1 (ko) 인터넷 접속 도구를 고려한 사용자 인증 방법 및 시스템
US9882891B2 (en) Identity verification
JP5793593B2 (ja) ユーザ識別情報を安全に検証するためのネットワーク認証方法
US20230421399A1 (en) Cross chain access granting to applications
Corella et al. An example of a derived credentials architecture
KR101987579B1 (ko) 웹 메일과 otp 및 디피 헬만 키교환을 이용한 보안메일의 송수신 방법 및 시스템

Legal Events

Date Code Title Description
RD01 Notification of change of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7421

Effective date: 20210103

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210113

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210810

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210810

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220706

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220826

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221005

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230116

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230214

R151 Written notification of patent or utility model registration

Ref document number: 7228977

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151