JP2019067430A - Authentication system - Google Patents

Abstract

To realize authentication that makes one application usable in a plurality of client units.SOLUTION: A server 10 performs authentication in accordance with an authentication request from a client PC, and issues a token when permitting the use of an application 31. The authentication request is repeatedly transmitted from the client to the server during the use of the application. When the application is activated from another client while the application is being used by one client, the server 10 issues a token to a new client when permitting the use of the application by the new client and invalidates the token issued to the other client previously using the application, thereby preventing illegal use and enabling application use by a plurality of client units.SELECTED DRAWING: Figure 1

Description

  The present invention relates to an authentication system that performs authentication for using an application at a client connected to a server via a network.

When using an application, authentication as to whether the user has a license for the use is performed by various methods. In recent years, assuming that the client using the application is connected to the Internet, many techniques for managing licenses are also provided by a server on the Internet.
For example, when performing authentication of an application using a network, Patent Document 1 discloses a technique for preventing the use of the application in a non-authorized terminal other than the authorized terminal by acquiring identification information unique to the terminal. Is disclosed.
Similarly, in the case of performing authentication using a license key including identification information unique to a terminal, Patent Document 2 authenticates the other terminal by managing identification information of the terminal using the application in a database. When this is done, the technology is disclosed that allows the new terminal to be used after stopping the use of the previously used terminal.
Patent Document 3 discloses a technique for controlling both the number of installed applications and the number of concurrently operating applications by setting two setting values, ie, the number of applications that can be installed and the number of licenses that can start applications simultaneously, at the time of licensing. It is disclosed.
Patent Document 4 issues an access token with an expiration date when performing authentication by the server, and verifies the license even while using the application by confirming whether the expiration date of the access token has passed. Disclose the technology to do

JP, 2013-015930, A JP, 2009-116392, A JP, 2015-14817, A JP, 2016-018529, A

In the authentication method in the prior art, in the authentication on the server premised on online as in Patent Documents 1 to 4, if the client installed with the application is not in an online state communicably connected to the server, the application is used. There was a problem that it was impossible. In addition, there is a problem that the adoption of a method capable of authenticating even in an off-line state where the server is not connected increases the risk of fraudulent action such as falsification of the access token expiration date. As described above, online authentication has a problem of lack of convenience, while off-line authentication is insufficient for dealing with fraud.
An object of the present invention is to realize authentication utilizing the advantages of online authentication and offline authentication.

The present invention
An authentication system for performing authentication for using an application in a client connected to a server via a network, comprising:
The server is
A token for permitting use of the application according to an authentication request from the client includes fixed date and time information representing its expiration date, and dynamic date and time information updated according to the execution of authentication, A token issuing unit that generates an off-line token used for authentication when the client is in an off-line state, and sends it to the client;
And a token management unit that manages the generated token.
The client is
A token holding unit that holds the offline token;
Use of the application is permitted when the current time is after the dynamic date and time information included in the offline token and within the expiration date, and use of the application is prohibited in other cases Use permission department,
According to the operation of the use permission unit, the dynamic date and time information can be configured as an authentication system including a date and time information update unit that updates the current time.
The token holding unit, the usage permission unit, and the date and time information updating unit configured in the client may be configured separately from the application, or may be incorporated as part of the application.

In the present invention, the offline token issued from the server can be used to permit / prohibit use of the application on the client. Therefore, when the offline token is issued, the client needs to be connected to the server via the network, but after that, the application can be used even if the client is not connected to the server, which ensures convenience.
In addition, as the date for determining whether or not the token for online use used in the present invention, fixed date and time information representing an expiration date, and dynamic date and time information updated according to the execution of authentication. Is included. The fixed date and time information includes the last available date and time information of the offline token, the available date and time when the offline token can be used, and the period from the start of the offline token to the unavailable time. Such information can be used. All of these may be used or a part may be used. Further, as the dynamic date and time information, it is possible to use the date and time when the authentication was performed, the date and time when the application was used, and the elapsed time after starting to use the offline token. In addition, it is determined that the use of the application is permitted when two conditions, that the current time is after the dynamic date and time information and that the current time is within the expiration date, are satisfied. The current time used here may be a time obtained based on the clock of the client. Thus, if dynamic date and time information is used in addition to fixed date and time information, the condition that the current time is after dynamic date and time information even if the client's clock is traced back after the expiration date has passed. Therefore, the offline token can not be used fraudulently.
Therefore, the present invention has the effect that it is possible to realize the convenience of being able to use the application offline while suppressing fraud.

In the present invention,
The date and time information update unit may be regulated so as to update the dynamic date and time information only in a direction toward the future.
By doing this, it is possible to prevent the fraud in which the dynamic date and time information is traced back, and it is possible to more reliably prevent the fraudulent use of the application.

When restricting the update of date and time information in this way,
When coming online, the date and time information updating unit may release the restriction, and synchronize the dynamic date and time information with the date and time acquired via the network.
By doing this, it is possible to correct the dynamic date and time information when it comes to an incorrect date and time by mistake. For example, if the client's clock changes for some reason to a future date and time after the expiration date, dynamic date and time information may also be updated to the future date and time. Even if the current time of the day is within the expiration date, the application based on the offline token can not be used. Since dynamic date and time information can not be easily traced back to prevent fraud, once such a situation occurs, it is not possible to resume use of the application even if the client's clock is returned to normal. There is a risk of
According to the above aspect, when the client comes online, it is possible to exceptionally recognize the synchronization of the dynamic date and time information, and it is possible to trace back to the normal time, so that the usage of the application is restored. Can.

Also, the present invention is
An authentication system for performing authentication for using an application in a client connected to a server via a network, comprising:
The server is
A token issuing unit that generates an on-line token unique to the client used for authentication for permitting use of the application when the client is online according to an authentication request from the client, and transmits the token to the client When,
Whether to permit the use of the application in the client based on at least one of the validity of the on-line token and the activation condition for permitting the activation of the application in response to the authentication request from the client An authentication unit that authenticates the
And a token management unit that manages the generated token.
The client is
An authentication request transmission unit that repeatedly transmits the authentication request to the server at the start of the application and at a predetermined timing after the start;
And a use permission unit for permitting the use of the application when it is confirmed that the token for online use is valid, and for prohibiting the use of the application otherwise.
At the server,
When the token issuing unit permits the use of the application by the authentication, the token issuing unit is a valid on-line token unique to the client, or information indicating that the on-line token issued to the client is valid. Send to the client,
When the token management unit is an issued online token corresponding to the authentication request and is issued to a client different from the online token newly generated by the token issuing unit The authentication system may be configured to invalidate the issued on-line token according to a predetermined invalidation condition.

The above aspect is an aspect for realizing authentication in a state of being connected to a network, that is, online authentication. That is, the server performs authentication in response to the authentication request from the client. This authentication is performed when the client newly starts an application and when the application is already used. In the latter case, the client periodically sends an authentication request to the server while the application is in use, without the user's instruction.
When the server permits the use of the application, the server transmits information such as an online token to the client. For example, when a new application is started on the client, a new online token is issued and sent to the client. Instead of the on-line token itself, an aspect of transmitting the on-line token identification information is also included.
On the other hand, when the client is already using the application, information is transmitted to the client that the existing online token is valid. A new online token may be issued to replace the existing online token and sent to the client.
By doing this, the client can be permitted to use the application upon receiving a valid online token (including its identification information and information indicating that the online token is valid).
In the present invention, furthermore, when an authentication request from a different client is sent, the server invalidates the issued online token and issues a new online token. As the issued online token is invalidated, the terminal which used the application before can not use the application. That is, when the user wants to change the terminal to be used, the terminal can be easily changed only by transmitting the authentication request from the new terminal without stopping the use of the application in the previous terminal. Become.
In the present invention, the on-line token is "unique" to the client in order to determine whether the authentication request is from a terminal different from the on-line token already issued. For example, identification information unique to the terminal of the client may be included in the on-line token, or the on-line token may be managed in association with the identification information of the client.

In the present invention,
The authentication request includes identification information of a developer of the application, identification information of the application, account information of a user of the application, and terminal identification information of the client.
The authentication may be performed in consideration of consistency between each information included in the authentication request and information registered in advance in the server.
By doing this, the authentication according to the present invention can be made a system that can be used without confusion among a plurality of developers, applications, users and client terminals. For example, by including the identification information of the application developer in the authentication request, even if other information (application identification information, account information, terminal information) is the same, the authentication request is associated with the developer. It is because it can be recognized that the Therefore, each developer can arbitrarily set these without considering what other developers use identification information and account information of applications.

In the present invention,
The server is
A database storing the identification information of the application and the account information of the user may be provided individually for each developer of the application.
By doing this, it becomes possible to manage data for each developer of the application, and it is possible to further improve the convenience of the present invention.

The present invention does not necessarily have to include all of the various features described above, and some of the features may be omitted or combined as appropriate. Further, the present invention is not limited to the configuration as the above-described authentication system, and configurations in various modes are possible,
For example,
An authentication method for performing authentication for using an application in a client connected to a server via a network, comprising:
As processing executed by the server,
A token for permitting use of the application according to an authentication request from the client includes fixed date and time information representing its expiration date, and dynamic date and time information updated according to the execution of authentication, Generating an offline token to be used for authentication when the client is in the offline state, and sending it to the client;
Managing the generated token.
As processing executed by the client,
A token holding step for holding the offline token;
Use of the application is permitted when the current time is after the dynamic date and time information included in the offline token and within the expiration date, and use of the application is prohibited in other cases Use permission step,
According to the use permission step, the dynamic date and time information may be configured as a date and time information update step of updating to the current time.
Also in these authentication methods, it is possible to incorporate the various features described in the authentication system.

Further, the present invention can also be configured as a computer program for causing a computer to realize the above-described authentication method, and a computer readable recording medium in which these computer programs are recorded. The computer program may be configured to be installed on a server, or may be configured to be installed on a client. As the latter aspect,
For example,
A computer program to be executed by a client connected to a server via a network to perform authentication for using the application, the client program comprising:
A function of sending an authentication request to the server;
From the server, the token for permitting the use of the application includes fixed date and time information representing its expiration date, and dynamic date and time information updated according to the execution of authentication, and the client is in the offline state A function for receiving an off-line token used for authentication in the
Use of the application is permitted when the current time is after the dynamic date and time information included in the offline token and within the expiration date, and use of the application is prohibited in other cases Use permission function,
The computer program is configured to cause the client to realize a date and time information update function that updates the dynamic time and date information to the current time according to the execution of the use permission function.
Also in these computer programs, various features described in the authentication system can be incorporated. In the case of a computer program to be executed by the client, it may be prepared as a computer program different from the application used by the client, or may be prepared incorporated into the application.

It is an explanatory view showing the composition of the attestation system as an example. It is explanatory drawing which illustrates the structure of a database. It is a flowchart of a network authentication process. It is a flowchart of a stand-alone switching process. It is a flowchart of application use permission processing. It is explanatory drawing which shows the content of utilization date update.

A. System configuration:
An embodiment of the present invention will be described.
FIG. 1 is an explanatory view showing the configuration of an authentication system as an embodiment. The authentication system is a system for the server 10 to provide authentication for use of an application installed on a client PC in an environment where the client PC and the server 10 are connected to the Internet INT. Hereinafter, authentication via a network may be referred to as “cloud authentication”.
Although only one client PC is shown in FIG. 1, a plurality of client PCs may be provided. The client PC is a computer that has a CPU, a memory, and the like and can execute various applications, and can use a tablet, a smartphone, a mobile phone, and the like in addition to a personal computer.
The authentication system is constructed by the functions provided to the server 10 and the authentication system module 20 provided to the client PC. In this embodiment, software is configured as software by installing a computer program for realizing the illustrated functional blocks in the server 10 and the client PC, but at least a part may be configured as hardware. It is possible. Also, each functional block shown in the server 10 may be realized by distributed processing by a plurality of servers.

  The authentication system of this embodiment is used, for example, in the following manner. The developer who is the developer of the application benefits by providing the user with the right to use the application, ie, the license, for a fee. In order to properly obtain such benefits, it is necessary to prevent unauthorized use of the application by the user, and for this purpose, it is necessary to authenticate whether the user has a valid license when using the application. It is the authentication system of this embodiment that realizes such authentication. Although this authentication system may be constructed and operated by a developer of the application itself, this embodiment shows an example in which an operation subject other than the developer operates the authentication system. That is, the developer prepares an authentication system module 20 to be installed on the client PC after entering into a use contract of the authentication system with the operation entity of the authentication system. The authentication system module 20 may be incorporated into an application developed by a developer, or may be a module separate from the application. The user who has licensed the application from the developer installs the authentication system module 20 at the same time by installing the application on his client. Thus, the application will run under authentication by the authentication system of this embodiment.

Each functional block provided in the server 10 will be described.
The server 10 is provided with three types of databases, a developer information database 16, a license information database 17, and an account information database 18. The developer information database 16 stores information on developers of applications using the authentication system. The license information database 17 and the account information database 18 are databases prepared for each developer. The license information database 17 stores information such as a user who has purchased a license of an application and license conditions. The account information database 18 stores information on accounts (or user IDs) available to licensed users. The contents of these databases will be specifically described later.
The database management unit 13 manages reading and writing of data with respect to the developer information database 16, the license information database 17, and the account information database 18.
The transmission / reception unit 11 transmits / receives various information via the Internet INT. Examples of the information transmitted and received in the present embodiment include an authentication request for authentication of use of the application, a token for permitting use, and the like.
The authentication unit 14 authenticates the application while also functioning as integrating the function blocks in the server 10. In this embodiment, as described later, in addition to the authentication performed when the application is started, the authentication is performed repeatedly while using the application. The authentication unit 14 receives an authentication request from the client PC, and refers to the information stored in the developer information database 16, the license information database 17, the account information database 18, the token management unit 15, etc. at each timing. It determines the availability.
The token issuing unit 12 issues a new token as necessary when the use of the application is permitted as a result of the authentication by the authentication unit 14. The token is one-time or disposable information for permitting the client PC to use the application.
The token management unit 15 holds the issued token.

Next, each functional block provided in the client PC will be described.
The transmission / reception unit 30 transmits / receives various information via the Internet INT.
The application 31 is various computer programs used by the client PC. Some may be subject to the authentication of the present embodiment and others may be included. In the present embodiment, when the application 31 is referred to hereinafter, the application 31 means one that is the target of the authentication of the present embodiment.
The authentication system module 20 cooperates with the server 10 to build the authentication system of the present embodiment. The authentication system module 20 may be prepared as an application 31 and a separate module, or may be incorporated in each application 31.
The authentication request transmission unit 21 transmits information (this will be referred to as an authentication request) for requesting an authentication to the server 10. The authentication request transmission unit 21 transmits an authentication request when it is intended to newly start an application in the client PC. In addition, while using the application, the authentication request is repeatedly transmitted at a predetermined timing regardless of the instruction from the user.
The authentication information storage unit 22 temporarily stores information included in the authentication request. The information included in the authentication request also includes terminal-specific identification information of the client PC. In addition, when a token is issued from the server 10 in response to an application authentication request, the authentication information storage unit 22 also stores this token.
The use permission unit 23 permits the use of the application 31 when the authentication by the server 10 is obtained. Further, in the present embodiment, a stand-alone mode is provided which can also perform authentication in a state where the client PC is not connected to the server 10. In the case of the stand-alone mode, the use permission unit 23 also has a function of determining whether the application 31 can be used based on the information stored in the authentication information storage unit 22, in particular, the offline token.
The date and time information update unit 24 updates the “date and time of use” information included in the offline token stored in the authentication information storage unit 22 in the standalone mode. The “use date and time” is information for preventing unauthorized use of the offline token, as described later. The date and time information update unit 24 updates the use date and time at a predetermined timing such as when authentication in the stand-alone mode is performed.

B. Database configuration:
FIG. 2 is an explanatory view illustrating the configuration of a database.
The developer information database 16 is a database that stores information on developers of applications using the authentication system.
Developer ID is identification information of a developer.
The contract information represents information related to the contract between the agent of the authentication system and the developer. The contract information includes, for example, the developer's name, contact information, contract conditions, billing information, payment information, and the like.
Developer keys are developer-specific information used in authenticating an application. The developer key may be the same information as the developer ID, but in the present embodiment, separate information is used.
The application name and the application ID are the name and identification information of the application to be authenticated in the present embodiment. A plurality of application names and application IDs can be provided for each developer. Since the developer information database 16 stores information for each developer, the application name and the application ID may overlap with application names and the like of other developers. However, in the present embodiment, in order to avoid confusion, as the application ID, when the application is newly registered by the developer, the authentication system adds unique identification information that does not overlap with other developers.

The license information database 17 and the account information database 18 are databases prepared for each developer.
The license information database 17 stores information such as a user who has purchased a license of an application and license conditions. The illustrated data will be prepared for each license by the user.
The application ID is identification information of an application to be licensed. It is information corresponding to the application ID stored in the developer information database 16.
The developer key is information representing a developer and is information stored in the developer information database 16.
The number of purchased licenses is information indicating the number of licenses purchased by the user, that is, the number of applications that can be used simultaneously. In addition, information may be added that represents the number that can be installed on the computer.
The application start date indicates the date when application usage can be started by applying a license.
The expiration date indicates the expiration date of the license, that is, the expiration date of the use of the application.
The number of licenses per account represents the number of applications that can be used simultaneously by one account, ie, the user ID.

The account information database 18 stores information on accounts (or user IDs) available to licensed users. For example, when a company receives a license and makes a plurality of employees use an application, a plurality of pieces of account information may be associated with one piece of license information.
The user ID is identification information of the user of the application, and the password is information to be input on the authentication screen to use the application.
The right is the right granted to the user for the use of the application. In this embodiment, in addition to the on-line authentication for authenticating an application in a state where the client is connected to the server, a stand-alone mode capable of authenticating even in an off-line state not connected to the server is provided. As permission, it is possible to set availability of stand-alone mode.
The application start date and time stores the date and time when the use of the application can be started for each user.

  In any database, it is not necessary to have all of the illustrated information, and some may be omitted as necessary. Also, information other than that illustrated may be added to the database. In the present embodiment, the license information database 17 and the account information database 18 are prepared separately, but they may be integrated databases.

C. Token configuration:
Next, the configuration of the token used in the authentication of this embodiment will be described. The token is one-time or disposable information for permitting the client PC to use the application. The information constituting the token can be arbitrarily set, but in the present embodiment, the following information is included.
"Token ID", that is, identification information of a token.
They are the "application ID" and the developer key stored in the license information database 17.
It is information indicating "license type", that is, whether it is for online authentication or standalone.
It is a "user ID" stored in the license information database 18.
Information used in the standalone mode is information such as "use date and time", "expiration date", and "switch date and time". The meaning of each item of information will be described later.
The "terminal ID" of the client, that is, identification information unique to hardware.
Other management information can also be included.

D. Online Certification:
Hereinafter, the authentication process by the authentication system of the present embodiment will be described in order.
FIG. 3 is a flowchart of the online authentication process. The on-line authentication is an authentication process performed in a situation where the client and the server can communicate via the Internet. This process is executed by the server when a client sends an authentication request to the server. The authentication request is transmitted when the user newly starts an application and when the user is already using the application. In the latter case, the client automatically sends an authentication request to the server at a predetermined timing regardless of the user's instruction.

The server first receives an authentication request (step S10). The authentication request includes a developer key, an application ID, a user ID, a password, and a terminal ID. By including the developer key and the application ID, it is possible to confirm that the authentication request is from a legitimate application created by a legitimate developer who has signed a contract using the certification system. Further, by including the developer key, the application ID, the user ID, and the password can use information set arbitrarily for each developer without considering duplication with other developers. However, the user ID, password, etc. may be information that can be used independently of the developer in the authentication system.
In the case of an authentication request transmitted during use of an application, information such as a user ID and a password may be omitted. Also, instead of information such as developer key and application ID, a token issued at the time of authentication may be used.
The terminal ID is information unique to the client, and in this embodiment, SecureUDID which is information unique to the combination of the client and the application is used. Alternatively, a MAC address may be used as the terminal ID. By using the terminal ID, there is an advantage that the server can specify the client that has transmitted the authentication request even in the state where a plurality of clients are connected to the Internet.

Next, the server determines whether the authentication request is valid (step S11). In this embodiment, when the following four conditions are satisfied, it is determined that the authentication request is valid.
The condition (1) is that the developer key is valid, that is, the developer key included in the authentication request matches the information stored in the developer information database 16.
The condition (2) is that the application ID is valid, that is, the application ID included in the authentication request matches the information stored in the developer information database 16 or the license information database 17.
The condition (3) is that the user ID and password are valid, that is, the information matches the information stored in the account information database 18.
The condition (4) is that the license has not expired, that is, the time of authentication is consistent with the “expiration date” information stored in the license information database 17.
Condition (3) may be omitted in the case of the authentication request sent during use of the application.

If any of the above four conditions are not satisfied and it is determined that the authentication request is not valid (step S11), the server ends the online authentication process without permitting the use of the application.
On the other hand, when it is determined that the authentication request is valid (step S11), the server searches the issued token stored in the token management unit 15 (see FIG. 1), and the token corresponding to the authentication request is issued. Determine if it has been done. The token corresponding to the authentication request is a token in which the developer key, the application ID, and the user ID match.

  When the token has not been issued (step S12), when the number of uses of the application falls within the valid range (step S17), the server newly issues a token (step S18). The application is available when the client receives the token. When the number of uses of the application exceeds the effective range (step S17), the server ends the online authentication process without permitting the use of the application.

  The determination as to whether the number of applications used exceeds the effective range (step S17) can be made, for example, by the following procedure. By searching the developer key stored in the token management unit 15 and the token whose application ID matches the authentication request, it is possible to obtain the number of uses of the application. If the number of uses is smaller than the number of purchased licenses stored in the license information database 17, the number of used applications does not exceed the number of purchased licenses even if the use of the application is newly permitted. Can be judged to fall within the effective range. If the number of uses matches the license information database 17, it can be determined that the number of uses of the application exceeds the valid range.

On the other hand, if the token matching the authentication request has already been issued (step S12), the server determines whether the issued token and the terminal ID included in the authentication request match (step S13).
If the two match, the server determines from the client that has already issued the token that the authentication request has been repeatedly sent during use of the application, and performs processing to continue using the token (step S16). For example, the token stored in the token management unit 15 may be transmitted to the client again, or information indicating that the issued token is valid may be transmitted to the client.

If the issued token and the terminal ID included in the authentication request do not match (step S13), the server determines that the user has transmitted the authentication request from a different terminal, and performs the following processing. First, the server confirms the number of licenses per account (step S14). That is, by obtaining the number of tokens including the user ID included in the authentication request from the token management unit 15, the number of applications used by the account that sent the authentication request is obtained, and this number of applications and storage in the license information database 17 Compare the number of licenses per account.
As a result, when it is determined that the number of uses of the application is within the range of the number of licenses per account (step S14), the server determines the availability of the application by the process of step S17 described above. When it is determined that the number of applications used exceeds the number of licenses per account (step S14), the issued token is invalidated (step S15), and the use of the application being used is stopped, Whether or not to use the application is determined by the process of step S17 described above.
In this way, the user stops the application used so far by invalidating the issued token when an authentication request is made that does not match the terminal ID while containing the same user ID. There is an advantage that it is possible to easily use the application at different terminals without having to do it.
The token invalidation is performed on tokens in which the authentication request and the user ID match, and is not performed on tokens in which the user IDs are different. That is, when the user ID is different, the one using the application earlier is treated with priority, and when the user ID matches, the terminal authenticated later is treated with priority. Become.

E. Stand-alone authentication:
FIG. 4 is a flowchart of the stand-alone switching process. This is a process for switching to a stand-alone mode in which the application can be used offline even after the on-line authentication is performed. This process is executed on the server by the user sending a switch request from the client to the server.

The server receives the switching request first (step S20). The switching request includes the token, expiration date, client date and time, and terminal ID information. A token is a token issued by online authentication. In this embodiment, switching to the stand-alone mode is performed after being authenticated online, and thus the switching request can include a token. However, authentication in the standalone mode may be permitted from the beginning. Even in this case, it is assumed that the client and server are connected in order to receive the token when starting the application, so after performing the above-mentioned online authentication (see FIG. 3), it is automatically stand-alone. It is sufficient to shift to the switching process.
The expiration date is the token expiration date, and the client date and time is date and time information based on a clock held by the client. The terminal ID is similar to the online authentication process. The switching request may include information such as a period desired to be used in the stand-alone mode.

The server determines the validity of the received switching request (step S21). In this embodiment, it is determined that the following two conditions are satisfied.
The condition (1) that the token is valid means that the token included in the switching request is managed without being invalidated by the token management unit 15 (see FIG. 1) of the server.
Condition (2) The expiration date of the license means that the expiration date stored in the license information database 17 has not passed. This is because there is no need to allow switching to the stand-alone mode if the license itself has expired.
If one or both of the conditions (1) and (2) are not satisfied, and it is determined that the switching request is invalid (step S21), the server ends this processing without allowing the switching.

If the switching request is valid (step S21), the server determines whether a valid token has been issued to the application for which the change to the standalone mode has been requested (step S22). If such a token has not been issued, it is determined that online authentication has not been completed, and the server ends this processing without allowing the switch.
If a valid token has been issued (step S22), it is determined whether the token is set to the stand-alone mode (step S23). If the token is already in the stand-alone mode, the token is selected. Continue to use (step S26). That is, without accepting the switch request again, the client retransmits the token that has already been issued, or transmits information that can use the issued token.

If the issued token is for online authentication (step S23), the server performs processing for switching to the standalone mode in the following procedure. First, the date and time of the client's clock is acquired, and it is determined whether the error is within the allowable range (step S24). As will be described later, in the present embodiment, in the authentication in the stand-alone mode, unauthorized use of the application by the user is prevented by the date and time information stored in the token. If the client's clock has a large error when switching to the standalone mode, there is a possibility that unauthorized use of the application can not be prevented. Therefore, when the error exceeds the allowable range (step S24), switching to the standalone mode is not permitted, and switching to the standalone mode is performed only when the error is within the allowable range (step S25). Finish. The “permissible error range” as a determination criterion as to whether or not to allow switching is a value that can be arbitrarily set from the viewpoint of preventing unauthorized use.
In switching to the stand-alone mode, an off-line token indicating that it is in the stand-alone mode is sent to the client. The offline token includes information such as the date and time of switching to the standalone mode, the expiration date available in the mode, and the date of use. The switching date and time and the expiration date are fixed date and time information set when switching to the standalone mode, but the usage date and time is information indicating the last date and time when authentication was performed using the offline token, and offline Dynamic date and time information that is updated as the token is used. The client holds this offline token in the authentication information storage unit 22 (see FIG. 1).

  FIG. 5 is a flowchart of the application use permission process. This process is a process executed when using the application in the client. There are cases where this process is executed when an application is newly launched and when an application is already used, and the client is online or stand-alone. When the application is being used, for example, this process may be performed at a constant cycle, or a specific operation of the user on the application may be used as a trigger.

If the client is connected to the network (step S30) and the application is not being activated (step S31), that is, if the application is newly activated, the client displays an authentication screen. (Step S32). The authentication screen is a screen for inputting authentication information such as a user ID and a password. Then, an authentication request is transmitted to the server, including the input authentication information, and the clock of the client is synchronized with the server (step S33).
If the application has already been started (step S31), the display of the authentication screen is skipped, and an authentication request is sent to the server, and the clock of the client is synchronized with the server (step S33). Information on the user ID and password may be omitted from the authentication request in this case.
In the process of step S33, the clock of the client is synchronized for the following reason. In this embodiment, in the stand-alone mode, unauthorized use of the application is prevented by the date and time information (referred to as use date and time) recorded in the token. From this point of view, it is preferable that the clocks of the client and server be synchronized. Also, when the clock is synchronized in the stand-alone mode, the information on the use date of the token is also synchronized accordingly. The significance of this will be explained later.

After transmitting the authentication request, if the client is not in the standalone mode (step S34), the client waits for the authentication on the server to be completed. If the token can not be received from the server (step S35), the client prohibits the use of the application (step S36) and ends this processing. The case where the token can not be received (step S35) includes the case where the token can not be received within the predetermined waiting time, the case where information indicating that the authentication has failed is received from the server, and the like.
On the other hand, if the token can be received from the server (step S35), the client permits the use of the application (step S43), and the process ends. The permission of use includes both the case of starting an application newly and the case of making the application in use continuously available. The received token is held in the authentication information storage unit 22 (see FIG. 1).

In the case of the stand-alone mode (step S34), it is judged whether or not it is usable (step S40). The same applies to the case where the client is not connected to the network (step S30).
The availability determination is a determination as to whether or not to permit the use of the application, and the client refers to the offline token held in the authentication information storage unit 22 and satisfies the following three conditions: Judge as available.

The condition (1) is a condition that the client date and time is after the switching date and time. The client date means the date and time of the client's clock. The switching date means the date when the switching to the standalone mode is performed. These pieces of information are recorded in the offline token.
The condition (2) is a condition that the client date and time is after the use date and time. The use date means the date when the authentication using the off-line token was last performed.
The condition (3) is a condition that the client date and time is within the expiration date.
If the authentication information storage unit 22 does not hold the off-line token, the stand-alone mode is not permitted in the first place, and none of the above three conditions are satisfied, so it is determined that the application can not be used. It will be

Among the above conditions, the conditions (1) and (3) are determinations using fixed date and time information such as switching date and time and expiration date. Assuming that the availability of the application is determined based only on these conditions, the condition (1), (2) can easily be satisfied by tracing back the client clock after the expiration date has passed, and the application It will be possible to illegally use
On the other hand, condition (2) is dynamic date and time information that is updated each time authentication is performed using an offline token. Therefore, as the offline token is used, the condition (2) is updated to approach the expiration date as the date and time progresses, so the time width satisfying the conditions (2) and (3) gradually It will be narrow. If the expiration date has passed, it may happen that there is no range that satisfies the conditions (2) and (3). There is an advantage that unauthorized use can be prevented by determining the availability of the application by combining such dynamic date and time information.
In the present embodiment, in order to further strengthen such functions, the information on the date of use can in principle be updated only in the future, and retrospective changes are not permitted.

If any one of the conditions (1) to (3) is not satisfied, it is determined that the use of the application is not possible (step S41), and the use of the application is prohibited (step S36).
If any of the conditions (1) to (3) is satisfied, it is determined that the application can be used (step S41), and after the use date and time is updated (step S42), the use of the application is permitted (step S43). ).

The meanings of the conditions (1) to (3) described in step S40 will be described again.
FIG. 6 is an explanatory view showing contents of use date and time update.
FIG. 6A shows the conditions (1) to (3) shown in step S40 of the application use permission process (FIG. 5). The condition (1) is satisfied when the client date and time indicated by a black triangle is in the range after the switching date and time as indicated by an arrow tr1. The condition (2) is satisfied when the client date and time is in the range after the use date and time as indicated by an arrow tr2. The condition (3) is satisfied when the client date and time is in the range up to the expiration date, as indicated by an arrow tr3. As a result, the range satisfying the conditions (1) to (3) is satisfied when the client date and time exists in the range et1 indicated by hatching in the drawing.
Then, as indicated by the arrow A, the use date and time is updated only in the future direction as the offline token is used.

  By updating the use date and time, as shown in FIG. 6B, the range et2 satisfying the conditions (1) to (3) gradually narrows. In this state, even if the client date and time is intentionally set back in the past as illustrated, the application can not be used because the condition (2) based on the use date and time is not satisfied.

As described above, although it is a use date and time that contributes to the prevention of unauthorized use in the stand-alone mode, when the client date and time is set to a future date and time for some reason, the state shown in FIG. For example, if the client date and time is set to a date and time after the expiration date, when authentication is performed, the utilization date and time of the offline token is similarly set to the date and time after the expiration date, and arrows tr1 to tr3. There is no area that satisfies all the conditions of. As a result, the use of the application is not permitted.
In order to resolve this situation, it is necessary to correct the use date and time to an accurate date and time, but in this embodiment, since the use date and time can be updated only in the future in principle in principle, Even if it is corrected to an accurate date and time as indicated by ta, the utilization date and time does not go back, so an area satisfying all the conditions of the arrows tr1 to tr3 can not be obtained.
In the present embodiment, in order to avoid such a state, only when the clocks of the server and the client can be synchronized online in step S33 of the application use permission process (FIG. 5), the use date and time is also retroactively traced back To allow. As a result, if the client is connected to the server, the use date and time is corrected to the true present date and time in FIG. 6C, so the condition (2) becomes the state shown by the broken arrow tr2, The time range that satisfies the condition can be recovered.

According to the authentication system of the present embodiment described above, by providing the standalone mode, the application can be used even when the client is in the offline state. Further, in the standalone mode, by combining fixed date and time information (switching date and expiration date) and dynamic date and time information (use date and time), unauthorized use of an application can be prevented.
In addition, when performing authentication processing online, when the user changes the client and makes an authentication request, the issued token is invalidated without stopping the application that has been used so far. There is an advantage that it is possible to start using the application with different clients.

  The various features described in the present embodiment do not necessarily have to be all, and some of them may be omitted or combined as appropriate.

  The present invention can be used to perform authentication for using an application at a client connected to a server via a network.

DESCRIPTION OF SYMBOLS 10 ... Server 11 ... Transmission / reception part 12 ... Token issuing part 13 ... Database management part 14 ... Authentication part 15 ... Token management part 16 ... Developer information database 17 ... License information database 18 ... Account information database 20 ... Authentication system module 21 ... Authentication request Transmission unit 22 ... authentication information storage unit 23 ... usage permission unit 24 ... date and time information update unit 30 ... transmission / reception unit 31 ... application

Claims (4)

An authentication system for performing authentication for using an application in a client connected to a server via a network, comprising:
The server is
A token issuing unit that generates an on-line token unique to the client used for authentication for permitting use of the application when the client is online according to an authentication request from the client, and transmits the token to the client When,
Whether to permit the use of the application in the client based on at least one of the validity of the on-line token and the activation condition for permitting the activation of the application in response to the authentication request from the client An authentication unit that authenticates the
And a token management unit that manages the generated token.
The client is
An authentication request transmission unit that repeatedly transmits the authentication request to the server at the start of the application and at a predetermined timing after the start;
And a use permission unit for permitting the use of the application when it is confirmed that the token for online use is valid, and for prohibiting the use of the application otherwise.
At the server,
When the token issuing unit permits the use of the application by the authentication, the token issuing unit is a valid on-line token unique to the client, or information indicating that the on-line token issued to the client is valid. Send to the client,
When the token management unit is an issued online token corresponding to the authentication request and is issued to a client different from the online token newly generated by the token issuing unit An authentication system for invalidating the issued on-line token according to a predetermined invalidation condition. The authentication system according to claim 1, wherein
The authentication request includes identification information of a developer of the application, identification information of the application, account information of a user of the application, and terminal identification information of the client.
An authentication system in which the authentication is performed in consideration of consistency between each information included in the authentication request and information registered in advance in the server. The authentication system according to claim 2, wherein
The server is
An authentication system comprising a database for storing identification information of the application and account information of the user individually for each developer of the application. An authentication method for performing authentication for using an application in a client connected to a server via a network, comprising:
As processing executed by the server,
(A) generating an on-line token specific to the client used for authentication for permitting use of the application when the client is online according to the authentication request from the client and transmitting it to the client Step and
(B) permitting the use of the application in the client in accordance with at least one of the validity of the on-line token and the activation condition for permitting the activation of the application in response to the authentication request from the client Performing authentication of whether or not
(C) managing the generated token.
As processing executed by the client,
(D) repeatedly transmitting the authentication request to the server at start-up of the application and at predetermined timing after the start-up;
(E) allowing the use of the application when it is confirmed that the token for online use is valid, and prohibiting the use of the application otherwise.
At the server,
In the step (a), when the authentication permits the use of the application, a valid on-line token unique to the client, or information indicating that the on-line token issued to the client is valid Sending to the client,
Step (c) is an issued online token corresponding to the authentication request, which is issued to a client different from the online token newly generated by the token issuing unit The authentication method is a step of invalidating the issued on-line token according to a predetermined invalidation condition.

Images