JP2020009259A - Information processing device, control method, and program thereof - Google Patents

Abstract

To minimize inquiry for date and hour acquisition to an authorization server.SOLUTION: A client terminal transmits a token issuance request including a first date and hour set to its own terminal to one of a plurality of authentication and authorization servers, receives a second date and hour of the authentication and authorization server as a response, and calculates and stores a date and hour offset on the basis of the first date and hour and the second date and hour. When transmitting a second token issuance request, the client terminal identifies a date and hour offset of a target authentication and authorization server from among the stored date and hour offsets and transmits a token issuance request including a third date and hour estimated from the identified time and hour offset.SELECTED DRAWING: Figure 8

Description

  The present invention relates to an information processing device using an access token, a control method, and a program therefor.

  In recent years, so-called cloud services deployed on the Internet have been increasingly used. Further, each of these cloud services discloses an API (Application Programming Interface) of the Web service. It is possible to use a function provided by the service via an API from another application or a cloud service. In these Web service APIs, the adoption of a standard protocol called OAuth 2.0 for realizing the cooperation of authorization is progressing. Non-Patent Document 1 discloses a technique using OAuth 2.0.

  According to OAuth 2.0, for example, a service B can access an API for acquiring data of a user managed by a certain service A within a range approved by the user. At this time, the service A clarifies the range accessed from the service B, and obtains the user's explicit permission for the service B to access the API. Explicit authorization by a user is called an authorization operation. In OAuth 2.0, this accessed range is called a scope, and the scope determines the data access allowance.

  When the user performs an authorization operation, the service B receives an authorization token proving that access to data in the range permitted by the user in the service A is authorized. Subsequent access to the API of service A can be realized using the authorization token. The authorization token is simply referred to as a token or an access token depending on the situation, but refers to the same authorization token in any case. Authorizing the service B to access the user's resources by the user's authorization operation is called authority transfer. In OAuth 2.0, a server that issues an authorization token based on a user's authorization operation is called an authorization server or an authentication authorization server. A server that exposes an API is called a resource server, and a subject that calls the API is called a client.

  In OAuth 2.0, the authorization server and the resource server can be configured by the same server. However, in a large-scale system in which there are a plurality of resource servers, the authorization server is usually configured as an independent server. . In this case, in the above flow, the service A requests the authorization server to verify the obtained access token every time the API is used from the service B. Then, based on the verification result, it is determined whether the API can be used. In that case, in a large-scale system, a problem occurs in that the load is concentrated on the authorization server. Therefore, use of a signed access token is being considered as a means for the service A to verify the access token by itself without requesting the authorization server for verification. Non-Patent Documents 2 and 3 disclose JWT (JSON Web Token) and JWS (JSON Web Signature) as signed access tokens. By verifying the signature of the received signed access token, the service A can determine whether the access token is valid without checking with the authorization server.

  In addition, the JWT can include the date and time when the JWT was created in itself to prevent replay attacks and to clarify how long the authorization server keeps the signed access token. Non-Patent Document 4 discloses a method in which a time stamp is included in a ticket and authentication is not accepted if the time stamp deviates from the server time by a certain amount or more. Similarly, if the JWT creation date and time included in the JWT is different from the date and time of the authorization server, the authorization server may reject the authorization.

  However, the date and time of the client and the authorization server are not always synchronized with the actual date and time (hereinafter, referred to as absolute date and time). There is also a method of synchronizing to the absolute date and time by using the NTP (Network Time Protocol) protocol or the SNTP (Simple Network Time Protocol) protocol, but it is necessary to publish a dedicated synchronization server on the Internet. In that case, it was difficult in terms of cost in view of the use by a large number of clients and the possibility of being used by a third party.

  As a general technique, Patent Document 1 discloses that a client synchronizes with a server date and time returned from a server, and transmits an authentication request after the synchronization.

"The OAuth 2.0 Authorization Framework", [online] D. Hardt, August 2012 <URL http: // tools. ief. org / html / rfc6749> "JSON Web Token (JWT)", [online] Jones, J .; Bradley, N .; Sakimura, May 2015 <URL https: // tools. ief. org / html / rfc7519> "JSON Web Signature (JWS)", [online] Jones, J .; Bradley, N .; Sakimura, May 2015 <https: // tools. ief. org / html / rfc7515> "The Kerberos Network Authentication Service (V5)", [online] J. Kohl, C.A. Neuman, September 1993 <https: // tools. ief. org / html / rfc1510>

JP 2016-31593A

  When a client communicates with multiple authorization servers, if the multiple authorization servers cannot synchronize with the same date and time, depending on the timing, the client repeatedly queries the authorization server for date and time information acquisition. . As a result, there is a problem in that unnecessary queries increase, thereby deteriorating performance and increasing costs.

  An object of the present invention is to solve the above-mentioned problem, when communicating with a plurality of authorization servers, the client appropriately manages the date and time offset with the authorization server, and minimizes queries to the authorization server for date and time acquisition. It is to limit.

  An information processing apparatus according to an embodiment of the present invention is an information processing apparatus that communicates with a plurality of authentication / authorization servers capable of issuing an access token, and includes a first date and time set in the information processing apparatus. Sending means for sending a token issuance request including one to one authentication and authorization server, and receiving a second date and time set in the one authentication and authorization server as a response to the token issuance request sent by the sending means Receiving means, and a storage means for calculating a date / time offset based on the second date / time and the first date / time received by the receiving means, and storing the date / time offset in association with the one authentication / authorization server. The storage means can store a date and time offset for each of the plurality of authentication / authorization servers, and the transmitting means When a second token issuance request is transmitted to any one of the authentication / authorization servers, the date / time offset of the authentication / authorization server to be transmitted is specified from the date / time offsets stored by the storage unit. The third token issuance request is transmitted including the third date and time estimated from the specified date and time offset.

  According to the system for solving the object of the present invention, it is possible to reduce the performance degradation and the server load by minimizing the number of times the client acquires the date and time of the authorization server.

System Configuration Hardware configuration diagram of each device Software module configuration diagram of each device Sequence diagram of access token issuance and verification in conventional technology Sequence diagram of JWS access token issuance and verification Flow chart of JWS access token issuance and verification for setting client date and time Flow diagram of JWS access token issuance and verification for setting client date and time to communicate with multiple authentication and authorization servers Sequence diagram of JWS access token issuance and verification using date and time offset corresponding to server Operation explanation diagram when using date and time offset corresponding to server using specific date and time Sequence diagram of JWS access token issuance and verification using server grouping Flowchart of initial group determination processing Operation explanation diagram when using server grouping using specific date and time

  Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.

[Example 1]
In this embodiment, it is assumed that an application is installed on each server on the Internet. The application cooperates with the client terminal to provide various functions. An entity that provides such a function is referred to as a service, and providing a function to a client terminal is referred to as providing a service.

  An authentication / authorization system, which is an information processing system according to the present embodiment, is realized on a network having a configuration as shown in FIG. Reference numeral 100 denotes a Wide Area Network (WAN), and a World Wide Web (WWW) system is constructed in the present invention. Reference numerals 101, 102, and 103 denote local area networks (LANs) for connecting the components. Reference numeral 110 denotes an authentication / authorization server A for realizing user client terminal authentication and OAuth. Reference numeral 120 denotes a resource server A, which provides various services.

  In the first embodiment, each server is installed one by one, but may be configured by a plurality of servers, and for example, may be provided as an authentication and authorization server A system. Reference numeral 140 denotes a client terminal, such as a personal computer, a mobile terminal, or an image forming apparatus. One or a plurality of resource service cooperation applications are installed in the client terminal 140, and perform data transmission and reception with the resource service. The authentication and authorization server B111 and the resource server B121 have the same configuration as the authentication and authorization server A110 and the resource server A120. However, it is a system in another security domain, and uses the resource server B121 with a token issued by the authentication and authorization server B111.

  FIG. 2 illustrates a general hardware configuration of an information processing apparatus that configures the authentication and authorization server A110, the authentication and authorization server B111, the resource server A120, the resource server B121, and the client terminal 140 according to the present embodiment. The CPU 231 executes a program such as an OS or an application stored in the program ROM of the ROM 233 or loaded into the RAM 232 from the external memory 241 such as a hard disk (HD). The CPU 231 controls each block connected to the system bus 234. Here, the OS is an abbreviation for an operating system running on a computer, and the operating system is hereinafter referred to as an OS. The processing of each sequence described later can be realized by executing this program.

  The RAM 232 functions as a main memory, a work area, and the like for the CPU 231. The operation unit I / F 235 controls an input from the operation unit 242. A CRT controller (CRTC) 236 controls the display on the CRT display 240. A disk controller (DKC) 237 controls data access in an external memory 241 such as a hard disk (HD) for storing various data.

  A network controller (NC) 238 executes a communication control process with a server computer or another device connected via the WAN 100 or the LANs 101, 102, and 103. The real-time clock (RTC) 239 is used to count the date and time even when the information processing apparatus is turned off. A power supply different from the power supply system of the system body is also connected. The different power is supplied from a primary battery such as a button-type battery, a capacitor, a secondary battery, or the like.

  In the following description, unless otherwise specified, the main body of the execution flow of each function on the hardware is the CPU 231, and the main body on the software is an application program installed in the external memory 241.

  FIG. 3 is a diagram showing the module configuration of each of the authentication and authorization server A110, the authentication and authorization server B111, the resource server A120, the resource server B121, and the client terminal 140 according to the present embodiment. Each function is realized by executing each module.

  The authentication and authorization server A 110 and the authentication and authorization server B 111 have an authentication and authorization module 310. The authentication / authorization module 310 performs an authentication process of a user or a client terminal, an authorization process of an authenticated user or a client terminal, and a process of issuing a signed access token.

  The resource server A 120 and the resource server B 121 have a resource server module 320. The resource server module 320 publishes an API as a Web service, receives a service provision request from the client terminal 140, and provides a service. In addition, in response to a request from the client terminal 140, whether or not to provide a service is determined by performing verification processing of a signed access token.

  The client terminal 140 has an authentication / authorization server cooperation client 341 and a resource service cooperation application 342. In addition, there is a case where a web browser 343 which is a user agent for using WWW is used, but this is not essential. The authentication / authorization server cooperation client 341 requests the authentication / authorization server A110 to authenticate a user or a client, and issues or obtains an access token.

  The resource service cooperation application 342 is an application that receives a service from the resource server A 120 and the resource server B 121. The resource service cooperation application 342 receives service provision from the resource server A 120 and the resource server B 121 in the following procedure. First, the resource service cooperation application 342 requests the authentication and authorization server cooperation client 341 to issue an access token. Here, the authentication / authorization server cooperation client 341 acquires an access token for the resource service cooperation application 342 from the authentication / authorization server A110.

  The authentication / authorization server cooperation client 341 returns the acquired access token to the requesting resource service cooperation application 342. The resource service cooperation application 342 can receive the service by making a resource request to the resource server A 120 and the resource server B 121 using the acquired access token.

  The authentication / authorization server cooperation client 341 has a date / time offset storage area 344. The date / time offset storage area 344 stores the difference between the server date / time returned by the authentication / authorization server A 110 and the authentication / authorization server B 111 and the client date / time of the client terminal 140.

  The flow of access token issuance and verification in OAuth 2.0 will be described with reference to FIG. FIG. 4 is a sequence diagram related to access token issuance and verification. The authentication / authorization server A110, the resource server A120, and the client terminal 140 cooperate.

  First, in step S401, the client terminal 140 transmits authentication information or an authorization code to the authentication / authorization server A110, requests and acquires an access token. Whether to send authentication information or an authorization code depends on the owner. If the client terminal 140 is the owner who performs the processing, the client terminal 140 itself performs authentication, and if the client terminal 140 is requested to perform processing by another owner, the authorization code received from the owner is passed.

  Next, using the acquired access token, the client terminal 140 requests the resource server A 120 to provide a service in step S402. In step S403, the resource server A120 requests the authentication / authorization server A110 to verify whether the received access token is appropriate.

  The authentication / authorization server A110 verifies the access token in step S404, and if appropriate, the resource server A120 executes processing for providing a service in step S405, and returns a processing result to the client terminal 140. If the access token is incorrect in the verification in step S404, the resource server A120 returns an error to the client terminal 140 without performing the processing.

  Next, the signed access token according to the first embodiment will be described. In the first embodiment, the resource server is accessed using JWS (hereinafter referred to as a JWS access token) that stores user information associated with the access token, which is the access token information and the resource owner information, instead of the normal access token.

  Hereinafter, the JWS access token used in the present embodiment will be described in detail. JWS (JSON Web Signature) is a method of protecting and expressing contents expressed by JWT (JSON Web Token) by digital signatures and MACs (Message Authentication Codes). JWT is a URL-safe claim expression method using a data structure based on JSON (JavaScript (registered trademark) Object Notation). JWS and JWT are specified and released as RFCs (RFC7515 (JWS) and RFC7519 (JWT)), respectively.

  The claims included in the JWS access token used in this embodiment are as follows.

  Each claim of the claim name class “Registered Claim” in Table 1 is a claim defined in advance by JWT RFC7519 and is as follows. That is, the identifier “iss” (Issuer) of the JWT issuer, the identifier “sub” (Subject) of the subject which is the subject of the JWT, a list of identifiers “aud” (Audience) of the subjects assumed to use the JWT, JWT expiration date “exp” (Expiration Time), date and time “nbf” (Not Before) when JWT becomes valid, time “Iat” (Issued At) when JWT was issued, and unique identifier “jti” for JWT ( JWT ID). The date and time designated as “exp”, “nbt”, and “iat” is IntDate, which is a JSON numeric value indicating the number of seconds from the 1970-01-01T0: 0: 0Z UTC to the date / time of the designated UTC. Use of these "Registered Claims" is optional.

  In the first embodiment, the authentication / authorization server A 110 that issues the JWS access token sets the values as follows. The URI of the authentication / authorization server A110 is set as “iss”, the UUID (Universally Unique Identifier) of the user is set as “sub”, and the URI of the resource server A120 is set as “aud”. Also, "exp" is set to 3600 seconds after the issuance of this JWT, that is, the value of "iat" +3600, and "nbf" is set to the same value as "iat" when this JWT is issued. Set the authorization token ID of the token information.

  Further, each claim of the claim name class “Private Claim” in Table 1 is a private claim name class used in accordance with JWT RFC7519 according to the agreement between the JWT issuer and the user. It is assumed that there is no conflict with other defined claim names. In the present embodiment, authorization token information (authorization token scope list “authz: scopes”, authorization token client ID “authz: client_id”) is added to the claim name of the “Private Claim” class, and attribute information (device serial number) associated with the authorization token "Ext: device-serial" and an application ID "ext: appid").

  Specifically, the authentication / authorization server A110 that issues the JWS access token sets claims of “authz: scopes” and “authz: client_id” as the authorization information. That is, a scope list that indicates resources that the resource server A 120 permits to acquire is set as “authz: scopes”. Further, “authz: client_id” representing the ID of the client accessing the resource server A 120 is set as “authz: client_id”. Further, a device serial number for identifying the client terminal 140 is set as “ext: dev-serial”, and an application ID for identifying the resource service cooperation application 342 is set as “ext: appid”. Details will be described later. The JWS is used not only for the access token but also when the client terminal 140 issues a token issuance request to the authentication and authorization server A110 and the authentication and authorization server B111. At this time, the value to be stored in each claim is the same as the JWS access token.

  The authentication / authorization server A110 that issues the JWS access token having the contents shown in Table 1 of the first embodiment encodes the claims of Table 1 as JSON according to RFC7519 which is a specification of JWT. Further, the content (JSON expression of the claim in Table 1, ie, the JWS payload) digitally signed in accordance with the compact serialization specification of RFC7515 which is the specification of JWS is represented and encoded as a compact URL-safe character string. According to the JWS compact serialization specification, the JWS access token of this embodiment is a character string obtained by concatenating an encoded JWS header, an encoded JWS payload, and an encoded JWS signature in this order with a period ('.') Character as a delimiter. It is.

  In the present embodiment, "alg" (algorithm) for identifying the encryption algorithm used for the signature of the JWS is used as the JWS header. Specifically, in the present embodiment, “RS256” (RSASSA-PKCS1_v1_5 using SHA-256) is used as “alg”. The “RS256” character string is registered as an alg value in the IANA JSON Web Signature and Encryption Algorithms registry, and is defined in Section 3 of the JSON Web Algorithms (JWA) specification (RFC7518).

  Note that in this embodiment, a key pair of a secret key and a public key used in the encryption algorithm “RS256” used for the signature of the JWS is generated in advance by the authentication / authorization server A110. A public key for verifying the signature of the JWS is provided in advance in the resource servers A 120 and 121 that use the JWS access token. The resource server B121 belongs to a security domain different from that of the authentication / authorization server A110, but holds a public key for verifying the JWS access token. Therefore, the resource server A120 can be used with the JWS access token issued by the authentication / authorization server A110.

  Next, the flow of issuing and verifying a JWS access token will be described with reference to FIG. FIG. 5 is a sequence diagram of issuing and verifying a JWS access token. In this embodiment, a case where communication with a plurality of authentication / authorization servers is performed is shown. The client terminal 140 communicates with two authentication / authorization servers A110 and B111.

  First, the client terminal 140 issues a token issue request to the authentication / authorization server A110 (S501). Here, the token issuance request is expressed as JWT. In particular, the client date and time of the client terminal 140 is used for the JWT claim “iat” (Issued At). The client date and time may be a value calculated based on the RTC 239, or may be calculated based on date and time information that the CPU 231 independently counts up.

  The authentication / authorization server A 110 verifies whether the token issuance request received from the client terminal 140 is valid or has not expired (S502). The authentication / authorization server A110 determines the expiration date by confirming whether the “exp” (Expiration Time), “nbf” (Not Before), and “iat” (Issued At) claims are valid. Specifically, the JWT issuance date / time “iat” is compared with the server date / time of the authentication / authorization server A 110 to determine whether the error is within a certain range, for example, ± 30 seconds. By performing the date and time verification processing, it is possible to increase the resistance to the replay attack.

  Next, the authentication / authorization server A110 issues a valid JWS access token in the resource server A120 (S503). The client terminal 140 receives the JWS access token issued in S503.

  Further, FIG. 5 shows a flow of acquiring a JWS access token from another authentication / authorization server B111. The transmission process S504 of the token issuance request is the same as the transmission process S501 of the token issuance request to the authentication / authorization server A except that the secret key for signing the issuance request is different. Similarly, the token issuing process S506 is the same as the token issuing process S503 performed by the authentication processing server A.

  The client terminal 140 makes a resource request to a different resource server by using the JWS access token obtained from the authentication / authorization server A and the JWS access token obtained from the authentication / authorization server B (S507). The processing between the client terminal 140 and the resource server is the same as in FIG. As described above, FIG. 5 shows that the client terminal 140 can communicate with a plurality of authentication / authorization servers at an arbitrary timing.

  FIG. 5 shows a case where the client date and time of the client terminal 140 and the server date and time of each of the authentication / authorization server A 110 and the authentication / authentication server B 111 are synchronized, and the verification regarding the date and time is successful in the JWT verification processing S502 and S505. On the other hand, the date and time may not be synchronized between these client servers. An example in which the client date and time of the client terminal 140 is not synchronized with the absolute date and time will be described with reference to FIG.

  First, the client terminal 140 issues a first token issuance request to the authentication / authorization server A110 (S601). This first token issuance request is the same as the token issuance request (S501) in FIG.

  Next, the authentication / authorization server A 110 verifies the validity of the token issuance request received in S601 (S602). Here, since it is assumed that there is a difference between the client date and time of the client terminal 140 and the server date and time of the authentication / authorization server A110, the JWT issue date and time "iat" is larger than the predetermined difference as compared with the server date and time. The authentication / authorization server A 110 returns a verification processing error to the client terminal 140 because the JWT issue date / time “iat” is too different from the server date / time. The authentication / authorization server A 110 not only returns an error but also returns its own server date and time to the client terminal 140.

  The client terminal 140 knows that the verification processing has failed in S602, and receives the server date and time of the authentication and authorization server A110. The client terminal 140 sets the received server date and time as its own client date and time (S603). As a storage destination of the client date and time, a method of storing the date and time in the RAM 232 and counting up by the CPU 231 may be used, or a method of directly setting the RTC 239 may be used.

  Subsequently, the client terminal 140 makes a second token issuance request to the authentication / authorization server A110. The second token issuance request is the same process as the first token issuance request, except that the JWT issuance date and time "iat" included in the issuance request is based on the server date and time of the authentication and authorization server A110. The contents used for the second token issuance request may not only differ from the JWT issuance date and time “iat”, but may also differ from other claims and signature results.

  The authentication and authorization server A110 verifies the JWT used for the second token issuance request (S604). The JWT issuance date and time "iat" of the JWT used for the second token issuance request is based on its own server date and time, and thus the verification is successful. Subsequent processes, S605 and S606, are the same processes as S503 and S507 in FIG.

  As described above, according to the processing method of FIG. 6, even if there is an error in the client date and time of the client terminal 140, if the client date and time does not cause an error again, the JWS access request is issued in the second and subsequent token issuing requests. Tokens can be obtained.

  However, when the method shown in FIG. 6 is adopted, a problem may occur that an excessive token issuance request is issued when acquiring a JWS access token from a plurality of authentication / authorization servers. An example of a process when a problem occurs will be described with reference to FIG. In FIG. 7, it is assumed that the server date and time of the authentication and authorization server A110 and the authentication and authorization server B111 have an error with respect to the absolute date and time.

  The client terminal 140 makes a first token issuance request to the authentication / authorization server A110. This processing is the same processing as S601, S602, and S603 in FIG. Such processing in which the JWT verification processing S602 fails and the authentication / authorization server A110 returns its own server date and time to the client terminal 140 is referred to as a token issue request to the authentication / authorization server A110 (S701).

  Similarly, the client terminal 140 makes a first token issuance request to the authentication / authorization server B111. As a premise, the server date and time of the authentication / authorization server B111 has no error with respect to the absolute date and time. However, the client date and time of the client terminal 140 has an error due to the client date and time setting process S603 using the server date and time of the authentication and authorization server A110. Therefore, the token issuance request to the authentication / authorization server B fails in the JWT verification processing (S602) due to the JWT issuance date / time "iat". As a result, the client terminal 140 sets the date and time sent from the authentication and authorization server B as the client date and time.

  Subsequently, the client terminal 140 issues a token issuance request to the authentication / authorization server A 110 again (S703). In this processing, since the client date and time of the client terminal 140 are synchronized with the authentication and authorization server B111, the JWT issuance date and time “iat” based on the server date and time of the authentication and authorization server B111 including the error causes the JWT verification processing S602. An error occurs.

  Thereafter, S703 and S704 are repeated depending on the timing, and there is a possibility that an excessive token issuance request may be issued. Excessive token issuance requests increase the load on the authentication and authorization server, leading to performance degradation and increased management and maintenance costs.

  The token issuance request processing (S705) that succeeds in the verification is the same as the second access token issuance request (S603) in FIG. In addition, the communication process with the resource server (S706) is the same as the communication process with the resource server (S606) in FIG.

  In FIG. 7, another process can be interrupted between the first token issue request and the second token issue request. However, even if a mutex lock or the like is performed between the first token issuance request and the second token issuance request so that other processing cannot be interrupted, an extra token issuance request is issued every time to obtain the server date and time. The problem remains.

  As described above, FIG. 7 shows that simply setting the date and time acquired from the authentication and authorization server to the client date and time may cause an excessive token issue request.

  A method of not issuing such an extra token issuance request will be described with reference to FIG. FIG. 8 follows the JWS access token issuance and verification processing of FIGS. 6 and 7. The difference will be described. First, the client terminal 140 calculates and stores a date / time offset from the server date / time acquired from the authentication / authorization server A 110 and its own client date / time (S801). The client terminal 140 performs the same processing for the authentication and authorization server B111 (S802).

  These date / time offset storage processes are stored in the date / time offset storage area 344 managed by the authentication / authorization server cooperation client 341. The date and time offset storage area 344 does not store a single date and time offset, but secures an area for storing the date and time offset for each authentication and authorization server. That is, the date and time offset calculated based on the server date and time of the authentication and authorization server A110 and the date and time offset calculated based on the server date and time of the authentication and authorization server B111 are stored in different areas without being overwritten each other. Each date and time offset is stored in association with each authentication / authorization server. The date and time offset is a value obtained by subtracting the client date and time when the server date and time is received from the returned server date and time.

  As yet another difference, the client terminal 140 estimates the value of the JWT issue date / time "iat" claim included in the token issue request before making the second token issue request to the authentication / authorization server A110 (S803). Similarly, the client terminal 140 estimates the value of the JWT issue date and time "iat" claim before the second token issuance request to the authentication / authorization server B111 (S804). The JWT creation date and time estimation processing (S803, S804) estimates the JWT creation date and time by adding the client date and time of the client terminal 140 to the date and time offset stored in the date and time offset storage processing of S801 and S802.

  The second token issuance request (S603) is the same as the processing in FIG. Similarly, the communication processing with the resource server (S805) is the same as the processing in FIG. As described above, according to the JWS access token issuance and verification processing of FIG. 8, even if the token issuance processing for another authentication / authorization server is interrupted between the first and second token issuance requests, the server date and time can be obtained. Requests can be suppressed at most once.

  Note that, in the example of FIG. 8, both the authentication and authorization server A110 and the authentication and authorization server B111 transmit the server date and time as a response to the token issuance request, but if the token issuance request is successfully verified, the process proceeds to S503 and S506 in FIG. Transmit the JWS access token as shown. In that case, the client terminal 140 does not calculate and store the date and time offset. When the second and subsequent token issuance requests are made, if the date and time offset is not stored, the date and time set in the client terminal 140 is used as shown in FIG. 5, and if the date and time offset is stored, the JWT creation date and time are used. Perform estimation processing. Note that the second and subsequent token issuance requests are made when the JWS access token has expired.

  With reference to FIG. 9, the operation of the JWS access token issuance and verification processing flow described in FIG. 8 will be specifically described using actual date and time values. In FIG. 9, three temporal snapshots are shown in order to represent the date and time of the client terminal 140 and each authentication / authorization server, and the lapse of time. More precisely, a time elapses from when a request is issued to the authentication / authorization server until a response arrives. However, FIG. 9 does not consider that the passage of time is negligibly short. However, if the elapsed time cannot be ignored, for example, several hundred milliseconds until the request arrives, the average value of the client date and time immediately before sending the request and the client date and time at the time of receiving the response is used for the second token issue request. You may. In the example of FIG. 9, an error is returned if the error between the JWT issue date and time "iat" and the server date and time of the authentication and authorization server exceeds 30 seconds.

  First, the processing of the state of the snapshot 1 will be described. The client terminal 140 issues a first token issuance request to the authentication / authorization server A110 (S901). At this time, since the date and time offset for server A is not set, the client terminal 140 sets the client date and time [12:00:50] in the JWT issue date and time “iat” included in the authentication request S901 (S901). .

  Next, the authentication / authorization server A 110 verifies the JWT included in the request received from the client terminal 140. Since there is a difference of 40 seconds between the server A date and time [12:01:30] and the date and time [12:00:50] set in the JWT issue date and time “iat”, which exceeds the specified number of seconds, the authentication and authorization server A Returns an authentication response as an error (S902). At this time, the authentication / authorization server A includes its own server date and time [12:01:30] in the authentication response.

  The client terminal 140 calculates a date / time offset [+00: 00: 40] from the server date / time [12:01:30] of the authentication response received in S902 and its own client date / time [12:00:50]. The client terminal 140 stores the calculated date / time offset [+00: 00: 40] as the date / time offset for server A, which is the date / time offset corresponding to the authentication / authorization server A110. Here, it is assumed that the date and time offset for server A is stored in the date and time offset storage area 344.

  Next, the flow of processing in snapshot 2 after a lapse of 40 seconds from snapshot 1 will be described. Snapshot 2 shows a state in which the client terminal 140 attempts to communicate with the authentication / authorization server B111 before issuing a second token issuing request to the authentication / authorization server A110.

  Since the date and time offset for server B has not been set, the client terminal 140 transmits an authentication request with its client date and time [12:01:30] to the JWT issue date and time “iat” because the date and time offset for server B has not been set. (S904).

  The authentication / authorization server B111 confirms that there is a difference of 80 seconds between the JWT issue date / time “iat” [12:01:30] and the server date / time [12:02:50] in the received authentication request. I do. As a result, since the number of seconds exceeds the predetermined number of seconds, an authentication response is returned to the client terminal 140 as an error (S905).

  The client terminal 140 calculates a date / time offset [+00: 01: 20] from the server date / time [12:02:50] of the authentication response included in the authentication response and its own client date / time [12:01:30]. The client terminal 140 stores the calculated date / time offset [+00: 00: 40] in the date / time offset storage area 344 as a date / time offset for server B, which is a date / time offset corresponding to the authentication / authorization server A110.

  In the snapshot 3, the client terminal 140 makes a second token issuance request to the authentication / authorization server A (S908). The client terminal 140 performs JWT creation date / time estimation processing S803 to calculate the JWT issue date / time “iat” in the authentication request transmitted in S908 (S907). Specifically, by adding the date and time offset [+00: 00: 40] for the server A to be transmitted to the client date and time [12:02:10] of the client terminal 140, the JWT creation estimated date and time [12:02: 50].

  The authentication authorization server A110 receives the authentication request transmitted in S908, and compares the JWT issuance date and time “iat” in the authentication request with its own server date and time. Here, since there is no difference between the JWT issue date and time “iat” [12:02:50] and the server date and time [12:02:50] of the own device, the JWT verification process S604 succeeds.

  The authentication / authorization server A 110 returns an authentication response including the JWS access token to the client terminal 140 (S909). By using the JWS access token received in S909, the client terminal 140 can make a resource request to the resource server corresponding to the scope of the JWS access token.

  In this embodiment, the processing related to the acquisition of the JWS access token has been described. However, the same method may be applied not only to the processing relating to the acquisition of the JWS access token but also to other processing of transmitting the JWT including the JWT issue date / time “iat” to the authentication / authorization server. For example, when the client ID and client secret of the OAuth 2.0 client are issued by the authentication / authorization server, the verification processing of the JWT issuance date and time “iat” is performed in the same manner as the JWS access token issuance. A similar method may be applied when issuing the client ID and the client secret.

  As described above, when the client terminal 140 communicates with a plurality of authorization servers, the client terminal 140 appropriately manages the date and time offset with the authorization server, and minimizes queries to the authorization server for date and time acquisition. Can be done. As a result, performance degradation and server load can be reduced.

[Example 2]
In the first embodiment, when communicating with a plurality of authorization servers, a method has been described in which the client terminal 140 individually manages the date and time of the authorization server, thereby minimizing inquiries for obtaining the date and time.

  In the method according to the first embodiment, the query for obtaining the date and time can be performed at most once if no additional error occurs in the date and time of the authentication and authorization server. By the way, it is highly likely that authentication / authorization servers existing in a data center in the same area or in the same LAN perform similar date and time synchronization, for example, synchronization with the same NTP server. However, in the method of the first embodiment, even in such a case, if there is a difference between the client date and time or the server date and time, an inquiry for date and time acquisition is made at least once.

  With reference to FIG. 10, JWS access token issuance and verification involving grouping for solving such a problem will be described. Note that the configuration of which the description is omitted is the same as that of the first embodiment.

  First, the client terminal 140 groups the authentication / authorization server group that it intends to communicate with based on specific characteristics, and sets the result as an initial group (S1001). The initial group determination processing S1001 will be described in detail with reference to FIG. The client terminal 140 checks whether there is an authentication / authorization server that has been grouped (S1101). If there is an authentication / authorization server for which grouping has not been determined, the process proceeds to S1102. On the other hand, when the grouping of all the authentication / authorization servers is completed, the processing exits from the repetition processing and returns to the present processing.

  The client terminal 140 checks whether a group already exists. If a group has already been created, the process proceeds to S1103. On the other hand, if a group has not been created yet, the process transits to S1104 (S1102).

  The client terminal 140 determines whether the authentication / authorization server to be grouped has the same characteristics as the already determined group. Here, the specific feature is, for example, whether the signature certificate of the JWT transmitted at the time of the token issuance request is common and / or whether the parent domain of the FQDN is common. Authentication / authorization servers that share them are in the same group. If the client terminal 140 determines that there is a group having common characteristics, the process proceeds to S1105. On the other hand, when it is determined that there is no group having the common feature, the process proceeds to S1104 (S1103).

  If the client terminal 140 determines in step S1103 that there is a group having common characteristics, the client terminal 140 adds an authorized authentication server being grouped to the group (S1105). If neither of S1102 and S1103 is satisfied, the client terminal 140 creates a new group in which the authentication / authorization server being grouped is the only server (S1104).

  Referring back to FIG. 10, after the initial group is determined, the client terminal 140 issues a token issue request to the authentication / authorization server A. In FIG. 10, it is assumed that the authentication and authorization server A110 and the authentication and authorization server B111 are in the same group. Also, the issuance request S601 and the JWT verification processing S602 of the authentication / authorization server A110 have already been described, so that the details are omitted.

  The client terminal 140 calculates a date / time offset from the server date / time and the client date / time included in the error response of the authentication / authorization server A110. The client terminal 140 records the calculated date / time offset in the date / time offset storage area 344 corresponding to the group to which the authentication / authorization server A110 belongs (S1002).

  Subsequently, the client terminal 140 makes a first token issuance request to the authentication / authorization server B111. Here, the client terminal 140 sets the date / time offset acquired from the date / time offset storage area 344 corresponding to the group to which the authentication / authorization server B111 belongs, in the JWT issue date / time “iat” included in the token issue request (S1003).

  As a premise, since the authentication / authorization server A110 and the authentication / authorization server B111 have determined that they belong to the same group in the initial group determination processing S1001, a date / time offset based on the server date / time returned by the authentication / authorization server A110 is used in S1002. . Here, the flow is divided into two flows depending on whether or not the server date and time of the authentication and authorization server A110 and the authentication and authorization server B111 are synchronized. If the difference between the JWT issue date / time “iat” and the server date / time is within the predetermined time, the authentication / authorization server B111 returns the JWS access token because the verification is successful in the JWT verification process S602.

  On the other hand, if the difference between the JWT issue date / time “iat” and the server date / time is outside the predetermined time, the authentication / authorization server B111 fails the verification in the JWT validation process S602 due to the JWT issue date / time “iat”. The client terminal 140 calculates a date and time offset from the server date and time included in the received error response and its own client date and time. At this time, among the date / time offsets corresponding to the already existing groups, the one with the closest date / time offset value to the calculated date / time offset is searched.

  If the difference between the date and time offset with the closest value and the calculated date and time offset is less than or equal to the maximum error time, the client terminal 140 adds the authentication and authorization server B111 to the group corresponding to the date and time offset with the closest value. That is, the group of the authentication and authorization server B111 that originally belonged to the group of the authentication and authorization server A110 is changed.

  If there is no group to be added, the client terminal 140 creates a new group including only the authentication and authorization server B111. Here, the maximum error time may be a predetermined constant, or may be an allowable error time between the JWT issue date and time “iat” and the server date and time used for the determination in the JWT verification process (S602) of the authentication and authorization server. Good.

  Next, the operation of the JWS access token issuance and verification processing flow described in FIG. 10 with reference to FIG. 12 will be specifically described using actual date and time and values. FIG. 12 shows an example in which the authentication / authorization server groups belonging to different groups are initially dynamically combined into one group in actual communication. As a premise, the authentication / authorization server A110 belongs to group A, the authentication / authorization server B111 belongs to group B, and the authentication / authorization server A110 and the authentication / authorization server B111 are synchronized with each other, and not synchronized only with the client date and time. And

  In snapshot 1, S901 and S902 are the same as those in FIG. The client terminal 140 calculates a date / time offset [+00: 00: 40] from the client date / time [12:00:50] and the server date / time [12:01:30] returned in S902. The client terminal 140 stores the date / time offset [+00: 00: 40] as the date / time offset for group A corresponding to the authentication / authorization server A110 (S1201).

  Subsequently, in snapshot 2, the client terminal 140 issues a token issue request to the authentication / authorization server B111. As a premise, since the authentication and authorization server A110 and the authentication and authorization server B111 have the same server date and time, the JWT verification processing (S602) fails. As a result, the authentication / authorization server B 111 returns its server date and time to the client terminal 140 together with an error response.

  The client terminal 140 calculates a date / time offset from the returned server date / time and its own client date / time, and searches for a group that is closest and has a date / time offset for a group whose difference is equal to or less than the maximum error time. In FIG. 12, since the authentication and authorization server A110 and the authentication and authorization server B111 have the same server date and time, the date and time offset for group A corresponds.

  The client terminal 140 moves the authentication / authorization server B111 to the corresponding group A, and deletes the empty group B (S1202).

  In the snapshot 3, the client terminal 140 makes a second token issuance request to the authentication / authorization server B. Since the association of the authentication authorization server B has moved from the group B to the group A, the client terminal 140 estimates the JWT from the group A date / time offset [+00: 00: 40] and its own client date / time [12:01:30]. The date and time [12:02:50] is obtained (S1203).

  Thereafter, the client terminal 140 makes a second token issuance request using the estimated JWT creation date and time [12:02:50] acquired in S1203. In the JWT verification processing (S602), the authentication authorization server B allows its own server date and time [12:02:50] and the estimated JWT creation date and time [12:02:50] included in the authentication request received from the client terminal 140. A JWS access token is issued because it is within the error date and time.

  In this way, even if there is a problem in the initial group determined in the initial group determination processing (S1001), the group is dynamically re-grouped, so that the authentication / authorization server groups that are assumed to be synchronized with the date and time are in the same group. It can be.

  As described above, according to the second embodiment, by inquiring the unnecessary date and time acquisition by grouping the servers that are assumed to be initially synchronized with the date and estimating the date and time by using the date and time offset corresponding to the group. Can be reduced. Further, by continuing the grouping dynamically, it is possible to maintain an appropriate group configuration according to a change in the environment.

[Other Examples]
The present invention is also realized by executing the following processing. That is, software (program) for realizing the functions of the above-described embodiments is supplied to a system or apparatus via a network or various storage media, and a computer (or CPU, MPU, or the like) of the system or apparatus reads the program and reads the program. This is the process to be performed.

110 Authentication / Authorization Server A
111 Authentication and authorization server B
120 Resource server A
121 Resource Server B
140 client terminal

Claims (10)

An information processing device that communicates with a plurality of authentication / authorization servers capable of issuing an access token,
Transmitting means for transmitting a token issuance request including a first date and time set in the information processing apparatus to one authentication and authorization server;
Receiving means for receiving a second date and time set in the one authentication and authorization server as a response to the token issuance request transmitted by the transmitting means;
Storage means for calculating a date / time offset based on the second date / time and the first date / time received by the receiving means, and storing the date / time offset in association with the one authentication / authorization server;
The storage means can store a date and time offset for each of the plurality of authentication and authorization servers,
When transmitting the second token issuance request to any one of the plurality of authentication / authentication servers, the transmission unit transmits the authentication / authentication server to be transmitted from the date / time offset stored by the storage unit. An information processing apparatus, wherein a date and time offset is specified, and the second token issuance request is transmitted including a third date and time estimated from the specified date and time offset.   The second date and time received by the receiving means is a date and time transmitted when the one authentication and authorization server determines that an error between the first date and time and the second date and time is not within a certain range. The information processing apparatus according to claim 1, wherein:   The receiving means is transmitted when the one authentication / authorization server determines that the token issuance request is a legitimate request and that an error between the first date and time and the second date and time is within a certain value. The information processing device according to claim 1, wherein the access token is received.   4. The information processing apparatus according to claim 3, wherein the storage unit does not store a date and time offset when the access token is received by the receiving unit.   When the transmitting unit transmits a second or later token issuing request to any one of the plurality of authentication / authorization servers, if the date and time offset stored by the storage unit is not stored, the first The token issuance request including the third date and time is transmitted when the token issuance request including the date and time is transmitted and the date and time offset stored by the storage unit is stored. The information processing device according to claim 1. Having grouping means for grouping each authentication and authorization server included in the plurality of authentication and authorization servers,
The transmitting means, when transmitting a token issuance request to any one of the plurality of authentication / authentication servers for the first time, selects a group to which the authentication / authentication server to be transmitted belongs from among the date / time offsets stored by the storage means. The information according to any one of claims 1 to 5, wherein a corresponding date / time offset is specified, and the token issuance request is transmitted including a third date / time estimated from the specified date / time offset. Processing equipment.   The information processing apparatus according to claim 6, wherein the grouping unit groups authentication and authorization servers having common features as the same group.   The information processing apparatus according to claim 1, wherein the third date and time is a date and time calculated from the first date and time and the date and time offset. A method for controlling an information processing device that communicates with a plurality of authentication / authorization servers capable of issuing an access token,
Transmitting a token issuance request including a first date and time set in the information processing device to one authentication and authorization server;
A receiving step of receiving a second date and time set in the one authentication and authorization server as a response to the token issuance request transmitted in the transmitting step;
Storing a date / time offset based on the second date / time and the first date / time received in the receiving step, and storing the date / time offset in association with the one authentication / authorization server;
In the storing step, it is possible to store a date and time offset for each of the plurality of authentication and authorization servers,
In the transmitting step, when transmitting a second token issuing request to any one of the plurality of authentication / authentication servers, the authentication / authentication server to be transmitted is selected from the date / time offsets stored in the storage step. A control method comprising specifying a date and time offset, and transmitting the second token issuance request including a third date and time estimated from the specified date and time offset. A program for a control method of an information processing device that communicates with a plurality of authentication and authorization servers capable of issuing an access token,
Transmitting a token issuance request including a first date and time set in the information processing device to one authentication and authorization server;
A receiving step of receiving a second date and time set in the one authentication and authorization server as a response to the token issuance request transmitted in the transmitting step;
Storing a date / time offset based on the second date / time and the first date / time received in the receiving step, and storing the date / time offset in association with the one authentication / authorization server;
In the storing step, it is possible to store a date and time offset for each of the plurality of authentication and authorization servers,
In the transmitting step, when transmitting a second token issuing request to any one of the plurality of authentication / authentication servers, the authentication / authentication server to be transmitted from the date / time offset stored in the storage step A program for identifying a date and time offset, and transmitting the second token issuance request including a third date and time estimated from the identified date and time offset.

Images