WO2017199577A1 - 認証システム - Google Patents

認証システム Download PDF

Info

Publication number
WO2017199577A1
WO2017199577A1 PCT/JP2017/011449 JP2017011449W WO2017199577A1 WO 2017199577 A1 WO2017199577 A1 WO 2017199577A1 JP 2017011449 W JP2017011449 W JP 2017011449W WO 2017199577 A1 WO2017199577 A1 WO 2017199577A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
authentication
application
client
date
Prior art date
Application number
PCT/JP2017/011449
Other languages
English (en)
French (fr)
Inventor
貴宏 伊鍋
吉男 前田
Original Assignee
システムメトリックス株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by システムメトリックス株式会社 filed Critical システムメトリックス株式会社
Priority to CN201780031209.6A priority Critical patent/CN109154953B/zh
Priority to EP17799011.6A priority patent/EP3460694B1/en
Publication of WO2017199577A1 publication Critical patent/WO2017199577A1/ja
Priority to US16/175,591 priority patent/US10693870B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time

Definitions

  • the present invention relates to an authentication system that performs authentication for using an application in a client connected to a server via a network.
  • Patent Document 1 discloses a technique for preventing the use of an application in an unauthorized terminal other than a legitimately permitted terminal by acquiring identification information unique to the terminal when authenticating the application using a network. Is disclosed.
  • Patent Document 2 authenticates with another terminal by managing the identification information of the terminal using the application in a database.
  • Patent Document 3 discloses a technique for controlling both the number of installed applications and the number of simultaneously operating applications by providing two setting values, that is, the number of applications that can be installed and the number of licenses that can be activated simultaneously. Disclosure.
  • Patent Document 4 when an authentication is performed by a server, an access token with an expiration date is issued, and by checking whether the expiration date of the access token has passed, the license authentication is performed even while the application is being used. The technology to perform is disclosed.
  • the present invention An authentication system for performing authentication for using an application in a client connected to a server via a network,
  • the token for permitting the use of the application includes fixed date and time information indicating the expiration date, and dynamic date and time information updated according to the execution of the authentication,
  • a token issuing unit that generates an offline token to be used for authentication when the client is in an offline state, and transmits the token to the client;
  • a token management unit for managing the generated token,
  • the client A token holding unit 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.
  • a permission section Along with 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 date and time.
  • the token holding unit, use permission unit, and date / time information update unit configured in the client may be configured separately from the application or may be incorporated as part of the application.
  • use of an application in a client can be permitted / prohibited using an offline token issued from a server. Therefore, when issuing an off-line token, the client needs to be connected to the server via a network, but thereafter, the application can be used without being connected to the server, so that convenience is ensured.
  • the online token used in the present invention as the date and time for determining whether or not it is valid, fixed date and time information indicating the expiration date and dynamic date and time information updated in accordance with the execution of authentication Is included.
  • the fixed date and time information includes the last date and time information on which the offline token can be used, the date and time when the offline token can be used or the date and time of issue, and the period from when the offline token can be used until it cannot be used.
  • Such information can be used. All of these may be used, or some of them may be used.
  • dynamic date and time information the date and time when authentication is executed, the date and time when an application is used, the elapsed time after the start of use of an offline token, and the like can be used.
  • the current time used here may be a time obtained based on the clock of the client.
  • the present invention has an effect that it is possible to realize the convenience of using an application offline while suppressing fraud.
  • the date / time information update unit may be restricted to update the dynamic date / time information only in a direction toward the future. By doing so, it is possible to prevent the illegal use of retroactive dynamic date and time information, and it is possible to more reliably avoid the unauthorized use of the application.
  • the date and time information update unit may release the restriction when it is online and synchronize the dynamic date and time information with the date and time acquired via the network.
  • the dynamic date / time information is erroneously set to an incorrect date / time, the correction can be made.
  • the dynamic date and time information may also be updated to the future date and time. Even if the current time is within the expiration date, the application based on the offline token cannot be used.
  • the server In response to an authentication request from the client, the server permits the validity of an online token unique to the client to be used for authentication when the client is in an online state, and allows the application to be activated Based on at least one of the start conditions, an authentication unit that authenticates whether to permit the use of the application in the client,
  • the client has an authentication request transmission unit that repeatedly transmits the authentication request to the server at a predetermined timing at the time of starting the application and after the start,
  • the token issuing unit includes information indicating that a valid online token unique to the client or an online token issued to the client is valid.
  • the use permission unit may permit the use of the application when the online token is confirmed to be valid, and prohibit the use of the application in other cases.
  • 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 an authentication request from the client. This authentication is performed when a new application is started on the client and when the application is already used. In the latter case, the client periodically sends an authentication request to the server even when the user does not give an instruction while using 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 transmitted to the client. A mode of transmitting the identification information of the online token instead of the online token itself is also included.
  • the server invalidates the issued online token and issues a new online token.
  • the application cannot be used on a terminal that has been using the application. In other words, if the user wants to change the terminal to be used, the terminal can be easily changed as long as an authentication request is transmitted from the new terminal without stopping the use of the application on the previous terminal.
  • the online token is “unique” to the client in order to determine whether or not the authentication request is from a terminal different from the already issued online token.
  • identification information unique to the client terminal may be included in the online token, or the online token may be managed in association with the client identification information.
  • the authentication request includes identification information of the developer of the application, identification information of the application, account information of a user of the application, terminal identification information of the client,
  • the authentication may be performed in consideration of consistency between each piece of information included in the authentication request and information registered in advance in the server.
  • the authentication according to the present invention can be made a system that can be used without confusion by a plurality of developers, applications, users, and client terminals.
  • 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 it was done. Accordingly, each developer can arbitrarily set the identification information and account information of other applications that are not used by other developers.
  • the server A database for storing the identification information of the application and the account information of the user may be individually provided for each developer of the application. By doing so, it becomes possible to manage data for each developer of the application, and the convenience of the present invention can be further improved.
  • An authentication method for performing authentication for using an application in a client connected to a server via a network As a process executed by the server, the token for permitting the use of the application includes fixed date and time information indicating the expiration date, and dynamic date and time information updated according to the execution of the authentication, Generating an offline token to be used for authentication when the client is offline 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.
  • An authorization step, and Along with the use permission step, the dynamic date and time information may be configured as an authentication method including
  • the above-described authentication method can be configured as a computer program for causing a computer to realize the above-described authentication method and a computer-readable recording medium on which these computer programs are recorded.
  • a computer program can be configured to be installed on a server or can be configured to be installed on a client.
  • a computer program executed in a client to perform authentication for using an application in a client connected to a server via a network A function of transmitting an authentication request to the server;
  • a token for permitting the use of the application from the server it includes fixed date and time information indicating the expiration date and dynamic date and time information updated in accordance with the execution of authentication, and the client is in an offline state
  • a function to receive an offline token used for authentication in the case of 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 It is a configuration as a computer program for causing the client to realize a date and time information update function for updating the dynamic date and time information to the current time as the use permission function is executed.
  • These computer programs can also incorporate various features described in the authentication system.
  • the computer program can be prepared as a computer program different from the application used by the client, or can be prepared by being incorporated in the application.
  • FIG. 1 is an explanatory diagram illustrating a configuration of an authentication system as an embodiment.
  • the authentication system is a system for the server 10 to authenticate use of an application installed in the client PC in an environment in which the client PC and the server 10 are connected to the Internet INT.
  • authentication via a network may be referred to as “cloud authentication”.
  • the client PC is a computer that includes a CPU, a memory, and the like and can execute various applications.
  • the client PC can use a tablet, a smartphone, a mobile phone, and the like.
  • the authentication system is constructed by the function provided in the server 10 and the authentication system module 20 provided in the client PC.
  • the server 10 and the client PC are configured by software by installing a computer program for realizing each functional block shown in the figure, but at least a part may be configured by hardware. Is possible.
  • 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 in the following manner, for example. Developers who are application developers benefit from providing users with a right to use the application, that is, a license, for a fee. In order to properly obtain such benefits, it is necessary to prevent unauthorized use of the application by the user. For this purpose, it is necessary to authenticate whether the user has a valid license when using the application.
  • the authentication system of this embodiment realizes such authentication.
  • This authentication system may be constructed and operated by the application developer itself, but in this embodiment, an example in which an operating entity other than the developer operates the authentication system is shown. In other words, the developer prepares the authentication system module 20 to be installed in the client PC after concluding an authentication system use contract with the authentication system operator.
  • the authentication system module 20 may be incorporated in an application developed by the developer, or may be a module different from the application.
  • the user who has received the application license from the developer installs the authentication system module 20 at the same time by installing the application in his client.
  • the application is operated under authentication by the authentication system of this embodiment.
  • the server 10 includes 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 related to the developer of the application that uses 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 the user who purchased the application license and the license conditions.
  • the account information database 18 stores information related to accounts (or user IDs) that can be used by 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 information transmitted / received in the present embodiment include an authentication request for authentication for use of an application and a token for permitting use.
  • the authenticating unit 14 performs application authentication while performing the function of integrating the functional blocks in the server 10. In this embodiment, as will be described later, authentication is performed when the application is activated, and authentication is repeatedly performed while the application is being used.
  • 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 and the like at each timing, and It is determined whether or not it can be used.
  • the token issuing unit 12 issues a new token as necessary when the use of the application is permitted as a result of authentication by the authentication unit 14.
  • the token is one-time, that is, disposable information for permitting the client PC to use the application.
  • the token management unit 15 holds the issued token.
  • the transmission / reception unit 30 transmits / receives various information via the Internet INT.
  • the application 31 is various computer programs used on the client PC. Some are subject to authentication in this embodiment, and others are not. In the present embodiment, the application 31 is hereinafter referred to as an object of authentication of the present embodiment.
  • the authentication system module 20 is a module that constructs the authentication system of the present embodiment in cooperation with the server 10. The authentication system module 20 may be prepared as a module separate from the application 31 or may be incorporated in each application 31.
  • the authentication request transmission unit 21 transmits information requesting authentication to the server 10 (this is called an authentication request).
  • the authentication request transmission unit 21 transmits an authentication request when trying to newly start an application in the client PC.
  • the authentication request is repeatedly transmitted at a predetermined timing regardless of an 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 includes identification information unique to the terminal of the client PC. Further, 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 use of the application 31 when authentication by the server 10 is obtained. Further, in this embodiment, a stand-alone mode is provided in which authentication can be performed in a state where the client PC is not connected to the server 10.
  • the use permission unit 23 also has a function of determining whether or not the application 31 can be used on the basis of information stored in the authentication information storage unit 22, in particular, an offline token.
  • the date / time information update unit 24 updates the “use date / time” information included in the offline token stored in the authentication information storage unit 22 in the stand-alone mode. “Use date and time” is information for preventing unauthorized use of an offline token, as will be 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.
  • FIG. 2 is an explanatory diagram illustrating the configuration of the database.
  • the developer information database 16 is a database that stores information related to the developer of an application that uses the authentication system.
  • the developer ID is developer identification information.
  • the contract information represents information related to a contract between the authentication system operator and the developer.
  • the contract information includes, for example, a developer name, contact information, contract conditions, billing information, payment information, and the like.
  • the developer key is information unique to the developer used for application authentication.
  • the developer key can be the same information as the developer ID, but in this embodiment, separate information is used.
  • the application name and application ID are the name and identification information of the application to be authenticated in this embodiment. A plurality of application names and application IDs can be provided for each developer.
  • the application name and application ID may overlap with the application names of other developers.
  • the authentication system attaches 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 the user who purchased the application license and the license conditions. Data shown in the figure is prepared for each license by the user.
  • the application ID is identification information of an application to be licensed. This is information corresponding to the application ID stored in the developer information database 16.
  • the developer key is information representing the developer, and is information stored in the developer information database 16.
  • the purchased license number 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 indicating the number that can be installed in the computer may be added.
  • the application start date and time represents the date and time when application use can be started by applying a license.
  • the expiration date represents the expiration date of the license, that is, the expiration date during which use of the application is permitted.
  • the number of licenses per account represents the number of applications that can be used simultaneously by one account, ie, a user ID.
  • the account information database 18 stores information related to accounts (or user IDs) that can be used by licensed users. For example, when a company receives a license and allows a plurality of employees to use an application, a plurality of account information may be associated with one license information.
  • the user ID is identification information of the application user
  • the password is information to be input on the authentication screen in order to use the application.
  • the authority is an authority permitted for the user to use the application. In this embodiment, in addition to online authentication for authenticating an application while the client is connected to the server, a stand-alone mode that can authenticate even in an offline state not connected to the server is provided. In the authority, the availability of the stand-alone mode can be set.
  • the application start date / time stores the date / time when the use of the application can be started for each user.
  • any database it is not necessary to provide all the information shown in the figure, and some of the information may be omitted as necessary. Information other than that shown in the figure may be added to the database.
  • the license information database 17 and the account information database 18 are prepared separately, but a database in which both are integrated can also be used.
  • Token structure Next, a configuration of a token used for authentication according to the present embodiment will be described.
  • the token is one-time, that is, disposable information for allowing the client PC to use the application.
  • Information constituting the token can be arbitrarily set, but in the present embodiment, the following information is included.
  • “Application ID” and “developer key” stored in the license information database 17. This is information indicating "license type", that is, for online authentication or stand-alone use. This is a “user ID” stored in the license information database 18.
  • Information used in the stand-alone mode includes information such as “use date and time”, “expiration date”, and “switching date and time”. The meaning of each piece of information will be described later.
  • the “terminal ID” of the client that is, identification information unique to the hardware. Other management information can also be included.
  • FIG. 3 is a flowchart of online authentication processing.
  • Online authentication is authentication processing performed in a situation where a client and a server can communicate via the Internet. This process is executed by the server when an authentication request to the server is transmitted from the client. The authentication request is transmitted when the user newly starts an application or when the application is already used. 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.
  • the developer key and the application ID it is possible to confirm that the authentication request is from an authorized application created by an authorized developer who has signed a contract to use the authentication system.
  • the application ID, user ID, and password can use information arbitrarily set for each developer without considering duplication with other developers.
  • the user ID, password, etc. may be information that can be used in the authentication system without depending on the developer. In the case of an authentication request transmitted while using an application, information such as a user ID and a password may be omitted.
  • the terminal ID is information unique to the client.
  • SecureUDID that is unique information for the combination of the client and the application is used.
  • a MAC address or the like may be used as the terminal ID.
  • the server determines whether the authentication request is valid (step S11).
  • the authentication request is valid when the following four conditions are satisfied.
  • 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, these pieces of information coincide with the information stored in the account information database 18.
  • the condition (4) is that the license is within the expiration date, that is, the time when the authentication is performed is consistent with the “expiration date” information stored in the license information database 17. In the case of an authentication request transmitted while using an application, the condition (3) may be omitted.
  • step S11 If any of the above four conditions is not satisfied and it is determined that the authentication request is not valid (step S11), the server ends the online authentication process without allowing the application to be used. On the other hand, when it is determined that the authentication request is valid (step S11), the server searches for the issued token stored in the token management unit 15 (see FIG. 1), and the token corresponding to the authentication request is issued. It is judged whether it was done.
  • the token corresponding to the authentication request is a token that matches the developer key, application ID, and user ID.
  • step S12 When the token has not been issued (step S12), when the number of applications used falls within the valid range (step S17), the server issues a new token (step S18). When the client receives the token, the application is available. When the number of applications used exceeds the valid range (step S17), the server terminates the online authentication process without allowing the use of the application.
  • Judgment whether or not the number of applications used exceeds the valid range can be performed, for example, by the following procedure.
  • the number of applications used can be obtained. If the number of uses is smaller than the number of purchased licenses stored in the license information database 17, the number of uses of the application will not exceed the number of purchased licenses even if the use of the application is newly approved. Can be determined 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.
  • the server determines whether the issued token and the terminal ID included in each authentication request match (step S13). If the two match, the server determines that an authentication request has been repeatedly transmitted from the client that has issued the token while using the application, and performs a process of continuing to use the token (step S16). For example, the token stored in the token management unit 15 may be transmitted again to the client, or information indicating that the issued token is valid may be transmitted to the client.
  • step S13 the server determines that the user has transmitted an authentication request from a different terminal, and performs the following processing.
  • 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 usage number is stored in the license information database 17. Compare the number of licenses per account. As a result, when it is determined that the usage number of the application is within the range of the number of licenses per account (step S14), the server determines whether or not the application can be used by the process of step S17 described above.
  • step S14 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 in use is stopped. Whether or not the application can be used is determined by the processing in step S17 described above. In this way, when an authentication request that includes the same user ID but does not match the terminal ID is made, by invalidating the issued token, the user stops the application that has been used so far Needless to say, there is an advantage that the application can be easily used in different terminals.
  • the token invalidation is performed for a token whose authentication request and user ID match, and is not performed for a token with a different user ID. In other words, when the user ID is different, the one that used the application first is treated with priority, and when the user ID matches, the terminal authenticated later is treated with priority. Become.
  • FIG. 4 is a flowchart of the stand-alone switching process. This is a process for switching to a stand-alone mode in which an application can be used even offline after online authentication is performed. This process is executed in the server when the user transmits a switching request from the client to the server.
  • the server first receives a switching request (step S20).
  • the switching request includes information on token, expiration date, client date and time, and terminal ID.
  • a token is a token issued by online authentication.
  • the switch to the stand-alone mode is performed after online authentication, a token can be included in the switch request in this way.
  • authentication in the stand-alone mode may be permitted from the beginning. Even in this case, it is assumed that the client and the server are connected to receive the token when the application is started. Therefore, after the online authentication described above (see FIG. 3) is executed, it is automatically stand-alone. It is sufficient to shift to the switching process.
  • the expiration date is the token expiration date
  • the client date / time is date / time information based on a clock held by the client.
  • the terminal ID is the same as in the online authentication process.
  • the switching request may include information such as a period for which use in the stand-alone mode is desired.
  • the server determines the validity of the received switching request (step S21). In the present embodiment, it is determined that it is effective when the following two conditions are satisfied.
  • Condition (1) 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) “Within the expiration date of the license” means that the expiration date stored in the license information database 17 has not passed. This is because it is not necessary to allow switching to the stand-alone mode when the license itself has exceeded the expiration date. If either or both of the conditions (1) and (2) are not satisfied and the switching request is determined to be invalid (step S21), the server ends this process without allowing the switching.
  • step S21 the server determines whether a valid token is issued for the application requested to change to the stand-alone mode (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 process without allowing switching. If a valid token has been issued (step S22), it is determined whether or not the token is set to the stand-alone mode (step S23). Continued use (step S26). That is, the token that has already been issued is retransmitted or information that can use the issued token is transmitted to the client without reapproving the switching request.
  • the server performs processing for switching to the stand-alone mode in the following procedure.
  • the date and time of the client's clock is acquired, and it is determined whether the error is within an allowable range (step S24).
  • the unauthorized use of the application by the user is prevented by the date / time information stored in the token. If the clock error of the client is large when switching to the stand-alone mode, there is a possibility that unauthorized use of the application cannot be prevented.
  • step S24 when the error exceeds the allowable range (step S24), switching to the stand-alone mode is not permitted and switching to the stand-alone mode is executed only when the error is within the allowable range (step S25).
  • “Error tolerance” as a criterion for determining whether or not to permit switching is a value that can be arbitrarily set from the viewpoint of preventing unauthorized use.
  • an off-line token indicating the stand-alone mode is transmitted to the client.
  • the offline token includes information such as the date and time of switching to the stand-alone mode, the expiration date that can be used in the mode, and the use date and time.
  • the switching date and time and expiration date are fixed date and time information that is set when switching to the stand-alone mode, but the usage date and time is information that represents the last date and time of authentication using the offline token, and is offline. This is dynamic date / time information that is updated as the token is used.
  • the client holds the 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 an application is used in the client. This process is executed when a new application is started or when the application is already used. The client may be online or stand-alone. When the application is being used, for example, this process may be executed at a constant cycle, or a specific user operation on the application may be executed as a trigger.
  • step S30 When the process is executed and the client is connected to the network (step S30) and the application is not being activated (step S31), that is, when the application is newly activated, the client displays an authentication screen.
  • the authentication screen is a screen for inputting authentication information such as a user ID and a password. Then, the authentication request including the input authentication information is transmitted to the server, and the client clock is synchronized with the server (step S33).
  • the application has already been started (step S31)
  • the authentication screen is skipped, an authentication request is transmitted to the server, and the client clock is synchronized with the server (step S33). In this case, the user ID and password information may be omitted from the authentication request.
  • the client clock is synchronized for the following reason.
  • unauthorized use of the application is prevented by the date / time information (referred to as use date / time) recorded in the token.
  • the clocks of the client and the server are synchronized.
  • the token use date and time information is synchronized accordingly. This significance will be described later.
  • step S34 After transmitting the authentication request, if the client is not in the stand-alone mode (step S34), the client waits for the authentication at the server to be completed. If the token cannot be received from the server (step S35), the client prohibits the use of the application (step S36) and ends this process.
  • the case where the token cannot be received (step S35) includes a case where the token cannot be received within a predetermined waiting time or a case where information indicating that the authentication has failed is received from the server.
  • the client permits the use of the application (step S43), and the process ends.
  • the use permission includes both a case where an application is newly started and a case where an application being used can be continuously used.
  • the received token is held in the authentication information storage unit 22 (see FIG. 1).
  • the availability is determined (step S40).
  • the availability determination is a determination as to whether or not to permit the use of an application, and the client refers to the offline token held in the authentication information storage unit 22 and satisfies the following three conditions: Judge that it is available.
  • Condition (1) is a condition that the client date is after the switching date.
  • the client date and time means the date and time of the client's clock.
  • the switching date and time means the date and time when switching to the stand-alone mode is performed. Such information is recorded in the off-line token.
  • Condition (2) is a condition that the client date is after the usage date.
  • the use date and time means the date and time when the authentication using the offline token was last performed.
  • Condition (3) is a condition that the client date is within the expiration date. If no offline token is held in the authentication information storage unit 22, the stand-alone mode is not permitted in the first place, and none of the above three conditions is satisfied, so it is determined that the application cannot be used. Will be.
  • conditions (1) and (3) are determinations using fixed date and time information such as switching date and time and expiration date. If it is determined whether or not the application can be used only under these conditions, it is possible to easily satisfy the conditions (1) and (2) by moving the client's clock backward after the expiration date. Can be used illegally.
  • the condition (2) is dynamic date / time information that is updated each time authentication is performed using an offline token. Accordingly, as the offline token is used, the condition (2) is updated so as to approach the expiration date as the date and time advances, so the time width that satisfies the conditions (2) and (3) gradually increases. It will become narrower. If the expiration date has passed, the range that satisfies the conditions (2) and (3) may not exist.
  • step S41 If any of the conditions (1) to (3) is not satisfied, it is determined that the application cannot be used (step S41), and 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), the use date is updated (step S42), and the use of the application is permitted (step S43). ).
  • FIG. 6 is an explanatory diagram showing the contents of usage date update.
  • FIG. 6A shows the conditions (1) to (3) shown in step S40 of the application use permission process (FIG. 5).
  • Condition (1) is satisfied when the client date and time indicated by the black triangle is in the range after the switching date and time as indicated by the arrow tr1.
  • Condition (2) is satisfied when the client date / time is in a range after the usage date / time as indicated by an arrow tr2.
  • Condition (3) is satisfied when the client date and time is within the range until the expiration date, as indicated by the arrow tr3.
  • the range satisfying the conditions (1) to (3) is satisfied when the client date / time exists in the range et1 indicated by hatching in the drawing.
  • the use date and time is updated only in the future direction as the offline token is used, as indicated by an arrow A.
  • the range et2 that satisfies the conditions (1) to (3) gradually narrows as shown in FIG. 6B.
  • the application cannot be used because the condition (2) based on the usage date / time is not satisfied.
  • the use date and time contributes to prevention of unauthorized use in the stand-alone mode
  • the state shown in FIG. 6C is obtained.
  • the use date / time of the offline token is also set to a date / time after the expiration date at the time of authentication, and the arrows tr1 to tr3.
  • the client date and time are indicated by arrows. Even if the date and time are corrected to the correct date and time as indicated by ta, the usage date and time does not go back, so that an area that satisfies all the conditions of the arrows tr1 to tr3 cannot be obtained.
  • the use date and time is exceptionally traced back to the past 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). Is allowed.
  • the usage date and time is corrected to the authentic current date and time in FIG. 6C, so that the condition (2) is in the state indicated by the dashed arrow tr2, and all The time range that satisfies the conditions can be restored.
  • the application can be used even when the client is offline. Further, in the stand-alone mode, by using fixed date / time information (switching date / time and expiration date) and dynamic date / time information (use date / time), unauthorized use of the application can be prevented.
  • switching date / time and expiration date switching date / time and expiration date
  • dynamic date / time information use date / time
  • the present invention can be used to perform authentication for using an application in a client connected to a server via a network.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

【課題】　オンラインによる認証とオフラインによる認証の利点を活かした認証を実現する。 【解決手段】　サーバ１０は、クライアントＰＣからの認証要求に従って、認証を行い、アプリケーションの利用を許可する場合には、トークンを発行する。オフラインでもアプリケーションを利用したい場合には、サーバ１０に対してスタンドアロンモードへの切替を要求すると、サーバは、発行済みのトークンを一定期間有効となるオフライン用に変更する。オフライン用トークンには、有効期限を表す固定的な情報だけでなく、認証のたびに更新される動的な日時情報も含まれる。動的な日時情報を含めることにより、有効期限を過ぎた後にクライアントＰＣの時計を遡らせる方法によるトークンの不正利用を防止することができる。こうすることで、オンラインでの認証システムをオフラインでも利用可能としつつ、不正利用を防止することが可能となる。

Description

認証システム
　本発明は、ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムに関する。
　アプリケーションの利用時には、ユーザが、その利用についてライセンスを有しているかの認証が、種々の方法によって行われている。近年では、アプリケーションを利用するクライアントがインターネットに接続されている環境にあることを前提として、同じくインターネット上のサーバによって、ライセンスを管理するための技術も多く提供されている。
　例えば、特許文献１は、ネットワークを利用してアプリケーションの認証を行う際に、端末に固有の識別情報を取得することによって、正規に許容された端末以外の非正規端末におけるアプリケーションの利用を防ぐ技術を開示している。
　特許文献２は、同様に端末に固有の識別情報を含むライセンスキーを利用して認証を行う場合において、アプリケーションを利用している端末の識別情報をデータベースで管理することにより、他の端末で認証が行われたときは、従前利用していた端末での利用を停止させた上で、新たな端末での利用を認める技術を開示している。
　特許文献３は、ライセンス時に、アプリケーションをインストール可能な台数、アプリケーションを同時に起動可能なライセンス数という２つの設定値を設けることにより、アプリケーションをインストールする台数および同時に稼働する台数の双方を制御する技術を開示している。
　特許文献４は、サーバによって認証を行う際に、有効期限付きのアクセストークンを発行し、このアクセストークンの有効期限が過ぎていないかを確認することによって、アプリケーションの利用中においても、ライセンスの認証を行う技術を開示している。
特開２０１３－０１５９３０号公報 特開２００９－１１６３９２号公報 特開２０１５－１４８１７号公報 特開２０１６－０１８５２９号公報
　従来技術における認証方法において、特許文献１～４のようにオンラインを前提としたサーバでの認証では、アプリケーションがインストールされたクライアントが、サーバと通信可能に接続されたオンライン状態でないと、アプリケーションを利用できないという課題があった。また、サーバと接続していないオフラインの状態でも認証可能な方法を採用すると、アクセストークンの有効期限を改ざんするなどの不正が行われる危険性が高まるという課題があった。このように、オンラインでの認証には、利便性に欠けるという課題があり、一方で、オフラインでの認証は不正への対処が不十分であった。
　本発明は、かかる課題に鑑み、オンラインによる認証とオフラインによる認証の利点を活かした認証を実現することを目的とする。
　本発明は、
　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムであって、
　前記サーバは、
　前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するトークン発行部と、
　前記生成されたトークンを管理するトークン管理部と
を備え、
　前記クライアントは、
　　前記オフライン用トークンを保持するトークン保持部と、
　　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可部と、
　　前記利用許可部の動作に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新部と
を備える認証システムとして構成することができる。
　クライアントに構成されるトークン保持部、利用許可部、および日時情報更新部は、それぞれアプリケーションとは別個に構成してもよいし、アプリケーションの一部として組み込んでもよい。
　本発明では、サーバから発行されるオフライン用トークンを用いて、クライアントにおけるアプリケーションの利用の許可／禁止を行うことができる。従って、オフライン用トークンの発行時には、クライアントはサーバにネットワークで接続されている必要があるが、その後は、サーバに接続されていなくとも、アプリケーションを利用することができるため利便性が確保される。
　しかも、本発明で用いられるオンライン用トークンには、有効か否かを判定するための日時として、有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報が含まれる。固定的な日時情報としては、オフライン用トークンを利用可能な最終の日時情報、オフライン用トークンの利用を開始可能な日時または発行日時、オフライン用トークンの利用を開始してから利用できなくなるまでの期間などの情報を用いることができる。これらを全てもちいてもよいし、一部を用いても良い。また、動的な日時情報としては、認証を実行した日時、アプリケーションを利用した日時、オフライン用トークンの利用を開始した後の経過時間などを利用することができる。その上で、現在時刻が動的な日時情報以降であること、および有効期限内であることという２つの条件を満たすときにアプリケーションの利用を許可するように判断する。ここで用いる現在時刻は、クライアントの時計に基づいて得られる時刻でよい。このように、固定的な日時情報に加えて、動的な日時情報を用いれば、仮に有効期限を過ぎた後にクライアントの時計を遡らせたとしても、現在時刻が動的な日時情報以降という条件を満たさないため、オフライン用トークンを不正に利用することはできなくなる。
　従って、本発明は、不正を抑制しつつ、オフラインでアプリケーションを利用できる利便性を実現することが可能となる効果を奏する。
　本発明においては、
　前記日時情報更新部は、前記動的な日時情報を、将来に向かう方向にのみ更新するよう規制されているものとしてもよい。
　こうすることにより、動的な日時情報を遡らせるという不正を防ぐことができ、アプリケーションの不正利用をより確実に回避することが可能となる。
　このように日時情報の更新を規制する場合、
　前記日時情報更新部は、オンラインとなった時には、前記規制を解除し、前記動的な日時情報を、前記ネットワーク経由で取得される日時に同期させるものとしてもよい。
　こうすることにより、動的な日時情報が誤って不正確な日時となったときに、その修正を図ることができる。例えば、クライアントの時計が、何らかの理由で、有効期限以降の将来の日時に変動してしまったとすると、動的な日時情報もこれに併せて将来の日時に更新されてしまう可能性があり、真の現在時刻が有効期限内であったとしても、オフライン用トークンに基づくアプリケーションの利用ができなくなってしまう。そして、動的な日時情報は不正防止のため簡単には遡らせることができないから、一旦、かかる事態が生じてしまうと、クライアントの時計を正常に戻しても、アプリケーションの利用は再開できなくなってしまうおそれがある。
　上記態様によれば、クライアントがオンラインとなった時には、例外的に動的な日時情報の同期を認めることができ、正常な時刻に遡らせることも可能となるから、アプリケーションの利用を復旧させることができる。
　また、本発明においては、
　前記サーバは、前記クライアントからの認証要求に応じて、前記クライアントがオンライン状態にある場合の認証に用いるための該クライアントに固有のオンライン用トークンの有効性、および前記アプリケーションの起動を許可するための起動条件の少なくとも一方を踏まえて、該クライアントにおける前記アプリケーションの利用を許可するか否かの認証を行う認証部を有し、
　前記クライアントは、前記アプリケーションの起動時および起動後の所定のタイミングで、繰り返し、前記サーバに対して前記認証要求を送信する認証要求送信部を有し、
　前記サーバにおいて、
　前記トークン発行部は、前記認証により前記アプリケーションの利用を許可する場合、該クライアントに固有の有効なオンライン用トークン、または前記クライアントに対して発行済みのオンライン用トークンが有効であることを示す情報を前記クライアントに送信し、
　前記トークン管理部は、前記認証要求に対応する発行済みのオンライン用トークンであって、前記トークン発行部によって新たに生成されたオンライン用トークンとは異なるクライアントに対して発行されたものがある場合は、所定の無効化条件に従って当該発行済みのオンライン用トークンを無効化し、
　前記クライアントにおいて、
　　前記利用許可部は、前記オンライン用トークンが有効であることが確認できたときは前記アプリケーションの利用を許可し、その他の場合は前記アプリケーションの利用を禁止するものとしてもよい。
　上記態様は、ネットワークに接続した状態での認証、即ちオンライン認証を実現する態様である。即ち、サーバは、クライアントからの認証要求に応じて認証を行う。この認証は、クライアントにおいて新たにアプリケーションを起動させる場合、および既にアプリケーションを利用している場合に行われる。後者の場合は、アプリケーションの利用中に、ユーザが指示しなくても、クライアントが定期的にサーバに対して認証要求を送信するのである。
　サーバは、アプリケーションの利用を許可する場合には、オンライン用トークン等の情報をクライアントに送信する。例えば、クライアントにおいて新たにアプリケーションを起動するときは、新しいオンライン用トークンを発行し、それをクライアントに送信する。オンライン用トークン自体に代えて、オンライン用トークンの識別情報を送信する態様も含まれる。
　一方、既にクライアントにおいてアプリケーションを利用しているときは、既存のオンライン用トークンが有効である旨の情報をクライアントに送信する。既存のオンライン用トークンに代わる新たなオンライン用トークンを発行し、それをクライアントに送信するようにしてもよい。
　こうすることにより、クライアントでは、有効なオンライン用トークン（その識別情報や、オンライン用トークンが有効であることを示す情報も含む）を受け取ると、アプリケーションの利用を許可することができる。
　本発明では、さらに、サーバは、異なるクライアントからの認証要求が送信された場合には、発行済みのオンライン用トークンを無効化した上で、新たなオンライン用トークンを発行する。発行済みのオンライン用トークンが無効化されることにより、従前、アプリケーションを利用していた端末では、アプリケーションの利用ができなくなる。つまり、ユーザは、使用する端末を変更したい場合、従前の端末でアプリケーションの利用を停止しなくても、新たな端末から認証要求を送信しさえすれば、容易に端末を変更することができることになる。
　既に発行されているオンライン用トークンと異なる端末からの認証要求か否かを判断するために、本発明では、オンライン用トークンは、クライアントに「固有」なものとしている。例えば、クライアントの端末に固有の識別情報をオンライン用トークンに含めるようにしてもよいし、オンライン用トークンをクライアントの識別情報と関連付けて管理してもよい。
　本発明においては、
　前記認証要求は、前記アプリケーションの開発者の識別情報、該アプリケーションの識別情報、該アプリケーションのユーザのアカウント情報、該クライアントの端末識別情報を含み、
　前記認証は、前記認証要求に含まれる各情報と、前記サーバに予め登録された情報との整合性を考慮して行われるものとしてもよい。
　こうすることにより，本発明による認証を複数の開発者、アプリケーション、ユーザ、クライアント端末で混乱なく利用可能なシステムとすることができる。例えば、認証要求にアプリケーションの開発者の識別情報を含めることにより、例え他の情報（アプリケーションの識別情報、アカウント情報、端末情報）が同一であったとしても、認証要求としては、開発者に関連づけられたものと認識することができるからである。従って、各開発者は、他の開発者がどのようなアプリケーションの識別情報、アカウント情報を用いているかを考慮せず、これらについて任意に設定することが可能となるのである。
　また、本発明においては、
　前記サーバは、
　　前記アプリケーションの識別情報および前記ユーザのアカウント情報とを記憶しておくデータベースを、前記アプリケーションの開発者ごとに個別に備えるものとしてもよい。
　こうすることにより、アプリケーションの開発者ごとに、データ管理をすることが可能となり、より本発明の利便性を向上させることが可能となる。
　本発明は、以上で説明した種々の特徴を必ずしも全て備えている必要はなく、適宜、その一部を省略したり、組み合わせたりして構成してもよい。また、本発明は、上述した認証システムとしての構成に限らず、種々の態様での構成が可能であり、
例えば、
　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証方法であって、
　前記サーバが実行する処理として、
　前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するステップと、
　前記生成されたトークンを管理するステップと
を備え、
　前記クライアントが実行する処理として、
　　前記オフライン用トークンを保持するトークン保持ステップと、
　　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可ステップと、
　　前記利用許可ステップに伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新ステップと
を備える認証方法として構成してもよい。
これらの認証方法においても、認証システムで説明した種々の特徴を組み込むことが可能である。
　また、上述の認証方法を、コンピュータに実現させるためのコンピュータプログラム、およびこれらのコンピュータプログラムを記録したコンピュータ読み取り可能な記録媒体として構成することもできる。かかるコンピュータプログラムとしては、サーバにインストールするものとして構成することもできるし、クライアントにインストールするものとして構成することもできる。後者の態様としては、
例えば、
　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行うために該クライアントにおいて実行させるコンピュータプログラムであって、
　前記サーバに対して認証要求を送信する機能と、
　前記サーバから、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを受信する機能と、
　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可機能と、
　前記利用許可機能の実行に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新機能と
を前記クライアントに実現させるためのコンピュータプログラムとしての構成である。
　これらのコンピュータプログラムにおいても、認証システムで説明した種々の特徴を組み込むことが可能である。クライアントに実行させるコンピュータプログラムの場合、クライアントで利用するアプリケーションとは別のコンピュータプログラムとして用意することもできるし、アプリケーションに組み込む形で用意することもできる。
実施例としての認証システムの構成を示す説明図である。 データベースの構成を例示する説明図である。 ネットワーク認証処理のフローチャートである。 スタンドアロン切替処理のフローチャートである。 アプリケーション利用許可処理のフローチャートである。 利用日時更新の内容を示す説明図である。
Ａ．システム構成：
　本発明の実施例について説明する。
　図１は、実施例としての認証システムの構成を示す説明図である。認証システムは、インターネットＩＮＴにクライアントＰＣおよびサーバ１０が接続された環境下において、クライアントＰＣにインストールされたアプリケーションの利用についての認証をサーバ１０が与えるためのシステムである。以下、ネットワークを介した認証を、「クラウド認証」と称することもある。
　図１においては、クライアントＰＣは１台のみを示したが、複数台であってもよい。クライアントＰＣは、ＣＰＵ、メモリなどを備え種々のアプリケーションを実行できるコンピュータであり、パーソナルコンピュータの他、タブレット、スマートフォン、携帯電話などを利用可能である。
　認証システムは、サーバ１０に備えられる機能と、クライアントＰＣに備えられる認証システムモジュール２０とによって構築されることになる。本実施例では、サーバ１０およびクライアントＰＣに、図示した各機能ブロックを実現するためのコンピュータプログラムをインストールすることによって、ソフトウェア的に構成されるが、少なくとも一部をハードウェア的に構成することも可能である。また、サーバ１０に示した各機能ブロックは、複数のサーバによる分散処理によって実現してもよい。
　本実施例の認証システムは、例えば、次のような態様で利用される。アプリケーションの開発者であるデベロッパは、アプリケーションを利用する権利、即ちライセンスを、ユーザに有償で提供することにより利益を得る。かかる利益を適正に得るためには、ユーザによるアプリケーションの不正利用を防止する必要があり、そのためには、アプリケーションの利用時にユーザが有効なライセンスを有しているか否かを認証する必要がある。かかる認証を実現するのが、本実施例の認証システムである。この認証システムは、アプリケーションのデベロッパ自身が構築し、運用するものとしてもよいが、本実施例では、デベロッパ以外の運用主体が認証システムを運用する例を示した。即ち、デベロッパは、認証システムの運用主体と、認証システムの利用契約を締結した上で、クライアントＰＣにインストールされる認証システムモジュール２０を用意する。この認証システムモジュール２０は、デベロッパが開発するアプリケーションに組み込んでも良いし、アプリケーションと別のモジュールとしてもよい。デベロッパからアプリケーションのライセンスを受けたユーザは、自身のクライアントにアプリケーションをインストールすることにより、同時に、認証システムモジュール２０もインストールすることになる。かくして、アプリケーションは、本実施例の認証システムによる認証の下で、稼働するようになるのである。
　サーバ１０に備えられた各機能ブロックについて説明する。
　サーバ１０には、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８の３種類のデータベースが備えられている。デベロッパ情報データベース１６は、認証システムを利用するアプリケーションのデベロッパに関する情報を格納する。ライセンス情報データベース１７およびアカウント情報データベース１８は、それぞれデベロッパごとに用意されるデータベースである。ライセンス情報データベース１７は、アプリケーションのライセンスを購入したユーザおよびライセンス条件などの情報を記憶する。アカウント情報データベース１８は、ライセンスを受けたユーザが利用可能なアカウント（またはユーザＩＤということもある）に関する情報を記憶する。これらのデータベースの内容については、後で具体的に説明する。
　データベース管理部１３は、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８に対するデータの読み書きを管理する。
　送受信部１１は、インターネットＩＮＴを介して種々の情報の送受信を実行する。本実施例で送受信される情報としては、例えば、アプリケーションの利用の認証を求める認証要求や、利用を許可するためのトークンなどが挙げられる。
　認証部１４は、サーバ１０における各機能ブロックを統合する機能も奏しつつ、アプリケーションの認証を行う。本実施例では、後で説明する通り、アプリケーションの起動時に認証が行われる他、アプリケーションの利用中にも繰り返し認証が行われる。認証部１４は、クライアントＰＣから認証要求を受取り、それぞれのタイミングにおいて、デベロッパ情報データベース１６、ライセンス情報データベース１７、アカウント情報データベース１８、トークン管理部１５などに格納された情報を参照しながら、アプリケーションの利用可否を判断するのである。
　トークン発行部１２は、認証部１４による認証の結果、アプリケーションの利用を許可する場合に、必要に応じて、新たなトークンを発行する。トークンとは、クライアントＰＣにアプリケーションの利用を許可するためのワンタイム、即ち使い捨ての情報である。
　トークン管理部１５は、発行されたトークンを保持する。
　次に、クライアントＰＣに備えられた各機能ブロックについて説明する。
　送受信部３０は、インターネットＩＮＴを介して各種情報の送受信をする。
　アプリケーション３１は、クライアントＰＣで利用される種々のコンピュータプログラムである。本実施例の認証の対象となっているものもあれば、そうでないものも含まれ得る。本実施例では、以下、アプリケーション３１と呼ぶときは、本実施例の認証の対象となっているものを意味するものとする。
　認証システムモジュール２０は、サーバ１０と連携して、本実施例の認証システムを構築するモジュールである。認証システムモジュール２０は、アプリケーション３１と個別のモジュールとして用意してもよいし、各アプリケーション３１に組み込むものとしてもよい。
　認証要求送信部２１は、サーバ１０に対して認証を要求する情報（これを認証要求と呼ぶ）を送信する。認証要求送信部２１は、クライアントＰＣにおいて新たにアプリケーションを起動しようとするときに、認証要求を送信する。また、アプリケーションの利用中は、ユーザからの指示に関わらず所定のタイミングで繰り返し認証要求を送信する。
　認証用情報記憶部２２は、認証要求に含まれる情報を一時的に格納しておく。認証要求に含まれる情報には、クライアントＰＣの端末固有の識別情報も含まれる。また、アプリケーションの認証要求に対して、サーバ１０からトークンが発行されているとき、認証用情報記憶部２２は、このトークンも記憶しておく。
　利用許可部２３は、サーバ１０による認証が得られた場合には、アプリケーション３１の利用を許可する。また、本実施例では、クライアントＰＣがサーバ１０と接続されていない状態での認証も行うことができるスタンドアロンモードが用意されている。利用許可部２３は、スタンドアロンモードの場合には、認証用情報記憶部２２に記憶された情報、特にオフライン用トークンに基づいて、アプリケーション３１の利用可否を判断する機能も奏する。
　日時情報更新部２４は、スタンドアロンモードにおいて、認証用情報記憶部２２に記憶されているオフライン用トークンに含まれる「利用日時」の情報を更新する。「利用日時」とは、後述する通り、オフライン用トークンの不正利用を防止するための情報である。日時情報更新部２４は、スタンドアロンモードでの認証が行われたときなど、所定のタイミングで、利用日時を更新するのである。
Ｂ．データベース構成：
　図２は、データベースの構成を例示する説明図である。
　デベロッパ情報データベース１６は、認証システムを利用するアプリケーションのデベロッパに関する情報を格納するデータベースである。
　デベロッパＩＤは、デベロッパの識別情報である。
　契約情報は、認証システムの運用主体と、デベロッパとの契約に関連する情報を表す。契約情報には、例えば、デベロッパの名称、連絡先、契約条件、課金情報、支払情報などが含まれる。
　デベロッパキーは、アプリケーションの認証の際に用いられるデベロッパに固有の情報である。デベロッパキーは、デベロッパＩＤと同じ情報とすることもできるが、本実施例では、別個の情報を用いるものとした。
　アプリケーション名称およびアプリケーションＩＤは、本実施例の認証対象となるアプリケーションの名称および識別情報である。アプリケーション名称、アプリケーションＩＤは、デベロッパごとに複数設けることもできる。デベロッパ情報データベース１６は、デベロッパごとに情報が格納されるものであるから、アプリケーション名称、アプリケーションＩＤは、他のデベロッパのアプリケーション名称等と重複していても差し支えない。もっとも、本実施例では、混乱を回避するため、アプリケーションＩＤについては、デベロッパによってアプリケーションが新たに登録されたときに、認証システムが他のデベロッパとも重複しない固有の識別情報を付すものとした。
　ライセンス情報データベース１７、アカウント情報データベース１８は、それぞれデベロッパごとに用意されるデータベースである。
　ライセンス情報データベース１７は、アプリケーションのライセンスを購入したユーザおよびライセンス条件などの情報を記憶する。ユーザによるライセンスごとに図示するデータが用意されることになる。
　アプリケーションＩＤは、ライセンスの対象となるアプリケーションの識別情報である。デベロッパ情報データベース１６に格納されているアプリケーションＩＤに対応した情報である。
　デベロッパキーは、デベロッパを表す情報であり、デベロッパ情報データベース１６に格納されている情報である。
　購入ライセンス数は、ユーザが購入したライセンス数、即ちアプリケーションを同時に利用可能な数を表す情報である。他に、コンピュータにインストール可能な数を表す情報を追加してもよい。
　適用開始日時は、ライセンスの適用によりアプリケーションの利用を開始できる日時を表す。
　有効期限は、ライセンスの有効期限、即ちアプリケーションの利用が許可される期限を表す。
　アカウント当たりのライセンス数は、一つのアカウント、即ち利用者ＩＤによってアプリケーションを同時に利用可能な数を表す。
　アカウント情報データベース１８は、ライセンスを受けたユーザが利用可能なアカウント（またはユーザＩＤということもある）に関する情報を記憶する。例えば、会社がライセンスを受け、複数の従業員にアプリケーションを利用させるような場合など、一つのライセンス情報に対して、複数のアカウント情報が対応づけられることもある。
　利用者ＩＤは、アプリケーションの利用者の識別情報であり、パスワードは、アプリケーションを利用するために認証画面において入力すべき情報である。
　権限は、アプリケーションの利用について、利用者に許容された権限である。本実施例では、クライアントがサーバに接続された状態でアプリケーションの認証を行うオンライン認証の他、サーバと接続されていないオフライン状態でも認証可能なスタンドアロンモードが用意されている。権限には、スタンドアロンモードの利用可否を設定可能とした。
　適用開始日時は、利用者ごとに、アプリケーションの利用を開始できる日時を記憶している。
　いずれのデータベースにおいても、図示した各情報の全てを備えている必要はなく、一部を必要に応じて省略してもよい。また、図示した以外の情報をデータベースに追加しても良い。本実施例では、ライセンス情報データベース１７とアカウント情報データベース１８とを分けて用意したが、両者を統合したデータベースとすることもできる。
Ｃ．トークンの構成：
　次に、本実施例の認証で利用されるトークンの構成について説明する。トークンは、クライアントＰＣにアプリケーションの利用を許可するためのワンタイム、即ち使い捨ての情報である。トークンを構成する情報は、任意に設定可能であるが、本実施例では、以下の情報を含めるものとした。
　「トークンＩＤ」、即ちトークンの識別情報である。
　ライセンス情報データベース１７に格納されている「アプリケーションＩＤ」、デベロッパキー」である。
　「ライセンス種別」、即ちオンライン認証用か、スタンドアロン用かを示す情報である。
　ライセンス情報データベース１８に格納されている「利用者ＩＤ」である。
　スタンドアロンモードのときに利用される情報として、「利用日時」、「有効期限」、「切替日時」などの情報である。これらの各情報の意味は後述する。
　クライアントの「端末ＩＤ」、即ちハードウェア固有の識別情報である。
　その他の管理情報などを含めることもできる。
Ｄ．オンライン認証：
　以下、本実施例の認証システムによる認証処理によって順に説明する。
　図３は、オンライン認証処理のフローチャートである。オンライン認証とは、クライアントとサーバとがインターネットを介して通信可能な状況で行う認証処理である。この処理は、クライアントからサーバに対する認証要求が送信されたときにサーバによって実行される。認証要求が送信される場面としては、利用者が新たにアプリケーションを起動させるとき、および既にアプリケーションを利用しているときがある。後者の場合は、利用者の指示に関係なく、所定のタイミングで、クライアントが自動的に認証要求をサーバに送信するのである。
　サーバは、まず認証要求を受信する（ステップＳ１０）。認証要求には、デベロッパキー、アプリケーションＩＤ、利用者ＩＤ、パスワード、端末ＩＤが含まれる。デベロッパキーおよびアプリケーションＩＤが含まれることにより、認証システムを利用する契約が締結された正規のデベロッパが作成した正規のアプリケーションからの認証要求であることを確認することができる。また、デベロッパキーを含むことにより、アプリケーションＩＤ、利用者ＩＤ、パスワードは、他のデベロッパとの重複を考慮することなく、デベロッパごとに任意に設定された情報を利用することが可能となる。もっとも、利用者ＩＤ、パスワードなどは、認証システムにおいてデベロッパに依存せずに利用可能な情報としても差し支えない。
　アプリケーションの利用中に送信される認証要求の場合は、利用者ＩＤやパスワードなどの情報を省略してもよい。また、デベロッパキー、アプリケーションＩＤなどの情報に代えて、認証の際に発行されるトークンを用いるようにしてもよい。
　端末ＩＤは、クライアントに固有の情報であり、本実施例ではクライアントおよびアプリケーションの組み合わせに対して固有の情報となるSecureUDIDを利用するものとした。端末ＩＤとしては、他にＭＡＣアドレスなどを用いても良い。端末ＩＤを用いることにより、サーバは、インターネットに複数のクライアントが接続されている状態でも、認証要求を送信したクライアントを特定することができる利点がある。
　次に，サーバは、認証要求が有効か否かを判断する（ステップＳ１１）。本実施例では、次の４つの条件を満たすときに、認証要求が有効と判断するものとした。
　条件(１)は、デベロッパキーが有効であること、即ち認証要求に含まれるデベロッパキーが、デベロッパ情報データベース１６に格納された情報と一致することである。
　条件（２）は、アプリケーションＩＤが有効であること、即ち認証要求に含まれるアプリケーションＩＤが、デベロッパ情報データベース１６またはライセンス情報データベース１７に格納された情報と一致することである。
　条件（３）は、利用者ＩＤ、パスワードが有効であること、即ちこれらの情報が、アカウント情報データベース１８に格納された情報と一致することである。
　条件（４）は、ライセンスの有効期限内であること、即ち認証を行っている時刻が、ライセンス情報データベース１７に格納された「有効期限」の情報と整合することである。
　アプリケーションの利用中に送信された認証要求の場合は、条件（３）を省略してもよい。
　上述の４つの条件のいずれかを満たさず、認証要求が有効ではないと判断されると（ステップＳ１１）、サーバは、アプリケーションの利用を認めることなく、オンライン認証処理を終了する。
　一方、認証要求が有効であると判断された場合（ステップＳ１１）、サーバは、トークン管理部１５（図１参照)に格納された発行済みのトークンを検索し、認証要求に対応するトークンが発行されたか否かを判断する。認証要求に対応するトークンとは、デベロッパキー、アプリケーションＩＤ、利用者ＩＤが一致するトークンを言う。
　トークンが発行済みでない場合において（ステップＳ１２）、アプリケーションの利用数が有効範囲内におさまるときは（ステップＳ１７）、サーバは新規にトークンを発行する（ステップＳ１８）。クライアントがトークンを受け取ると、アプリケーションは利用可能となる。アプリケーションの利用数が有効範囲を超えるときは（ステップＳ１７）、サーバはアプリケーションの利用を認めることなく、オンライン認証処理を終了する。
　アプリケーションの利用数が有効範囲を超えるか否かの判断（ステップＳ１７）は、例えば、次の手順で行うことができる。トークン管理部１５に格納されたデベロッパキー、アプリケーションＩＤが認証要求と一致するトークンを検索することにより、アプリケーションの利用数を求めることができる。この利用数が、ライセンス情報データベース１７に格納された購入ライセンス数よりも小さい場合には、新たにアプリケーションの利用を認めても、利用数が購入ライセンス数を超えることはないため、アプリケーションの利用数は有効範囲内におさまると判断できる。また、この利用数が、ライセンス情報データベース１７と一致する場合は、アプリケーションの利用数は有効範囲を超えると判断できる。
　一方、認証要求に一致するトークンが発行済みの場合（ステップＳ１２）、サーバは、発行済みのトークンと認証要求にそれぞれ含まれる端末ＩＤが一致するかを判断する（ステップＳ１３）。
　両者が一致するときは、サーバは、トークンを発行済みのクライアントから、アプリケーション利用中に繰り返し認証要求が送信されたものと判断し、トークンを継続利用する処理を行う（ステップＳ１６）。例えば、トークン管理部１５に格納されているトークンを改めてクライアントに送信してもよいし、発行済みのトークンが有効である旨の情報をクライアントに送信してもよい。
　発行済みのトークンと認証要求にそれぞれ含まれる端末ＩＤが一致しない場合（ステップＳ１３）、サーバは、利用者が異なる端末から認証要求を送信したと判断し、以下の処理を行う。まず、サーバは、アカウント当たりのライセンス数を確かめる（ステップＳ１４）。即ち、トークン管理部１５から認証要求に含まれる利用者ＩＤを含むトークンの数を求めることにより、認証要求を送ったアカウントによるアプリケーションの利用数を求め、この利用数と、ライセンス情報データベース１７に格納されたアカウント当たりのライセンス数を比較する。
　この結果、アプリケーションの利用数がアカウント当たりのライセンス数の範囲内と判断されるときは（ステップＳ１４）、サーバは、先に説明したステップＳ１７の処理によって、アプリケーションの利用可否を判断する。また、アプリケーションの利用数がアカウント当たりのライセンス数を超過すると判断されるときは（ステップＳ１４）、発行済みのトークンを無効化して（ステップＳ１５）、利用中のアプリケーションの利用を停止した上で、先に説明したステップＳ１７の処理によって、アプリケーションの利用可否を判断する。
　このように、同じ利用者ＩＤを含みつつ、端末ＩＤが一致しない認証要求がなされたときに、発行済みのトークンを無効化することにより、利用者は、それまでに利用していたアプリケーションを停止させるまでなく、異なる端末でアプリケーションを容易に利用することが可能となる利点がある。
　トークンの無効化は、認証要求と利用者ＩＤが一致するトークンに対して行われるものであり、利用者ＩＤが異なるトークンに対しては、行われない。即ち、利用者ＩＤが異なる場合には、先にアプリケーションを利用していたものが優先して扱われ、利用者ＩＤが一致する場合には、あとから認証した端末が優先して扱われることになる。
Ｅ．スタンドアロン認証：
　図４は、スタンドアロン切替処理のフローチャートである。オンライン認証が行われた後、オフラインでもアプリケーションを利用することができるスタンドアロンモードに切り替えるための処理である。この処理は、利用者が、クライアントからサーバに対して切替要求を送信することによって、サーバにおいて実行される。
　サーバは、まず切替要求を受信する（ステップＳ２０）。切替要求には、トークン、有効期限、クライアント日時、および端末ＩＤの各情報が含まれる。トークンとは、オンライン認証によって発行されたトークンである。本実施例では、オンラインで認証を受けた後、スタンドアロンモードへの切替を行うものとしたため、このように切替要求にはトークンを含めることができる。もっとも、最初からスタンドアロンモードでの認証を認めるようにしてもよい。この場合でも、アプリケーションの起動時には、トークンを受け取るために、クライアントとサーバが接続されていることが前提となるから、先に説明したオンライン認証（図３参照）を実行した後、自動的にスタンドアロン切替処理に移行するようにすれば足りる。
　有効期限はトークンの有効期限、クライアント日時は、クライアントが保持する時計に基づく日時情報である。端末ＩＤはオンライン認証処理と同様である。切替要求には、スタンドアロンモードでの利用を希望する期間などの情報を含めても良い。
　サーバは、受信した切替要求の有効性を判断する（ステップＳ２１）。本実施例では、次の２つの条件を満たすときに有効と判断するものとした。
　条件（１）トークンが有効とは、切替要求に含まれるトークンが、サーバのトークン管理部１５（図１参照）に無効化されずに管理されていることを意味する。
　条件（２）ライセンスの有効期限内とは、ライセンス情報データベース１７に格納された有効期限を過ぎていないことを意味する。ライセンス自体が有効期限を超過している場合は、スタンドアロンモードへの切替えを認める必要もないからである。
　条件（１）（２）のいずれか一方または双方を満たさず、切替要求が無効と判断される場合には（ステップＳ２１）、サーバは、切替えを認めることなく、この処理を終了する。
　切替要求が有効な場合（ステップＳ２１）、サーバは、スタンドアロンモードへの変更が要求されたアプリケーションに対して有効なトークンが発行されているかを判断する（ステップＳ２２）。かかるトークンが発行されていない場合には、オンラインでの認証が未了と判断し、サーバは、切替えを認めることなく、この処理を終了する。
　有効なトークンが発行されている場合には（ステップＳ２２）、そのトークンがスタンドアロンモードに設定されているか否かを判断し（ステップＳ２３）、既にスタンドアロンモードになっている場合には、そのトークンを継続利用する（ステップＳ２６）。つまり、クライアントに対して、改めて切替要求を認めることなく、既に発行されているトークンを再送するか、発行済みのトークンを利用できる情報を送信する。
　発行済みのトークンがオンライン認証用である場合には（ステップＳ２３）、サーバは、以下の手順で、スタンドアロンモードへの切替えのための処理を行う。まず、クライアントの時計の日時を取得し、その誤差が許容範囲内かを判断する(ステップＳ２４)。後述する通り、本実施例においては、スタンドアロンモードによる認証では、トークンに格納された日時情報によって、利用者によるアプリケーションの不正利用を防止している。スタンドアロンモードへの切替時に、クライアントの時計の誤差が大きい場合には、アプリケーションの不正利用を防止できないおそれがある。従って、誤差が許容範囲を超える場合には（ステップＳ２４）、スタンドアロンモードへの切替えを認めず、誤差が許容範囲内のときのみ、スタンドアロンモードへの切替を実行して（ステップＳ２５）、この処理を終了する。切替を認めるか否かの判断基準としての、「誤差の許容範囲」は、不正利用防止の観点から、任意に設定可能な値である。
　スタンドアロンモードへの切替では、スタンドアロンモードであることを表すオフライン用トークンがクライアントに送信される。オフライン用トークンには、スタンドアロンモードへの切替日時、同モードで利用可能な有効期限、および利用日時などの情報が含まれる。切替日時および有効期限は、スタンドアロンモードへの切替時に設定される固定的な日時情報であるが、利用日時は、オフライン用トークンを利用して認証を行った最後の日時を表す情報であり、オフライン用トークンの利用に伴って更新される動的な日時情報である。クライアントは、このオフライン用トークンを、認証用情報記憶部２２（図１参照）に保持する。　
　図５は、アプリケーション利用許可処理のフローチャートである。この処理は、クライアントにおいて、アプリケーションを利用する際に実行される処理である。この処理が実行される場面としては、アプリケーションを新規に起動するとき、およびアプリケーションを既に利用しているときがあり、クライアントがオンラインの場合とスタンドアロンの場合とがある。アプリケーションの利用中である場合には、例えば、一定の周期でこの処理を実行するようにしてもよいし、アプリケーションに対するユーザの特定の操作をトリガとして実行するようにしてもよい。
　処理を実行し、クライアントがネットワークに接続されている場合であって（ステップＳ３０）、アプリケーションを起動中でない場合（ステップＳ３１）、つまりアプリケーションを新たに起動する場合には、クライアントは認証画面を表示する（ステップＳ３２）。認証画面とは、利用者ＩＤおよびパスワードなどの認証情報を入力するための画面である。そして、入力された認証情報も含めて、認証要求をサーバに送信し、またクライアントの時計をサーバと同期する（ステップＳ３３）。
　既にアプリケーションを起動しているときは（ステップＳ３１）、認証画面の表示をスキップした上で、認証要求をサーバに送信し、またクライアントの時計をサーバと同期する（ステップＳ３３）。この場合の認証要求からは、利用者ＩＤやパスワードの情報は省略してもよい。
　ステップＳ３３の処理において、クライアントの時計を同期するのは、次の理由によるものである。本実施例では、スタンドアロンモードにおいて、トークンに記録された日時情報（利用日時という）によって、アプリケーションの不正利用を防止している。かかる観点から、クライアントとサーバの時計が同期していることが好ましいのである。また、スタンドアロンモードにおいて時計が同期されたときは、それに合わせてトークンの利用日時の情報も同期させるものとしている。この意義については、後で説明する。
　クライアントは、認証要求を送信した後、スタンドアロンモードでない場合は（ステップＳ３４）、サーバでの認証が完了するのを待つ。サーバからトークンが受信できない場合には（ステップＳ３５）、クライアントは、アプリケーションの利用を禁止して（ステップＳ３６）、この処理を終了する。トークンが受信できない（ステップＳ３５）とは、トークンが所定の待機時間内に受信できなかった場合や、認証に失敗した旨の情報をサーバから受信した場合などが含まれる。
　一方、サーバからトークンを受信できた場合には（ステップＳ３５）、クライアントはアプリケーションの利用を許可して（ステップＳ４３）、この処理を終了する。利用の許可には、新規にアプリケーションを起動する場合、および利用中のアプリケーションを継続的に利用可能とする場合の双方が含まれる。受信したトークンは、認証用情報記憶部２２（図１参照）に保持される。
　スタンドアロンモードの場合（ステップＳ３４）には、利用可否判断を行う（ステップＳ４０)。クライアントがネットワークに接続されていない場合（ステップＳ３０）も同様である。
　利用可否判断とは、アプリケーションの利用を許可するか否かの判断であり、クライアントは、認証用情報記憶部２２に保持されたオフライン用トークンを参照し、次の３つの条件を満たすときに、利用可能と判断する。
　条件（１）は、クライアント日時は切替日時以降であるという条件である。クライアント日時とは、クライアントの時計の日時を意味する。切替日時とは、スタンドアロンモードへの切替えが行われた日時を意味する。これらの情報は、オフライン用トークンに記録されている。
　条件（２）は、クライアント日時は利用日時以降であるという条件である。利用日時とは、オフライン用トークンを用いた認証が最後に行われた日時を意味する。
　条件（３）は、クライアント日時は有効期限内であるという条件である。
　認証用情報記憶部２２にオフライン用トークンが保持されていないときは、そもそもスタンドアロンモードが許容されていないことになり、上の３つの条件のいずれも満たさないから、アプリケーションの利用は不可と判断されることになる。
　上記条件のうち、条件（１）（３）は、切替日時、有効期限という固定的な日時情報を用いた判断である。仮に、これらの条件のみでアプリケーションの利用可否を判断するとすれば、有効期限を過ぎた後に、クライアントの時計を、遡らせることによって、容易に条件（１）（２）を満たすようにでき、アプリケーションの不正利用をすることが可能となってしまう。
　これに対し、条件（２）は、オフライン用トークンを用いて認証するたびに更新される動的な日時情報である。従って、オフライン用トークンを利用するにつれて、日時の進行に伴って、条件（２）は有効期限に近づくように更新されることになるから、条件（２）（３）を満たす時間幅は徐々に狭くなることになる。仮に有効期限を過ぎてしまえば、条件（２）（３）を満たす範囲は存在しなくなることも起き得る。このように動的な日時情報を組み合わせてアプリケーションの利用可否を判断することにより、不正利用を防止することができる利点がある。
　本実施例では、こうした機能をさらに強化するため、利用日時の情報は、原則として将来に向かってのみ更新可能とし、遡る変化は許容しないものとした。
　条件（１）～（３）のいずれかを満たさない場合には、アプリケーションの利用は不可と判断され（ステップＳ４１）、アプリケーションの利用が禁止される（ステップＳ３６）。
　条件（１）～（３）のいずれも満たす場合には、アプリケーションの利用が可能と判断され（ステップＳ４１）、利用日時を更新した後（ステップＳ４２）、アプリケーションの利用が許可される（ステップＳ４３）。
　ステップＳ４０で説明した条件（１）～条件（３）の意義について改めて説明する。
　図６は、利用日時更新の内容を示す説明図である。
　図６（ａ）は、アプリケーション利用許可処理（図５）のステップＳ４０に示した条件（１）～（３）を図示している。条件（１）は、黒塗りの三角で示したクライアント日時が、矢印ｔｒ１に示すように、切替日時以降の範囲にあるときに満たされる。条件（２）は、クライアント日時が、矢印ｔｒ２に示すように、利用日時以降の範囲にあるときに満たされる。条件（３）は、クライアント日時が、矢印ｔｒ３に示すように、有効期限までの範囲にあるときに満たされる。この結果、条件（１）～（３）を満たす範囲は、図中のハッチングを示した範囲ｅｔ１にクライアント日時が存在するときに満たされることになる。
　そして、利用日時は、矢印Ａで示すように、オフライン用トークンの利用に伴って、将来方向に向かってのみ更新される。
　利用日時が更新されることにより、図６（ｂ）に示すように、条件（１）～（３）を満たす範囲ｅｔ２は、徐々に狭くなる。この状態で、クライアント日時を図示するように、意図的に過去に遡らせて設定したとしても、利用日時に基づく条件（２）を満たさないため、アプリケーションは利用できないことになる。
　このようにスタンドアロンモードでの不正利用の防止に寄与する利用日時であるが、何らかの理由でクライアント日時が、将来の日時に設定されてしまうと、図６（ｃ）に示す状態となる。例えば、クライアント日時が有効期限を過ぎた日時に設定されると、認証が行われた時点で、オフライン用トークンの利用日時も、同様に有効期限以降の日時に設定されてしまい、矢印ｔｒ１～ｔｒ３の条件を全て満たす領域は存在しなくなってしまう。この結果、アプリケーションの利用は許可されなくなる。
　かかる状態を解消するためには、利用日時を正確な日時に修正する必要があるが、本実施例では、利用日時は原則として将来方向に向かってのみ更新可能としているため、たとえクライアント日時を矢印ｔａで示すように正確な日時に修正したとしても、利用日時は遡らないため、やはり矢印ｔｒ１～ｔｒ３の条件を全て満たす領域は得られない。
　本実施例では、かかる状態を回避するため、アプリケーション利用許可処理（図５）のステップＳ３３において、オンラインでサーバとクライアントの時計を同期できたときに限り、例外的に利用日時も過去に遡ることを許容している。この結果、クライアントがサーバに接続されれば、利用日時が、図６（ｃ）中の真正の現在日時に修正されるため、条件（２）は、破線の矢印ｔｒ２に示す状態となり、全ての条件を満たす時間範囲を回復させることができる。
　以上で説明した本実施例の認証システムによれば、スタンドアロンモードを設けることにより、クライアントがオフライン状態にあるときでも、アプリケーションを利用することができる。また、スタンドアロンモードにおいて、固定的な日時情報（切替日時および有効期限）と動的な日時情報（利用日時）とを併用することにより、アプリケーションの不正利用を防止することができる。
　また、オンラインで認証処理を行う際に、利用者が、クライアントを変えて認証要求をしたときは、発行済みのトークンを無効にすることにより、それまで利用していたアプリケーションを停止するまでなく、異なるクライアントでアプリケーションの利用を開始することが可能となる利点がある。
　本実施例で説明した種々の特徴は、必ずしも全てを備えている必要はなく、その一部を適宜、省略したり組み合わせたりしてもよい。
　本発明は、ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行うために利用することができる。
　　１０…サーバ
　　１１…送受信部
　　１２…トークン発行部
　　１３…データベース管理部
　　１４…認証部
　　１５…トークン管理部
　　１６…デベロッパ情報データベース
　　１７…ライセンス情報データベース
　　１８…アカウント情報データベース
　　２０…認証システムモジュール
　　２１…認証要求送信部
　　２２…認証用情報記憶部
　　２３…利用許可部
　　２４…日時情報更新部
　　３０…送受信部
　　３１…アプリケーション
 

 

Claims (8)

  1. 　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証システムであって、
    　前記サーバは、
    　前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するトークン発行部と、
    　前記生成されたトークンを管理するトークン管理部と
    を備え、
    　前記クライアントは、
    　　前記オフライン用トークンを保持するトークン保持部と、
    　　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可部と、
    　　前記利用許可部の動作に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新部と
    を備える認証システム。
  2. 　請求項１記載の認証システムであって、
    　前記日時情報更新部は、前記動的な日時情報を、将来に向かう方向にのみ更新するよう規制されている認証システム。
  3. 　請求項２記載の認証システムであって、
    　前記日時情報更新部は、オンラインとなった時には、前記規制を解除し、前記動的な日時情報を、前記ネットワーク経由で取得される日時に同期させる認証システム。
  4. 　請求項１～３いずれか記載の認証システムであって、
    　前記サーバは、前記クライアントからの認証要求に応じて、前記クライアントがオンライン状態にある場合の認証に用いるための該クライアントに固有のオンライン用トークンの有効性、および前記アプリケーションの起動を許可するための起動条件の少なくとも一方を踏まえて、該クライアントにおける前記アプリケーションの利用を許可するか否かの認証を行う認証部を有し、
    　前記クライアントは、前記アプリケーションの起動時および起動後の所定のタイミングで、繰り返し、前記サーバに対して前記認証要求を送信する認証要求送信部を有し、
    　前記サーバにおいて、
    　前記トークン発行部は、前記認証により前記アプリケーションの利用を許可する場合、該クライアントに固有の有効なオンライン用トークン、または前記クライアントに対して発行済みのオンライン用トークンが有効であることを示す情報を前記クライアントに送信し、
    　前記トークン管理部は、前記認証要求に対応する発行済みのオンライン用トークンであって、前記トークン発行部によって新たに生成されたオンライン用トークンとは異なるクライアントに対して発行されたものがある場合は、所定の無効化条件に従って当該発行済みのオンライン用トークンを無効化し、
    　前記クライアントにおいて、
    　　前記利用許可部は、前記オンライン用トークンが有効であることが確認できたときは前記アプリケーションの利用を許可し、その他の場合は前記アプリケーションの利用を禁止する認証システム。
  5. 　請求項１～４いずれか記載の認証システムであって、
    　前記認証要求は、前記アプリケーションの開発者の識別情報、該アプリケーションの識別情報、該アプリケーションのユーザのアカウント情報、該クライアントの端末識別情報を含み、
    前記認証は、前記認証要求に含まれる各情報と、前記サーバに予め登録された情報との整合性を考慮して行われる認証システム。
  6. 　請求項５記載の認証システムであって、
    　前記サーバは、
    　　前記アプリケーションの識別情報および前記ユーザのアカウント情報とを記憶しておくデータベースを、前記アプリケーションの開発者ごとに個別に備える認証システム。
  7. 　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行う認証方法であって、
    　前記サーバが実行する処理として、
    　前記クライアントからの認証要求に従い、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを生成して、該クライアントに送信するステップと、
    　前記生成されたトークンを管理するステップと
    を備え、
    　前記クライアントが実行する処理として、
    　　前記オフライン用トークンを保持するトークン保持ステップと、
    　　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可ステップと、
    　　前記利用許可ステップに伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新ステップと
    を備える認証方法。
  8. 　ネットワークを介してサーバに接続されたクライアントにおいてアプリケーションを利用するための認証を行うために該クライアントにおいて実行させるコンピュータプログラムであって、
    　前記サーバに対して認証要求を送信する機能と、
    　前記サーバから、前記アプリケーションの利用を許可するためのトークンとして、その有効期限を表す固定的な日時情報と、認証の実行に応じて更新される動的な日時情報を含み、前記クライアントがオフライン状態にある場合の認証に用いられるオフライン用トークンを受信する機能と、
    　現在時刻が、前記オフライン用トークンに含まれる前記動的な日時情報以降であり、かつ前記有効期限内である場合に前記アプリケーションの利用を許可し、その他の場合には前記アプリケーションの利用を禁止する利用許可機能と、
    　前記利用許可機能の実行に伴い、前記動的な日時情報を、前記現在時刻に更新する日時情報更新機能と
    を前記クライアントに実現させるためのコンピュータプログラム。
     
    　
    　　
    　　
    　　
PCT/JP2017/011449 2016-05-20 2017-03-22 認証システム WO2017199577A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201780031209.6A CN109154953B (zh) 2016-05-20 2017-03-22 认证系统
EP17799011.6A EP3460694B1 (en) 2016-05-20 2017-03-22 Authentication system
US16/175,591 US10693870B2 (en) 2016-05-20 2018-10-30 Authentication system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2016101166A JP6476402B2 (ja) 2016-05-20 2016-05-20 認証システム
JP2016-101166 2016-05-20

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/175,591 Continuation US10693870B2 (en) 2016-05-20 2018-10-30 Authentication system

Publications (1)

Publication Number Publication Date
WO2017199577A1 true WO2017199577A1 (ja) 2017-11-23

Family

ID=60325890

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2017/011449 WO2017199577A1 (ja) 2016-05-20 2017-03-22 認証システム

Country Status (5)

Country Link
US (1) US10693870B2 (ja)
EP (1) EP3460694B1 (ja)
JP (1) JP6476402B2 (ja)
CN (1) CN109154953B (ja)
WO (1) WO2017199577A1 (ja)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019144995A (ja) * 2018-02-23 2019-08-29 富士ゼロックス株式会社 情報処理装置及び情報処理プログラム
US11102004B2 (en) * 2019-04-29 2021-08-24 Google Llc Systems and methods for distributed verification of online identity
JP7203690B2 (ja) * 2019-05-31 2023-01-13 東京エレクトロン株式会社 ライセンス認証装置及びライセンス認証方法
US11423135B1 (en) * 2019-07-31 2022-08-23 Intuit Inc. Offline processing using on-demand access tokens
JP7395932B2 (ja) 2019-10-04 2023-12-12 富士フイルムビジネスイノベーション株式会社 情報処理装置、情報処理プログラム、及び画像形成装置
US11451396B2 (en) * 2019-11-05 2022-09-20 Microsoft Technology Licensing, Llc False positive reduction in electronic token forgery detection
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
DE102020125570A1 (de) 2020-09-30 2022-03-31 Novar Gmbh Verfahren, system und computerprogramm zur authentifikation von brandsteuersystemen
CN112866419B (zh) * 2021-03-11 2023-05-02 统信软件技术有限公司 一种激活控制方法、系统及计算设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08181965A (ja) * 1994-12-26 1996-07-12 Mitsubishi Electric Corp 電子レンタルシステム
JP2004046756A (ja) * 2002-05-20 2004-02-12 Fujitsu Fip Corp ライセンス管理方法、ライセンス管理システム、ライセンス管理プログラム
JP2009116392A (ja) 2007-11-01 2009-05-28 Nec Infrontia Corp ライセンス管理装置、ライセンス管理方法及びライセンス認証プログラム
JP2013015930A (ja) 2011-06-30 2013-01-24 Rakuten Inc コンテンツ又はアプリケーションの提供システム、コンテンツ又はアプリケーションの提供システムの制御方法、端末装置、端末装置の制御方法、認証装置、認証装置の制御方法、プログラム、及び情報記憶媒体
JP2015014817A (ja) 2013-05-31 2015-01-22 株式会社日本デジタル研究所 ソフトウェア使用制御システム
JP2015207152A (ja) * 2014-04-21 2015-11-19 アルパイン株式会社 アプリケーションの有効期限認証システム、有効期限認証装置および有効期限認証方法
JP2016018529A (ja) 2014-07-11 2016-02-01 株式会社リコー 認証システム、認証方法、プログラム及び通信システム

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU722579B2 (en) * 1997-06-30 2000-08-10 Fuji Photo Film Co., Ltd. Image communication system and method
JP2003233590A (ja) * 2002-02-08 2003-08-22 Hitachi Ltd 移動追従型サービス提供方法、システム及びプログラム
JP4266096B2 (ja) * 2002-03-26 2009-05-20 株式会社日立製作所 ファイル保管システムとｎａｓサーバ
US7315238B2 (en) * 2004-07-22 2008-01-01 Advanced Diagnostics Usa Corporation Method and system for providing key programming tokens to a multiple vehicle programming device
JP4514134B2 (ja) * 2005-01-24 2010-07-28 株式会社コナミデジタルエンタテインメント ネットワークシステム、サーバ装置、不正利用検出方法、ならびに、プログラム
CN101278538A (zh) * 2005-10-05 2008-10-01 普里瓦斯菲尔公司 用于用户认证的方法和设备
JP5314485B2 (ja) * 2009-04-20 2013-10-16 株式会社日立ソリューションズ クライアントサーバシステム
KR101284114B1 (ko) * 2009-11-18 2013-07-10 한국전자통신연구원 익명 ｉｄ 관리 장치 및 그 방법, 익명 ｉｄ 관리 시스템 및 이를 이용한 서비스 제공 방법
US9197642B1 (en) * 2009-12-10 2015-11-24 Otoy, Inc. Token-based billing model for server-side rendering service
WO2013126615A1 (en) * 2012-02-21 2013-08-29 Pulselocker, Inc. Method and apparatus for limiting access to data by process or computer function with stateless encryption
KR20130132672A (ko) * 2012-05-21 2013-12-05 김주한 결제 단말기 애플리케이션, asp 시스템 및 결제 방법
JP6006533B2 (ja) * 2012-05-25 2016-10-12 キヤノン株式会社 認可サーバー及びクライアント装置、サーバー連携システム、トークン管理方法
US9246894B2 (en) * 2012-10-30 2016-01-26 Microsoft Technology Licensing, Llc. Communicating state information to legacy clients using legacy protocols
US9098687B2 (en) * 2013-05-03 2015-08-04 Citrix Systems, Inc. User and device authentication in enterprise systems
CN105580038A (zh) * 2013-07-24 2016-05-11 维萨国际服务协会 用于可互操作的网络令牌处理的系统和方法
CN104734849B (zh) * 2013-12-19 2018-09-18 阿里巴巴集团控股有限公司 对第三方应用进行鉴权的方法及系统
US20150188910A1 (en) * 2013-12-26 2015-07-02 Iswind Digital Engineering Inc. Policy group based file protection system, file protection method thereof, and computer readable medium
US10395024B2 (en) * 2014-03-04 2019-08-27 Adobe Inc. Authentication for online content using an access token
EP3035270A1 (de) * 2014-12-15 2016-06-22 Giesecke & Devrient GmbH Kartenbasierte offline-token generierung
CN105072608B (zh) * 2015-06-30 2019-02-12 青岛海信移动通信技术股份有限公司 一种管理认证令牌的方法及装置
US10382424B2 (en) * 2016-01-26 2019-08-13 Redhat, Inc. Secret store for OAuth offline tokens
KR102289419B1 (ko) * 2017-06-26 2021-08-12 한국전자통신연구원 바이오메트릭을 이용한 사용자의 인증 방법 및 장치

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08181965A (ja) * 1994-12-26 1996-07-12 Mitsubishi Electric Corp 電子レンタルシステム
JP2004046756A (ja) * 2002-05-20 2004-02-12 Fujitsu Fip Corp ライセンス管理方法、ライセンス管理システム、ライセンス管理プログラム
JP2009116392A (ja) 2007-11-01 2009-05-28 Nec Infrontia Corp ライセンス管理装置、ライセンス管理方法及びライセンス認証プログラム
JP2013015930A (ja) 2011-06-30 2013-01-24 Rakuten Inc コンテンツ又はアプリケーションの提供システム、コンテンツ又はアプリケーションの提供システムの制御方法、端末装置、端末装置の制御方法、認証装置、認証装置の制御方法、プログラム、及び情報記憶媒体
JP2015014817A (ja) 2013-05-31 2015-01-22 株式会社日本デジタル研究所 ソフトウェア使用制御システム
JP2015207152A (ja) * 2014-04-21 2015-11-19 アルパイン株式会社 アプリケーションの有効期限認証システム、有効期限認証装置および有効期限認証方法
JP2016018529A (ja) 2014-07-11 2016-02-01 株式会社リコー 認証システム、認証方法、プログラム及び通信システム

Also Published As

Publication number Publication date
EP3460694A1 (en) 2019-03-27
CN109154953B (zh) 2023-06-13
CN109154953A (zh) 2019-01-04
EP3460694B1 (en) 2021-02-24
JP6476402B2 (ja) 2019-03-06
US20190068588A1 (en) 2019-02-28
JP2017208000A (ja) 2017-11-24
US10693870B2 (en) 2020-06-23
EP3460694A4 (en) 2019-11-13

Similar Documents

Publication Publication Date Title
JP6476402B2 (ja) 認証システム
CN107979590B (zh) 数据共享方法、客户端、服务器、计算设备及存储介质
CN109309683B (zh) 基于token的客户端身份验证的方法及系统
US10375069B2 (en) Authorization delegation system, information processing apparatus, authorization server, control method, and storage medium
US9571494B2 (en) Authorization server and client apparatus, server cooperative system, and token management method
RU2560784C2 (ru) Модель взаимодействия для переноса состояний и данных
US9626137B2 (en) Image forming apparatus, server device, information processing method, and computer-readable storage medium
EP2713300B1 (en) Image forming apparatus, method for controlling image forming apparatus, and program therefor
JP5602841B2 (ja) ユーザー識別に基づく製品機能強化
US9154504B2 (en) Device apparatus, control method, and relating storage medium
JP5318719B2 (ja) 端末装置及び端末装置におけるアクセス制御ポリシー取得方法
KR102017057B1 (ko) 인증 관리 방법 및 시스템
JP2020030759A (ja) 権限委譲システム、情報処理装置およびその制御方法、並びにプログラム。
JP6640960B2 (ja) 認証システム
WO2019224912A1 (ja) 車両通信装置、車両アクセス制御システム、管理装置、車両アクセス制御方法、および車両アクセス制御プログラム
JP2009003501A (ja) ワンタイムパスワード認証システム
JP2012115992A (ja) 画像形成装置及び画像形成システム
JP5997604B2 (ja) ソフトウェア不正使用防止機能を備えた情報処理装置、ソフトウェア不正使用防止方法及びプログラム
JP2018036707A (ja) プログラム及び認証装置
JP2008108137A (ja) なりすまし防止方法、画像処理装置、なりすまし防止プログラム及び記録媒体
JP5686689B2 (ja) 電子認証代替システムおよび電子認証代替方法
JP2011197917A (ja) サービスシステム及びサービス方法
JP2007087275A (ja) ライセンス管理装置

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 17799011

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2017799011

Country of ref document: EP

Effective date: 20181220