JP7226457B2 - トークン保護方法、認可システム、装置、及び、プログラム記録媒体 - Google Patents

トークン保護方法、認可システム、装置、及び、プログラム記録媒体 Download PDF

Info

Publication number
JP7226457B2
JP7226457B2 JP2020572042A JP2020572042A JP7226457B2 JP 7226457 B2 JP7226457 B2 JP 7226457B2 JP 2020572042 A JP2020572042 A JP 2020572042A JP 2020572042 A JP2020572042 A JP 2020572042A JP 7226457 B2 JP7226457 B2 JP 7226457B2
Authority
JP
Japan
Prior art keywords
token
hash value
client
refresh
authorization server
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
JP2020572042A
Other languages
English (en)
Other versions
JPWO2020166066A1 (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.)
NEC Corp
Original Assignee
NEC Corp
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 NEC Corp filed Critical NEC Corp
Publication of JPWO2020166066A1 publication Critical patent/JPWO2020166066A1/ja
Application granted granted Critical
Publication of JP7226457B2 publication Critical patent/JP7226457B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Storage Device Security (AREA)

Description

本発明は、トークン保護方法、認可システム、装置、及び、プログラム記録媒体に関する。
企業等で保有するシステムやデータを呼び出すためのインターフェースは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（ネットワークインタフェースカード、ネットワークインタフェースコントローラ）
３０１、４０１ トークン制御部
３０２、４０２ トークン管理部
３０３、４０３ ハッシュ値生成部
３０４、４０６ トークン更新部
４０４ ハッシュ値比較部
４０５ 更新用乱数生成部
４０７ ハッシュ値検索部

Claims (10)

  1. ユーザの情報を保有するリソースサーバと、
    前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、
    前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、
    を備え、
    前記クライアントは、前記リフレッシュトークンの使用時に、前記認可サーバに対して前記リフレッシュトークンのハッシュ値と前記リフレッシュトークンのトークンID(識別子)を送信し、
    前記認可サーバは、前記トークンIDから前記リフレッシュトークンを特定し、特定した前記リフレッシュトークンが有効である場合、特定した前記リフレッシュトークンのハッシュ値と、受信した前記ハッシュ値との一致が検証されると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
    前記クライアントは、前記認可サーバからの前記更新用乱数を用いて、前記クライアントが保持する前記リフレッシュトークンを更新し、
    前記認可サーバは、生成した前記更新用乱数を用いて、前記認可サーバが保持する前記トークンIDに対応する前記リフレッシュトークンを更新する、ことを特徴とする、認可システム。
  2. 前記クライアントは、前記アクセストークン使用時に、前記リソースサーバに対して、前記アクセストークンのハッシュ値と前記アクセストークンのトークンIDを送信し、
    前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値と前記トークンIDを受信すると、前記トークンIDからアクセストークンを特定し、特定した前記アクセストークンが有効である場合、特定した前記アクセストークンのハッシュ値と受信した前記ハッシュ値との一致が検証されると、前記アクセストークンの更新用乱数を生成して前記クライアントに送信し、
    前記クライアント及び前記認可サーバは、前記更新用乱数を用いてそれぞれが保持する前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項１に記載の認可システム。
  3. 予め前記認可サーバと前記クライアントで共有している初期値と、前記認可サーバから送信される更新用乱数とに基づき、前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項１又は２に記載の認可システム。
  4. リソースサーバへのアクセスの認可がリソースオーナーから与えられたクライアントにトークンを発行する認可サーバ装置であって、
    少なくともトークンのハッシュ値とトークンID(識別子)を受信する第１の手段と、
    前記トークンIDからトークンを特定し、前記特定したトークンのハッシュ値と受信した前記ハッシュ値とが一致するか検証する第２の手段と、
    前記検証の結果、前記特定したトークンのハッシュ値と受信した前記ハッシュ値の一致が検証されると、トークン更新用乱数を生成し、前記トークン更新用乱数を前記クライアントに送信する第３の手段と、
    を備えた、ことを特徴とする、認可サーバ装置。
  5. 前記トークンはリフレッシュトークンであり、
    前記第１の手段は、
    前記リフレッシュトークンのハッシュ値と、前記リフレッシュトークンのトークンIDを前記クライアントから受信し、
    前記第２の手段は、
    前記トークンIDからリフレッシュトークンを特定し、
    前記特定したリフレッシュトークンのハッシュ値を生成し、
    生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
    ２つのハッシュ値が互いに一致する場合、新しいアクセストークンを生成する第４の手段を備え、
    前記第３の手段は、
    前記新しいアクセストークンと、前記リフレッシュトークンの更新用乱数とを前記クライアントに送信する、ことを特徴とする、請求項４に記載の認可サーバ装置。
  6. 前記トークンは、アクセストークンであり、
    前記第１の手段は、
    前記クライアントから受信したアクセストークンのハッシュ値の問い合わせを前記認可サーバ装置に行うリソースサーバから、前記アクセストークンのハッシュ値と前記アクセストークンのトークンIDを受信し、
    前記第２の手段は、
    前記トークンIDからアクセストークンを特定し、前記特定したアクセストークンのハッシュ値を生成し、
    生成した前記ハッシュ値と、受信した前記ハッシュ値とを比較し、
    ２つのハッシュ値が互いに一致する場合、認可情報を生成して前記リソースサーバに送信する第４の手段を備え、
    前記２つのハッシュ値が互いに一致する場合、前記第３の手段は、
    前記更新用乱数を生成し、前記クライアントに送信する、ことを特徴とする、請求項５に記載の認可サーバ装置。
  7. リソースオーナーの許可を得てリソースオーナーの代理として保護されたリソースに対するアクセスを行うクライアント装置であって、
    認可サーバから発行されたトークンのハッシュ値を生成する第１の手段と、
    前記ハッシュ値とトークンID（識別子）を前記認可サーバに送信する第２の手段と、
    前記ハッシュ値と前記トークンIDを受信した前記認可サーバで前記トークンの検証を行った結果、前記認可サーバで生成された前記トークンの更新用乱数を前記認可サーバから受信し、前記クライアント装置が保持する前記トークンを、前記更新用乱数を用いて更新する第３の手段と、
    を備えた、ことを特徴とする、クライアント装置。
  8. リソースオーナーの許可を得てリソースオーナーの代理としてリソースサーバの保護されたリソースに対するアクセスを行うクライアントが、リフレッシュトークンの使用時に、前記リフレッシュトークンのハッシュ値と前記リフレッシュトークンのトークンID(識別子)を認可サーバに送信し、
    前記認可サーバは、前記トークンIDから前記リフレッシュトークンを特定し、特定した前記リフレッシュトークンが有効である場合、特定した前記リフレッシュトークンのハッシュ値と、受信した前記ハッシュ値との一致が検証されると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、
    前記クライアントは、前記認可サーバからの前記更新用乱数を用いて、前記クライアントが保持する前記リフレッシュトークンを更新し、
    前記認可サーバも、生成した前記更新用乱数を用いて、前記認可サーバが保持する前記トークンIDに対応する前記リフレッシュトークンを更新する、ことを特徴とする、トークン保護方法。
  9. 前記クライアントは、アクセストークン使用時に、前記リソースサーバに対して、前記アクセストークンのハッシュ値と前記アクセストークンのトークンIDを送信し、
    前記認可サーバは、前記リソースサーバから、前記アクセストークンの前記ハッシュ値と前記トークンIDを受信すると、前記トークンIDからアクセストークンを特定し、特定した前記アクセストークンが有効である場合、特定した前記アクセストークンのハッシュ値と受信した前記ハッシュ値との一致が検証されると、前記アクセストークンの更新用乱数を生成して前記クライアントに送信し、
    前記クライアント及び前記認可サーバは、それぞれの前記アクセストークン及び前記リフレッシュトークンを更新する、ことを特徴とする、請求項８に記載のトークン保護方法。
  10. リソースオーナーからの認可許可が成功した場合、クライアントにトークンを発行する認可サーバ装置のプロセッサに、
    前記トークンのハッシュ値と前記トークンのトークンID(識別子)を受信する処理と、
    前記トークンIDから前記トークンを特定し、特定した前記トークンが有効である場合、特定した前記トークンのハッシュ値と、受信した前記ハッシュ値とが一致するか検証する処理と、
    特定した前記トークンのハッシュ値と、受信した前記ハッシュ値との一致が検証されると、前記トークンの更新用乱数を生成し、前記トークンの更新用乱数をクライアントに送信する処理と、
    を実行させるプログラムを記録したプログラム記録媒体。
JP2020572042A 2019-02-15 2019-02-15 トークン保護方法、認可システム、装置、及び、プログラム記録媒体 Active JP7226457B2 (ja)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/005578 WO2020166066A1 (ja) 2019-02-15 2019-02-15 トークン保護方法、認可システム、装置、及び、プログラム記録媒体

Publications (2)

Publication Number Publication Date
JPWO2020166066A1 JPWO2020166066A1 (ja) 2021-12-09
JP7226457B2 true JP7226457B2 (ja) 2023-02-21

Family

ID=72044417

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020572042A Active JP7226457B2 (ja) 2019-02-15 2019-02-15 トークン保護方法、認可システム、装置、及び、プログラム記録媒体

Country Status (2)

Country Link
JP (1) JP7226457B2 (ja)
WO (1) WO2020166066A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113542235B (zh) * 2021-06-28 2023-04-07 上海浦东发展银行股份有限公司 一种基于令牌互信机制的安全互访方法
US11943370B2 (en) * 2021-11-10 2024-03-26 International Business Machines Corporation Using device-bound credentials for enhanced security of authentication in native applications

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002259343A (ja) 2001-02-27 2002-09-13 Nec Soft Ltd クライアント認証とサービス提供の方式及び方法
JP2004070463A (ja) 2002-08-02 2004-03-04 Sony Corp 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム
JP2004310327A (ja) 2003-04-04 2004-11-04 Bank Of Tokyo-Mitsubishi Ltd ユーザ認証装置、端末装置及びプログラム
US20090235349A1 (en) 2008-03-12 2009-09-17 Intuit Inc. Method and apparatus for securely invoking a rest api
JP2010113462A (ja) 2008-11-05 2010-05-20 Yahoo Japan Corp 情報管理装置、情報処理システム、情報管理方法及び情報管理プログラム

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002259343A (ja) 2001-02-27 2002-09-13 Nec Soft Ltd クライアント認証とサービス提供の方式及び方法
JP2004070463A (ja) 2002-08-02 2004-03-04 Sony Corp 情報処理システムおよび方法、情報処理装置および方法、記録媒体、並びにプログラム
JP2004310327A (ja) 2003-04-04 2004-11-04 Bank Of Tokyo-Mitsubishi Ltd ユーザ認証装置、端末装置及びプログラム
US20090235349A1 (en) 2008-03-12 2009-09-17 Intuit Inc. Method and apparatus for securely invoking a rest api
JP2010113462A (ja) 2008-11-05 2010-05-20 Yahoo Japan Corp 情報管理装置、情報処理システム、情報管理方法及び情報管理プログラム

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HARDT, D.，The OAuth 2.0 Authorization Framework，Request for Comments，6749，[online]，2012年10月，pp.1-76，URL:https://tools.ietf.org/html/rfc6749，[2022年6月日検索]
LATINOV, L.，How to implement secure REST API authentication over HTTP，[online]，2018年03月05日，URL:https://automationrhapsody.com/implement-secure-rest-apiauthentication- http

Also Published As

Publication number Publication date
WO2020166066A1 (ja) 2020-08-20
JPWO2020166066A1 (ja) 2021-12-09

Similar Documents

Publication Publication Date Title
JP6643373B2 (ja) 情報処理システムと、その制御方法とプログラム
US10003587B2 (en) Authority transfer system, method, and authentication server system by determining whether endpoints are in same or in different web domain
US7774611B2 (en) Enforcing file authorization access
EP3585032B1 (en) Data security service
JP4674044B2 (ja) クライアントが許可を検証できるキー管理プロトコルを設けるためのシステムおよび方法
KR101534890B1 (ko) 신뢰된 장치별 인증
US8532620B2 (en) Trusted mobile device based security
TWI288552B (en) Method for implementing new password and computer readable medium for performing the method
US9762567B2 (en) Wireless communication of a user identifier and encrypted time-sensitive data
WO2019239591A1 (ja) 認証システム、認証方法、アプリケーション提供装置、認証装置、及び認証用プログラム
US20180062863A1 (en) Method and system for facilitating authentication
CN109981665B (zh) 资源提供方法及装置、资源访问方法及装置和系统
CN111901346A (zh) 一种身份认证系统
EP2414983B1 (en) Secure Data System
EP3513539A1 (en) User sign-in and authentication without passwords
JP7226457B2 (ja) トークン保護方法、認可システム、装置、及び、プログラム記録媒体
US20130091355A1 (en) Techniques to Prevent Mapping of Internal Services in a Federated Environment
RU2698424C1 (ru) Способ управления авторизацией
JP6712707B2 (ja) 複数のサービスシステムを制御するサーバシステム及び方法
JPH05298174A (ja) 遠隔ファイルアクセスシステム
WO2019234801A1 (ja) サービス提供システム及びサービス提供方法
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
CN114765551A (zh) 基于区块链的sdp访问控制方法及装置
KR102048534B1 (ko) 인증 방법 및 시스템
JP2002328905A (ja) クライアント認証方法及び認証装置並びにプログラム及び記録媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210811

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220705

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220815

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: 20230110

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230123

R151 Written notification of patent or utility model registration

Ref document number: 7226457

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151