JP2017091221A - Authority delegation system, control method thereof, authorization server, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a system for delegating authority of a user from a client to whom the authority of the user has been delegated to another client.SOLUTION: An authority delegation system includes: first and second clients; a service provision device; and an authorization server. The first client uses a service of the second client on the basis of first authorization information indicating that specific authority has been delegated from a user to the first client. The authorization server specifies the first client from the first authorization information transmitted according as the service is used, and confirms whether or not the specified first client is associated with the second client, and issues second authorization information indicating that specific authority has been delegated to the second client according as it is confirmed that the first client is associated with the second client. The second client uses a service of the service provision device on the basis of the provided second authorization information.SELECTED DRAWING: Figure 7

Description

  The present invention relates to an authority delegation system, a control method thereof, an authorization server, and a program.

In recent years, the use of services that provide software functions via the Internet called cloud services is expanding. For example, there are services for creating PDF-format electronic documents on the Internet and services for storing electronic documents. By using such a service, a user can create a PDF even if the terminal owned by the user does not have a PDF creation function, and can also store an electronic document more than the storage capacity of the terminal. . In addition, cloud services can be linked to increase added value. For example, it is possible to create an electronic document in PDF format using the cloud service described above, and store the created electronic document directly in a service that stores electronic documents on the Internet without going through a terminal owned by the user. It can be realized by service cooperation.
Conventionally, in order to realize such service cooperation, a standard protocol for delegation of authority called OAuth has been widely used. OAuth will be described later.

  As the use of cloud services increases, there is a demand for providing a service that links three or more cloud services. For this purpose, the client to which the authority of the user has been delegated uses the first resource service, and further, the first resource service becomes the client and wants to use the second resource service. Therefore, Patent Document 1 discloses a technology for performing authority delegation in two stages in a device in which a user can delegate authority to a device and a device can delegate authority to an application in the device. ing. With the technology that expands this OAuth, if the user confirms authorization and delegates authority to the device, then authority can be delegated from the device to the application in the device without authorization operation.

JP 2014-099030 A

  However, in Patent Document 1, the first authority delegation can only be performed on the device, and the second-stage authority delegation can be performed only on the application in the device.

  It is an object of the present invention to provide a system for delegating authority from a client whose authority has been delegated to another client.

  In order to solve the above-described problems, the present invention provides an authority delegation system including a first client and a second client that provide a service via a network, a service providing device, and an authorization server. The first client has a first use means for using the service of the second client based on the first authorization information indicating that a specific authority is delegated from the user to the first client. Have. The authorization server identifies the first client from the first authorization information transmitted along with use by the first utilization means, and the identified first client and second client are associated with each other. Confirmation means for confirming whether or not there is a second authorization information indicating that a specific authority has been delegated to the second client in response to confirmation by the confirmation means Issuing means for issuing. The second client has second use means for using the service of the service providing apparatus based on the second authorization information provided from the issuing means.

  According to the present invention, it is possible to delegate authority from a client whose authority has been delegated to another client.

It is a system configuration diagram. It is a hardware block diagram of each apparatus. It is a software module block diagram of each apparatus. It is a processing sequence diagram of a service in which three services are linked. It is a processing sequence diagram of a service in which three services are linked. It is an example of the screen related to authorization processing. It is a flowchart of the trust relationship confirmation process at the time of the 2nd authorization token issue. It is a processing sequence diagram of a service in which three services are linked. It is a flowchart of a client trust relationship confirmation process. It is a figure which shows a user management table and a client management table. It is a figure which shows an authorization token management table. It is a figure which shows a client trust relationship management table.

(First embodiment)
First, OAuth, which is a standard protocol for the authority delegation system, will be described. According to OAuth, for example, service A delegated by a user can access user data managed by service B. As in service A, a user whose authority is delegated to access service B on behalf of the user is called a client. The service B that manages user data is called a resource server (service providing apparatus). When a client accesses a resource server, the client is to obtain an explicit authorization for access from the user after clarifying the range of resources to be accessed. The explicit authorization by the user is called authorization operation.
When the user performs an authorization operation, the client receives a token certifying that access to the resource server has been granted (hereinafter referred to as an authorization token). Thereafter, the client can access the resource server using the authorization token.
When the authorization token is used, the client can access the resource server with the authority of the authorized user without the user authentication information. Therefore, OAuth stipulates that the client / resource server should not leak the authorization token to the outside from the viewpoint of security. Each cloud service is responsible for strictly and properly managing authorization tokens so as not to leak outside.

A method that can be considered as a method of linking three or more services using an OAuth authorization token is a method of acquiring an authorization token for using a plurality of services, and passing this authorization token between services. is there. However, from the viewpoint of security, OAuth restricts the delivery of the authorization token only between the client and the service and prohibits the leakage of the authorization token to the outside. When a resource service passes an authorization token to another external resource service, there is a risk of leakage of the authorization token. A third party who has stolen an authorization token can use a plurality of resource services with the authority of the authorized user without user authentication information.
Therefore, in this embodiment, when delegating authority between services, a new authorization token that takes over the authority from a certain authorization token is issued, and the authorization token is transferred, so that the authority of the user is delegated between services. Take measures to let you. In this way, authority delegation between services can be realized while complying with the OAuth rules.

  Further, in the authority delegation between three or more services, there is a possibility that authority delegation is performed from one service to another without the user's knowledge. Therefore, in this embodiment, the risk of leakage of the authorization token is reduced, and the cooperation of three or more services is realized after obtaining the user's consent that the service delegates authority to another service. To.

In this embodiment, it is assumed that a floor machine management service that manages printers on the office floor, a form service that generates form data, and a print service that acquires and prints data are installed on a server on the Internet. ing. Hereinafter, services that provide functions on the Internet, such as floor machine management services, form services, and printing services, are referred to as resource services. In the present embodiment, a service for processing floor machine usage data into form data by linking the above-described floor machine management service, form service, and print service, and further printing the form data will be described. .
In this embodiment, it is assumed that the service is used from a Web browser or a native application on a user terminal such as a PC or a portable terminal. A Web browser or application on the user terminal is called a service cooperation application. The resource service to which the present invention can be applied is not limited to the floor machine management service, the form service, and the printing service.

The authority delegation system according to the present embodiment is realized on a network configured as shown in FIG.
The WAN 100 is a wide area network (WAN), and a world wide web (WWW) system is constructed in the present embodiment. A LAN 101 is a local area network (LAN) that connects each component.
The authorization server 200 is an authorization server for realizing OAuth. The floor machine management server 220, the form server 240, and the print server 260 provide respective services to the user in cooperation with the authorization server 200 as resource servers. The floor machine management server 220 is a first client, the form server 240 is a second client, and the print server 260 corresponds to a service providing apparatus. Note that one or more resource services may be installed on one resource server. Further, the authorization server and the resource server may be a server group including a plurality of servers instead of one.
The user terminal 300 is an information device such as a personal computer or a smartphone, and a web browser and an application are installed. The user uses the service of the resource server using a web browser or an application. The authorization server 200, floor machine management server 220, form server 240, print server 260, and user terminal 300 are connected via the WAN 100 and the LAN 101, respectively. The authorization server 200, the floor machine management server 220, which is a resource server, the form server 240, the print server 260, and the user terminal 300 may be configured on individual LANs or on the same LAN. Good. The authorization server 200, the floor machine management server 220, which is a resource server, the form server 240, and the print server 260 may be configured on the same server.

  The authority delegation system according to the present embodiment is realized on a system including information processing apparatuses configured as shown in FIG. The hardware block diagram shown in FIG. 2 corresponds to a hardware block diagram of a general information processing apparatus. The hardware configurations of the authorization server 200, the floor machine management server 220, the form server 240, the print server 260, and the user terminal 300 according to this embodiment can be applied.

In FIG. 2, a CPU 201 executes programs such as an OS and applications and controls each block connected to the system bus 204. 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. Processing of each sequence described later can be realized by executing this program. The OS and applications are stored in an external memory 211 such as a program ROM in the ROM 203 or a hard disk (HD), and loaded into the RAM 202. The RAM 202 functions as a main memory, work area, and the like for the CPU 201. A keyboard controller (KBC) 205 controls key input from a keyboard 209 or a pointing device (not shown). The DSP controller (DSPC) 206 controls display on the display (DSP) 210. A disk controller (DKC) 207 controls data access in an external memory 211 such as a hard disk (HD) that stores various data. A network controller (NC) 208 executes communication control processing with the user terminal 300 and other devices connected via the WAN 100 or the LAN 101.
In all the descriptions below, unless otherwise specified, the hardware main body of execution in the server is the CPU 201, and the software main body is an application program installed in the external memory 211.

FIG. 3 is a diagram showing module configurations of the authorization server 200, the floor machine management server 220, the form server 240, the print server 260, and the user terminal 300 according to the present embodiment. Each of the modules shown in FIG. 3 is a module realized by the CPU of each device shown in FIG. 2 executing an application program installed in the external memory on the RAM.
The authorization server 200 includes an authorization service module 212. The authorization service module 212 has a user authentication function, a client authentication function, an authorization token issue function, and an authorization token verification function. The floor machine management server 220 includes a floor machine management service module 221. The floor machine management service module 221 has a function of outputting the usage status of the floor machine as data. The form server 240 includes a form service module 241. The form service module 241 has a function of generating form data from the received data. The print server 260 includes a print service module 261. The print service module 261 has a function of printing the acquired data.

The user terminal 300 controls each application by the CPU executing the OS 302 or the OS stored in the external memory. The OS 302 is generally a general-purpose OS such as Windows (registered trademark) or Linux (registered trademark), or a mobile terminal OS such as Android (registered trademark) or iOS (registered trademark).
The user terminal 300 has a service cooperation application 301. The service cooperation application 301 is a user agent for using the WWW. The service cooperation application 301 may be a general Web browser that can use the WWW or a native application that includes an embedded browser. The service use sequence in the service cooperation application 301 will be described later.

10A, 10B, 11, and 12A are data tables stored in the external memory by the authorization server 200. FIG. The data table may be stored not in the external memory of the authorization server 200 but in another server configured to be communicable via the LAN 101.
FIG. 10A shows a user management table 1200. The user management table 1200 includes a user ID 1201, a password 1202, and a user type 1203. The authorization service module 212 has a function of authenticating each user or client by verifying the information set of the user ID 1201 and the password 1202 and generating authentication information if they are correct.

  FIG. 10B shows a client management table 1300. The client management table 1300 includes a client ID 1301, a client name 1302, a redirect URL 1303, and an application ID 1304. The client ID 1301 is associated with the user ID 1201 of the user management table 1200 and can be referred to each other. The client name 1302 and the redirect URL 1303 are values used in an OAuth sequence described later. The application ID 1304 is a value for specifying which service the client uses.

  FIG. 11 shows an authorization token management table 1400. The authorization token management table 1400 includes an authorization token ID 1401, a token type 1402, an expiration date 1403, a scope 1404, a client ID 1407, a user ID 1408, and an application ID 1409. Further, the authorization token management table 1400 also includes a refresh token ID 1405 and a refresh time limit 1406. Details of the processing of the authorization token management table 1400 will be described later.

FIG. 12A shows a client trust relationship management table 1500. The client trust relationship management table 1500 includes a token issuing client 1501 and an authority transferable client 1502. The token issuing client 1501 and the authority transferable client 1502 are associated with the application ID 1304 of the client management table 1300 and can be referred to each other.
The client trust relationship management table 1500 is used to determine whether authority can be taken over between clients when authority is delegated between services. Details of processing for determining whether or not authority can be taken over between clients will be described later.

A process for providing a service in which three services of a floor machine management service, a form service, and a printing service are linked will be described with reference to FIGS. 4 and 5.
4 and 5 are sequence diagrams of service processing in which three services are linked. First, in the service cooperation application 301, the user performs an operation of using a service for printing the floor machine usage status as form data (S401). Then, the service cooperation application 301 transmits a resource service use request to the floor machine management service module 221 (S402). When the floor machine management service module 221 receives a resource service use request, the floor machine management service module 221 transmits an authorization request to the authorization endpoint of the authorization service module 212 (S403). Thereby, the OAuth flow with the floor machine management service module 221 as a client starts.
At this time, the floor machine management service module 221 includes the client ID, the request scope, and the redirect URI in the authorization request to be transmitted. Here, the client ID designates cli_000000001. The client ID “cli — 000000001” is the client ID of the client of the floor machine management service module 221 registered in advance in the client management table 1300 of the authorization server. The request scope is a value indicating an authority range to be authorized by OAuth. In the present embodiment, it is assumed that three scope values of floor machine usage status output, form, and printing are designated as request scopes in order to link the three services.

Upon receiving the authorization request, the authorization service module 212 makes a login request to the service cooperation application 301 via the floor machine management service module 221 (S404). At this time, the authorization service module 212 displays a login screen 601 that is an authentication screen shown in FIG. 6A on the service cooperation application 301 in order to authenticate the user.
The user logs in by entering a user ID and password on the login screen 601 shown in the service cooperation application 301 (S405). Here, the user performs a login operation using a pair of the user ID 1201 and the password 1202 of the user ID “user001” in FIG. Then, the service cooperation application 301 transmits a login request including the user ID and password input by the user to the authorization service module 212 via the floor machine management service module 221 (S406). The authorization service module 212 verifies whether the received user ID and password information matches the information registered in the user management table 1200. If it matches with the registered information, it is determined that the logged-in user is a legitimate user, that is, authentication information is generated as successful authentication. If the set of user ID and password information does not match, the authorization service module 212 transmits the login request of S404 again to the floor machine management service module 221 as an authentication error. Note that if the user has logged in before performing the operation in S401, the processing from S404 to S406 is skipped.

  If the authentication is successful, it is next verified whether the redirect URL included in the authorization request is the redirect URL of the client of the floor machine management service module 221. At that time, the authorization service module 212 verifies whether the combination of the client ID and the redirect URL included in the authorization request matches the information registered in the client management table 1300 (S407). If the redirect URL of the authorization request and the redirect URL registered in the client do not match, an error response of the redirect URL is returned to the floor machine management service module 221. Note that the floor machine management service module 221 must not redirect a redirect error.

  If the redirect URL of the authorization request matches the redirect URL registered in the client and the redirect URL verification is successful, the authorization service module 212 acquires a list of clients to which the client can delegate authority (S408). In this process, first, an application ID 1304 of the client of the floor machine management service is acquired from the client management table 1300. Next, in the client trust relationship management table 1500, the authority transferable client 1502 of the record in which the client application ID 1304 and the token issuing client 1501 acquired in the preprocessing match is acquired. Then, a record in which the value of the authority delegable client 1502 acquired in the preprocessing and the value of the application ID 1304 match is acquired from the client management table 1300. The acquired list of records becomes a list of clients to which authority of the floor machine management service can be transferred.

  Then, the authorization screen 602 shown in FIG. 6B is generated and responded to the service cooperation application 301 (S409). At this time, the list of clients that can transfer the authority of the floor machine management service acquired in S408 is displayed on the authorization confirmation screen. In addition to the information described in this embodiment, the authorization confirmation screen can be configured to display a detailed description of the client added here or to display information of the logged-in user. . When the authorization request includes a scope, the authorization screen 602 can be configured to display information on the resource to be accessed that explains the scope of the scope. In addition, the authentication information is stored as cookie information to the service cooperation application 301 and responds.

Next, the user gives an instruction to permit authority transfer on the authorization screen 602 displayed on the service cooperation application 301 (S410). Upon receiving the user instruction, the service cooperation application 301 returns an instruction as a result of the authorization operation to the authorization service module 212 (S411).
Upon receiving the permission instruction, the authorization service module 212 executes the following process. An authorization code is issued and registered in the authorization token management table 1400. At this time, the ID of the token issued to the authorization token ID 1401, the authorization code in the token type 1402, the expiration date 1403, and the client ID received at the time of the authorization request are registered in the client ID 1407. Furthermore, the user ID associated with the authentication information transmitted as a cookie from the service cooperation application 301 is registered in the user ID 1408 (S412). Then, as the authorization code response, the authorization token ID of the authorization code is returned to the redirect URL of the service cooperation application 301 (S413).

Upon receiving the authorization code response, the floor machine management service module 221 makes an authorization token request to the authorization service module 212 (S414). This authorization token request includes the authorization token ID of the authorization code acquired by the authorization code response, the client ID 1301 of the floor machine management service module, the client name 1302, and the redirect URL 1303.
Upon receiving the authorization token request, the authorization service module 212 performs the following verification. If it is correct, the authorization service module 212 generates a first authorization token (first authorization information) (S415). The authorization service module 212 verifies whether the combination of the client ID and the client name received in the token request matches the combination of the user ID 1201 and the password 1202 registered in the user management table 1200. Next, it is verified whether the authorization token ID of the authorization code received in the token request is registered in the authorization token management table 1400 or within the expiration date. Then, it is verified whether the client ID received in the token request matches the client ID 1407 specified by the authorization token ID in the authorization token management table 1400. Furthermore, it is verified whether the redirect URL received in the token request matches the redirect URL 1303 of the client management table 1300. Here, the redirect URL 1303 can be configured to add a column to the authorization token management table 1400 instead of the client management table 1300, register it when issuing the authorization code, and verify the added column.

  If all these verifications are correct, the authorization service module 212 generates an authorization token. At this time, the authorization service module 212 stores the information of the first authorization token in the authorization token management table 1400. In the first authorization token, the ID of the token issued as the authorization token ID 1401, the authorization token and the expiration date 1403 as the token type 1402 are registered. Further, a client ID 1407, a user ID 1408, and an application ID 1409 are registered in the first authorization token as information inherited from the authorization code. The application ID registered at this time is the value of the client application ID 1304 in which the client ID 1301 of the client management table 1300 matches the client ID 1407. Also, a refresh token for refreshing the authorization token is issued, and a refresh token ID 1405 and a refresh time limit 1406 are registered. Then, the authorization token ID 1401 of the generated first authorization token is returned to the floor machine management service module 221. At this time, the refresh token ID issued simultaneously as the response content is also included (S416).

  The floor machine management service module 221 outputs data on the usage status of the floor machine (S417). Then, the floor machine management service module 221 passes the first authorization token acquired in S416 and the floor machine usage status data output in S417 to the form service module 241, and requests the form output as a resource request (S418). Upon receiving the resource request, the form service module 241 requests the authorization service module 212 to verify the token of the authorization token ID of the first authorization token included in the request (S419). This authorization token verification request can include a scope.

Upon receiving the first authorization token verification request, the authorization service module 212 determines whether the accepted authorization token ID is registered in the authorization token management table 1400, is within the valid period, and the accepted scope is within the scope 1404. Verify that. Then, the verification result is returned to the form service module 241 (S420).
As a result of the verification, if it is determined that access is permitted, the form service module 241 outputs a form of usage data of the floor machine (S421).

Subsequently, the form service module 241 makes a second authorization token acquisition request to the authorization server 200 (S422). The second authorization token acquisition request includes the authorization token ID of the authorization token received in S418, the client ID of the form service client registered in the client management table 1300, the client name, and the application.
The authorization service module 212 that has received the second authorization token acquisition request executes the following processing. First, it is verified whether the combination of the client ID and the client name included in the second authorization token acquisition request matches the combination of the user ID 1201 and the password 1202 in the user management table 1200. If it is correct, the authorization token ID included in the second authorization token acquisition request is registered in the authorization token management table 1400, and it is confirmed whether it is within the valid period (S423).

Further, it is confirmed whether the client that has issued the second authorization token issuance request can delegate the authority of the first authorization token (S424).
This confirmation process will be described in detail with reference to FIG. FIG. 7 is a flowchart of the trust relationship confirmation process when the second authorization token is issued.
First, the authorization service module 212 refers to the authorization token management table 1400, and acquires information that identifies the client that issued the first authorization token received in S422 (S701). In this embodiment, the application ID 1409 of the first authorization token is acquired as information that identifies the client that issued the first authorization token.

Next, the authorization service module 212 refers to the client management table 1300, and acquires information identifying the client that has requested the issuance of the second authorization token (S702). In the present embodiment, the client application ID 1304 with the matching client ID received in S422 is acquired.
Then, the authorization service module 212 performs the following process in order to confirm whether or not the client that has issued the first authorization token and the client that has issued the second authorization token issuance request are in a trust relationship. First, the authorization service module 212 refers to the client trust relationship management table 1500, and acquires a record in which the application ID of the first authorization token acquired in S701 matches the token issuing client 1501. Next, it is checked whether the authority delegable client 1502 of the acquired record matches the application ID of the client that issued the second authorization token acquired in S702 (S703).
If the application ID values do not match in S703, it is determined that the client is not reliable, and an error response is returned (705).

  If the application ID values match in S703, it is determined that the client that issued the first authorization token trusts the client that has made the second authorization token issuance request. In that case, the authorization service module 212 generates a second authorization token (S704). In this embodiment, the application ID attribute of the authorization token is compared with the client application ID in order to confirm the client trust relationship. However, if there are other attributes that the client can identify and the authorization token and the client have in common, the trust relationship of the client may be confirmed using that attribute.

  For the second authorization token, a new authorization token ID is issued, the ID is registered in the authorization token ID 1401, the authority takeover token is registered in the token type 1402, and the expiration date of the second authorization token is registered in the expiration date 1403. In the client ID 1407, the client ID of the client that has made the second authorization token issue request is registered. The scope 1404 and user ID 1408 inherit the values from the record specified by the authorization token ID received in the second authorization token acquisition request. In the application ID 1409, a value obtained by combining the value of the client application ID 1304 received by the second authorization token issue request with the application ID 1409 of the record is stored. The application ID 1409 of the record is the application ID 1409 of the record specified by the authorization token ID received in the second authorization token issue request. The application ID 1409 of the second authorization token can be used to identify the client that has passed through when issuing the authorization token. Then, the authorization service module 212 returns the authorization token ID 1401 of the generated second authorization token to the form service module 241 (S425). Note that the authority transfer when issuing the second authorization token from the first authorization token has been confirmed by the user in advance in S410. Therefore, the authorization confirmation screen is not displayed because it is not necessary to notify the user of authority delegation again and receive the user's authorization.

Thereafter, the floor machine management service module 221 passes the second authorization token acquired in S425 and the form data of the floor machine usage status output in S421 to the print service module 261, and requests printing as a resource request (S426).
Upon receiving the resource request, the print service module 261 requests the authorization service module 212 to verify the authorization token of the authorization token ID of the second authorization token included in the request (S427). Upon receiving the authorization token verification request, the authorization service module 212 verifies whether the accepted authorization token ID is registered in the authorization token management table 1400, whether it is within the validity period, and whether the accepted scope is within the scope 1404 range. To do. Then, the verification result is returned to the print service module 261 (S428).

As a result of the verification, if it is determined that access is permitted, the print service module 261 prints the form data on the usage status of the floor machine (S429).
As described above, by linking the floor machine management service, the form service, and the printing service, it is possible to realize a service that processes the usage data of the floor machine into form data and prints the form data. In the present embodiment, an example of providing a service in which three services are linked has been described. However, a service in which three or more services are linked can be realized by repeating the processing from S418 to S429.

  According to the present embodiment, the risk of leakage of the authorization token is reduced, and the cooperation of three or more services can be realized by delegating authority to three or more services with the user's consent. .

(Second Embodiment)
In the first embodiment, whenever the number of clients to which authority can be delegated increases or decreases, it is necessary to add the clients to the client trust relationship management table 1500. In addition, it is necessary to have the user agree that more clients will delegate authority. Therefore, in the second embodiment, when realizing a service in which three or more services are linked, the purpose of delegating a client is to avoid maintenance of information in the client trust relationship table every time the number is increased or decreased. And
Since the second embodiment is substantially the same as the first embodiment, different parts will be described below.

  FIG. 12B shows a client trust relationship management table 1600 that the authorization server 200 stores in the external memory. As in FIG. 12A of the first embodiment, the client trust relationship management table 1600 confirms the trust relationship between the client that issued the first authorization token and the client that has issued the second authorization token issuance request. Use for. In the client trust relationship management table 1600, the authority transferable client 1602 is a character string for comparison with the application ID of the client. In the authority transferable client 1602, a character string including a regular expression can be set.

FIG. 8 is a processing sequence for providing a service that links the three services of the floor machine management service, the form service, and the printing service in the second embodiment. The processing of the next S801 is a part different from the processing sequence of FIGS. 4 and 5 of the first embodiment. The processing contents will be described below.
The authorization service module 212 acquires a list of clients to which the client can delegate authority (S801). In this process, first, an application ID 1304 of the client of the floor machine management service is acquired from the client management table 1300. Next, in the client trust relationship management table 1600, the authority transferable client 1602 of the record in which the client application ID 1304 acquired in the preprocessing and the token issuing client 1601 match is acquired. Then, a client record having an application ID 1304 that matches the value of the regular expression of the authority transferable client 1602 acquired in the preprocessing is acquired from the client management table 1300. The acquired list becomes a list of clients that can delegate authority of the floor machine management service.

FIG. 9 is a diagram illustrating a client trust relationship confirmation process according to the second embodiment. The process of the next S901 is different from the first embodiment. The processing contents will be described below.
In the client trust relationship confirmation processing of FIG. 8, the following processing is performed with reference to FIG. 12B instead of FIG. It is confirmed whether or not the application ID of the client that issued the second authorization token in S702 matches the regular expression of the authority transferable client 1602 in the record of the client trust relationship management table 1600 acquired in S801. (S901).

  In the second embodiment, the client application ID is com. example. * Or jp. example. User permission can be acquired in advance for authority delegation to all clients that match *. For this reason, it is possible to deal with an increase or decrease in the number of clients that can be delegated authority. Further, when realizing a service in which three or more services are linked, it is not necessary to maintain the information in the client trust relationship table every time the number of clients to which authority can be delegated increases or decreases.

(Other examples)
The present invention supplies a program that realizes one or more functions of the above-described embodiments to a system or apparatus via a network or a storage medium, and one or more processors in a computer of the system or apparatus read and execute the program This process can be realized. It can also be realized by a circuit (for example, ASIC) that realizes one or more functions.

As mentioned above, although preferable embodiment of this invention was described, this invention is not limited to these embodiment, A various deformation | transformation and change are possible within the range of the summary.

Claims (11)

An authority delegation system including a first client and a second client and a service providing apparatus that provide a service via a network, and an authorization server,
The first client is
Based on first authorization information indicating that a specific authority has been delegated from the user to the first client, and having a first using means for using the service of the second client;
The authorization server is
Whether the first client is identified from the first authorization information transmitted in association with the use by the first utilization means, and whether the identified first client and the second client are associated with each other Confirmation means for confirming,
Issuing means for issuing second authorization information indicating that specific authority has been delegated to the second client in response to the confirmation by the confirmation means;
The second client is
An authority delegation system comprising: a second use unit that uses a service of the service providing apparatus based on the second authorization information provided from the issuing unit. The authorization server is
Authentication means for determining whether or not the user is a legitimate user based on authentication information input via an authentication screen displayed on a terminal operated by the user;
The issuing means further controls the authority of the user in the service of the second client via an authorization screen displayed on the terminal by the user determined to be a legitimate user by the authentication means. The first authorization information indicating that the authority of the user is delegated to the first client is issued when an instruction to permit delegation to one client is issued. The authority delegation system described. The authorization screen displays a list of the first client that delegates the authority of the user in the service of the second client, and a client to which the first client can delegate authority. The authority delegation system according to claim 2. The authorization server is
Whether to authorize the first usage means to use the service of the second client with the authority of the user based on the first authorization information transmitted along with the usage by the first usage means A first authorization means for verifying whether or not,
Whether or not to authorize the second usage unit to use the service of the service providing apparatus with the authority of the user, based on the second authorization information transmitted along with the usage by the second usage unit. The authority delegation system according to any one of claims 1 to 3, further comprising: a second authorization unit for verifying the above. The authorization server is
Having storage means for storing information on whether or not authority can be transferred between clients;
The confirmation means confirms whether or not the identified first client and the second client are associated with each other based on information on whether or not authority can be taken over between the clients stored in the storage means. The authority delegation system according to any one of claims 1 to 4, characterized in that: 6. The information as to whether or not authority can be taken over between the clients is a combination of an application ID included in the first authorization information and an application ID of the second client. The authority delegation system according to item 1. The information as to whether or not authority can be transferred between the clients is a combination of an application ID included in the first authorization information and a character string for comparison with the application ID of the second client. Item 6. The authority delegation system according to any one of Items 1 to 5. The first authorization information includes at least one of an authorization token ID, a token type, an expiration date, a scope, a client ID, a user ID, an application ID, a refresh token ID, and a refresh time limit,
The scope is a range of services that can be used by the second client and the service providing apparatus,
The second authorization information includes at least one of an authorization token ID, a token type, an expiration date, a scope, a client ID, a user ID, and an application ID. The authority delegation system according to item 1. A control method of an authority delegation system including a first client and a second client and a service providing apparatus that provide a service via a network, and an authorization server,
The first client is
Based on first authorization information indicating that a specific authority has been delegated from the user to the first client; and using a service of the second client;
The authorization server is
Whether the first client is specified from the first authorization information transmitted with use in the first use step, and whether the specified first client and the second client are associated with each other A confirmation process to confirm,
Issuing a second authorization information indicating that specific authority has been delegated to the second client in response to being confirmed to be associated in the confirmation step;
The second client is
And a second usage step of using the service of the service providing apparatus based on the second authorization information provided in the issuing step. An authorization server connected to a first client and a second client that provide a service via a network and a service providing apparatus;
Authentication means for determining whether or not the user is a legitimate user based on authentication information input via an authentication screen displayed on a terminal operated by the user;
Delegating the authority of the user in the service of the second client to the first client via the authorization screen displayed on the terminal by the user determined to be a legitimate user by the authentication means A first issuing means for issuing the first authorization information indicating that the authority of the user has been delegated to the first client;
Based on the first authorization information transmitted from the first client, it is verified whether or not the first utilization means authorizes the use of the service of the second client with the authority of the user. Authorization means to
Confirmation that identifies the first client from the first authorization information transmitted from the first client, and confirms whether the identified first client and the second client are associated with each other. Means,
Second issuing means for issuing second authorization information indicating that specific authority has been delegated to the second client in response to being confirmed to be associated by the confirmation means;
Based on the second authorization information transmitted from the second client, the second client verifies whether or not to authorize the use of the service of the service providing apparatus with the authority of the user. And an authorization server.   The program for functioning a computer as each means with which the authorization server of Claim 10 is provided.

Images