JP6268242B1 - Server and token issuing method - Google Patents

Abstract

It is possible to set a validity period of a token based on information on access to a resource performed or performed by an authorized third party. A token request reception unit 402 of an IB server 4 receives a request for a token that proves that a user device user is authorized to access a user resource by a user. The validity period setting unit 403 sets the validity period of the requested token based on one or more pieces of information regarding access to the resource performed or performed by the client to which the authority is granted. The access token issuing unit 404 issues a token with the above valid period set to the client. [Selection] Figure 3

Description

  The present invention relates to a technology for granting a right to access a user's resources from the user to a third party.

  2. Description of the Related Art Conventionally, there is a mechanism called Internet banking that provides bank services such as balance inquiry and transfer to users through the Internet. At the beginning of the service, it was a general rule that the user who holds the ID and password uses the system. Services such as creating a household account book for users are provided. A third party providing such a service has an authorization server issue a token that proves that the authority to access the user's account information has been granted. Then, the issued token is presented to a resource server that manages the account information, thereby permitting access to the account information. Such a mechanism for granting authority is realized by, for example, a standard protocol called OAuth 2.0 (see Patent Document 1).

JP2015-125510A

  However, in the conventional authorization system, the validity period of the token is set regardless of the access method and scope, and by granting authority to a third party for a time longer than necessary, the account information of the user is obtained. Could be at risk.

  The present invention has been made in view of such circumstances, and it is possible to set the validity period of a token based on information relating to access to resources performed or performed by an authorized third party. The purpose is to.

  In order to solve the above-mentioned problem, the present invention provides a token that proves that the user is authorized to access a user's resource by the user or a token used to obtain the token. A token request receiving unit that receives a request, and a validity period for setting a validity period of the requested token based on one or more information related to access to the resource performed or performed by the client to which the authority is granted A server is provided that includes a setting unit and a token issuing unit that issues a token with the valid period set to the client.

  In a preferred aspect, the one or more pieces of information are information relating to access made to the resource by the client after the requested token is issued.

  In another preferred aspect, the one or more information is information relating to access made to the resource by the client before the requested token is issued.

  In a further preferred aspect, the one or more pieces of information are a plurality of pieces of information, and the valid period setting unit identifies a plurality of valid periods based on each of the plurality of pieces of information, and among the plurality of identified valid periods The longest or shortest validity period is set as the validity period of the requested token.

  In another preferable aspect, the one or more pieces of information are a plurality of pieces of information, and the valid period setting unit identifies a plurality of valid periods based on each of the plurality of pieces of information, The validity period calculated by substituting into a predetermined mathematical formula is set as the validity period of the requested token.

  In a further preferred aspect, the effective period setting unit weights each of the specified effective periods according to the information referred to in order to specify the effective period.

  In a further preferred aspect, the apparatus further comprises a priority setting unit configured to set a priority of the requested token based on a content of access to the resource performed by the client to which the authority is granted. The reference is made to determine whether to permit other access to the resource performed by the client to which the authority is granted, and the token issuing unit determines whether the valid period and the priority are The set token is issued to the client.

  In a further preferred aspect, when the other access is not permitted, the token request accepting unit certifies that another authority to perform another access has been granted from the user to the client. Accepts a request for a token, and the validity period setting unit determines whether the requested other is based on one or more information related to other access to the resource performed or performed by the client to which the other authority is granted. The priority setting unit sets other priorities of the other requested tokens based on the content of other accesses to the resource performed by the authorized client. And setting another priority higher than the priority, and the token issuing unit sets the other valid period and the other Other tokens priority and is set to issue to the client.

  The present invention is also a token issuing method executed by a computer for acquiring a token or a token for proving that an authority to access a user's resource is granted to the client from the user. Accepting a request for a token to be used for, and setting a validity period for the requested token based on one or more information regarding access to the resource made or performed by the authorized client And a token issuing method comprising: issuing a token with the valid period set to the client.

  According to the present invention, it is possible to set the validity period of a token based on information related to access to a resource performed or performed by an authorized third party.

1 is a diagram illustrating an example of a configuration of an authorization system 100. FIG. 5 is a diagram illustrating an example of an account information management table 21, an access token management table 22, and a refresh token management table 23. FIG. 2 is a diagram illustrating an example of a configuration of an IB server 4. FIG. It is an example of a user management table 409. 4 is an example of a client management table 410. 5 is a diagram illustrating an example of an authorization code management table 412, an access token management table 413, and a refresh token management table 414. FIG. It is a figure which shows an example of the effective period table. 5 is a diagram illustrating an example of a processing history management table 416. FIG. It is a sequence diagram which shows an example of an authorization process. It is a flowchart which shows an example of an access token issue process. It is a sequence diagram which shows an example of an access process. It is a sequence diagram which shows an example of an access token reissue process. It is a figure which shows an example of a priority table.

1. Embodiment 1-1. Configuration of Authorization System 100 FIG. 1 is a diagram illustrating an example of a configuration of an authorization system 100 according to an embodiment of the present invention. The authorization system 100 includes one or more user devices 1, one or more client devices 2, one or more bank servers 3, and an Internet banking function providing server (hereinafter “IB server”) 4. The user device 1, the client device 2, and the IB server 4 are connected to each other by a communication line 5 such as the Internet. The bank server 3 and the IB server 4 are interconnected by a communication line 6 such as a dedicated line.

1-2. Configuration of User Device 1 The user device 1 is a computer used by a user of a service provided by the client device 2 and a service provided by the IB server 4. For example, a portable computer such as a smartphone or a tablet terminal, or a stationary computer. Specifically, the user device 1 includes an arithmetic processing device such as a CPU, a memory such as a flash memory, an input device such as a touch sensor, a display device such as a liquid crystal display, and a communication module such as a data communication card. Prepare. In the user device 1, the function of the user agent 10 is realized by the arithmetic processing device executing a program stored in the memory. The user agent 10 is specifically a web browser.

  The user of the user device 1 has the authority to access his / her resources stored in the bank server 3 or the IB server 4. Further, this user has the authority to give the right to access the resource to the client 20 that functions on the client device 2.

1-3. Configuration of Client Device 2 The client device 2 is used by a service provider that accesses a user resource of the user device 1 stored in the bank server 3 or the IB server 4 and provides a service to the user based on the resource. Computer. For example, a server. Specifically, the client device 2 includes an arithmetic processing device such as a CPU, a storage device such as an HDD, and a communication module such as a data communication card. In the client device 2, the function of the client 20 is realized by the arithmetic processing device executing a program stored in the storage device. The client 20 is specifically a household account book application. More specifically, an application that accesses account information of the user of the user device 1 stored in the bank server 3 or the IB server 4 and automatically creates a household account book for the user based on the account information. is there. In order to automatically create a household account book, the client 20 receives from the user an authority to access the user's account information.

  In the storage device of the client 20, an account information management table 21, an access token management table 22, and a refresh token management table 23 are stored.

  FIG. 2A is a diagram illustrating an example of the account information management table 21. The account information management table 21 is created for each user account of the user device 1, and the user account information acquired from the IB server 4 is registered therein. Each record of the account information management table 21 includes fields of date, deposit amount, withdrawal amount, balance, and description.

  FIG. 2B is a diagram illustrating an example of the access token management table 22. The access token management table 22 is a table for managing an access token issued to the client 20 by the IB server 4. Here, the access token is authentication information that proves that the right to access the account information of the user of the user device 1 is given to the client 20 by the user. Specifically, it is a random character string. Each record of the access token management table 22 includes an access token, an access token expiration date, and an access token scope field. Here, the scope of the access token indicates the range of access that is proved to be authorized by the access token, and the type of access and the user ID that identifies the user of the user device 1 (different for each bank). ), An access processing method, and an inquiry period. Here, of the access processing methods, the offline method is to access resources stored in the IB server 4, and the online method is to access original resources stored in the bank server 3.

  FIG. 2C is a diagram illustrating an example of the refresh token management table 23. The refresh token management table 23 is a table for managing refresh tokens issued to the client 20 by the IB server 4. Here, the refresh token is authentication information used for acquiring an access token. More specifically, the authentication information proves that the user has the authority to request reissuance of the access token. The refresh token consists of a random character string. Each record of the refresh token management table 23 includes a refresh token, a refresh token expiration date, and a refresh token scope field. Here, the scope of the refresh token indicates a range of access that is proved to be authorized by an access token acquired using the refresh token, and includes an access type, a user ID, and an access type. It consists of processing method and inquiry period.

1-4. Configuration of Bank Server 3 The bank server 3 is a server managed by a bank. Specifically, the bank server 3 includes an arithmetic processing device such as a CPU, a storage device such as an HDD, a communication module such as a data communication card, and the like. An account information management table 30 is stored in the storage device of the bank server 3. The account information management table 30 is created for each user account of the user device 1, and the original account information of the user is registered. Each record of the account information management table 30 includes fields of date, deposit amount, withdrawal amount, balance, and description. The configuration of the account information management table 30 is the same as that of the account information management table 21, and is not shown.
A bank (ordinary bank) is merely an example of a financial institution, and in other embodiments, the server may be managed by another financial institution such as a trust bank, a credit card company, or an insurance company.

1-5. Configuration of IB Server 4 FIG. 3 is a diagram illustrating an example of the configuration of the IB server 4. The IB server 4 is a server that is managed by an internet banking company that provides the bank server 3 with an internet banking function. Specifically, the IB server 4 includes an arithmetic processing device such as a CPU, a storage device such as an HDD, a communication module such as a data communication card, and the like. In the IB server 4, various functions for granting access authority from the user of the user device 1 to the client 20 are realized by the arithmetic processing device executing a program stored in the storage device. These functions will be described later.

  The storage device of the IB server 4 includes a user management table 409, a client management table 410, an account information management table 411, an authorization code management table 412, an access token management table 413, and a refresh token management table 414. A period table 415 and a processing history management table 416 are stored.

  FIG. 4 is an example of the user management table 409. The user management table 409 is a table for managing authentication information and personal information of the user of the user device 1 that uses Internet banking. Each record of the user management table 409 includes a user ID, a password, a name, and an address.

  FIG. 5 is an example of the client management table 410. The client management table 410 is a table for managing authentication information of the client 20 that receives an access token issued from the IB server 4. Each record of the client management table 410 includes a client ID for identifying the client 20 and a password.

  The account information management table 411 is created for each user account of the user device 1, and the user account information acquired from the bank server 3 is registered therein. The IB server 4 periodically synchronizes the account information management table 411 with the account information management table 30 of the bank server 3. Each record of the account information management table 411 includes fields of date, deposit amount, withdrawal amount, balance, and description. The configuration of the account information management table 411 is the same as that of the account information management table 21 and is not shown.

  FIG. 6A is a diagram illustrating an example of the authorization code management table 412. The authorization code management table 412 is a table for managing information related to the authorization code issued to the client 20. Here, the authorization code is authentication information used to acquire an access token and a refresh token. More specifically, the authentication information proves that the user has the authority to request access token and refresh token issuance. The authorization code consists of a random character string. Each record of the authorization code management table 412 includes an authorization code, a client ID, an expiration date of the authorization code, and fields of a redirect URI transmitted from the client 20 to the IB server 4 when the authorization code is requested.

  FIG. 6B is a diagram illustrating an example of the access token management table 413. The access token management table 22 is a table for managing an access token issued to the client 20 by the IB server 4. Each record of the access token management table 413 includes fields of an access token, a client ID, an access token expiration date, and an access token scope. The scope of the access token includes an access type, a user ID, an access processing method, and an inquiry period.

  FIG. 6C is a diagram illustrating an example of the refresh token management table 414. The refresh token management table 414 is a table for managing refresh tokens issued to the client 20 by the IB server 4. Each record of the refresh token management table 414 includes fields for a refresh token, a client ID, a refresh token expiration date, a refresh token scope, and an access token reissue count. The scope of the refresh token includes an access type, a user ID, an access processing method, and an inquiry period.

  FIG. 7 is a diagram illustrating an example of the validity period table 415. The validity period table 415 is a table referred to for setting the validity period of the access token. In this effective period table 415, an effective period is associated with each piece of information related to access to resources performed or performed by the client 20 to which the access authority is granted. Here, the information related to this access includes information related to access (in other words, future access) performed on the resource by the client 20 after the requested access token is issued, and the requested access token. It is divided into information related to access (in other words, past access) previously performed on the resource by the client 20. In other words, the information related to future access is information on the scope of the access token, and includes a processing method and a query range. Here, the inquiry range includes the inquiry period, the number of accounts to be inquired, and the number of deposit / withdrawal items to be inquired. Regarding the effective period associated with the processing method, the effective period associated with the online method is set shorter than the effective period associated with the offline method from the viewpoint of security. The effective period associated with the inquiry range is set to be proportional to the value of the inquiry range from the viewpoint of convenience of the client 20. On the other hand, information related to past access includes processing time, the number of accesses (in other words, the number of reissues of access tokens), and the most recent access date and time. Here, the processing time is the time required for the IB server 4 to execute the requested access after receiving the access request from the client 20. The effective time associated with the processing time and the access count is set to be proportional to the value from the viewpoint of convenience of the client 20. The effective time associated with the most recent access date / time is set to have a negative proportional relationship from the viewpoint of security.

  FIG. 8 is a diagram illustrating an example of the processing history management table 416. The processing history management table 416 is a table for managing a history of access to resources performed by the client 20 to which access authority is granted. The processing history management table 416 is created for each client 20. Each record of the processing history management table 416 includes fields of date / time, processing time, and access scope. The access scope includes an access type, a user ID, an access processing method, and an inquiry period.

  Next, various functions realized by the IB server 4 will be described. Specifically, the authorization acquisition unit 401, the token request reception unit 402, the validity period setting unit 403, the access token issue unit 404, the refresh token issue unit 405, the access request reception unit 406, and the process execution unit 407. The token re-request receiving unit 408 will be described.

  Upon receiving the authorization request generated by the client 20, the authorization acquisition unit 401 acquires an authorization for granting the client 20 authority to access the user's resources from the user of the user device 1. At that time, the authorization acquisition unit 401 refers to the user management table 409 and authenticates the user before acquiring the authorization from the user. If the authentication is successful, the authorization acquisition unit 401 acquires an authorization for granting access authority to the client 20 from the user. When obtaining the authorization from the user, the authorization obtaining unit 401 issues an authorization code to the client 20.

  The token request reception unit 402 receives an access token request generated by the client 20 that has been issued an authorization code. When receiving this request, the token request receiving unit 402 refers to the client management table 410 and authenticates the client 20. If the authentication is successful, the token request reception unit 402 verifies the validity of the authorization code included in the received request. Specifically, with reference to the authorization code management table 412, it is verified whether or not the expiration date of the authorization code has passed.

  When the authentication and verification by the token request receiving unit 402 is successful, the valid period setting unit 403 sets the valid period of the access token for which the request has been received by the token request receiving unit 402. At that time, the validity period setting unit 403 sets the validity period based on the authorization request received by the authorization acquisition unit 401 while referring to the validity period table 415. Specifically, the validity period setting unit 403 identifies a plurality of validity periods based on the client ID and access scope included in the authorization request, and requests the shortest validity period among the identified validity periods. Set as the validity period of the access token Here, the reason why the shortest valid period is set as the valid period of the access token is that, from the viewpoint of security, it is preferable that the valid period set in the access token is short.

  The access token issuing unit 404 issues an access token whose validity period has been set by the validity period setting unit 403 to the client 20. When the access token is issued, the access token issuing unit 404 calculates the expiration date after the set effective period has elapsed from the current time, and is received by the issued access token and the authorization acquisition unit 401. Are registered in the access token management table 413 in association with the client ID and the access scope included in the authorization request.

  The refresh token issuing unit 405 issues a refresh token to the client 20. When the refresh token is issued, the refresh token issuing unit 405 calculates an expiration date that is a time point after a predetermined validity period set for each bank has elapsed from the current time point, and issues the refresh token and authorization acquisition. Registered in the refresh token management table 414 in association with the client ID and the access scope included in the authorization request received by the unit 401.

  The access request receiving unit 406 receives an access request transmitted from the client 20. When receiving the access request, the access request receiving unit 406 refers to the client management table 410 and authenticates the client 20. If the authentication is successful, the access request receiving unit 406 verifies the validity of the access token included in the received access request. Specifically, the access token management table 413 is referenced to verify whether the access token expiration date has passed. When the validity of the access token is verified, the access request receiving unit 406 verifies whether or not the requested access is within the authority range. Specifically, referring to access token management table 413, it is determined whether or not a pair of access token and access token scope included in the received access request is registered.

  When the authentication and verification by the access request receiving unit 406 is successful, the process execution unit 407 permits the access for which the request has been received by the access request receiving unit 406. Here, the access is an inquiry of account information such as balance and deposit / withdrawal details. Access is performed, for example, by calling an API (Application Programming Interface) of the IB server 4. When executing the requested process, the process executing unit 407 registers the date and time of the executed process, the process time, and the access scope in the process history management table 416 in association with each other.

  The token rerequest receiving unit 408 receives an access token rerequest transmitted from the client 20. When receiving the access token re-request, the token re-request receiving unit 408 refers to the client management table 410 and authenticates the client 20. If the authentication is successful, the token rerequest receiving unit 408 verifies the validity of the refresh token included in the received access token rerequest. Specifically, the refresh token management table 23 is referenced to verify whether or not the expiration date of the refresh token has elapsed. When the validity of the refresh token is verified, the token rerequest receiving unit 408 verifies whether or not the scope of the access token included in the received access token rerequest is within the authority range. Specifically, the refresh token management table 414 is referred to, and it is determined whether or not a pair of a refresh token and an access token scope included in the received access token re-request is registered. At this time, the inquiry period may be the same as or shorter than the inquiry period registered in the refresh token management table 414.

1-6. Operation of Authorization System 100 The operation of the authorization system 100 will be described. Specifically, an authorization process for issuing an access token and a refresh token to the client 20 upon receiving the authorization of the user of the user device 1, and an access process for permitting access upon receiving an access request from the client 20. An access token reissue process for reissuing an access token in response to an access token rerequest from the client 20 will be described.

1-6-1. Authorization processing FIG. 9 is a sequence diagram illustrating an example of authorization processing. When the user of the user device 1 who uses the household account book creation service provided by the client 20 desires cooperation between the service and the Internet banking service provided by the IB server 4, the user 20 communicates with the client 20 about the Internet banking service. Request cooperation. At that time, the user agent 10 of the user device 1 transmits a cooperation request to the client 20 (step Sa1). Upon receiving the cooperation request transmitted from the user agent 10, the client 20 redirects the user agent 10 to the IB server 4 (step Sa2). At this time, an authorization request is transmitted from the user agent 10 to the IB server 4. This authorization request includes the client ID of the client 20, the access scope, and the redirect URI. Here, the scope of access is constituted by the type of access, the user ID of the user of the user device 1, the access processing method, and the inquiry period. The redirect URI is identification information indicating a destination to which the IB server 4 redirects the user agent 10 when an authorization code is issued. Specifically, the URL indicates the web page of the client 20.

  Upon receiving the authorization request transmitted from the user agent 10, the authorization acquisition unit 401 of the IB server 4 transmits an authentication screen for authenticating the user to the user agent 10 (step Sa3). When the user agent 10 acquires the authentication screen transmitted from the IB server 4, the user agent 10 displays the authentication screen on the display device. This authentication screen includes an input field for inputting a user ID and a password, and a login button. When the user of the user device 1 inputs a user ID and a password and selects a login button, the user agent 10 transmits the set of the input user ID and password as authentication information to the IB server 4 (step Sa4). Upon obtaining the authentication information transmitted from the user agent 10, the authorization acquisition unit 401 of the IB server 4 determines whether or not this authentication information (that is, a combination of a user ID and a password) is registered in the user management table 409. (Step Sa5). If the result of this determination is that the user is not registered (that is, if user authentication has failed), the authorization acquisition unit 401 transmits an error response to the user agent 10. On the other hand, when registered (that is, when user authentication is successful), the authorization acquisition unit 401 transmits an authorization screen for obtaining user authorization to the user agent 10 (step Sa6).

  When acquiring the authorization screen transmitted from the IB server 4, the user agent 10 displays the authorization screen on the display device. This authorization screen includes an explanation regarding the scope of access included in the authorization request acquired by the IB server 4 in step Sa2, an authorization button, and a rejection button. When the user of the user device 1 selects the authorization button, the user agent 10 notifies the IB server 4 that the user has authorized (step Sa7). Upon receiving this notification, the authorization acquisition unit 401 of the IB server 4 issues an authorization code and redirects the user agent 10 to the client 20 using the redirect URI acquired in step Sa3 (step Sa8). At that time, the authorization code is transmitted from the user agent 10 to the client 20. Further, the authorization acquisition unit 401 of the IB server 4 registers the issued authorization code, the expiration date of the authorization code, the client ID and the redirect URI acquired in step Sa3 in association with each other in the authorization code management table 412.

  When the user of the user device 1 selects the reject button, the user agent 10 notifies the IB server 4 that the user has rejected the authorization. Upon receiving this notification, the authorization acquisition unit 401 of the IB server 4 generates an error response and redirects the user agent 10 to the client 20 using the redirect URI acquired in step Sa3. At this time, an error response is transmitted from the user agent 10 to the client 20.

  When acquiring the authorization code transmitted from the user agent 10, the client 20 transmits an access token request to the IB server 4 (step Sa9). This access token request includes the authorization code, the client ID, the password of the client 20, and the redirect URI notified to the IB server 4 in step Sa2. When receiving the access token request transmitted from the client 20, the token request receiving unit 402 of the IB server 4 first authenticates the client 20 (step Sa10). Specifically, first, it is determined whether or not a client ID and password pair included in the received access token request is registered in the client management table 410. Second, it is determined whether or not a combination of an authorization code, a client ID, and a redirect URI included in the received access token request is registered in the authorization code management table 412. If one or both of the two determination results are negative (that is, if the client authentication fails), the token request reception unit 402 returns an error response to the client 20. Send. On the other hand, if both the determination results are affirmative (that is, if the client authentication is successful), then the token request reception unit 402 verifies the validity of the authorization code (step Sa11). . Specifically, the authorization code management table 412 is referenced to determine whether or not the expiration date of the authorization code included in the received access token request has passed. As a result of this determination, when the expiration date has passed (that is, when the authorization code is not valid), the token request reception unit 402 transmits an error response to the client 20. On the other hand, when the expiration date has not elapsed (that is, when the authorization code is valid), the IB server 4 executes an access token issuing process (step Sa12).

  FIG. 10 is a flowchart showing an example of the access token issuing process. In steps Sb1 to Sb7 of this access token issuing process, the validity period setting unit 403 specifies the validity period of the access token. At that time, the valid period setting unit 403 identifies the valid period based on the authorization request acquired in step Sa2 while referring to the valid period table 415.

  First, the valid period setting unit 403 identifies a valid period based on the access processing method indicated in the authorization request (step Sb1). For example, when the processing method is the “online” method, “3 minutes” is specified as the effective period (see FIG. 7).

  Next, the valid period setting unit 403 identifies a valid period based on the inquiry period indicated in the authorization request (step Sb2). For example, when the inquiry period is “for the current day”, “3 minutes” is specified as the effective period (see FIG. 7).

  Next, the validity period setting unit 403 specifies the validity period based on the number of accounts associated with the user ID indicated in the authorization request (in other words, the number of accounts to be referred) (step Sb3). Here, it can be said that the number of accounts to be inquired is the number of account information management tables 411 associated with the user ID. For example, when the number of accounts to be inquired is “2”, “3 minutes” is specified as the valid period (see FIG. 7).

  Next, the validity period setting unit 403 is the deposit / withdrawal details of the account associated with the user ID indicated in the authorization request, and the number of deposit / withdrawal details corresponding to the inquiry period indicated in the authorization request (in other words, And the valid period is specified based on the number of deposit / withdrawal items to be inquired (step Sb4). For example, when the number of deposit / withdrawal items to be inquired is “100”, “9 minutes” is specified as the valid period (see FIG. 7).

  Next, the validity period setting unit 403 specifies the validity period based on the processing time of the access performed in the past by the client 20 identified by the client ID indicated in the authorization request (step Sb5). At that time, the valid period setting unit 403 refers to the processing history management table 416 associated with the client 20 and among the processing times associated with the access scope indicated in the authorization request, The processing time of access performed within a predetermined period from the time is specified. When a plurality of processing times are specified, an average value is calculated. For example, when “3 seconds” is specified as the processing time, the effective period setting unit 403 specifies “3 minutes” as the effective period (see FIG. 7).

  Next, the validity period setting unit 403 specifies the validity period based on the number of accesses made in the past by the client 20 identified by the client ID indicated in the authorization request (in other words, the number of reissues of the access token). (Step Sb6). This step is executed when an access token and a refresh token have already been issued to the client 20, and when the refresh token is presented from the client 20 and the access token is re-requested. The valid period setting unit 403 refers to the refresh token management table 23 and identifies the number of reissues of the access token associated with the presented refresh token. For example, when “50 times” is specified as the reissue number of access tokens, the validity period setting unit 403 identifies “6 minutes” as the validity period (see FIG. 7).

  Next, the validity period setting unit 403 identifies the validity period based on the most recent access date and time performed by the client 20 identified by the client ID indicated in the authorization request (step Sb7). At this time, the valid period setting unit 403 refers to the processing history management table 416 associated with the client 20 and is associated with the access scope (excluding the inquiry period) indicated in the authorization request. Identify the most recent date and time. For example, when “3 days ago” is specified as the most recent access date and time, the effective period setting unit 403 specifies “6 minutes” as the effective period (see FIG. 7).

When a plurality of effective periods are specified through steps Sb1 to Sb7, the effective period setting unit 403 specifies the shortest effective period among the effective periods (step Sb8). When the shortest valid period is specified by the valid period setting unit 403, the access token issuing unit 404 generates an access token and the expiration date that is the time after the specified valid period has elapsed from the current time And the generated access token and the calculated expiration date are registered in the access token management table 413 in association with each other (step Sb9). At that time, the access token issuing unit 404 registers the client ID and the access scope indicated in the authorization request acquired in step Sa2 in association with each other. Next, the refresh token issuing unit 405 generates a refresh token, calculates an expiration date after a predetermined validity period set for each bank from the current time, and generates the generated refresh token. Are registered in the refresh token management table 414 in association with each other (step Sb10). At that time, the refresh token issuing unit 405 registers the client ID and the access scope shown in the authorization request acquired in step Sa2 in association with each other.
This completes the description of the access token issuing process.

When the access token issuing process is completed, the access token issuing unit 404 transmits an access token response including the issued access token and the refresh token to the client 20 (step Sa13). This access token response includes the issued access token and its expiration date, the issued refresh token and its expiration date, and the scope of access indicated in the authorization request acquired in step Sa2. When acquiring the access token response transmitted from the IB server 4, the client 20 registers the information included in the acquired access token response in the access token management table 22 and the refresh token management table 23 (step Sa14).
This completes the description of the authorization process.

  According to the right granting process described above, the validity period of the access token is set based on information related to access to the resource performed or performed by the client 20 to which the access authority is granted. At that time, the shortest effective period is set as the effective period of the access token among the multiple effective periods specified based on a plurality of information related to access, compared with the case where such setting is not performed. , Improve resource security.

1-6-2. Access Processing FIG. 11 is a sequence diagram illustrating an example of access processing. The client 20 accessing the user resource of the user device 1 stored in the bank server 3 or the IB server 4 transmits an access request to the IB server 4 (step Sc1). This access request includes the access token, the client ID and password of the client 20, and the scope of the access token. Here, the scope of the access token is configured by the type of access, the user ID of the user of the user device 1, the access processing method, and the inquiry period.

When the access request receiving unit 406 of the IB server 4 receives the access request transmitted from the client 20, it first authenticates the client 20 (step Sc2). Specifically, first, it is determined whether or not a combination of a client ID and a password included in the received access request is registered in the client management table 410. Second, it is determined whether or not a pair of an access token and a client ID included in the received access request is registered in the access token management table 413. If one or both of the two determination results are negative (that is, if the client authentication fails), the access request reception unit 406 returns an error response to the client 20. Send. On the other hand, if both the determination results are affirmative (that is, if the client authentication is successful), then the access request receiving unit 406 verifies the validity of the access token (step Sc3). . Specifically, the access token management table 413 is referenced to determine whether or not the expiration date of the access token included in the received access request has passed. As a result of this determination, when the expiration date has passed (that is, when the access token is not valid), the access request reception unit 406 transmits an error response to the client 20. On the other hand, if the expiration date has not elapsed (that is, if the access token is valid), the access request reception unit 406 then determines whether the requested access is within the authority range. It is verified whether or not (step Sc4). Specifically, referring to access token management table 413, it is determined whether or not a pair of access token and access token scope included in the received access request is registered. As a result of the determination, if the information is not registered (that is, not within the authority range), the access request receiving unit 406 transmits an error response to the client 20. On the other hand, when registered (that is, within the authority range), the process execution unit 407 permits the requested access (step Sc5). For example, when an inquiry about the balance information of the user A is requested by the offline method, the process execution unit 407 refers to the account information management table 411 associated with the user A and specifies the latest balance. To the client 20. After executing the requested process, the process execution unit 407 associates the date and time of the executed process, the process time, and the access scope with each other and registers them in the process history management table 416 (step Sc6).
The above is the description of the access process.

1-6-3. Access Token Reissue Process FIG. 12 is a diagram illustrating an example of the access token reissue process. The client 20 requesting reissue of the access token transmits an access token rerequest to the IB server 4 (step Sd1). This access token re-request includes the refresh token, the client ID and password, and the scope of the access token that requests issuance. Here, the scope of the access token is configured by the type of access, the user ID of the user of the user device 1, the access processing method, and the inquiry period.

  When receiving the access token re-request transmitted from the client 20, the token re-request receiving unit 408 of the IB server 4 first authenticates the client 20 (step Sd2). Specifically, first, it is determined whether or not the client ID and password pair included in the received access token re-request is registered in the client management table 410. Second, it is determined whether or not a set of the refresh token and the client ID included in the received access token re-request is registered in the refresh token management table 414. If one or both of the two determination results are negative (that is, if the client authentication fails), the token rerequest receiving unit 408 gives an error to the client 20. Send a response. On the other hand, if both the determination results are affirmative (that is, if the client authentication is successful), then the token re-request receiving unit 408 verifies the validity of the refresh token (step Sd3). ). Specifically, the refresh token management table 414 is referred to, and it is determined whether or not the expiration date of the refresh token included in the received access token re-request has passed. As a result of this determination, when the expiration date has passed (that is, when the refresh token is not valid), the token rerequest receiving unit 408 transmits an error response to the client 20. On the other hand, when the expiration date has not elapsed (that is, when the refresh token is valid), the token rerequest receiving unit 408 then sets the scope of the access token included in the received access token rerequest. Is within the authority range (step Sd4). Specifically, the refresh token management table 414 is referred to, and it is determined whether or not a pair of a refresh token and an access token scope included in the received access token re-request is registered. At this time, the inquiry period may be the same as or shorter than the inquiry period registered in the refresh token management table 414. As a result of the determination, if the information is not registered (that is, not within the authority range), the access request receiving unit 406 transmits an error response to the client 20. On the other hand, if registered (that is, within the authority range), the IB server 4 executes the access token issuing process shown in FIG. 10 (step Sd5).

  However, in the access token issuing process executed here, the validity period setting unit 403 is based on the access token re-request accepted in step Sd2 instead of the authorization request obtained in step Sa2 in steps Sb1 to Sb7. To determine the validity period. In step Sb9, the access token issuing unit 404 generates the client ID and the access token scope indicated in the access token re-request accepted in step Sd2, instead of the authorization request acquired in step Sa2. The access token is registered in the access token management table 413 in association with the calculated expiration date. Further, the refresh token is not issued (step Sb10).

When the access token issuing process is completed, the access token issuing unit 404 refers to the refresh token management table 414, and reissues the access token associated with the refresh token included in the access token re-request accepted in step Sd2. The number of times is incremented (step Sd6). Next, the access token issuing unit 404 transmits an access token response including the issued access token to the client 20 (step Sd7). This access token response includes the issued access token and its expiration date, and the scope of the access token indicated in the access token re-request accepted in step Sd2. When acquiring the access token response transmitted from the IB server 4, the client 20 registers information included in the acquired access token response in the access token management table 22 (step Sd8).
This completes the description of the access token reissue process.

2. Modifications The above embodiment may be modified as shown below. Further, the following modifications may be combined with each other.

2-1. Modification 1
Although the client 20 which concerns on said embodiment is a household account book application, it may be another application which accesses a user's account information of the user apparatus 1, and provides a service to a user based on the said account information. For example, it may be an accounting application for creating an accounting book, or a money transfer (specifically, settlement or remittance) application for transferring money between bank accounts.

2-2. Modification 2
The IB server 4 according to the above embodiment has a function of an authorization server that issues an access token and a function of a resource server that holds a resource and processes an access request for the resource. You may build a server.

2-3. Modification 3
In the authorization system 100 according to the above embodiment, the Internet banking function is provided to the bank server 3 by the IB server 4, but the bank server 3 itself has the Internet banking function (that is, the function of the IB server 4). ) And may be connected to the communication line 5.

2-4. Modification 4
In the above embodiment, as a method for obtaining authorization from the user, “The OAuth 2.0 Authorization Framework” ([online] D. Hardt, August 2016 <URL http://tools.ietf.org/html/rfc6749> However, instead of this, the Implicit Grant method, the Resource Owner Password Credentials Grant method, and the Client Credentials Grant method specified in the same specification are adopted. Good.

2-5. Modification 5
In step Sb3 of the access token issuing process according to the above embodiment, when the user has accounts at a plurality of banks, the validity period setting unit 403 uses the total of the accounts of the plurality of banks as the number of accounts to be referred. You may specify.

2-6. Modification 6
In step Sb5 of the access token issuing process according to the above-described embodiment, the valid period setting unit 403 identifies the access processing time with reference to the process history management table 416 and identifies with reference to the valid period table 415. The effective time associated with the processed time is specified, but the access processing time specified with reference to the processing history management table 416 may be used as the effective period.

2-7. Modification 7
In the access token issuing process according to the above-described embodiment, the validity period setting unit 403 may identify the validity period based on other information related to access by the client 20 in addition to or in place of steps Sb1 to Sb7. Good. For example, the validity period setting unit 403 may specify the validity period based on the type of access indicated in the authorization request. Here, the type of access includes inquiry of account information and update of account information. Specifically, the update of the account information is money transfer between accounts such as transfer or transfer. Regarding the effective period associated with the type of access, the effective period associated with the update of the account information is set shorter than the effective period associated with the inquiry of the account information.

  Alternatively, the validity period setting unit 403 may specify the validity period based on the type of account information when the type of account information to be referred is indicated by the authorization request. Here, the type of account information includes a balance, deposit / withdrawal details, and user personal information. Regarding the effective period associated with the type of account information, the effective period associated with the balance is set shorter than the effective period associated with the deposit / withdrawal details.

2-8. Modification 8
In the access token issuing process according to the above embodiment, the validity period setting unit 403 does not have to execute all of steps Sb1 to Sb7.

2-9. Modification 9
In steps Sb1 to Sb7 of the access token issuing process according to the above-described embodiment, the valid period setting unit 403 uses a predetermined mathematical formula prepared for each piece of information related to access by the client 20 without referring to the valid period table 415. The validity period may be specified.

2-10. Modification 10
In the effective period table 415 according to the above embodiment, for the effective period associated with the processing method, the effective period associated with the online method is the effective period associated with the offline method from the viewpoint of the convenience of the client 20. You may make it set longer than a period. Further, the effective time associated with the most recent access date and time may be set so as to have a positive proportional relationship from the viewpoint of convenience of the client 20.

2-11. Modification 11
In step Sb8 of the access token issuing process according to the above embodiment, the validity period setting unit 403 specifies the longest validity period from the plurality of identified validity periods from the viewpoint of the convenience of the client 20. Also good.

2-12. Modification 12
In step Sb8 of the access token issuing process according to the above embodiment, the validity period setting unit 403 identifies one validity period by calculating by substituting the plurality of identified validity periods into a predetermined mathematical expression. May be. Here, the predetermined mathematical expression is expressed as follows, for example.
[Equation 1]
y = (ax ₁ + bx ₂ + cx ₃ + dx ₄ + ex ₅ + fx ₆ + gx ₇ ) / (a + b + c + d + e + f + g)

In the formula (1), y represents the effective period to be obtained, x _{1 to} x ₇ represent the effective period specified in steps Sb1 to Sb7, and a to g represent coefficients. Here, the coefficients a to g may be set so as to differ for each effective period specified in steps Sb1 to Sb7. That is, the validity period setting unit 403 may weight each of the plurality of validity periods identified in steps Sb1 to Sb7 according to the information referred to identify the validity period. For example, the effective period specified based on the access processing method may be given a greater weight than the effective period specified based on the number of deposit / withdrawal details to be queried. Alternatively, the coefficients a to g may be uniformly set to “1”. In other words, the validity period setting unit 403 may not weight each of the plurality of validity periods specified in steps Sb1 to Sb7.

2-13. Modification 13
In the above embodiment, the access token may be a character string including a character string indicating the validity period. Similarly, the refresh token may be a character string including a character string indicating the validity period.

2-14. Modification 14
In the above embodiment, the IB server 4 sets the priority for the access token according to the scope of the access token, and when the access request is received from the client 20, the priority set in the access token and the request It may be determined whether to permit the access by comparing the priority associated with the type of access made.

  In order to set the priority to the access token, the IB server 4 may have a function of a priority setting unit. The function of the priority setting unit is realized by the arithmetic processing device of the IB server 4 executing a program stored in the storage device. This priority setting unit sets the priority of the access token for which the request has been received by the token request reception unit 402, based on the access scope included in the authorization request received by the authorization acquisition unit 401. At that time, the priority setting unit sets the priority of the access token with reference to a priority table described later. Here, the priority is information that is referred to in order to determine whether or not to permit access to the resource performed by the client 20 to which the access authority is granted.

  FIG. 13 is a diagram illustrating an example of a priority table. In this priority table, a priority is associated with each access type. The high priority is proportional to the size of the number indicating the priority.

  In the access token issuing process according to the above embodiment, when the shortest valid period is specified by the valid period setting unit 403 (step Sb8), the priority setting unit refers to the priority table and indicates the authorization request. The priority of the issued access token is set based on the type of access to be issued. For example, when the type of access indicated in the authorization request is “settlement (transfer)”, “2” is set as the priority of the access token (see FIG. 13). When the priority setting unit sets the priority, the access token issuing unit 404 associates the set priority with the access token, the expiration date, and the client ID in step Sb9, instead of the access scope. Register in the token management table 413. In step Sb10, the refresh token issuing unit 405 registers the set priority in the refresh token management table 414 in association with the refresh token, the expiration date, and the client ID instead of the access scope.

  When the priority is set for the access token, in step Sc4 of the access process according to the above embodiment, the access request receiving unit 406 verifies whether the requested access is within the authority range. Therefore, it is determined whether or not the priority of the access token included in the received access request is equal to or higher than the priority associated with the requested access type. Here, the priority of the access token included in the access request is specified by referring to the access token management table 413, and the priority associated with the requested access type is referred to the priority table. Specified by. As a result of this determination, when the priority of the access token is less than the priority of the requested access type (that is, not within the authority range), the access request receiving unit 406 Send an error response. On the other hand, when the priority of the access token is equal to or higher than the priority of the requested access type (that is, within the authority range), the process execution unit 407 permits the requested access. (Step Sc5).

  When priority is set for the access token, in step Sd4 of the access token reissue process according to the above embodiment, the token rerequest accepting unit 408 determines the scope of the access token included in the accepted access token rerequest. In order to verify whether or not is within the scope of authority, the priority of the refresh token included in the received access token re-request is associated with the type of access indicated in the received access token re-request It is determined whether or not the priority is higher. Here, the priority of the refresh token included in the access token re-request is specified by referring to the refresh token management table 414, and the priority of the access type indicated in the received access token re-request is the priority table. It is specified by referring to. As a result of this determination, if the priority of the refresh token is less than the priority of the access type indicated in the received access token re-request (that is, not within the authority), the token re-request is accepted. The unit 408 transmits an error response to the client 20. On the other hand, when the priority of the refresh token is equal to or higher than the priority of the access type indicated in the received access token re-request (that is, within the authority range), the IB server 4 The access token issuing process shown in FIG. 10 is executed (step Sd5).

  According to this modification described above, there is no need to issue different access tokens for each type of access.

2-15. Modification 15
In step Sc4 of the access process according to the modified example 14 described above, when the priority of the access token is less than the priority of the requested access type (that is, not within the authority range), the access request is accepted. The unit 406 may invalidate the access token. Specifically, information regarding the access token may be deleted from the access token management table 413.

2-16. Modification 16
In step Sc4 of the access process according to the modified example 14 described above, the client 20 that has received the error response from the IB server 4 receives the error response and gives the authority of access denied to the IB server 4 to the user device 1. You may make it acquire from the user. In other words, the client 20 may acquire from the IB server 4 an access token set with a higher priority than the access token included in the access request rejected by the IB server 4. In order to acquire an access token with a high priority, the client 20 may acquire the user agent 10 by requesting a cooperation request, and may start the authorization process shown in FIG.

  In the access token issuing process in the authorization process executed here, the access token issuing unit 404 has a higher priority than the access token as the generated access token is registered in the access token management table 413. An access token that is a low access token and associated with a common client ID and user ID may be deleted (step Sb9). In addition, the refresh token issuing unit 405 is a refresh token having a lower priority than the refresh token as the generated refresh token is registered in the refresh token management table 414, and corresponds to a common client ID and user ID. The attached refresh token may be deleted (step Sb10).

  Alternatively, instead of the access token issuing unit 404 deleting the access token having a low priority, the refresh token issuing unit 405 may omit issuing the refresh token. Since the issue of the refresh token is omitted, the newly generated access token cannot be reissued, and the use opportunity of the newly generated access token is limited. Alternatively, the refresh token issuing unit 405 may set the same validity period as the access token as the validity period of the refresh token.

2-17. Modification 17
In the access token issuance process according to the modified example 14, the validity period setting unit 403 does not execute steps Sb1 to Sb8, but sets a predetermined validity period set for each bank to the validity period of the issued access token. May be specified.

2-18. Modification 18
In the above embodiment, an access token and a refresh token are issued for each client 20, but an access token and a refresh token may be issued for each group including a plurality of clients 20.

2-19. Modification 19
In step Sb10 of the access token issuing process according to the above embodiment, the refresh token issuing unit 405 sets the validity period of the refresh token issuing unit 405 based on the type of access indicated in the authorization request acquired in step Sa2. May be. Here, the type of access includes inquiry of account information and update of account information. Regarding the effective period associated with the type of access, the effective period associated with the update of the account information is set shorter than the effective period associated with the inquiry of the account information.

2-20. Modification 20
In the authorization process according to the above embodiment, the client 20 may request the IB server 4 to issue only the refresh token.

2-21. Modification 21
The program executed in the IB server 4 according to the above-described embodiment or modification may be provided in a state stored in a storage medium such as a magnetic disk, an optical disk, a magneto-optical disk, or a memory. The program may be downloaded via a communication line such as the Internet.

DESCRIPTION OF SYMBOLS 1 ... User apparatus, 2 ... Client apparatus, 3 ... Bank server, 4 ... IB server, 5 ... Communication line, 6 ... Communication line, 10 ... User agent, 20 ... Client, 21 ... Account information management table, 22 ... Access token Management table, 23 ... Refresh token management table, 30 ... Account information management table, 100 ... Authorization system, 401 ... Authorization acquisition unit, 402 ... Token request reception unit, 403 ... Validity period setting unit, 404 ... Access token issuing unit, 405 ... Refresh token issuing unit, 406 ... Access request receiving unit, 407 ... Processing execution unit, 408 ... Token re-request receiving unit, 409 ... User management table, 410 ... Client management table, 411 ... Account information management table, 412 ... Authorization Code management table, 413 ... Access talk Management table 414 ... refresh token management table, 415 ... valid period table, 416 ... processing history management table

Claims (7)

A token request accepting unit that accepts a request for a token that is used to acquire a token or a token that proves that an authority to access a user's resource is granted to the client from the user;
A validity period setting unit that sets a validity period of the requested token based on one or more information related to access to the resource performed or performed by the client to which the authority is granted;
A priority setting unit configured to set the priority of the requested token based on the content of access to the resource performed by the client to which the authority is granted;
A token issuing unit that issues a token in which the validity period and the priority are set to the client ;
The priority is information that is referred to in order to determine whether or not to permit other access to the resource performed by the client to which the authority is granted,
When the other access is not permitted, the token request accepting unit accepts a request for another token certifying that another authority for performing another access is granted from the user to the client. ,
The validity period setting unit determines the validity period of the requested other token based on one or more information related to other access to the resource performed or performed by the client to which the other authority is granted. Set,
The priority setting unit is another priority of the other requested tokens based on the content of another access to the resource performed by the client to which the authority is granted, and is higher than the priority. Set another high priority,
The token issuing unit issues another token in which the other valid period and the other priority are set to the client.
A server characterized by that .   The server according to claim 1, wherein the one or more pieces of information are information related to an access made to the resource by the client after the requested token is issued.   The server according to claim 1, wherein the one or more pieces of information are information related to an access made to the resource by the client before the requested token is issued. The one or more pieces of information are a plurality of pieces of information;
The validity period setting unit identifies a plurality of validity periods based on each of the plurality of pieces of information, and sets the longest or shortest validity period of the identified plurality of validity periods as the validity period of the requested token. The server according to claim 1, wherein the server is set as follows. The one or more pieces of information are a plurality of pieces of information;
The effective period setting unit specifies a plurality of effective periods based on each of the plurality of pieces of information, and calculates the effective period calculated by substituting the specified plurality of effective periods into a predetermined mathematical formula. The server according to any one of claims 1 to 3, wherein the server is set as an effective period.   The server according to claim 5, wherein the effective period setting unit weights each of the specified effective periods according to the information referred to in order to specify the effective period. . A token issuing method executed on a computer,
Receiving a request for a token certifying that the user has been authorized to access the user's resources from the user or a token used to obtain the token;
Setting a validity period of the requested token based on one or more information regarding access to the resource made or performed by the authorized client;
Setting the priority of the requested token based on the content of access to the resource performed by the authorized client;
Issuing a token in which the validity period and the priority are set to the client ,
The priority is information that is referred to in order to determine whether or not to permit other access to the resource performed by the client to which the authority is granted,
Receiving a request for another token certifying that the user has been granted other authority to perform other access when the other access is not permitted; and
Setting a validity period for the other requested tokens based on one or more information relating to other access to the resource made or performed by the client to which the other authorization has been granted;
Based on the content of other accesses to the resource performed by the authorized client, other priorities of the requested other tokens that are higher than the priorities are set. And steps to
Issuing another token set with the other validity period and the other priority to the client;
A token issuing method further comprising :

Images