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

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

Info

Publication number
WO2020166066A1
WO2020166066A1 PCT/JP2019/005578 JP2019005578W WO2020166066A1 WO 2020166066 A1 WO2020166066 A1 WO 2020166066A1 JP 2019005578 W JP2019005578 W JP 2019005578W WO 2020166066 A1 WO2020166066 A1 WO 2020166066A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
client
hash value
authorization
authorization server
Prior art date
Application number
PCT/JP2019/005578
Other languages
English (en)
French (fr)
Inventor
利彦 岡村
Original Assignee
日本電気株式会社
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 日本電気株式会社 filed Critical 日本電気株式会社
Priority to JP2020572042A priority Critical patent/JP7226457B2/ja
Priority to PCT/JP2019/005578 priority patent/WO2020166066A1/ja
Publication of WO2020166066A1 publication Critical patent/WO2020166066A1/ja

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

Definitions

  • the present invention relates to a token protection method, an authorization system, a device, and a program recording medium.
  • API Application Programming Interface
  • PFM Personal Finance Management
  • PFM operators store IDs and passwords from users and access the services of financial institutions to collect information.
  • the PFM business operator can realize the service without keeping the user's authentication information.
  • PSD2 Payment Service Directive 2
  • the payment service directive PSD2 Payment Service Directive 2
  • financial institutions became obliged to support open APIs (enforced from 2018). This is to prevent the financial institution from enclosing the customer information so that the user can utilize his/her own data.
  • the Open API policy has been announced in the Financial Council's "Japan Revitalization Strategy 2016-Toward the Fourth Industrial Revolution-" (approved by the Cabinet on June 2, 2016) and measures are being taken.
  • Non-Patent Document 1 for the specifications of OAuth 2.0.
  • Non-Patent Document 2 is referred to.
  • FIG. 1 is a diagram based on an entity of RFC 6767 (framework of OAuth 2.0) of Non-Patent Document 2.
  • Resource owner 10 is an entity that allows access to protected resources. When a resource owner is a person, it is called an end user (user).
  • the user agent 20 is a browser or the like of a terminal (smartphone 11 or PC (Personal Computer) 12) used by the resource owner 10.
  • the client 30 is an application (application provided by an intermediary company) that requests the resource on behalf of the resource owner 10 with the permission of the resource owner 10. ..
  • the authorization server 40 issues an access token to the client 30 after the authentication of the resource owner 10 and the acquisition of the authorization from the resource owner 10 are successful.
  • the resource server 50 is a server that holds protected resources (protected contents: account information, transfer function, etc.) and can receive the protected request using an access token from a client and return a response. ..
  • the access token is a credential for accessing the protected resource (the access token is a string representing an authorization issued to the client 30 and is usually opaque to the client 30). (Random character string).
  • the PFM operator corresponds to the client 30, the authorization server 40, and the resource server 50 by a financial institution such as a bank.
  • OAuth2.0 separates the authorization server from the resource server, and gives authorization information to the client as an access token with limited authority, thus achieving both security by centralized authorization and authorization and convenience for suppressing the opportunity for the user to perform authorization processing. Aim to do.
  • OAuth2.0 is ⁇ Authentication code flow that enables client authentication, -Since it is difficult for the client to securely store the authentication information, an implicit flow that does not perform client authentication, Can be roughly divided into
  • the authorization code flow is often applied when the operator's web service is the client, and the implicit flow is often applied when the terminal application is the client.
  • FIG. 2 is a diagram based on Chart 2 (Outline (Conceptual Diagram) of Processing Flow in Authorization Code Method) of Non-Patent Document 2.
  • HTTP Hypertext Transfer Protocol
  • Authorization endpoint is the HTTP endpoint of authorization server and performs end user authentication and authorization acquisition.
  • the authorization server 40 confirms with the resource owner 10 that the client 30 is allowed to access the resource server 50 (grant authorization) via the screen of the user agent (browser) 20. If the resource owner 10 agrees with it, the resource owner 10 transmits a notice of approval (S102).
  • the authorization server 40 issues the authorization code storing the data necessary for issuing the access token to the client 30 via the user agent 20 (S103).
  • the authorization server 40 sends the authorization code by HTTP response.
  • TLS Transport Layer Security
  • HTTP messages placed in the TCP (Transport Control Protocol) payload of HTTP packets are encrypted.
  • the encrypted communication using TLS or the like is once decrypted by the user agent (browser) 20 that has received the authorization code in step S103.
  • the client 30 transmits the authentication information (client secret) held by the client 30 to the authorization server 40, and requests the issuance of the access token (S104).
  • HTTP request (request method is POST) is used for requesting access token issuance.
  • client authentication is performed, in case of HTTP basic authentication, client password is set in the parameter in Authorization header of HTTP request, or client identifier and client secret parameter are added.
  • the authorization server 40 verifies the authorization code and performs client authentication using the authentication information (client secret) (S105).
  • the authorization server 40 issues an access token and a refresh token and sends them to the client 30 (S106).
  • the access token and refresh token are sent by HTTP response to HTTP request.
  • the number of valid seconds of the access token is also arbitrarily set in the HTTP response.
  • the refresh token is a token (character string) for the client to obtain a new access token of the resource owner.
  • the client 30 transmits an access token to the resource server 50 and uses the access token to access the resource server 50 (S107). Data of the resource owner is transferred from the resource server 50 to the client 30.
  • a part that performs authentication and authorization for a user (authorization endpoint) and a part that issues a token (token endpoint) are separated.
  • the authorization server 40 issues an access token for an authorization code that is valid for client authentication.
  • the client authentication method called Basic authentication
  • the client 30 performs authentication by sending secret information shared in advance with the authorization server 40.
  • the client 30 can send a refresh token to the authorization server 40 and obtain a new access token.
  • the refresh token is used only between the client 30 and the authorization server 40, the attack opportunity is considered to be less than that of the access token involving the resource server. Therefore, the expiration date is set to be long.
  • the authorization server 40 If the client authentication information is OK and the refresh token is valid, the authorization server 40 newly generates an access token and a refresh token (S202).
  • the authorization server 40 sends the access token and the refresh token to the client 30 (S203).
  • the client 30 newly uses the access token to access the resource server 50 (S204).
  • FIG. 4 is a diagram schematically illustrating a general configuration of the OAuth 2.0 authorization system.
  • the token control unit 401 of the authorization server 40 receives the result of the authentication and authorization, and executes generation and verification of the authorization code, access token, and refresh token.
  • the access token and refresh token can be configured to include a random number component of sufficient length so that it is difficult for an attacker to guess. Therefore, the token control unit 401 of the authorization server 40 has a random number generation function.
  • the token control unit 401 of the authorization server 40 generally also has a hash function for issuing a token with a digital signature and a public key encryption function.
  • the token management unit 402 includes a storage device such as a semiconductor memory or an HDD (Hard Disk Drive), and the authorization code, access token, and refresh token, information for identifying a token, authorization of random number components, access range, expiration date, and the like. Holds and manages information.
  • a storage device such as a semiconductor memory or an HDD (Hard Disk Drive)
  • the authorization code, access token, and refresh token information for identifying a token, authorization of random number components, access range, expiration date, and the like. Holds and manages information.
  • the authorization server 40 is compatible with a plurality of clients 30, and it is preferable to implement a data management method for managing the token identification information and authorization information in a table for each client 30 for efficient and reliable management. To be done.
  • the client 30 also includes a token control unit 301, and the token management unit 302 manages the access token and the refresh token received from the authorization server 40.
  • the token control unit 301 uses the access token to access the resource server 50 in response to a user's or application's request, and uses a refresh token to obtain a new access token and a refresh token from the authorization server 40 as necessary. To do.
  • the token control unit 301 has a function for verifying the token with a digital signature of the authorization server 40, and generally has a hash function and a public key encryption function.
  • FIG. 5 is a diagram showing an example of the exchange of information when the access token inquiry process is executed.
  • the resource server 50 may be configured to inquire of the authorization server 40 about the access token and obtain the status and the permission information of the access token.
  • the related technology mentioned above has a problem regarding the security related to the attacker taking the token.
  • TLS Transport Layer Security
  • the malware is temporarily present until the malware is detected, and there is a risk that the token information as well as the authentication information is stolen from the client.
  • the present invention was created on the basis of the recognition of the above-mentioned problems, and the purpose thereof is to provide a system, an apparatus, and a device that can avoid the abuse of the token even if the token is stolen.
  • a method and a program recording medium are provided.
  • a resource server that holds user information
  • a client that accesses the resource server to provide a service to the user, and a user when accessing the resource server to the client
  • an authorization server for issuing a refresh token for reissuing the access token, wherein the client refreshes the authorization server when the refresh token is used.
  • an authorization server device that issues a token to a client provided by a resource owner to authorize access to a resource server, wherein the authorization server device receives at least a hash value of the token.
  • a client device that accesses a protected resource on behalf of the resource owner with the permission of the resource owner, and generates a hash value of the token issued from the authorization server.
  • First means second means for transmitting the hash value to the authorization server, and a random number for updating the token transmitted from the authorization server, and using the random number for updating the token.
  • a third means for updating and a client device are provided.
  • a client which obtains the permission of the resource owner and accesses the protected resource of the resource server on behalf of the resource owner, uses the hash value of the refresh token when the refresh token is used. Send it to the authorization server, When the authorization server receives the hash value of the refresh token, it generates a random number for updating the refresh token and sends it to the client, A token protection method is provided in which the client updates the refresh token using the update random number.
  • a processor of an authorization server device that issues a token to a client given authorization from a resource owner to access a resource server, At least the process of receiving the hash value of the token, A process of verifying a token corresponding to the hash value based on the hash value; As a result of the verification, when the token corresponding to the hash value is a correct token, a program for generating a random number for updating the token and transmitting the random number for updating the token to the client, and A computer-readable recording medium in which a program is recorded (semiconductor memory (for example, RAM (Random Access Memory), ROM (Read Only Memory), or EERROM (Electrically Erasable and Programmable ROM)), semiconductor storage, HDD (Hard Disk Drive) ), CD (Compact Disc), DVD (Digital Versatile Disc), and other non-transitory computer readable recording media.
  • semiconductor memory for example, RAM (Random Access Memory), ROM (Read Only Memory), or EERROM (Electrically
  • FIG. 5 illustrates another exemplary embodiment of the present invention.
  • FIG. 6 is a diagram illustrating yet another exemplary embodiment of the present invention. It is a figure explaining a computer implementation example as an exemplary embodiment of the present invention.
  • the client when a client uses a refresh token, the client sends the hash value of the refresh token to the authorization server instead of the refresh token.
  • the authorization server Upon receiving the hash value of the refresh token, the authorization server generates a random number for updating the refresh token and sends it to the client.
  • the client updates the refresh token using the update random number transmitted from the authorization server. Even if the attacker succeeds in wiretapping the fresh token at some point between the authorization server and the client, the attacker obtains only the hash value. Because of this, the original refresh token is unknown. Therefore, it is difficult to update the refresh token.
  • the attacker does not succeed in updating the refresh token. Then, even if the attacker uses the previous token, the authorization server determines that the token is invalid.
  • the resource server 50 inquires the authorization server 40 about the authorization information of the access token
  • it can be considered in the same manner as the refresh token update between the authorization server 40 and the client 30.
  • the client 30 sends the hash value of the access token to the resource server 50
  • the resource server 50 inquires of the authorization server 40 about the authorization information using the hash value of the access token. It becomes possible to raise.
  • FIG. 6 is a diagram illustrating an exemplary embodiment.
  • FIG. 6 schematically illustrates the characteristic functional portions of the exemplary embodiment in the token control unit 301 of the client 30 and the token control unit 401 of the authorization server 40 in FIG.
  • the arrow between the client 30 and the resource server 50 indicates an example of signal transmission from the client 30 to the resource server 50, and the client 30 and the resource server 50 are connected only in one direction. It does not mean that.
  • the description of the same parts as those in FIG. 4 will be omitted.
  • the token control unit 301 of the client 30 includes a hash value generation unit 303 and a token update unit 304.
  • the hash value generation unit 303 generates a hash value of the token and transmits the hash value and the token index (token ID (Identifier)) to the authorization server 40.
  • the token updating unit 304 receives the update random number of the token transmitted from the authorization server 40, and uses the update random number to hold the token in the client 30 (the client 30 transmits the hash value to the authorization server 40. Token) that you have updated.
  • the token control unit 401 of the authorization server 40 includes a hash value generation unit 403, a hash value comparison unit 404, an update random number generation unit 405, and a token update unit 406.
  • the hash value generation unit 403 receives the hash value of the token and the index of the token via a NIC (Network Interface Card) not shown, identifies the token corresponding to the index, and then hash the identified token. Generate a value.
  • NIC Network Interface Card
  • the hash value comparison unit 404 compares the hash value of the token specified from the index with the hash value received from the client 30.
  • the update random number generation unit 405 When the two hash values match as a result of the comparison in the hash value comparison unit 404, the update random number generation unit 405 generates a token update random number, and the update random number is sent to the client via a NIC (not shown). Send to 30.
  • the token update unit 406 updates the token corresponding to the index using the generated update random number.
  • the authorization server 40 may receive the hash value of the token and the index of the token from the client 30.
  • the token is a refresh token.
  • the token control unit 401 of the authorization server 40 may generate a new access token and transmit the new access token to the client 30 together with the update random number.
  • the token control unit 401 of the authorization server 40 may be configured to include a hash value search unit that searches the received hash value (this configuration example will be described later with reference to FIG. 11).
  • the client 30 may send the hash value of the token to the authorization server 40 (it is not necessary for the client 30 to send the token index to the authorization server 40).
  • the token itself but the token whose hash value is transmitted is not limited to the refresh token, and may be an access token.
  • the authorization server 40 uses the hash value from the resource server 50 and the index of the access token. May be received.
  • the hash value generation unit 303 of the token control unit 301 of the client 30 generates a hash value of the access token and sends the hash value of the access token and the index (token ID) of the access token to the resource server 50.
  • the resource server 50 transmits the hash value of the access token and the index of the access token to the authorization server 40.
  • the authorization server 40 receives the hash value of the access token and the index of the access token by the NIC (not shown), the hash value generation unit 404 identifies the access token corresponding to the index, and the identified access token is valid. If so, a hash value of the specified access token is generated.
  • the hash value comparison unit 404 compares the generated hash value with the hash value received from the resource server 50.
  • the resource server 50 notifies the authorization server 40 of the access token.
  • the hash value of the access token may be transmitted to the authorization server 40 (the transmission of the index of the access token is unnecessary).
  • the update random number generation unit 405 of the authorization server 40 generates a token update random number when the two hash values match as a result of the comparison by the hash value comparison unit 404.
  • the update random number generation unit 405 transmits the generated update random number to the client 30 via the NIC.
  • the token updating unit 304 of the client 30 receives the token updating random number transmitted from the authorization server 40, and updates the token held by the client 30 using the updating random number.
  • the authorization server 40 may assign a token ID that is a uniquely identifiable index to each of the access token and the refresh token, and make the token ID a part of the token.
  • the client 30 sends the token ID of the refresh token and the client authentication information to the authorization server 40 (S302).
  • the authorization server 40 identifies the refresh token from the token ID when the authentication is OK as a result of authenticating the client authentication information. If the refresh token is valid, the authorization server 40 generates the hash value (S303).
  • the authorization server 40 checks whether the hash value received from the client 30 in step S302 and the hash value generated by the authorization server 40 in step S303 match each other. If they match, the authorization server 40 generates a refresh token update random number and a new access token (S304).
  • the authorization server 40 transmits a new access token and a refresh token update random number to the client (S305).
  • the authorization server 40 updates the refresh token specified by the token ID with the update random number (S306). Further, the client 30 updates the refresh token for which the hash value was created in step S301 with the update random number received from the authorization server 40 (S307).
  • the generation of the update random number can be realized by the token control unit 401 of the authorization server 40 using a random number generation function used for generating an access token or a refresh token.
  • the update of the refresh token by the update random number may be realized by a function provided in advance in the token control unit 401 of the authorization server 40, such as an addition (exclusive OR) operation or a hash function.
  • the refresh token update flow can be executed at any timing, not only when the access token has expired, but also without issuing a new access token.
  • the above-mentioned refresh token update flow may be executed when using the access token.
  • the resource server 50 inquires the authorization server 40 about the authorization information of the access token, the same processing as the above refresh token update flow can be applied to the access token. ..
  • the access token is generally set to have a short expiration date, but by introducing a renewal flow, it is possible to further increase the resistance to misuse, etc. due to the theft of the token.
  • FIG. 8 is a diagram illustrating a processing flow of an access token with update as another embodiment of the present invention.
  • FIG. 9 is a diagram illustrating transmission/reception of signals between the client 30, the authorization server 40, and the resource server 50 in the processing flow of the access token with update.
  • An access token process with update according to another embodiment of the present invention will be described with reference to FIGS. 8 and 9.
  • the client 30 sends the generated hash value together with the token ID (index) of the access token to the resource server 50 (S402).
  • the resource server 50 sends the token ID (index) and hash value of the access token sent from the client 30 to the authorization server 40 to make an inquiry (S403).
  • the authorization server 40 identifies the access token from the token ID (index) inquired by the resource server 50, and confirms whether the access token is valid. If the access token is valid, the authorization server 40 generates a hash value of the access token and checks whether the hash value matches the hash value queried by the resource server 50. If the hash values match, the authorization server 40 generates authorization information (S404) and sends the authorization information to the resource server 50 (S405).
  • the resource server 50 provides the service to the client 30 based on the authorization information (S406).
  • the authorization server 40 generates a random number for updating the access token (S407).
  • the authorization server 40 transmits the update random number to the client 30 (S408).
  • the authorization server 40 updates the access token specified based on the token ID (index) with the update random number created in step S407 (S409).
  • the client 30 updates the access token for which the hash value was created in step S401 with the update random number received in step S408 (S410). In step S410, the client 30 may update the refresh token using the update random number.
  • FIG. 10 is a diagram illustrating the token initialization process.
  • the authorization server 40 generates a random number for token update (S501).
  • the authorization server 40 transmits the update random number to the client 30 (S502).
  • the authorization server 40 and the client 30 update the access token and the refresh token based on the shared initial information and the random number for update (S503, S504).
  • update random number will be generated for each of the access token and the refresh token, but by setting the initial information to be different for the access token and the refresh token, the update random number will be set to the access token and the refresh token. Can also be common.
  • the token specification has a token ID, a token random number component, and authorization information as elements.
  • Token ID can be configured to have authorization server name, client name, resource server name, token type (access token or refresh token), and serial number as elements.
  • Update of the token (update with update random number) can be realized by applying the token random number component while keeping the token ID and other information as it is (not updating).
  • the authorization information (provided to the resource server 50 from the authorization server 40 in S405 in FIGS. 8 and 9) includes the range of access to the resource server 50, the expiration date, and the like.
  • the client 30 can inquire the authorization server 40 each time without including these pieces of information in the token.
  • the token specification may be configured by only the token random number component without setting the token ID. Even in this case, the probability that the token IDs collide can be sufficiently reduced by taking a sufficiently large size (256 bits, etc.).
  • the authorization server 40 searches the received hash value so that the hash value transmitted in step S301 of FIG. 7 and step S401 of FIG. 8 can be searched at high speed.
  • the hash value search unit may be provided. According to the present embodiment, it is not necessary to send the index to the authorization server 40.
  • FIG. 11 is a diagram illustrating an authorization server 40 including a hash value search unit.
  • the one-way hash function one-way compression function
  • the inverse transformation (decoding) of the hash value is virtually impossible. Therefore, when the authorization server 40 issues the access token and the refresh token to the client 30 and when the access token and the refresh token are updated with the update random number, the hash value generation unit 403 changes the hash value of the token to the hash value.
  • the search unit 407 may be registered in a memory (table) (not shown). In this case, the hash value of the token and the token may be registered in the memory (table) in association with each other.
  • the hash value search unit 407 Upon receiving the hash value of the refresh token from the client 30, the hash value search unit 407 searches the memory (table), and when the hash value is found, the refresh token corresponding to the hash value received from the client 30 is correct. It is determined that the token is a token (a token issued by the authorization server 40 to the client 30 or a token updated by the random number for update provided by the authorization server 40). On the other hand, if the hash value is not found, the refresh token corresponding to the hash value received from the client 30 is incorrect (for example, the authorization server 40 has not issued the refresh token corresponding to the hash value to the client 30). To judge. According to this embodiment, in S302 of FIG. 7, it is not necessary to transmit the index from the client 30 to the authorization server 40.
  • the hash value search unit 407 receives the hash value of the access token from the resource server 50, it searches the memory (table), and when the hash value is found, determines that the access token is a correct token, The authorization information is transmitted to the resource server 50, and the token updating random number is further generated. In this case, it is not necessary to transmit the index in steps S402 and S403 of FIG.
  • the hash values of the refresh token and the access token may be generated using a cryptographically secure hash function such as SHA256 (Secure Hash Algorithm 256). Good.
  • SHA256 Secure Hash Algorithm 256
  • steps S409 and S410 the following two types of methods may be typically applied to the refresh token update processing.
  • the refresh token is represented by RT and the update random number is represented by r.
  • r has the same size as RT.
  • xor is a bitwise exclusive or.
  • r is an arbitrary length
  • is a concatenation of bit strings (concatenation)
  • H is a hash function
  • Trunc is a function that truncates the output of the hash function so that it has the same size as RT (Truncation).
  • the same function (SHA256 etc.) as in steps S301 and S401 may be applied.
  • public information for example, authorization server name and client name
  • secret information may be used in addition to RT and _r.
  • the secret information shared by the authorization server 40 and the client 30 in addition to using the client authentication information of OAuth2.0, it is possible to separately share a random number for this purpose between the authorization server 40 and the client 30.
  • the above token update process can also be used for initial setting of the token.
  • FIG. 12 is a diagram illustrating an example in which the client 30 and the authorization server 40 of the embodiment are mounted on the computer device 100, respectively.
  • the computer device 100 includes a processor (CPU (Central Processing Unit), data processing device) 101, a semiconductor memory (for example, RAM (RandomAccessMemory), ROM (ReadOnlyMemory), or RRPROM (ElectricallyErasableandProgrammableROM). ), USB (Universal Serial Bus), HDD (Hard Disk Drive), CD (Compact Disc), DVD (Digital Versatile Disc), and/or other memory 102 and NIC (Network Interface Card or Controller Interface) 103 Equipped with.
  • CPU Central Processing Unit
  • data processing device 101 for example, RAM (RandomAccessMemory), ROM (ReadOnlyMemory), or RRPROM (ElectricallyErasableandProgrammableROM).
  • USB Universal Serial Bus
  • HDD Hard Disk Drive
  • CD Compact Disc
  • DVD Digital Versatile Disc
  • NIC
  • the computer device 100 By executing the program (instruction group) stored in the memory 102 by the processor 101, the computer device 100 can be operated as the authorization server of the above-described embodiment.
  • the program of the client 30 application
  • the computer device 100 By holding the program of the client 30 (application) as the program held in the memory 102 and executing the program by the processor 101, the computer device 100 can be operated as the client system of the above-described embodiment.
  • an input/output device such as a display device or a printer may be connected to the computer device 100.
  • Non-Patent Documents 1 and 2 above are incorporated by reference in this document. Modifications and adjustments of the exemplary embodiments and examples are possible within the scope of the overall disclosure (including the claims) of the present invention and based on the basic technical concept thereof. Further, various combinations and selections of various disclosed elements (including each element of each claim, each element of each embodiment, each element of each drawing, and the like) are possible within the scope of the claims of the present invention. .. That is, it goes without saying that the present invention includes various variations and modifications that can be made by those skilled in the art according to the entire disclosure including the claims and the technical idea.
  • a resource server that holds user information A client for accessing the resource server to provide a service to a user, An access token indicating authorization information of a user when accessing the resource server to the client, and an authorization server issuing a refresh token for reissuing the access token, Equipped with The client sends a hash value of the refresh token to the authorization server when using the refresh token, When the authorization server receives the hash value of the refresh token, it generates a random number for updating the refresh token and sends it to the client, The authorization system, wherein the client updates the refresh token using the update random number.
  • the client transmits a hash value of the access token to the resource server when using the access token
  • the authorization server receives the hash value of the access token from the resource server
  • the authorization server generates a random number for update and transmits it to the client, 2.
  • the authorization system according to appendix 1, wherein the client and the authorization server update the access token and the refresh token held by the client using the update random number.
  • the authorization server receives a hash value of the refresh token and an index of the refresh token from the client, Identify the refresh token from the index, Generating a hash value of the specified refresh token, Comparing the generated hash value and the received hash value, If the two hash values match each other, generate a new access token,
  • the authorization system according to any one of appendices 1 to 3, wherein the new access token and a random number for updating the refresh token are transmitted to the client.
  • the authorization server receives the hash value of the refresh token from the client, The received hash value is searched by referring to the memory storing the hash value of the token, If the hash value is retrieved, generate a new access token, The authorization system according to any one of appendices 1 to 3, wherein the new access token and a random number for updating the refresh token are transmitted to the client.
  • the authorization server is From the resource server that queries the authorization server for the hash value of the access token received from the client, receives the hash value of the access token and the index of the access token, Specifying an access token from the index, generating a hash value of the specified access token, Comparing the generated hash value and the received hash value, If the two hash values match each other, Generate authorization information and send to the resource server, The authorization system according to appendix 2, wherein the update random number is generated and transmitted to the client.
  • the authorization server is From the resource server that queries the authorization server for the hash value of the access token received from the client, receives the hash value of the access token, The received hash value is searched by referring to the memory storing the hash value of the token, If the hash value is retrieved, Generate authorization information and send to the resource server, The authorization system according to appendix 2, further comprising generating the update random number and transmitting the random number to the client.
  • An authorization server device that issues a token to a client given authorization from a resource owner to access a resource server, A first means for receiving at least the hash value of the token; Second means for verifying a token based on the hash value; As a result of the verification, if the token corresponding to the hash value is a correct token, a third means for generating a random number for updating the token and transmitting the random number for updating the token to the client is provided.
  • An authorization server device characterized by the above.
  • the token is a refresh token
  • the first means receives a hash value of the refresh token and an index of the refresh token from the client
  • the second means identifies a refresh token from the index
  • Generating a hash value of the specified refresh token Comparing the generated hash value and the received hash value
  • the third means comprises means for generating a new access token when the two hash values match each other, and transmitting the new access token and a random number for updating the refresh token to the client.
  • the authorization server device according to Appendix 8, which is a feature.
  • the token is a refresh token
  • the first means receives a hash value of the refresh token from the client
  • the second means refers to the memory storing the hash value of the token to search
  • the authorization server device according to appendix 8, wherein the third means transmits the new access token and a random number for updating the refresh token to the client.
  • the token is an access token
  • the first means when the resource server device that has received the access token from the client makes a token inquiry to the authorization server device, a hash value of the access token and the access token from the resource server device. Received the index of The second means specifies an access token from the index, and if the access token is valid, generates a hash value of the specified access token, Comparing the generated hash value and the received hash value, A fourth means for generating authorization information and transmitting the authorization information to the resource server when the two hash values match each other; The authorization server device according to appendix 8, wherein the third means generates the update random number and transmits the update random number to the client when the two hash values match each other.
  • the token is an access token
  • the first means receives a hash value of the access token from the resource server device when the resource server device that has received the access token from the client makes a token inquiry to the authorization server device
  • the second means refers to the memory storing the hash value of the token to search
  • the authorization server device according to appendix 8, wherein the third means generates the update random number and transmits the update random number to the client.
  • a client device comprising:
  • a client that accesses the protected resource of the resource server on behalf of the resource owner with the permission of the resource owner sends a hash value of the refresh token to the authorization server when using the refresh token,
  • the authorization server receives the hash value of the refresh token, it generates a random number for updating the refresh token and sends it to the client,
  • the token protection method wherein the client updates the refresh token using the update random number.
  • the client transmits a hash value of the access token to the resource server when using the access token
  • the authorization server receives the hash value of the access token from the resource server
  • the authorization server generates a random number for update and transmits it to the client, 15.
  • the authorization server receives a hash value of the refresh token and an index of the refresh token from the client, Identify the refresh token from the index, Generating a hash value of the specified refresh token, Comparing the generated hash value and the received hash value, If the two hash values match each other, generate a new access token,
  • the token protection method according to any one of appendices 14 to 16, characterized in that the new access token and a random number for updating the refresh token are transmitted to the client.
  • the authorization server receives the hash value of the refresh token from the client, The received hash value is searched by referring to the memory storing the hash value of the token, If the hash value is retrieved, generate a new access token, 18.
  • the token protection method according to any one of appendices 14 to 17, characterized in that the new access token and the random number for updating the refresh token are transmitted to the client.
  • the authorization server is From a resource server that queries the authorization server for the hash value of the access token received from the client, receives the hash value of the access token and the index of the access token, Specifying an access token from the index, generating a hash value of the specified access token, Comparing the generated hash value and the received hash value, If the two hash values match each other, Generate authorization information and send to the resource server, 16.
  • the authorization server is From the resource server that queries the authorization server for the hash value of the access token received from the client, receives the hash value of the access token, The received hash value is searched by referring to the memory storing the hash value of the token, If the hash value is retrieved, Generate authorization information and send to the resource server, 16.
  • a resource server device which holds a protected resource, accepts a request to the protected resource using an access token from a client, and returns a response, First means for receiving a hash value of an access token from the client, Second means for inquiring the authorization server for the hash value of the access token; Third means for providing a service to the client based on the authorization information from the authorization server;
  • a resource server device comprising:

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)

Abstract

本発明は、仮にトークンが窃取された場合であっても、該トークンが悪用されることを回避可能とする。認可システムは、ユーザの情報を保有するリソースサーバと、前記リソースサーバにアクセスしてユーザにサービスを提供するクライアントと、前記クライアントに対して前記リソースサーバにアクセスする際のユーザの認可情報を示すアクセストークン、及び、前記アクセストークンを再発行するためのリフレッシュトークンを発行する認可サーバと、を備え、前記クライアントは前記リフレッシュトークンの使用時に前記リフレッシュトークンのハッシュ値を前記認可サーバに送信し、前記認可サーバは、前記リフレッシュトークンのハッシュ値を受信すると、前記リフレッシュトークンの更新用乱数を生成して前記クライアントに送信し、前記クライアントは、前記更新用乱数を用いて、前記リフレッシュトークンを更新する。

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

Priority Applications (2)

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

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
WO2020166066A1 true WO2020166066A1 (ja) 2020-08-20

Family

ID=72044417

Family Applications (1)

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

Country Status (2)

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

Cited By (2)

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

Citations (4)

* 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

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5317629B2 (ja) * 2008-11-05 2013-10-16 ヤフー株式会社 情報管理装置、情報処理システム、情報管理方法及び情報管理プログラム

Patent Citations (4)

* 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

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
HARDT, D: "The OAuth 2.0 Authorization Framework", REQUEST FOR COMMENTS, October 2012 (2012-10-01), pages 1 - 76, XP015086448, Retrieved from the Internet <URL:URL:https://tools.ietf.org/html/rfc6749> [retrieved on 20190510] *
LATINOV, L.: "How to implement secure REST API authentication over HTTP", AUTOMATION RHAPSODY, 5 March 2018 (2018-03-05), Retrieved from the Internet <URL:https://automationrhapsody.com/implement-secure-rest-api-authentication-http> [retrieved on 20190510] *

Cited By (4)

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

Also Published As

Publication number Publication date
JP7226457B2 (ja) 2023-02-21
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
JP4674044B2 (ja) クライアントが許可を検証できるキー管理プロトコルを設けるためのシステムおよび方法
TWI288552B (en) Method for implementing new password and computer readable medium for performing the method
US7774611B2 (en) Enforcing file authorization access
TWI620087B (zh) 驗證伺服器、驗證方法及其電腦程式產品
RU2297037C2 (ru) Управление защищенной линией связи в динамических сетях
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
US9762567B2 (en) Wireless communication of a user identifier and encrypted time-sensitive data
US11829502B2 (en) Data sharing via distributed ledgers
JP2017521934A (ja) クライアントとサーバとの間の相互検証の方法
KR20090091727A (ko) 세계적 고유 디바이스 특정 식별자들의 생성 및 검증
JP5992535B2 (ja) 無線ｉｄプロビジョニングを実行するための装置及び方法
CN112968910B (zh) 一种防重放攻击方法和装置
US20210392004A1 (en) Apparatus and method for authenticating device based on certificate using physical unclonable function
WO2020166066A1 (ja) トークン保護方法、認可システム、装置、及び、プログラム記録媒体
CN114127764A (zh) 与分布式账本关联的目的地寻址
US20130091355A1 (en) Techniques to Prevent Mapping of Internal Services in a Federated Environment
JP2024501728A (ja) ブロックチェーンベースのｓｄｐアクセス制御方法及びシステム
US10764065B2 (en) Admissions control of a device
WO2019234801A1 (ja) サービス提供システム及びサービス提供方法
JP7043480B2 (ja) 情報処理システムと、その制御方法とプログラム
KR20190091511A (ko) 난수에 기초한 데이터 메시지 인증
CN114765551A (zh) 基于区块链的sdp访问控制方法及装置
KR101209812B1 (ko) 홈 네트워크 시스템에서의 클라이언트 접근 제어 방법 및 이를 위한 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19915301

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020572042

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19915301

Country of ref document: EP

Kind code of ref document: A1