(57)【要約】  本発明は、仮にトークンが窃取された場合であっても、該トークンが悪用されることを回避可能とする。認可システムは、ユーザの情報を保有するリソースサーバと、前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、を備え、前記クライアントは前記リフレッシュトークンの使用時に前記リフレッシュトークンのハッシュ値を前記認可サーバに送信し、前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、前記クライアントは、前記更新用乱数を用いて、前記リフレッシュトークンを更新する。
2020166066.tif 000002
【特許請求の範囲】
【請求項１】
ユーザの情報を保有するリソースサーバと、
前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、
前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、
を備え、
前記クライアントは、前記リフレッシュトークンの使用時に、前記認可サーバに対して前記リフレッシュトークンのハッシュ値を送信し、
前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
前記クライアントは、前記更新用乱数を用いて、前記リフレッシュトークンを更新する、ことを特徴とする、認可システム。
【請求項２】
前記クライアントは、前記アクセストークン使用時に、前記リソースサーバに対して、前記アクセストークンのハッシュ値を送信し、
前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値を受信すると、更新用乱数を生成して前記クライアントに送信し、
前記クライアント及び前記認可サーバは、前記更新用乱数を用いてそれぞれが保持する前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項１に記載の認可システム。
【請求項３】
予め前記認可サーバと前記クライアントで共有している初期値と、前記認可サーバから送信される更新用乱数とに基づき、前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項１又は２に記載の認可システム。
【請求項４】
リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置であって、
少なくともトークンのハッシュ値を受信する第１の手段と、
前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する第２の手段と、
前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、トークン更新用乱数を生成し、前記トークン更新用乱数を前記クライアントに送信する第３の手段と、
を備えた、ことを特徴とする、認可サーバ装置。
【請求項５】
前記トークンはリフレッシュトークンであり、
前記第１の手段は、
前記リフレッシュトークンのハッシュ値と、前記リフレッシュトークンのインデックスを前記クライアントから受信し、
前記第２の手段は、
前記インデックスからリフレッシュトークンを特定し、
前記特定したリフレッシュトークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、新しいアクセストークンを生成する第４の手段を備え、
前記第３の手段は、
前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、請求項４に記載の認可サーバ装置。
【請求項６】
前記トークンは、アクセストークンであり、
前記第１の手段は、
前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバ装置に行うリソースサーバから、前記アクセストークンのハッシュ値と前記アクセストークンのインデックスを受信し、
前記第２の手段は、
前記インデックスからアクセストークンを特定し、前記特定したアクセストークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、認可情報を生成して前記リソースサーバに送信する第４の手段を備え、
前記２つのハッシュ値が互いに一致する場合、前記第３の手段は、
前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする、請求項５に記載の認可サーバ装置。
【請求項７】
リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアント装置であって、
認可サーバから発行されたトークンのハッシュ値を生成する第１の手段と、
前記ハッシュ値を前記認可サーバに送信する第２の手段と、
前記認可サーバから送信されたトークンの更新用乱数を受信し、前記トークンを、前記更新用乱数を用いて更新する第３の手段と、
を備えた、ことを特徴とする、クライアント装置。
【請求項８】
リソースオーナーの許可を得てリソースオーナーの代理としてリソースサーバの保護されたリソースに対するアクセスを行うクライアントが、リフレッシュトークンの使用時に、前記リフレッシュトークンのハッシュ値を認可サーバに送信し、
前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
前記クライアントは、前記更新用乱数を用いて前記リフレッシュトークンを更新する、ことを特徴とする、トークン保護方法。
【請求項９】
前記クライアントは、前記アクセストークン使用時に、前記アクセストークンのハッシュ値を前記リソースサーバに送信し、
前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値を受信すると、更新用乱数を生成して前記クライアントに送信し、
前記クライアント及び前記認可サーバは、それぞれの前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項８に記載のトークン保護方法。
【請求項１０】
リソースオーナーからの認可許可が成功した場合、クライアントにトークンを発行する認可サーバ装置のプロセッサに、
少なくともトークンのハッシュ値を受信する処理と、
前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する処理と、
前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する処理と、
を実行させるプログラムを記録したプログラム記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トークン保護方法、認可システム、装置、及び、プログラム記録媒体に関する。
【背景技術】
【０００２】
企業等で保有するシステムやデータを呼び出すためのインターフェースはAPI（Application Programming Interface）と呼ばれている。このAPIを開放して保有するリソースを外部に提供するオープンAPIの動きが広まっている。オープンAPIの目的は、システムやデータの利用に対する課金によって直接に新たな収益源とする場合もあるが、オープンイノベーションによるエコシステムを構築して新たな顧客の獲得につなげるための施策として注目されている。代表例としてGoogle社が提供する「Google MapsＴＭ API」が挙げられる。【０００３】
オープンAPIは金融サービス等において特に注目されている。パーソナルファイナンスマネジメント（Personal Finance Management: PFM）は、ユーザが持つ複数の金融機関の口座情報を集約してユーザに資産状況を提供するサービスである。【０００４】
PFM事業者は、ユーザからIDとパスワードを預かり、金融機関のサービスにアクセスして情報を収集している。これに対して、ユーザの口座情報をPFM事業者に安全に提供するオープンAPIを各金融機関が整備することで、PFM事業者はユーザの認証情報を預かることなくサービスを実現できるようになる。欧州では、決済サービス指令PSD2（Payment Service Directive  2）が2015年11月に採択されており、金融機関は、オープンAPI対応が必須となった（2018年から施行）。これは、金融機関による顧客情報の囲い込みを防止し、ユーザが自分のデータを活用できるようにするためである。日本においても、金融審議会の「日本再興戦略２０１６  −第４次産業革命に向けて−」（２０１６年６月２日閣議決定）等においてオープンAPIの方針が打ち出され、対応が進んでいる。【０００５】
安全なオープンAPIを実現するための認可フレームワークの標準としてOAuth2.0の活用が進んでいる。OAuth2.0の仕様は非特許文献１が参照される。OAuth2.0の金融サービスへの適用およびセキュリティ上の課題に関しては非特許文献２が参照される。【０００６】
IETF（Internet Engineering Task Force）のRFC（Request for Comments) 6749には、OAuth2.0の中心的な役割を果たすエンティティとして５つのエンティティ（リソースオーナー、ユーザエージェント、クライアント、認可サーバ、リソースサーバ）が記載されている。図１は、非特許文献２の図表1 RFC 6749（OAuth2.0 のフレームワーク）のエンティティに基づく図である。【０００７】
リソースオーナー(resource owner)１０は、保護されたリソースへのアクセスを許可するエンティティである。リソースオーナーが人である場合、エンドユーザ（ユーザ）という。【０００８】
ユーザエージェント(user agent)２０は、リソースオーナー１０が用いる端末（スマートフォン１１やPC(Personal Computer)１２）のブラウザ等である。【０００９】
クライアント(client)３０は、リソースオーナー１０の許可を得てリソースオーナー１０の代理としてリソースに対するリクエストを行うアプリケーション（中間業者が提供するアプリケーション）である。  【００１０】
認可サーバ（authorization server）４０は、リソースオーナー１０の認証とリソースオーナー１０からの認可取得が成功したのち、クライアント３０にアクセストークンを発行する。【００１１】
リソースサーバ５０は、保護されたリソース（保護コンテンツ：口座情報や振込機能等）を保持し、クライアントからのアクセストークンを用いた前記保護されたリクエストを受理してリスポンスを返すことができるサーバである。アクセストークンは保護されたリソースにアクセスするためのクレデンシャルである（アクセストークンはクライアント３０に対して発行される権限（authorization）を表す文字列（string）であり、通常、クライアント３０にとって不透明（opaque）（ランダムな文字列）である。【００１２】
金融サービスの例では、PFM事業者はクライアント３０、認可サーバ４０およびリソースサーバ５０は、銀行等の金融機関が対応する。【００１３】
OAuth2.0は、認可サーバをリソースサーバから分離し、権限を限定したアクセストークンとして認可情報をクライアントに与えることで一元的な認証認可による安全性とユーザによる認証処理の機会を抑える利便性を両立することを目指している。【００１４】
OAuth2.0は、
・クライアント認証が可能な認可コードフローと、
・クライアントが認証情報を安全に保持することが難しいために、クライアント認証を行わないインプリシットフローと、
に大きく分けられる。【００１５】
認可コードフローは、事業者によるｗｅｂサービスがクライアントの場合、インプリシットフローは、端末のアプリケーションがクライアントの場合に適用されることが多い。【００１６】
以下、図２を参照して、認可コードフローについて説明する。図２は、非特許文献２の図表２（認可コード方式における処理フローの概要（概念図））に基づく図である。【００１７】
[認可コードフロー]
(1-1) クライアント３０が、ユーザエージェント２０を介してリソースサーバ５０へのアクセスを要求するリクエストを認可サーバ４０に送信する(S101)。【００１８】
このリクエストは、HTTP(Hypertext Transfer Protocol)リクエストが用いられる。HTTPリクエストのリクエストメソッドは、GETが用いられ、認可エンドポイント（リクエスト対象URI（Uniform Resource Identifier））に続いて"?"のあと、response_type =code & client_id={クライアント識別子}等が設定され、HTTPメッセージヘッダのHOSTは認可サーバとなる。認可エンドポイントは、認可サーバのHTTPのエンドポイントでエンドユーザの認証、認可の取得を行う。【００１９】
(1-2) 認可サーバ４０は、ユーザエージェント(ブラウザ)２０の画面を介して、リソースサーバ５０へのアクセスをクライアント３０に許可すること（認可を与えること）を、リソースオーナー１０に確認する。リソースオーナー１０は、それに同意する場合には、承認する旨を送信する（S102）。【００２０】
(1-3) 認可サーバ４０は、ユーザエージェント２０を経由して、アクセストークンの発行に必要なデータを格納した認可コードをクライアント３０に発行する（S103）。【００２１】
認可サーバ４０は、HTTPリスポンスにて認可コードを送信する。TLS（Transport Layer Security）1.2では、HTTPパケットのうちTCP（Transport  Control  Protocol）ペイロードに配置されるHTTPメッセージは暗号化される。なお、TLS等による暗号通信は、ステップS103で認可コードを受けたユーザエージェント(ブラウザ)２０において一旦復号される。【００２２】
(1-4) クライアント３０は、認可コードに加えて、クライアント３０が保有している認証情報（クライアント・シークレット）を認可サーバ４０に送信し、アクセストークンの発行を要求する（S104）。【００２３】
アクセストークンの発行の要求は、HTTPリクエスト（リクエストメソッドはPOST）が用いられる。クライアント認証(Client Authentication)が行われる場合、HTTP Basic認証の場合、HTTPリクエストのAuthorizationヘッダ内のパラメータにクライアントパスワードが設定され、あるいは、クライアント識別子、クライアントシークレットパラメータが追加される。【００２４】
(1-5) 認可サーバ４０は、認可コードを検証するとともに、認証情報（クライアント・シークレット）を用いてクライアント認証を行う（S105） 。【００２５】
(1-6）認可サーバ４０は、クライアント認証が成功した場合、アクセストークンとリフレッシュトークンを発行し、これらをクライアント３０に送信する（S106）。【００２６】
アクセストークンとリフレッシュトークンは、HTTPリクエストに対するHTTPリスポンスで送信される。HTTPリスポンスには、アクセストークンの有効秒数も任意で設定される。なお、リフレッシュトークンは、クライアントがリソースオーナーの新しいアクセストークンを取得するためのトークン（文字列）である。【００２７】
(1-7) クライアント３０は、アクセストークンをリソースサーバ５０に送信し、アクセストークンを用いてリソースサーバ５０にアクセスする（S107）。リソースサーバ５０からリソースオーナーのデータがクライアント３０に転送される。【００２８】
OAuth2.0では、認可サーバ４０において、ユーザに対して認証、認可を行う部分（認可エンドポイント）と、トークンを発行する部分（トークンエンドポイント）を分離している。【００２９】
また、認可コードフローでは、認可サーバ４０は、クライアント認証の上で有効な認可コードに対して、アクセストークンを発行する。なお、Basic認証と呼ばれるクライアント認証方式では、認可サーバ４０との間で予め共有した秘密情報をクライアント３０が送付することで認証を行う。【００３０】
OAuth2.0では、アクセストークンが有効期限を過ぎたら、クライアント３０はリフレッシュトークンを認可サーバ４０に送付し、新たなアクセストークンを入手することができる。【００３１】
リフレッシュトークンは、クライアント３０と認可サーバ４０の間だけで使用されるために、リソースサーバも関与するアクセストークンと比べて、攻撃機会は少ないと考えられる。このため、有効期限を長く設定することが行われている。【００３２】
以下、図３を参照して、リフレッシュトークンフローを説明する。図３において、アクセストークンによるリソースサーバアクセス（S200）は、図２のS107に対応している。【００３３】
[リフレッシュトークンフロー]
(2-1) クライアント３０は、アクセストークンの有効期限が切れたら、認可サーバ４０へリフレッシュトークンとクライアント認証情報を送信する（S201）。【００３４】
(2-2) 認可サーバ４０は、クライアント認証情報がOKであり、且つ、リフレッシュトークンが有効であれば、新たにアクセストークンとリフレッシュトークンを生成する（S202）。【００３５】
(2-3) 認可サーバ４０は、アクセストークンとリフレッシュトークンをクライアント３０に送信する（S203）。【００３６】
(204) クライアント３０は、新たにアクセストークンを用いてリソースサーバ５０にアクセスする（S204）。【００３７】
図４は、OAuth2.0の認可システムの一般的な構成を模式的に例示した図である。図４において、認可サーバ４０のトークン制御部４０１は、認証認可の結果を受けて、認可コード、アクセストークンやリフレッシュトークンの生成および検証等を実行する。アクセストークンおよびリフレッシュトークンは攻撃者による推測が難しくなるように、十分な長さの乱数成分を含むように構成することができる。このため、認可サーバ４０のトークン制御部４０１は、乱数生成機能を有する。認可サーバ４０のトークン制御部４０１は、さらにデジタル署名付きのトークンを発行するためのハッシュ関数や公開鍵暗号の機能も一般に保持する。【００３８】
トークン管理部４０２は、半導体メモリ又はHDD（Hard Disk Drive）等からなる記憶装置を備え、認可コード、アクセストークンおよびリフレッシュトークンについてトークン識別のための情報や乱数成分およびアクセス範囲や有効期限などの認可情報の保持、管理を行う。【００３９】
認可サーバ４０は、複数のクライアント３０に対応しており、好ましくは、クライアント３０毎に、トークン識別のための情報、認可情報をテーブル化する等、効率的かつ確実に管理するデータ管理手法が実装される。【００４０】
クライアント３０もトークン制御部３０１を備え、認可サーバ４０から受信したアクセストークンやリフレッシュトークンをトークン管理部３０２で管理する。トークン制御部３０１は、ユーザやアプリケーションの要求に応じてアクセストークンを利用してリソースサーバ５０にアクセスし、必要に応じて、リフレッシュトークンを用いて、認可サーバ４０から新規アクセストークンおよびリフレッシュトークンを入手する。【００４１】
トークン制御部３０１は、認可サーバ４０のデジタル署名付きのトークンを検証するための機能を備え、一般に、ハッシュ関数や公開鍵暗号の機能を具備する。【００４２】
図５は、アクセストークン問い合わせ処理の実行時の情報のやりとりの一例を示す図である。図５に示すように、リソースサーバ５０は、クライアント３０からアクセストークンを受け取ると、認可サーバ４０にアクセストークンの問い合わせを行い、当該アクセストークンのステータスと許可情報を得るように構成することもできる。
【先行技術文献】
【非特許文献】
【００４３】
【非特許文献１】RFC  6749  "The OAuth 2.0 Authorization Framework“, 2012
【非特許文献２】中村啓祐、”OAuth2.0に対する対策と脅威：金融APIの一段の有効活用に向けて”Discussion Paper No.2017-J-16, 日本銀行, 2017、［平成30年12月25日検索］  インターネット（URL  https://www.imes.boj.or.jp/research/papers/japanese/kk37-3-4.pdf）
【発明の概要】
【発明が解決しようとする課題】
【００４４】
上記した関連技術においては、攻撃者によるトークンの奪取に関わる安全性に関して課題を有する。【００４５】
関連技術の認可システムにおいて、通信は、例えばTLS(Transport Layer Security)などによって保護されることが想定されていても、例えば実装の不備等から、中間者攻撃等によって攻撃が可能になるというリスクは存在する。このような攻撃に成功すると、攻撃者は、トークンの窃取が可能になる。【００４６】
また、マルウェアや内部犯行によって、クライアントから、認証情報とともにトークンが窃取される可能性についても考慮する必要がある。【００４７】
さらに、マルウェア対策が進んでも、マルウェアが検知されるまでの期間、該マルウェアは一時的に存在し、クライアントから、認証情報とともに、トークン情報が窃取されるリスクも存在する。【００４８】
そして、リフレッシュトークンは、その性質上、有効期間を長く設定されていることから、一層安全に保持する必要がある。【００４９】
オープンAPIが金融サービスなど機微な情報を扱うサービスにおいて活用が進むためには、こうした脅威に対応するために、仮にトークンが窃取されても、該トークンが悪用されることを防ぐことを可能とする強固な保護対策が望まれる。【００５０】
本発明は、上記課題の認識に基づき創案されたものであって、その目的は、仮にトークンが窃取された場合であっても、該トークンが悪用されることを回避可能とするシステム、装置、方法、プログラム記録媒体を提供することにある。
【課題を解決するための手段】
【００５１】
本発明の１つの側面によれば、ユーザの情報を保有するリソースサーバと、前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、を備え、前記クライアントは、前記リフレッシュトークンの使用時に、前記認可サーバに対して前記リフレッシュトークンのハッシュ値を送信し、前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、前記クライアントは、前記更新用乱数を用いて、前記リフレッシュトークンを更新する認可システムが提供される。【００５２】
本発明の別の側面によれば、リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントに対してトークンを発行する認可サーバ装置であって、少なくともトークンのハッシュ値を受信する第１の手段と、前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する第２の手段と、前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、トークン更新用乱数を生成し、前記トークン更新用乱数を前記クライアントに送信する第３の手段と、を備えた認可サーバ装置が提供される。【００５３】
本発明のさらに別の側面によれば、リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアント装置であって、認可サーバから発行されたトークンのハッシュ値を生成する第１の手段と、前記ハッシュ値を、前記認可サーバに送信する第２の手段と、前記認可サーバから送信されたトークンの更新用乱数を受信し、前記トークンを、前記更新用乱数を用いて更新する第３の手段と、クライアント装置が提供される。【００５４】
本発明のさらに別の側面によれば、リソースオーナーの許可を得てリソースオーナーの代理としてリソースサーバの保護されたリソースに対するアクセスを行うクライアントが、リフレッシュトークンの使用時に、前記リフレッシュトークンのハッシュ値を認可サーバに送信し、
前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
前記クライアントは、前記更新用乱数を用いて前記リフレッシュトークンを更新するトークン保護方法が提供される。【００５５】
本発明のさらに別の側面によれば、リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置のプロセッサに、
少なくともトークンのハッシュ値を受信する処理と、
前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する処理と、
検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する処理と、を実行させるプログラム、及び、該プログラムを記録したコンピュータ読み出し可能な記録媒体（半導体メモリ（例えばRAM（Random Access Memory）、ROM（Read Only Memory）、又は、EERROM（Electrically Erasable and Programmable ROM)）等の半導体ストレージ、HDD（Hard Disk Drive）、CD（Compact Disc）、DVD（Digital Versatile Disc）等の非一時的コンピュータ読み出し可能記録媒体（non-transitory computer readable recording medium））が提供される。
【発明の効果】
【００５６】
本発明によれば、仮にトークンが窃取された場合であっても、該トークンが悪用されることを回避可能とする。
【図面の簡単な説明】
【００５７】
【図１】非特許文献２の図表１（RFC 6749（OAuth2.0 のフレームワーク）のエンティティ）に基づく図である。
【図２】認可コードフローを説明する図である（非特許文献２の図表２（認可コード方式における処理フローの概要（概念図））に基づく）。
【図３】リフレッシュトークンフローを説明する図である。
【図４】OAuth2.0の認可システムの一般的な構成（クライアント、認可サーバ）を模式的に示す図である。
【図５】アクセストークン問い合わせ処理の実行時の情報のやりとりの一例を模式的に示す図である。
【図６】本発明の例示的な実施形態を説明する図である。
【図７】本発明の例示的な実施形態の認可システム（クライアント、認可サーバ）を説明する図である。
【図８】本発明の例示的な実施形態を説明する図である。
【図９】本発明の別の実施形態におけるアクセストークン問い合わせ処理の実行時の情報のやりとりの一例を模式的に示す図である。
【図１０】本発明の別の例示的な実施形態を説明する図である。
【図１１】本発明のさらに別の例示的な実施形態を説明する図である。
【図１２】本発明の例示的な実施形態としてコンピュータ実装例を説明する図である。
【発明を実施するための形態】
【００５８】
本発明の例示的な一実施形態によれば、クライアントはリフレッシュトークンを使用する時、認可サーバに対してリフレッシュトークンの代わりに、該リフレッシュトークンのハッシュ値を送信する。認可サーバは、リフレッシュトークンのハッシュ値を受信すると、リフレッシュトークンの更新用乱数を生成してクライアントに送信する。クライアントは、認可サーバから送信された更新用乱数を用いてリフレッシュトークンを更新する。仮に、攻撃者が、認可サーバとクライアント間においてある時点でフレッシュトークンの通信盗聴に成功したとしても、攻撃者はハッシュ値のみを入手する。このために、元のリフレッシュトークンは不明である。したがって、リフレッシュトークンを更新することは困難である。
【００５９】
また、攻撃者が、たとえ、ある時点でクライアント内のメモリ上などからリフレッシュトークンの窃取に成功したとしても、該攻撃者は、その後の更新用乱数も入手できなければ、当該リフレッシュトークンの更新は困難になる。
【００６０】
いずれのケースにおいても、攻撃者はリフレッシュトークンの更新に成功しない。そして、攻撃者が以前のトークンを利用しても、認可サーバには、無効なトークンと判定される。
【００６１】
図５に例示したように、リソースサーバ５０が認可サーバ４０へアクセストークンの認可情報を問い合わせる仕様においては、認可サーバ４０とクライアント３０間でのリフレッシュトークンの更新と同様に考えることが可能である。例えば、クライアント３０がアクセストークンのハッシュ値をリソースサーバ５０に送信し、リソースサーバ５０が認可サーバ４０に、アクセストークンのハッシュ値を用いて認可情報を問い合わせることで、攻撃者の窃取、悪用に対する耐性を高めることが可能となる。
【００６２】
本実施形態によれば、図４のクライアント３０のトークン制御部３０１と認可サーバ４０のトークン制御部４０１の機能を拡張することで実現することができる。図６は、例示的な実施形態を説明する図である。図６には、図４のクライアント３０のトークン制御部３０１と、認可サーバ４０のトークン制御部４０１において、例示的な実施形態の特徴的な機能部分が模式的に例示されている。図６において、クライアント３０とリソースサーバ５０間の矢線は、クライアント３０からリソースサーバ５０への信号の送信の一例を示したものであり、クライアント３０とリソースサーバ５０間が一方向でのみ接続されることを表すものではない。以下では、図６の説明において、図４と重複する部分の説明は省略する。
【００６３】
図６を参照すると、クライアント３０のトークン制御部３０１は、ハッシュ値生成部３０３と、トークン更新部３０４を備えている。ハッシュ値生成部３０３は、トークンのハッシュ値を生成し、該ハッシュ値と、トークンのインデックス（トークンID（Identifier：識別子））を認可サーバ４０に送信する。
【００６４】
トークン更新部３０４は、認可サーバ４０から送信されたトークンの更新用乱数を受信し、更新用乱数を用いてクライアント３０で保持しているトークン（クライアント３０が認可サーバ４０に対してハッシュ値を送信したトークン）を更新する。
【００６５】
認可サーバ４０のトークン制御部４０１は、ハッシュ値生成部４０３と、ハッシュ値比較部４０４と、更新用乱数生成部４０５と、トークン更新部４０６を備えている。ハッシュ値生成部４０３は、トークンのハッシュ値と該トークンのインデックスとを、不図示のNIC（Network Interface Card）等を介して受信し、該インデックスに対応するトークンを特定し、特定したトークンのハッシュ値を生成する。
【００６６】
ハッシュ値比較部４０４は、インデックスから特定したトークンのハッシュ値と、クライアント３０から受信したハッシュ値とを比較する。
【００６７】
更新用乱数生成部４０５は、ハッシュ値比較部４０４での比較の結果、２つのハッシュ値が一致する場合、トークンの更新用乱数を生成し、該更新用乱数を不図示のNICを介してクライアント３０に送信する。
【００６８】
トークン更新部４０６は、生成した更新用乱数を用いて該インデックスに対応するトークンを更新する。
【００６９】
なお、認可サーバ４０は、トークンのハッシュ値と該トークンのインデックスをクライアント３０から受信してもよい。この場合、トークンはリフレッシュトークンである。認可サーバ４０のトークン制御部４０１は、２つのハッシュ値が一致する場合、新たなアクセストークンを生成し、該更新用乱数とともに、新たなアクセストークンをクライアント３０に送信するようにしてもよい。
【００７０】
なお、認可サーバ４０のトークン制御部４０１において、受信したハッシュ値を検索するハッシュ値検索部を備えた構成としてもよい（この構成例は、図１１を参照して後述される）。この場合、クライアント３０は、トークンのハッシュ値を認可サーバ４０に送信すればよい（クライアント３０からの認可サーバ４０へのトークンのインデックスの送信は不要である）。
【００７１】
なお、トークン自体でなくそのハッシュ値の送信が行われるトークンは、リフレッシュトークンに制限されるものでなく、アクセストークンであってもよい。この場合、クライアント３０からアクセストークンのハッシュ値を受信したリソースサーバ５０が、アクセストークンのハッシュ値の問い合わせを認可サーバ４０に行うときに、認可サーバ４０がリソースサーバ５０からハッシュ値とアクセストークンのインデックスを受信するようにしてもよい。
【００７２】
すなわち、クライアント３０のトークン制御部３０１のハッシュ値生成部３０３は、アクセストークンのハッシュ値を生成し、アクセストークンのハッシュ値とアクセストークンのインデックス（トークンID）をリソースサーバ５０に送信する。リソースサーバ５０は、認可サーバ４０に当該アクセストークンのハッシュ値の問い合わせを行う際に、アクセストークンのハッシュ値と、該アクセストークンのインデックスを認可サーバ４０に送信する。
【００７３】
認可サーバ４０は、アクセストークンのハッシュ値と、該アクセストークンのインデックスを不図示のNICで受信し、ハッシュ値生成部４０４は、該インデックスに対応するアクセストークンを特定し、特定したアクセストークンが有効であれば、特定したアクセストークンのハッシュ値を生成する。ハッシュ値比較部４０４は、生成したハッシュ値と、リソースサーバ５０から受信した前記ハッシュ値を比較する。
【００７４】
なお、認可サーバ４０のトークン制御部４０１が、ハッシュ値を検索するハッシュ値検索部を備えた構成（図１１を参照して後述される）の場合、リソースサーバ５０は認可サーバ４０にアクセストークンのハッシュ値の問い合わせを行う際に、アクセストークンのハッシュ値を認可サーバ４０に送信すればよい（アクセストークンのインデックスの送信は不要である）。
【００７５】
認可サーバ４０の更新用乱数生成部４０５は、ハッシュ値比較部４０４での比較の結果、２つのハッシュ値が一致する場合、トークンの更新用乱数を生成する。更新用乱数生成部４０５は、生成した更新用乱数をNICを介してクライアント３０に送信する。
【００７６】
クライアント３０のトークン更新部３０４は、認可サーバ４０から送信されたトークンの更新用乱数を受信し、クライアント３０で保持するトークンを更新用乱数を用いて更新する。
【００７７】
認可サーバ４０は、アクセストークンとリフレッシュトークンそれぞれに一意に識別可能なインデックスであるトークンIDを割り当て、該トークンIDをトークンの一部とするようにしてもよい。
【００７８】
次に、図７を参照して、本実施形態における、リフレッシュトークンの更新フローを説明する。各処理で条件がNG（no good）となった場合には、認可コードフローを最初から再度実行する。なお、図７において、アクセストークンによるリソースサーバアクセス（S300）は、図３のアクセストークンによるリソースサーバアクセス（S200）と同じである。
【００７９】
[リフレッシュトークンの更新フロー]
(3-1) クライアント３０は、リフレッシュトークンのハッシュ値を生成する（S301）。
【００８０】
(3-2) クライアント３０は、リフレッシュトークンのトークンIDと、クライアント認証情報とともに認可サーバ４０へ送信する（S302）。
【００８１】
(3-3) 認可サーバ４０は、クライアント認証情報を認証した結果、認証がOKの場合、トークンIDからリフレッシュトークンを特定する。認可サーバ４０は、リフレッシュトークンが有効であれば、そのハッシュ値を生成する（S303）。
【００８２】
(3-4) 認可サーバ４０は、ステップS302でクライアント３０から受信したハッシュ値と、ステップS303で認可サーバ４０が生成したハッシュ値とが互いに一致しているかチェックする。一致していれば、認可サーバ４０は、リフレッシュトークンの更新用乱数を生成し、新たなアクセストークンを生成する（S304）。
【００８３】
(3-5) 認可サーバ４０は、新たなアクセストークンと、リフレッシュトークンの更新用乱数を、クライアントに送信する（S305）。
【００８４】
(3-6) 認可サーバ４０は、トークンIDで特定したリフレッシュトークンを更新用乱数で更新する（S306）。また、クライアント３０は、ステップS301でハッシュ値を作成した当該リフレッシュトークンを、認可サーバ４０から受信した更新用乱数で更新する（S307）。
【００８５】
更新用乱数の生成は、認可サーバ４０のトークン制御部４０１において、アクセストークンやリフレッシュトークンの生成に利用する乱数生成の機能を用いて実現することができる。
【００８６】
また、リフレッシュトークンの更新用乱数による更新は、加算（排他的論理和）演算やハッシュ関数など、認可サーバ４０のトークン制御部４０１に予め具備されている機能で実現するようにしてもよい。
【００８７】
リフレッシュトークンの更新フローは、アクセストークンの有効期限が切れたタイミングだけではなく、新規アクセストークンの発行を伴わなくても、任意のタイミングで実行することができる。例えば、アクセストークンの利用時に、上記したリフレッシュトークン更新フローを実行するようにしてもよい。
【００８８】
図５のように、リソースサーバ５０が、認可サーバ４０に対して、アクセストークンの認可情報を問い合わせるときには、アクセストークンに対しても、上記したリフレッシュトークン更新フローと同様な処理を適用することができる。
【００８９】
アクセストークンは、一般に有効期限が短く設定されているが、更新フローを導入することで、トークンの窃取による悪用等に対する耐性を一層高くすることができる。
【００９０】
図８は、本発明の別の実施形態として、更新付きアクセストークンの処理フローを説明する図である。図９は、更新付きアクセストークンの処理フローにおけるクライアント３０、認可サーバ４０、リソースサーバ５０の間の信号の送受を説明する図である。図８及び図９を参照して、本発明の別の実施形態の更新付きアクセストークン処理を説明する。
【００９１】
[更新付きアクセストークンの処理フロー]
(4-1) クライアント３０は、アクセストークンのハッシュ値を生成する（S401）。
【００９２】
(4-2) クライアント３０は、生成したハッシュ値をアクセストークンのトークンID（インデックス）とともに、リソースサーバ５０へ送信する（S402）。
【００９３】
(4-3) リソースサーバ５０は、クライアント３０から送信されたアクセストークンのトークンID（インデックス）、 ハッシュ値を認可サーバ４０へ送信して問い合わせる（S403）。
【００９４】
(4-4) 認可サーバ４０は、リソースサーバ５０が問い合わせたトークンID（インデックス）からアクセストークンを特定し、該アクセストークンが有効であるか確認する。該アクセストークンが有効であれば、 認可サーバ４０は、アクセストークンのハッシュ値を生成し、リソースサーバ５０が問い合わせたハッシュ値と一致するか否かをチェックする。ハッシュ値が一致すれば、認可サーバ４０は、認可情報を生成し（S404）、リソースサーバ５０へ認可情報を送信する（S405）。
【００９５】
(4-6) リソースサーバ５０は、認可情報に基づいて、クライアント３０へサービスを提供する（S406）。
【００９６】
(4-7) 認可サーバ４０は、アクセストークンの更新用乱数を生成する（S407）。
【００９７】
(4-8) 認可サーバ４０は、更新用乱数をクライアント３０へ送信する(S408)。
【００９８】
(4-9) 認可サーバ４０は、トークンID（インデックス）に基づき特定したアクセストークンを、ステップS407で作成した更新用乱数で更新する(S409)。クライアント３０は、ステップS401でハッシュ値を作成した当該アクセストークンを、ステップS408で受信した更新用乱数で更新する(S410)。ステップS410において、クライアント３０は更新用乱数を用いてリフレッシュトークンを更新してもよい。
【００９９】
トークンの初期設定に対しても、予め、認可サーバ４０とクライアント３０で共有する初期情報を用意しておくことで、更新処理と同様の手順を適用することができる。図１０は、トークン初期設定処理を説明する図である。
【０１００】
[トークン初期設定フロー]
【０１０１】
(5-1)  認可サーバ４０は、トークンの更新用乱数を生成する（S501）。
【０１０２】
(5-2)  認可サーバ４０は、更新用乱数をクライアント３０へ送信する（S502）。
【０１０３】
(5-3)  認可サーバ４０とクライアント３０は、予め共有した初期情報と更新用乱数に基づき、アクセストークンとリフレッシュトークンを更新する（S503、S504）。
【０１０４】
なお、更新用乱数は、アクセストークンとリフレッシュトークンそれぞれに対して生成することが想定されるが、初期情報をアクセストークンとリフレッシュトークンで異なる設定とすることで、更新用乱数をアクセストークンとリフレッシュトークンで共通とすることもできる。
【０１０５】
また、初期情報に、認可サーバ４０とクライアント３０で共有する秘密情報を加えることで、認可サーバとクライアント間の通信が最初からすべて盗聴されたとしても、攻撃者がトークンを生成することを困難にすることができる。
【０１０６】
以下、上記した例示的な実施形態について具体例を説明する。
【０１０７】
上記実施形態では、トークンの仕様として、トークンIDおよびトークン乱数成分および認可情報を要素として持つことを想定している。
【０１０８】
トークンIDは、認可サーバ名、クライアント名、リソースサーバ名、トークン種別（アクセストークン、またはリフレッシュトークン）、およびシリアル番号などを要素として持つように構成することができる。
【０１０９】
あるいは、単なる一意識別可能なインデックスとして表現して、こられの情報は認可情報とともに、別途、関連付けして管理するようにしてもよい。
【０１１０】
トークンの乱数成分は、攻撃者がトークンを推測することを困難にするために利用される。トークンの更新（更新用乱数による更新）は、トークンIDやその他情報はそのままにして（更新しない）、このトークン乱数成分に対して適用することで実現することができる。
【０１１１】
このトークン乱数成分の典型的なサイズは、例えば、256ビット(=32バイト)もしくは128ビット(=16バイト)として設定してもよい。
【０１１２】
認可情報（図８、図９においてS405で認可サーバ４０からリソースサーバ５０に提供される）は、リソースサーバ５０へのアクセスの範囲や有効期限等を含む。
【０１１３】
これらの情報は、トークンには含めずに、クライアント３０は、その都度、認可サーバ４０へ問い合わせることも可能である。
【０１１４】
本実施形態において、トークンの仕様として、トークンIDを設定せずに、トークン乱数成分だけで構成するようにしてもよい。この場合も、十分大きなサイズ(256ビットなど)をとるようにすることで、トークンIDが衝突する確率を十分に小さくすることができる。
【０１１５】
また、本発明の別の実施形態において、認可サーバ４０は、図７のステップS301、図８のステップS401で送信されるハッシュ値に対して、高速に検索できるように、受信したハッシュ値を検索するハッシュ値検索部を備えた構成としてもよい。本実施形態によれば、認可サーバ４０へのインデックスの送信は不要である。
【０１１６】
図１１は、ハッシュ値検索部を備えた認可サーバ４０を例示する図である。一方向性ハッシュ関数（一方向性圧縮関数）の場合、事実上、ハッシュ値の逆変換（復号）はできない。そこで、ハッシュ値生成部４０３は、認可サーバ４０がクライアント３０にアクセストークン、リフレッシュトークンを発行する際、及び、アクセストークン、リフレッシュトークンを更新用乱数で更新した場合、該トークンのハッシュ値をハッシュ値検索部４０７の不図示のメモリ（テーブル）に登録しておくようにしてもよい。この場合、当該メモリ（テーブル）には、トークンのハッシュ値と該トークンとを関連付けて登録する構成としてもよい。ハッシュ値検索部４０７は、クライアント３０からリフレッシュトークンのハッシュ値を受信すると、該メモリ（テーブル）を検索し、該ハッシュ値が見つかると、クライアント３０から受信した該ハッシュ値に対応するリフレッシュトークンは正しいトークン（認可サーバ４０がクライアント３０に発行したトークン、又は認可サーバ４０が提供した更新用乱数で更新したト−クン）であると判断する。一方、該ハッシュ値が見つからないと、クライアント３０から受信したハッシュ値に対応するリフレッシュトークンは正しくないトークン（例えば、認可サーバ４０は該ハッシュ値に対応するリフレッシュトークンをクライアント３０に発行してない）と判断する。本実施形態によれば、図７のS302において、クライアント３０から認可サーバ４０へのインデックスの送信は不要である。
【０１１７】
同様に、ハッシュ値検索部４０７は、リソースサーバ５０からアクセストークンのハッシュ値を受信すると、該メモリ（テーブル）を検索し、該ハッシュ値が見つかると、アクセストークンは正しいトークンであると判断し、リソースサーバ５０に認可情報を送信し、さらにトークンの更新用乱数を生成する。この場合、図８のステップS402、S403において、インデックスの送信は不要である。
【０１１８】
図７、図８のステップS301とS401において、リフレッシュトークンとアクセストークンのハッシュ値の生成は、例えば、SHA256（Secure Hash Algorithm 256）など、暗号学的に安全なハッシュ関数を用いて実現してもよい。
【０１１９】
クライアント３０から送信するハッシュ値のサイズは、安全性レベルに沿って、例えばSHA256の出力を打ち切って、64ビット(=16バイト)等に設定してもよい。
【０１２０】
ステップS409とS410において、リフレッシュトークンの更新処理は、典型的には、次の2種類の方法を適用してもよい。リフレッシュトークンをRT, 更新用乱数をrで表す。
【０１２１】
[ワンタイムパッド]
RT ← RT xor r          ・・・(1)
【０１２２】
ここで、rは、RTと同一サイズである。
xorは、ビット毎の排他的論理和（bitwise exclusive or）である。
【０１２３】
[ハッシュ関数利用]
RT ← Trunc(H(RT||r))       ・・・(2)
【０１２４】
ここで、rは任意長、||はビット列の連接（concatenation）、Hはハッシュ関数、Truncはハッシュ関数の出力をRTと同一サイズとなるように打ち切る関数（Truncation）を表す。
【０１２５】
ハッシュ関数HはステップS301、S401と同一の関数（SHA256など）を適用するようにしてもよい。
【０１２６】
ハッシュ関数の入力としては、RT, r以外に、クライアント３０と認可サーバ４０で共有している公開情報（例えば、認可サーバ名とクライアント名など）や、秘密情報も併せて用いてもよい。
【０１２７】
上記(2)式のハッシュ関数利用では処理コストは大きくなるが、更新用乱数rをRTよりも小さく設定することができる。このため、rの通信および生成コストを小さくすることが可能になる。
【０１２８】
認可サーバ４０とクライアント３０が共有する秘密情報としては、OAuth2.0のクライアント認証情報を用いる他に、このための乱数を認可サーバ４０とクライアント３０で別途共有することも可能である。
【０１２９】
RTの初期値を認可サーバ４０とクライアント３０で予め決めておくことによって、上記トークン更新処理は、トークンの初期設定にも利用することができる。
【０１３０】
このとき、クライアント認証情報ではなく、専用の乱数を用いた場合には、認可コードフロー（例えば図２）の開始からのすべての通信の盗聴に攻撃者が成功しても、リフレッシュトークンおよびアクセストークンを取得することを困難にすることができる。
【０１３１】
図１２は、実施形態のクライアント３０と、認可サーバ４０をそれぞれコンピュータ装置１００に実装した例を説明する図である。コンピュータ装置１００は、プロセッサ（CPU（Central Processing Unit）、データ処理装置）１０１と、半導体メモリ（例えばRAM（Random Access Memory）、ROM（Read Only Memory）、又は、RRPROM（Electrically Erasable and Programmable ROM）等）、USB（Universal Serial Bus）、HDD（Hard Disk Drive）、CD（Compact Disc）、DVD（Digital Versatile Disc）等の少なくともいずれかを含むメモリ１０２と、NIC（Network Interface Card or Network Interface Controller）１０３を備えている。メモリ１０２に保持されたプログラム（インストラクション群）をプロセッサ１０１で実行することで、コンピュータ装置１００を、上記した実施形態の認可サーバとして動作させることができる。メモリ１０２に保持されたプログラムとしてクライアント３０（アプリケーション）のプログラムを保持し、プロセッサ１０１で該プログラムを実行することで、コンピュータ装置１００を、上記した実施形態のクライアントシステムとして動作させることができる。なお、図１２において、表示装置やプリンタ等の入出力装置をコンピュータ装置１００に接続してもよいことは勿論である。
【０１３２】
なお、上記の非特許文献１、２の各開示を、本書に引用をもって繰り込むものとする。本発明の全開示（請求の範囲を含む）の枠内において、さらにその基本的技術思想に基づいて、実施形態ないし実施例の変更・調整が可能である。また、本発明の請求の範囲の枠内において種々の開示要素（各請求項の各要素、各実施例の各要素、各図面の各要素等を含む）の多様な組み合わせ乃至選択が可能である。すなわち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得るであろう各種変形、修正を含むことは勿論である。
【０１３３】
上記した実施形態は以下のように付記される（ただし以下に制限されない）。
【０１３４】
（付記１）
ユーザの情報を保有するリソースサーバと、
前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、
前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、
を備え、
前記クライアントは、前記リフレッシュトークンの使用時に、前記認可サーバに対して前記リフレッシュトークンのハッシュ値を送信し、
前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
前記クライアントは、前記更新用乱数を用いて、前記リフレッシュトークンを更新する、ことを特徴とする、認可システム。
【０１３５】
（付記２）
前記クライアントは、前記アクセストークン使用時に、前記リソースサーバに対して、前記アクセストークンのハッシュ値を送信し、
前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値を受信すると、更新用乱数を生成して前記クライアントに送信し、
前記クライアント及び前記認可サーバは、前記更新用乱数を用いてそれぞれが保持する前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、付記１に記載の認可システム。
【０１３６】
（付記３）
予め前記認可サーバと前記クライアントで共有している初期値と、前記認可サーバから送信される更新用乱数とに基づき、前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、付記１又は２に記載の認可システム。
【０１３７】
（付記４）
前記認可サーバは、前記リフレッシュトークンのハッシュ値と、前記リフレッシュトークンのインデックスを前記クライアントから受信し、
前記インデックスからリフレッシュトークンを特定し、
前記特定したリフレッシュトークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、新しいアクセストークンを生成し、
前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記１乃至３のいずれか一に記載の認可システム。
【０１３８】
（付記５）
前記認可サーバは、前記リフレッシュトークンのハッシュ値を前記クライアントから受信し、
受信した前記ハッシュ値を、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、新しいアクセストークンを生成し、
前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記１乃至３のいずれか一に記載の認可システム。
【０１３９】
（付記６）
前記認可サーバは、
前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバに行うリソースサーバから、前記アクセストークンのハッシュ値と前記アクセストークンのインデックスを受信し、
前記インデックスからアクセストークンを特定し、前記特定したアクセストークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、
認可情報を生成して前記リソースサーバに送信し、
前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする付記２に記載の認可システム。
【０１４０】
（付記７）
前記認可サーバは、
前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバに行うリソースサーバから、前記アクセストークンの前記ハッシュ値を受信し、
受信した前記ハッシュ値を、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、
認可情報を生成して前記リソースサーバに送信し、
さらに前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする付記２に記載の認可システム。
【０１４１】
（付記８）
リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置であって、
少なくともトークンのハッシュ値を受信する第１の手段と、
前記ハッシュ値に基づきトークンを検証する第２の手段と、
前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する第３の手段と、を備えた、ことを特徴とする、認可サーバ装置。
【０１４２】
（付記９）
前記トークンはリフレッシュトークンであり、
前記第１の手段は、前記リフレッシュトークンのハッシュ値と、前記リフレッシュトークンのインデックスを前記クライアントから受信し、
前記第２の手段は、前記インデックスからリフレッシュトークンを特定し、
前記特定したリフレッシュトークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
前記第３の手段は、２つのハッシュ値が互いに一致する場合、新しいアクセストークンを生成する手段を備え、前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記８に記載の認可サーバ装置。
【０１４３】
（付記１０）
前記トークンはリフレッシュトークンであり、
前記第１の手段は、前記リフレッシュトークンのハッシュ値を前記クライアントから受信し、
前記第２の手段は、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、新しいアクセストークンを生成する第４の手段を備え、
前記第３の手段は、前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記８に記載の認可サーバ装置。
【０１４４】
（付記１１）
前記トークンはアクセストークンであり、
前記第１の手段は、前記クライアントからアクセストークンを受信したリソースサーバ装置が、トークンの問い合わせを、前記認可サーバ装置に行う際に、前記リソースサーバ装置から、前記アクセストークンのハッシュ値と前記アクセストークンのインデックスを受信し、
前記第２の手段は、前記インデックスからアクセストークンを特定し、前記アクセストークンが有効であれば、前記特定したアクセストークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、認可情報を生成して前記リソースサーバに送信する第４の手段を備え、
前記２つのハッシュ値が互いに一致する場合、前記第３の手段は、前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする、付記８に記載の認可サーバ装置。
【０１４５】
（付記１２）
前記トークンはアクセストークンであり、
前記第１の手段は、前記クライアントからアクセストークンを受信したリソースサーバ装置が、トークンの問い合わせを、前記認可サーバ装置に行う際に、前記リソースサーバ装置から、前記アクセストークンのハッシュ値を受信し、
前記第２の手段は、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、認可情報を生成して前記リソースサーバに送信する第４の手段を備え、
前記第３の手段は、前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする、付記８に記載の認可サーバ装置。
【０１４６】
（付記１３）
リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアント装置であって、
リソースサーバへのアクセスの認可がリソースオーナーから与えられた前記クライアントにトークンを発行する認可サーバから発行されたトークンのハッシュ値を生成する第１の手段と、
前記ハッシュ値を前記認可サーバに送信する第２の手段と、
前記認可サーバから送信されたトークンの更新用乱数を受信し、前記トークンを、前記更新用乱数を用いて更新する第３の手段と、
を備えた、ことを特徴とする、クライアント装置。
【０１４７】
（付記１４）
リソースオーナーの許可を得てリソースオーナーの代理としてリソースサーバの保護されたリソースに対するアクセスを行うクライアントが、リフレッシュトークンの使用時に、前記リフレッシュトークンのハッシュ値を認可サーバに送信し、
前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
前記クライアントは、前記更新用乱数を用いて前記リフレッシュトークンを更新する、ことを特徴とする、トークン保護方法。
【０１４８】
（付記１５）
前記クライアントは、前記アクセストークン使用時に、前記アクセストークンのハッシュ値を前記リソースサーバに送信し、
前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値を受信すると、更新用乱数を生成して前記クライアントに送信し、
前記クライアント及び前記認可サーバは、それぞれの前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、付記１４に記載のトークン保護方法。
【０１４９】
（付記１６）
予め前記認可サーバと前記クライアントで共有している初期値と、前記認可サーバから送信される更新用乱数とに基づき、前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、付記１４又は１５に記載のトークン保護方法。
【０１５０】
（付記１７）
前記認可サーバは、前記リフレッシュトークンのハッシュ値と、前記リフレッシュトークンのインデックスを前記クライアントから受信し、
前記インデックスからリフレッシュトークンを特定し、
前記特定したリフレッシュトークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、新しいアクセストークンを生成し、
前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記１４乃至１６のいずれか一に記載のトークン保護方法。
【０１５１】
（付記１８）
前記認可サーバは、前記リフレッシュトークンのハッシュ値を前記クライアントから受信し、
受信した前記ハッシュ値を、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、新しいアクセストークンを生成し、
前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、付記１４乃至１７のいずれか一に記載のトークン保護方法。
【０１５２】
（付記１９）
前記認可サーバは、
前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバに行うリソースサーバから、前記アクセストークンのハッシュ値と前記アクセストークンのインデックスを受信し、
前記インデックスからアクセストークンを特定し、前記特定したアクセストークンのハッシュ値を生成し、
生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
２つのハッシュ値が互いに一致する場合、
認可情報を生成して前記リソースサーバに送信し、
前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする付記１５に記載のトークン保護方法。
【０１５３】
（付記２０）
前記認可サーバは、
前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバに行うリソースサーバから、前記アクセストークンの前記ハッシュ値を受信し、
受信した前記ハッシュ値を、トークンのハッシュ値を記憶したメモリを参照して検索し、
前記ハッシュ値が検索された場合、
認可情報を生成して前記リソースサーバに送信し、
さらに前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする付記１５に記載のトークン保護方法。  
【０１５４】
（付記２１）
保護されたリソースを保持し、クライアントからのアクセストークンを用いた前記保護されたリソースへのリクエストを受理しリスポンスを返すリソースサーバ装置であって、
前記クライアントからアクセストークンのハッシュ値を受信する第１の手段と、
前記アクセストークンのハッシュ値を認可サーバに問い合わせる第２の手段と、
前記認可サーバからの認可情報に基づいて、前記クライアントにサービスを提供する第３の手段と、
を備えた、こと特徴とする、リソースサーバ装置。
【０１５５】
（付記２２）
リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置のプロセッサに、
少なくともトークンのハッシュ値を受信する処理と、
前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する処理と、
前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する処理と、を実行させるプログラム。
【０１５６】
（付記２３）
リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置のプロセッサに、
少なくともトークンのハッシュ値を受信する処理と、
前記ハッシュ値に基づき、前記ハッシュ値に対応するトークンを検証する処理と、
前記検証の結果、前記ハッシュ値に対応するトークンが正しいトークンである場合、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する処理を実行させるプログラムを記録したコンピュータ読み出し可能な非一時的（non-transitory）記録媒体。
【０１５７】
（付記２４）
リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアント装置のプロセッサに、
認可サーバ装置から発行されたトークンのハッシュ値を生成する処理と、
前記ハッシュ値を前記認可サーバに送信する処理と、
前記認可サーバから送信されたトークンの更新用乱数を受信し、前記トークンを、前記更新用乱数を用いて更新する処理と、を実行させるプログラム。
【０１５８】
（付記２５）
リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアントシステムのプロセッサに、
認可サーバ装置から発行されたトークンのハッシュ値を生成する処理と、
前記ハッシュ値を前記認可サーバに送信する処理と、
前記認可サーバから送信されたトークンの更新用乱数を受信し、前記トークンを、前記更新用乱数を用いて更新する処理を実行させるプログラムを記録したコンピュータ読み出し可能な非一時的（non-transitory）記録媒体。
【０１５９】
（付記２６）
保護されたリソースを保持し、クライアントからのアクセストークンを用いた前記保護されたリソースへのリクエストを受理しリスポンスを返すリソースサーバ装置のプロセッサに、
前記クライアントからアクセストークンのハッシュ値を受信する処理と、
前記アクセストークンのハッシュ値を認可サーバに問い合わせる処理と、
前記認可サーバからの認可情報に基づいて、前記クライアントにサービスを提供する処理、を実行させるプログラム。
【０１６０】
（付記２７）
保護されたリソースを保持し、クライアントからのアクセストークンを用いた前記保護されたリソースへのリクエストを受理しリスポンスを返すリソースサーバ装置のプロセッサに、
前記クライアントからアクセストークンのハッシュ値を受信する処理と、
前記アクセストークンのハッシュ値を認可サーバに問い合わせる処理と、
前記認可サーバからの認可情報に基づいて、前記クライアントにサービスを提供する処理、を実行させるプログラムを記録したコンピュータ読み出し可能な非一時的（non-transitory）記録媒体。
【符号の説明】
【０１６１】
１０  リソースオーナー（ユーザ）
１１  スマートフォン（移動機）
１２  PC
２０  ユーザエージェント
３０  クライアント
４０  認可サーバ
５０  リソースサーバ
１００  コンピュータ装置
１０１  プロセッサ
１０２  メモリ
１０３  NIC（ネットワークインタフェースカード、ネットワークインタフェースコントローラ）
３０１、４０１  トークン制御部
３０２、４０２  トークン管理部
３０３、４０３  ハッシュ値生成部
３０４、４０６  トークン更新部
４０４  ハッシュ値比較部
４０５  更新用乱数生成部
４０７  ハッシュ値検索部
【図１】
2020166066.tif 000003
【図２】
2020166066.tif 000004
【図３】
2020166066.tif 000005
【図４】
2020166066.tif 000006
【図５】
2020166066.tif 000007
【図６】
2020166066.tif 000008
【図７】
2020166066.tif 000009
【図８】
2020166066.tif 000010
【図９】
2020166066.tif 000011
【図１０】
2020166066.tif 000012
【図１１】
2020166066.tif 000013
【図１２】
2020166066.tif 000014
【国際調査報告】
2020166066.tif 000015
2020166066.tif 000016
2020166066.tif 000017
2020166066.tif 000018