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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
  • G06F21/31—User authentication
  • G06F21/33—User authentication using certificates
  • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
• • 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
  • H04L67/00—Network arrangements or protocols for supporting network services or applications
  • H04L67/01—Protocols
  • H04L67/10—Protocols in which an application is distributed across nodes in the network
  • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
  • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2101—Auditing as a secondary aspect
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F2221/2151—Time stamp

Definitions

• the present invention relates to an
• authorization server and client apparatus a server cooperative system, and a token management method, which are required to control accesses between a plurality of online service systems in, for example, an online system implemented by mashing up a plurality of online service systems.
• OAuth OAuth 2.0 Authorization Protocol draft-ietf-oauth-v2-25" , E.
• OAuth is a technique for transferring an access authority of a user of a cooperating system to a cooperation asking system while limiting to the access authority.
• the cooperation asking system can access the cooperating system using the authority of that user, and can provide services using those provided by the cooperating system to users.
• authentication mechanisms of cooperating systems include the access authority transfer configuration of systems based on OAuth, the cooperation between systems can be securely implemented without storing
• OAuth sets a valid period for authorization information required to permit accesses from the cooperation asking system, and also sets a mechanism for re-issuing authorization information after the valid period of the authorization information has expired and a mechanism for
• the present invention provides an authorization system which can solve the aforementioned problems.
• the present invention provides an authorization server and client, a server cooperative system, and a token management method, which enhance security.
• the present invention includes the following arrangement .
• an authorization server which authorizes an access request from a client apparatus to a resource server based on valid authorization information received from the client apparatus in association with the request
• the server comprising: issuance means for issuing authorization information used to access the resource server and update authorization information used to re-issue new authorization information without any authentication information in accordance with an issuance request received from the client apparatus together with authentication information; re-issuance means for reissuing new update authorization information and new authorization information in accordance with a refresh processing request received together with update authorization information, and storing the update authorization information issued by the issuance means so as to re-issue new update authorization information and authorization information as initial update
• invalidation means for invalidating, in accordance with an invalidation request received together with update authorization information, update authorization information with which the received update authorization information is associated as initial update authorization information.
• the present invention includes the following arrangement. That is, there is provided a client apparatus which transmits an access request to a resource server together with authorization information issued by an authorization server to request a service by the resource server, the apparatus comprising: means for storing the
• authorization information issued by the authorization server update authorization information used to reissue new authorization information without any
• invalidation request means for transmitting an invalidation request together with the stored initial update authorization information to the
• authorization server to request the authorization server to invalidate update authorization information associated with the initial update authorization information .
• the present invention includes the following arrangement. That is, there is provided a server cooperative system including an authorization server, which authorizes an access request from a client apparatus to a resource server based on valid authorization information received from the client apparatus in association with the request, a client apparatus, which transmits an access request to a resource server together with authorization
• the authorization server comprising:
• authorization information without any authentication information in accordance with an issuance request received from the client apparatus together with authentication information; re-issuance means for reissuing new update authorization information and new authorization information in accordance with a refresh processing request received together with update authorization information, and storing the update authorization information issued by the issuance means so as to re-issue new update authorization information and authorization information as initial update
• invalidation means for invalidating, in accordance with an invalidation request received together with update authorization information, update authorization information with which the received update authorization information is associated as initial update authorization information, and the client apparatus comprising: means for storing the authorization information issued by the client apparatus
• authorization server update authorization information used to re-issue new authorization information without any authentication information, and initial update authorization information issued first by the
• invalidation request means for transmitting an invalidation request together with the stored initial update authorization information to the
• authorization server to request the authorization server to invalidate update authorization information associated with the initial update authorization information.
• the present invention includes the following arrangement. That is, there is provided a token management method in a server cooperative system including an authorization server, which authorizes an access request from a client apparatus to a resource server based on valid
• a client apparatus which transmits an access request to a resource server together with authorization information issued by the authorization server to request a service by the resource server, and the resource server, which provides a service to the client apparatus, the method comprising: an issuance step of issuing, by the
• authorization server authorization information used to access the resource server and update authorization information used to re-issue new authorization
• authorization server update authorization information used to re-issue new authorization information without any authentication information, and initial update authorization information issued first by the
• FIG. 1 is a block diagram of an overall system
• FIG. 2 is a block diagram showing the hardware arrangement of a server
• FIG. 3 is a block diagram showing the software configuration of an external server
• FIG. 4 is a block diagram showing the software configuration of an access management server
• FIG. 5 is a block diagram showing the software configuration of a form server
• FIGs. 6A, 6B, and 6C are tables showing data structures held by an external service system 103;
• Figs. 7A and 7B are account tables held by an access management service system 104;
• Fig. 8 is a table showing the data structure of an authorization code held by the access management service system 104
• Fig. 9 is a table showing the data structure of authorization information held by the access management service system 104
• FIGs. 10A and 10B are flowcharts of access token issuance processing
• Fig. 11 shows an example of an authorization screen
• FIGs. 12A and 12B are flowcharts of
• Fig. 13 is a flowchart of authorization
• Fig. 14 is a flowchart of authorization
• Fig. 15 is a block diagram showing an access authority transfer sequence of OAuth
• Fig. 16 is a block diagram showing problem 1 of OAuth.
• Fig. 17 is a block diagram showing problem 2 of OAuth.
• a cooperating system Upon transferring an access authority by OAuth, a cooperating system performs authority confirmation of a cooperation asking system and that of a user who uses the cooperation asking system.
• the cooperation asking system is a system which is directly accessed by the user to request a service.
• the cooperating system is a system which provides services and the like (including resources) to the cooperation asking system in
• the cooperation asking system will be referred to as a client
• the cooperating system will be referred to as a resource server
• an authorization server information of the resource server.
• authentication information managed by the authorization server includes security information required to authenticate users and systems which use the resource server.
• the authentication information includes user IDs and passwords.
• the authorization information managed by the authorization server includes security information required to authenticate users and systems which use the resource server.
• the authorization server according to the OAuth authority transfer sequence, and is required to permit accesses to the resource server.
• the authorization information is called an access token.
• the client Upon accessing the resource server, the client transmits an access token to the resource server.
• the resource server requests the authorization server to confirm the received access token, and determines whether or not to permit an access.
• the client can use the
• the OAuth authority transfer sequence will be described below with reference to Fig. 15.
• a user who uses the cooperation asking system will be referred to as a resource owner (or simply referred to as an owner) hereinafter, and a Web browser included in an information processing terminal operated by the user will be referred to as a user agent hereinafter.
• processing step 1501 an owner operates the client via the user agent.
• the client starts the OAuth sequence so as to use the resource server.
• the client redirects the user agent to the authorization server.
• the client sends a client ID used to uniquely identify the client itself and a redirect URL to the authorization server.
• the authorization server authenticates the owner via the user agent.
• the owner authentication is implemented by, for example, a method of displaying an authentication screen on the user agent, and prompting the owner to input a user ID and password managed by the authorization server. If the owner authentication has succeeded, the authorization server determines whether or not the authenticated owner has an appropriate access authority to the resource server.
• the authorization server performs authorization confirmation of an access to the resource server by the client for the owner who is determined to have the access authority via the user agent.
• the authorization confirmation for the owner is implemented by, for example, a method of displaying an authorization confirmation screen, and prompting the owner to press an authorization button.
• the authorization server When the owner authorizes, the authorization server generates an authorization code.
• the authorization code is
• processing step 1505 the authorization server sends the generated authorization code to the redirect URL passed from the client in processing step 1502.
• processing step 1506 the client requests the authorization server to send authorization information required to use the resource server.
• the client sends the received authorization code and authentication information of the client.
• the authorization server confirms the received authorization code and authenticates the client. If the client authentication has succeeded, the authorization server confirms whether or not the resource server permits the client to cooperate. If it is confirmed that the
• authorization code is valid, and the resource server permits the client to cooperate, the authorization server generates authorization information for the resource server.
• the authorization server sends the generated authorization information to the client .
• processing step 1508 the client sends the authorization information to the resource server, thereby issuing a use request of the resource server.
• the resource server sends the received authorization information to the authorization server so as to determine access
• the authorization confirms the received authorization information.
• the authorization server returns the confirmation result of the authorization information to the resource server.
• the resource server judges according to the confirmation result of the authorization information whether or not to grant access permission to the client.
• OAuth recommends setting a short valid period of the access token for the sake of security.
• authorization confirmation for the owner in processing step 1504 is generated every access even in the system authorized once by the owner, resulting in
• OAuth provides a method of issuing update authorization information which authorizes updating of an access token together with the access token at the access token issuance timing in processing step 1506. This update
• the refresh token is information required to issue an access token without any authorization confirmation for the owner.
• the authorization server issues a new access token which has an authority which is the same as or narrower than that of the access token issued together with the refresh token.
• the client Upon issuing the new access token using the refresh token, the client sends the refresh token and authentication information of the client to the
• the authorization server The authentication information of the client includes, for example, a client ID and password.
• the authorization server confirms the refresh token, and authenticates the client. If the client authentication has succeeded, the authorization server confirms whether or not the resource server permits the client to cooperate. If it is confirmed that the refresh token is valid and the resource server permits the client to cooperate, the authorization issues a new access token and refresh token. In this case, the authorization server invalidates the used refresh token. Processing for re-issuing an access token using a refresh token will be referred to as refresh processing hereinafter. Note that re-issuance of a token will often be referred to as updating or refreshing of a token, but they are synonymous in this embodiment .
• an illicit client can spoof an authentic client to execute refresh processing.
• the illicit client which executed the refresh processing can spoof the authentic client to use the resource server using an issued access token.
• the illicit client can also spoof the authentic client to continuously use the resource server using a new refresh token issued by the refresh processing. Furthermore, by only providing an access token issued by the illicit client, various clients can illicitly use the resource server.
• processing step 1601 an illicit client requests the authorization server to execute refresh processing. Assume that the illicit client is a system which possesses authentication information and a refresh token leaked from the client. Since the illicit client uses the authentication
• the authorization server executes refresh processing, and issues a new access token and refresh token. After that, the authorization server invalidates the refresh token used in the refresh processing. In processing step 1602, the authorization server passes the issued access token and refresh token to the illicit client.
• processing step 1603 the client requests to invalidate the refresh token and access token.
• the refresh token possessed by the client has already been invalidated by the refresh processing in processing step 1601.
• the client cannot know the refresh token issued by the refresh processing in processing step 1601. For this reason, if the illicit client executes the refresh processing even once, the client cannot invalidate the subsequent refresh processing.
• authentication information of an authentic client is updated. For example, when a password of the client is changed at the authorization server, refresh processing by an illicit client which knows only authentication information before change can be prevented. According to this method, even when the illicit client executes the refresh processing, the refresh processing can be prevented.
• processing step 1706 since the access token is invalid, the client attempts to re-issue an access token using a refresh token.
• the client sends the refresh token and authentication information of the client to the authorization server, and requests it to execute refresh processing. Assume that the refresh token is invalid.
• the refresh token is invalid, it has already been invalidated since the refresh processing was executed, or it is invalid since a valid period of the refresh token has expired.
• authorization server returns a refresh token invalid message to the client in processing step 1707.
• the client Upon reception of the refresh token invalid message, the client detects a possibility of illicit execution of refresh processing. For this reason, in processing step 1708, the client requests the authorization server to change its authentication information. A change of the authentication
• the authorization server Upon reception of the authentication information change request of the client, the authorization server updates the client authentication information managed by itself. After that, the authorization server sends a client authentication information change end notification to the client in processing step 1709.
• the client authentication at the authorization server is executed at an access token issuance timing and an execution timing of refresh processing. For this reason, in order to change the password, these processes have to be stopped. That is, these processes at the client are stopped between processing steps 1708 and 1709.
• OAuth is a use model of one client by a plurality of owners.
• the present invention can solve such problems, and provides a mechanism which prevents an access token from being re-issued within a narrow influence range and prevents an illicit use of a system when
• Such online services include a standalone online service managed by a single service provider and also a method of implementing one solution by combining a plurality of online services managed by a plurality of service providers.
• the latter solution is called “mashup", and seems like one Web site or Web service on the surface.
• a plurality of online services are made to cooperate and linked to combine required functions, thereby implementing the solution.
• an online service in this case is a function group provided by a Web site, Web application, Web service, and the like.
• the Web site, Web application, Web service, and the like are software programs executed by a server
• a system configured by "mashup” will also be referred to as a server cooperative system or simply as a cooperative system in this embodiment.
• Fig. 1 shows the network arrangement including various online services.
• the Internet 100 is a public network such as the Internet, which can be externally connected.
• An intranet 101 is a private network such as a LAN, which cannot be externally connected.
• An information terminal 102 includes a personal computer, mobile terminal, and the like, and is used when online services are used via the Internet 100.
• This example shows two terminals 102A and 102B. However, since either of these terminals may be used, they will be described as an information terminal 102 unless
• OAuth a user who operates the information terminal 102 is called an owner, and a Web browser included in the information terminal 102 is called a user agent.
• An external service system 103 is an online service system which mashes up a form service system 105 (to be described later) online. This system is called a client in OAuth. Note that in this
• this system is often called a client apparatus to clarify that the client is an apparatus.
• the external service system 103 includes one or a plurality of external servers, and is configured to distribute and process requests from the Internet 100 by a load distribution apparatus 108. Note that the external service system 103 includes two external servers 103A and 103B in Fig. 1, but it includes one or a plurality of external servers in practice.
• An access management service system 104 is a service system which manages authentication information of a user and authorization information. In OAuth, this system is called an authorization server.
• the access management service system 104 includes one or a plurality of access management servers, and is
• the access management service system 104 includes two access management servers 104A and 104B in Fig. 1, but it includes one or a plurality of access management servers in practice.
• the form service system 105 is an online service system which generates a form in accordance with a request from the information terminal 102 or external service system 103 via the Internet 100.
• this system is called a resource server.
• the form service system 105 includes one or a plurality of form servers, and is configured to distribute and process requests from the Internet 100 by a load distribution apparatus 108. Also, the form service system 105 can distribute and process requests via the intranet 101 by another load distribution apparatus 108.
• the form service system 105 includes two form servers 105A and 105B in Fig. 1, but it includes one or a plurality of form servers in practice.
• the form service system is exemplified as the resource server, and any other servers are applicable as long as they provide services via webs.
• Fig. 2 shows the logical arrangement of an information processing function of a server computer which executes software programs such as a Web site, Web application, and Web service that configure various servers shown in Fig. 1.
• a user interface 201 is hardware required to input/output information by means of a display, keyboard, mouse, and the like.
• a computer which does not include these hardware components can be connected and operated from another computer by remote desktop or the like.
• a network interface 202 is hardware which connects a network such as a LAN to communicate with another computer and network device.
• a CPU 203 is hardware which connects a network such as a LAN to communicate with another computer and network device.
• the ROM 204 is a storage device which records embedded programs and data.
• the RAM 205 is a temporary memory area.
• the secondary storage device 206 is an external storage device represented by an HDD. The respective units are connected via an input/output interface 207.
• FIG. 3 is a block diagram showing the internal structure of the external server 103A.
• a request processor 301 processes a function request which is received by the external service system 103 via the Internet 100.
• a function controller 302 receives the request from the request processor 301, executes required processing, and returns response data to the call source.
• a function cooperation data manager 303 manages data required to generate a request to a system with which the external service system 103 cooperates.
• An authorization code manager 304 manages authorization code data.
• a token manager 305 manages authorization information data.
• the external server 103B can provide functions different from those of the external server 103A. However, in this example, the external server 103B has the same arrangement as that of the external server 103A, and provides the same functions to
• Functions to be provided by the external server 103A include, for example, a network print service.
• the external server 103A receives, as a client, a print request of form data together with designations of a location and name of form data to be printed from a Web browser as a user agent.
• the external server 103A accesses the form service system 105 to acquire form data requested by the user.
• the external server 103A converts the form data into print data after being merged with designated data according to the request, and transmits the print data to a printing apparatus or print server on a designated network to control it to print the print data.
• the service provided by the external service system 103 is not limited to the print service.
• Fig. 4 is a block diagram showing the internal structure of the access management server 104A. The same applies to the access management server 104B.
• An access management request processor 401 is a processor which processes authentication and authorization
• each user account includes, for example, a set of an ID and password unique to each user. Note that a set of an ID and password is also called a credential.
• authorization data manager 404 manages authorization information data.
• the authorization data manager 404 also manages update authorization information data in addition to the authorization information.
• authorization data manager 404 stores not only the latest authorization information and update
• Fig. 5 is a block diagram showing the internal structure of the form server 105A. The same applies to the form server 105B.
• a form request processor 501 receives a form data generation request and form data acquisition request via the Internet 100.
• a form controller 502 executes required processing according to the requests received by the form request processor 501, and returns response data to a call source.
• the form controller 502 transmits an authentication request to the access management service system 104 via the intranet 101, and receives an authentication result. Also, the form controller 502 transmits an
• a form data manager 504 registers and manages form format data and form data used in form data generation
• the form data manager 504 receives the form data
• Figs. 6A to 6C show the data structures of authorization information and an authorization code which are held by the external service system 103, and authentication information of the external service system in a table format.
• Authorization information and those related to authorization are managed using an authorization information management table 600 and authorization code table 610, and authentication information of the external service system is managed using a client credential table 620.
• the authorization information management table 600 includes a cooperating system name 601 indicating a cooperation target system name, an access token ID 602 indicating authorization information, a refresh token ID 603 indicating update authorization information, and an initial refresh token ID 604.
• the access token ID 603 saves an access token issued by the access
• the refresh token ID 603 saves a refresh token issued by the access management server.
• the initial refresh token ID 604 saves a first refresh token issued by the access management server at the time of first authorization processing.
• the contents of the access token ID 602 and refresh token ID 603 are respectively updated by authorization information and update
• the initial refresh token ID 604 successively stores the update authorization information used in the first refresh processing.
• these field names include “token ID”, but these fields store tokens themselves in place of token IDs.
• the authorization code table 610 includes a cooperating system name 611 indicating a cooperation target system name, and an authorization code ID 612 used to uniquely identify an authorization code
• the authentication information table 620 includes a cooperating system name 621 indicating a cooperation target system name, and a client ID 622 and password 623 which are required to authenticate the external service system 103 with respect to the cooperation target system. Details of processing of data stored in the respective data structures shown in Figs. 6A to 6C will be described later. Note that one record of the authorization information management table 600 managed by the external server system 103 will also be referred to as client authorization related information in this embodiment .
• Figs. 7A and 7B, Fig. 8, and Fig. 9 show various kinds of information which are held by the access management service system 104 and are associated with authorization and authentication.
• Figs. 7A and 7B show the data structures of user information and system information held by the access management service system 104 in a table format. The user information is managed using a user table 700, and the system
• the user information to be managed is that of each user of a system (resource server in
• OAuth OAuth managed by the access management service 104.
• users of the form service system 105 are registered .
• the system information to be managed is authentication information used in client
• the system information includes a client ID and password required to identify the external service system 103 as a client.
• the user table 700 includes user information including a user ID 701 and password 702.
• the client table 710 includes system information including a client ID 711 indicating an ID of the client and a password 712. Details of processing of data stored in the respective data structures shown in Figs. 7A and 7B will be described later.
• Fig. 8 shows the data structure of an
• authorization code is managed using an authorization code table 800.
• the authorization code table 800 includes an authorization code ID 801 indicating a value used to uniquely identify an authorization code, and a user ID 802 used to uniquely identify a user who executes authorization.
• the authorization code indicates
• Fig. 9 shows the data structure of authorization information held by the access management service system 104 in a table format.
• authorization information corresponds to an access token
• update authorization information corresponds to a refresh token. Also, in Fig. 9, a set of
• authorization related information in fields 901 to 908 will also be referred to as authorization related information in this
• the authorization information management table 900 has an access token ID 901 as authorization
• the authorization information management table 900 has a refresh token ID 904 as update authorization
• the authorization information management table 900 has a user ID 907 of a user who is permitted to access the resource server (that is, the form service system) by the access token, and an initial refresh token ID 908 for each access authority.
• the initial refresh token ID 908 saves a refresh token ID issued together with a first access token in association with that access authority .
• both an access token and refresh token are reissued.
• the re-issued access token is also related to one access authority which is the same as that of the source access token.
• authorization related information of the re-issued access token and the like is to be distinguished from that of the source access token and the like, "new" and "previous” are to be attached to them. That is, when refresh processing is executed using a refresh token, a new access token and new refresh token are re-issued. An access token and refresh token before re-issuance will be
• a previous access token and previous refresh token respectively referred to as a previous access token and previous refresh token.
• a first access token and refresh token related to one access authority will be respectively referred to as an initial access token and initial refresh token.
• An access token and refresh token re-issued by refresh processing are saved in the authorization information management table 900 together with their issuance dates and times and valid dates and times. The valid date and time can be obtained by adding a predetermined period to the issuance date and time.
• the user ID 907 saves a user ID stored in association with a refresh token used for the refresh processing, and the initial refresh token ID 908 saves a value of an initial refresh token stored in
• processing is the initial refresh token, and that value is saved as the initial refresh token ID 908 of the corresponding access authority.
• the initial refresh token may be saved in place of null.
• authorization information management table 900 whether or not the valid date and time of each token have expired is determined, and when the valid date and time has expired, the corresponding token may be deleted.
• the access authority or refresh authority is determined with reference to the valid date and time, and deletion is not indispensable. However, efficiency of a storage area can be enhanced by deletion. Note that when a refresh token is used once to execute refresh
• authorization related information including a valid access token or valid refresh token in association with one access authority. For this reason, as long as tokens are updated by appropriate refresh processing, the latest access token and refresh token are kept synchronized between the external service system 103 (client) and access management service system 104 (authorization server) by a sequence to be described later. However, when illicit refresh processing (also called re-issuance processing or update processing) is executed due to leakage of a refresh token and client credentials, that synchronization is lost.
• the authorization information management tables shown in Figs. 6A and 9 exemplify that state.
• the authorization information management table 900 shown in Fig. 9 three sets of authorization information are registered in association with an access authority having "EFGH5678" as an initial access token. Of these pieces of information, the latest access token is
• synchronization is, for example, illicit refresh processing or the like, which is requested by a third party who originally does not have any authority using the leaked refresh token and client credentials, as described above.
• FIGs. 10A and 10B show an access token issuance sequence for issuing an access token which is issued by the access management service system 104 and is
• the external service system 103 and form service system 105 are online service systems managed by different service providers.
• the access management service system 104 controls accesses to the form service system 105 from users including another service.
• the external service system 103 provides a service using form data provided by the form service system 105, for example, a print service to users.
• a user who issued a form generation instruction to the external service system 103 has to be that of both of the external service system 103 and form service system 105. Also, the external service system 103 actually transmits a form generation request to the form service system 105. For this reason, the external service system 103 has to be a user of the form service system 105. On that basis, within an authority range of the user who issued the form generation instruction, the external service system 103 has to be able to use the form service system 105. More specifically, the user who issues a service request to the external service system 103 has to permit the external service system 103 to use the form service system, and to authorize use of the form service system 105 by the external service system 103. Note that in the following
• a user who operates the information terminal 102 will be referred to as "user”.
• step S1001 the information terminal 102A executes a user agent such as a Web browser, and accepts an operation by a user A.
• a user agent such as a Web browser
• the user A operates the information terminal 102A and issues a form generation instruction to the external service system 103, that form generation instruction is
• step S1002 the external service system 103 accepts the form generation instruction from the information terminal 102A. After that, the external service system 103 confirms whether or not it possesses an access token to the form service system 105 in the authorization information management table 600. If the external service system 103 possesses an access token to the form service system 105, it ends the access token issuance sequence. If the external service system 103 does not possess any access token to the form service system 105, it transmits an authorization request to the access management service system 104 in step S1003.
• step S1004 upon reception of the
• the access management service system 104 generates an authentication screen (not shown) which prompts the user A to undergo authentication processing, and transmits that screen to a Web browser (not shown) included in the information terminal 102A to display the screen on the browser.
• step S1005 the user A inputs a user ID and password to the authentication screen displayed on the Web browser of the information terminal 102A as
• the information terminal 102A sends an input authentication request to the access management service system 104.
• step S1006 the access management service system 104 receives the authentication request from the information terminal 102, and verifies the user ID and password. More specifically, the access management service system 104 determines whether or not a
• the access management service system 104 judges the user A who operates the information terminal 102 as a user of the form service system 105, and the process advances to step S1009 to continue processing.
• step S1009 the access management service system 104 generates an authorization screen 1100 (to be described later) , and transmits that screen to the Web browser (not shown) included in the information terminal 102.
• step S1010 the Web browser included in the information terminal 102 receives and displays the authorization screen 1100.
• the information terminal 102A transmits an authorization approval to the access management service system 104.
• step S1011 the access management service system 104 generates an authorization code based on the received authorization approval, and stores that code in the authorization code table 800 managed by the authorization data manager 404 in association with the authorized user ID.
• the access management service system 104 redirects the Web browser (not shown) included in the information terminal 102A to the external service system 103, and returns the generated authorization code to the external service system 103 as a response to the request in step S1003.
• step S1012 the external service system 103 stores the received authorization code in the
• the external service system 103 transmits an access token request as an issuance request of an access token together with the authorization code and a client ID and password stored in the authentication information table 620 to the access management service system 104.
• the access management service system 104 receives the access token request, and authenticates the external service system 103. More specifically, the access management service system 104 determines whether or not a combination of the client ID and password included in the access token request is registered in the client table 710 stored in the authentication data manager 403. [0096] If the combination of the client ID and passwor is registered in the client table 710, the access management service system 104 judges the external service system 103 which issued the access token request as a user of the form service system 105.
• step S1014 the process advances to step S1014 to continue processing.
• step S1014 the access management service system 104 verifies the authorization code included in the access token request. More specifically, the access management service system 104 determines whethe or not the authorization code received together with the access token request is registered in the
• the access management service system 104 judges that the user permits use of the form service system 105, and the process advances to step S1016 to continue processing.
• step S1016 the access management service system 104 generates an access token and refresh token and stores the generated tokens in the authorization information management table 900 managed by the authorization data manager 404.
• the access management service system 104 sets the generation times of the tokens in the access token issuance date and time 902 and refresh token issuance date and time 905.
• the access management service system 104 sets a valid period of the access token in the access token valid date and time 903, and that of the refresh token in the refresh token valid date and time 906.
• the access management service system 104 sets, as user information, the user ID who issued the successfully verified authorization code in the user ID 907. Then, the access management service system 104 sets refresh token information issued first in the initial refresh token ID 908.
• the initial refresh token ID 908 available is set in the initial refresh token ID 908. Note that the same value as the refresh token ID 904 may be set in the initial refresh token ID 908 as issued refresh token information.
• the access management service system 104 returns the generated access token and refresh token to the external service system 103 as a response of step S1013.
• step S1017 the external service system 103 stores the received access token and refresh token in the authorization information management table 600 managed by the token manager 305. More specifically, the external service system 103 sets the received access token in the access token ID 602, and sets the received refresh token in the refresh token ID 603 and initial refresh token ID 604.
• step S1006 the access management service system 104 judges that the user A who operates the information terminal 102A is not a user of the form service system 105. After that, the access management service system 104 returns an authentication error to the external service system 103 as a response of step S1004.
• step S1007 upon reception of the
• the external service system 103 generates an authentication error screen (not shown) , and sends that screen to the information terminal 102A.
• the Web browser (not shown) included in the information terminal 102 receives and displays the error screen, thus ending the processing.
• the access management service system 104 judges that the external service system 103 which issued the access token request is not a user of the form service system 105. After that, the access management service system 104 transmits an
• step S1015 the process advances to step S1015.
• the access management service system 104 judges that the user does not permit use of the form service. After that, the access management service system 104
• step S1015 the process advances to step S1015.
• step S1015 the external service system 103 receives the authentication error or authorization error from the access management service system 104.
• the external service system 103 generates an
• step S1008 the information terminal 102A displays the received error screen, thus ending the processing .
• the client that is, the external service system 103
• the resource server that is, the form service system 104
• the external service system 103 can use the access authority of the user to the form service system 105 without receiving any
• Fig. 11 shows the authorization screen generated by the access management service system 104 in step S1004.
• the authorization screen 1100 includes an information display area 1101, authorization button 1102, and authorization cancel button 1103.
• the information display area 1101 presents information of a service to be authorized and a service to be executed by the authorized service to the user. In this
• the service to be authorized indicates the external service system 103, and the service to be executed by the authorized service indicates the form service system 105.
• Figs. 12A and 12B show the sequence of
• the sequence shown in Figs. 12A and 12B includes the token issuance sequence shown in Figs. 10A and 10B, and also a sequence executed when the external service system 103 accesses the form service system 105.
• Steps S1001 and S1002 are the same as those in the sequence described using Fig. 10A. Also, step
• S1201 represents the access token issuance sequence from step S1003 to step S1017 in Figs. 10A and 10B.
• FIGS. 12A and 12B show this step as the
• step S1202 the external service system 103 sends a form generation request to the form service system 105 using the access token which is stored in the authorization information management table 600 and is required to use the form service system. That is, the client transmits an access request required to request a service to the resource server. Note that "use” is to transmit, together with a service request message, an access token indicating that a request source has been authorized in association with that request to a request destination. Assume that the external service system 103 passes an access token
• step S1203 the form service system 105 requests the access management service system 104 to verify the access token sent together with the form generation request.
• step S1204 the access management service system 104 verifies the received access token. More specifically, the access management service system 104 determines whether or not the received access token is registered in the authorization information management table 600. If the access token is registered, the access management service system 104 determines whether or not the access token falls within the valid period. If the access token is registered and falls within the valid period, the access management service system 104 returns an access token valid message as a response. If the access token is not registered or if the access token is registered but it falls outside the valid period, the access management service system 104 returns an access token invalid message as a response. Assume that the verification time is "15:00, April 1, 2011", and the access token "IJKL9012" is passed. In this case, although the access token "IJKL9012" is registered in the authorization information management table 900 but a time set in the access token valid date and time 903 has elapsed, it is judged that the access token is invalid.
• step S1205 the form service system 105 receives the access token verification result returned from the access management service system 104. If the access token is valid, the form service system 105 permits access of a form generation function, and the process advances to step S1206. If the access token is invalid, the form service system 105 returns an access token invalid message to the external service system 103 as a response of step S1203, and the process
• step S1206 the form service system 105 generates a form, and returns the generated form data to the external service system 103 as a response of step S1203.
• step S1207 the external service system 103 receives the form data from the form service system 105, and transmits the form data to the information terminal 102A.
• step S1208 the information terminal 102A displays the received form data on its Web browser (not shown) , thus normally ending the form generation
• step S1209 upon reception of the access token invalid message, the external service system 103
• the external service system 103 requests the access management service system 104 to execute refresh processing. More specifically, the external service system 103 sends a refresh processing request to the access management service system 104 together with a refresh token of the form service system 105 saved in the authorization information management table 600 and a client ID and password for the form service system 105. Assume that the external service system 103 passes a refresh token "4567EFGH".
• step S1210 the access management service system 104 verifies the external service system 103. More specifically, the access management service system 104 determines whether or not the combination of the client ID and password included in the refresh
• processing request is registered in the client table 710 stored in the authentication data manager 403.
• the access management service system 104 judges that the form service system 105 permits cooperation with the
• step S1213 to continue processing.
• the access management service system 104 If the combination of the client ID and password is not registered in the client table 710, the access management service system 104 returns an authentication error to the external service system 103, and the process advances to step S1211.
• step S1211 upon reception of the
• the external service system 103 generates an authentication error screen (not shown) and sends that screen to the information terminal 102A. After that, in step S1212, the error screen is displayed on the Web browser (not shown) included in the information terminal 102, thus ending the
• step S1213 the access management service system 104 verifies the refresh token sent together with the refresh processing request. More specifically, the access management service system 104 determines whether or not the received refresh token is registered in the authorization information management table 600. If the refresh token is registered, the access
• management service system 104 further determines
• step S1214 the process advances to step S1214 to continue processing.
• the access management service system 104 judges that the refresh token is invalid, and returns a token invalid message to the external service system 103 as a response. Then, the process advances to step S1217. Assume that the refresh token "4567EFGH” is passed at "14:30, April 1, 2011". In this case,
• step S1214 the access management service system 104 generates a new access token and refresh token, and stores these tokens in the authorization information management table 900 managed by the
• the access management service system 104 acquires a value of the initial refresh token ID 908 set in association with the refresh token verified in step S1210 from the authorization information management table 900, and registers that value as an initial refresh token of the newly stored token. Note that when the value of the initial refresh token ID 908 is "null", the access management service system 104 registers the refresh token used in verification as an initial refresh token.
• step S1215 the access management service system 104 invalidates the refresh token used in verification. More specifically, the access management service system 104 updates a value of the refresh token valid date and time 906 to a value of the refresh token issuance date and time 905 in association with the corresponding refresh token in the authorization information management table 900. Note that this embodiment invalidates the refresh token by updating the refresh token valid date and time, but the refresh token may be invalidated by other methods. For example, an item of a refresh token valid flag may be defined in the authorization information management table 900, and the refresh token may be invalidated by updating a value of that item. After that, the access management service system 104 returns the newly issued access token and refresh token to the external service system 103 as a response of step S1210.
• step S1216 the external service system 103 updates the values of the access token and refresh token of the form service system 105, which are
• the external service system 103 respectively sets the received access token and refresh token in the access token ID 602 and the
• the external service system 103 does not update the initial refresh token ID 604.
• step S1202 the process returns to step S1202, and the external service system 103 issues a form generation request again.
• step S1217 upon reception of the refresh token invalid response, the external service system 103 requests to invalidate authorization information. More specifically, the external service system 103 sends a value of the initial refresh token of the form service system registered in the authorization information management table 600 to the access management service system 104. Assume that the external service system 103 passes "0123ABCD" as the value of the initial refresh token.
• step S1218 the access management service system 104 executes token invalidation processing (to be described later) .
• step S1219 the external service system 103 deletes authorization information of the form service system 105. More specifically, the external service system 103 deletes values of the access token ID 602, refresh token ID 603, and initial refresh token ID 604 of the form service system 105 registered in the authorization information management table 600.
• step S1201 the process returns to step S1201, and the external service system 103 executes the access token issuance processing again.
• step S1217 the external service system 103 requests the access management service system 104 to execute refresh token invalidation processing using the initial refresh token as a characteristic feature of this embodiment.
• the external service system 103 transmits the initial refresh token for the form service system 105, which token is registered in the authorization information management table 600, together with the invalidation processing request.
• the access management service system 104 which received the invalidation processing request, executes the refresh token invalidation processing of the received refresh token registered as the initial refresh token in step S1218. Details of this processing will be described later with reference to Fig. 13. After the refresh token invalidation processing is complete, the access management service system 104 returns an invalidation completion response to the external service system 103.
• the external service system 103 which received the response, deletes the client authorization related information including the invalidated refresh token from the authorization information management table 600 in step S1219. Note that at the time of step S1219, the access token has already been invalidated. After that, the process returns to step S1201, and the external service system 103 executes processing for issuing a new access token and refresh token again. Note that the external service system 103 may transmit the set of the client ID and password for the form service system 105 together as in the refresh processing request, although such transmission is not required in this example. In this case, the access management service system 104 authenticates the authority as in step S1210 immediately before step S1218. If the authentication has succeeded, the access management service system 104 invalidates the refresh token in step S1218.
• Fig. 13 shows the detailed sequence of the refresh token invalidation processing according to the first embodiment, that is, step S1218 in Fig. 12B.
• step S1301 the access management service system 104 accepts the refresh token together with the refresh token invalidation request. Assume that a refresh token "0123ABCD" is passed.
• step S1302 the access management service system 104 invalidates all refresh tokens, the initial refresh token of which is the received refresh token. More specifically, the access management service system 104 invalidates refresh tokens corresponding to the received refresh token registered in their refresh token ID 908 of the authorization information
• step S1303 the access management service system 104 invalidates the received refresh token.
• the access management service system 104 updates the value of the refresh token valid date and time 906 to that of the refresh token issuance date and time 905 in association with corresponding refresh tokens in the authorization information management table 900. Note that when an access token and refresh token are issued for the first time, and the issued refresh token is registered as an initial refresh token, since that refresh token is also invalidated in step S1302, this step may be omitted. Also, the sequence for invalidating a refresh token corresponding to an initial refresh token "null" is a conventional
• step S1302. compatibility with a client which issues an
• a refresh token is invalid in two patterns, that is, when the valid period has expired without any refresh processing, and when that refresh token is invalidated as a result of issuance of a new refresh token by executing the refresh processing.
• Fig. 14 shows the sequence of authorization information invalidation processing according to the second embodiment. Steps S1301 to S1303 are the same as those in Fig. 13.
• step S1401 an access management service system 104 invalidates access tokens corresponding to refresh tokens which are invalidated in steps S1302 and S1303. More specifically, the access management service system 104 updates a value of access token valid date and time 903 to that of access token
• invalidation is attained by updating the valid date and time of an access token, but it may be
• an item of an access token valid flag may be defined in the
• authorization information management table 900 and invalidation may be attained by updating a value of that item.
• a refresh token "0123ABCD” is passed at "14:30, April 1, 2011” in step S1301.
• refresh tokens "0123ABCD”, "4567EFGH”, and "89011JKL” are selected as invalidation targets.
• access tokens "EFGH5678”, “IJKL9012”, and “MNOP3456” are invalidated.
• the access tokens "EFGH5678” and “IJKL9012” have already been invalidated, only the access token "MNOP3456” is invalidated .
• access tokens can also be invalidated by the method described in the second embodiment.
• an authorization server which implements the invention according to this embodiment not only supports a client which implements the invention according to this embodiment, but also can maintain compatibility with a client which implements the conventional OAuth protocol.
• aspects of the present invention can also be realized by a computer of a system or apparatus (or devices such as a CPU or MPU) that reads out and executes a program recorded on a memory device to perform the functions of the above-described
• embodiment ( s ) and by a method, the steps of which are performed by a computer of a system or apparatus by, for example, reading out and executing a program recorded on a memory device to perform the functions of the above-described embodiment (s) .
• the program is provided to the computer for example via a network or from a recording medium of various types serving as the memory device (for example, computer- readable medium) .

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• General Engineering & Computer Science (AREA)
• Computer Hardware Design (AREA)
• Theoretical Computer Science (AREA)
• Computing Systems (AREA)
• Software Systems (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Storage Device Security (AREA)
• Computer And Data Communications (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=49623602

Family Applications (1)

Country Status (5)

Cited By (5)

Families Citing this family (68)

Citations (2)

Family Cites Families (9)

• 2012
  • 2012-05-25 JP JP2012120140A patent/JP6006533B2/ja active Active
• 2013
  • 2013-04-10 CN CN201380027459.4A patent/CN104350501B9/zh active Active
  • 2013-04-10 WO PCT/JP2013/061344 patent/WO2013175901A1/en not_active Ceased
  • 2013-04-10 KR KR1020147035695A patent/KR101640383B1/ko active Active
  • 2013-04-10 US US14/001,658 patent/US9571494B2/en active Active

Patent Citations (2)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events