JP6759691B2 - Information processing equipment, authorization methods and programs - Google Patents

Description

The present invention relates to information processing devices, authorization methods and programs.

In recent years, microservices have been attracting attention as one of the methods for realizing cloud services. Microservices are a method of configuring a system as a collection of multiple services. Microservices have the advantage that by dividing the service, each can be independently developed and maintained.

In order to realize such microservices, cooperation between services and access control are required. For example, as a method of linking services and controlling access, a method of storing and using an authentication ticket in a cookie is already known. Further, as another method for performing cooperation between services and access control, a method using a standard protocol for realizing cooperation of authorization called OAuth 2.0 is already known (see, for example, Patent Document 1).

In the method of storing and using the authentication ticket in Cookie, the operations that can be used for each service cannot be restricted, and there is a security concern. On the other hand, in the method using a standard protocol for realizing the linkage of authorization called OAuth 2.0, the operations that can be used by each service can be restricted.

However, in the method using a standard protocol called OAuth 2.0 for realizing the cooperation of authorization, the user must explicitly authorize each service. Therefore, in the information processing system realized by the above-mentioned microservices, the user must repeatedly confirm the permission to allow the authority to use the microservices to be delegated to the client, which improves the convenience of the user. I was losing.

An embodiment of the present invention has been made in view of the above points, and an object of the present invention is to provide an information processing device that improves user convenience in authorization confirmation.

In order to achieve the above-mentioned problem, claim 1 of the present application is an information processing device that performs an authorization process for delegating the usage authority from a user who has the usage authority of the service to a client who uses the service. The authorization request receiving means for accepting the authorization request from the client and whether or not to omit the display of the authorization confirmation screen which is set in advance in the information processing device and accepts the authorization approval or denial from the user is described. Based on the information shown for each client, the determination means for determining whether or not to omit the display of the authorization confirmation screen, and the terminal device operated by the user when it is determined that the display of the authorization confirmation screen is omitted. When it is determined that the display of the authorization confirmation screen is omitted, the usage authority delegation means for delegating the usage authority to the client as if the authorization is accepted from the user, and the display of the authorization confirmation screen is not omitted. The user has an authorization confirmation screen display requesting means for requesting the terminal device to display the authorization confirmation screen, and the usage authority delegation means is limited when receiving an authorization permission from the user on the authorization confirmation screen. by issuing credentials indicating a use authority of the service be performed on the clients, characterized by delegating authority to use the service that is limited to the client.

According to the embodiment of the present invention, it is possible to improve the convenience of the user in confirming the authorization.

It is a block diagram of an example of an information processing system which concerns on this embodiment. It is a hardware block diagram of an example of a computer. It is a processing block diagram of an example of the application server device which concerns on this embodiment. It is a processing block diagram of an example of the authorization server apparatus which concerns on this embodiment. It is a processing block diagram of an example of the user terminal apparatus which concerns on this embodiment. It is a block diagram of an example of client information. It is a block diagram of an example of authorization code information. It is a block diagram of an example of access token information. It is a block diagram of an example of refresh token information. It is a sequence diagram of an example of authorization processing when automatic authorization is not valid. It is an image diagram of an example of an authorization confirmation screen. It is a sequence diagram of an example of authorization processing when automatic authorization is effective.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
[First Embodiment]
<System configuration>
FIG. 1 is a configuration diagram of an example of an information processing system according to the present embodiment. The information processing system 1 of FIG. 1 has a configuration in which a user terminal device 10, one or more application server devices 12, an authorization server device 14, and a resource server device 16 are connected by a network 18 such as the Internet.

The user terminal device 10 is a terminal device operated by a user (resource owner) who owns a resource. The user terminal device 10 can be realized by a computer equipped with a general OS or the like. The user terminal device 10 is a terminal device (electronic device) such as a desktop PC, a notebook PC, a smartphone, a mobile phone, a tablet PC, a multifunction device, a copier, a scanner, a printer, a laser printer, a projector, or an electronic blackboard.

The application server device 12 can be realized by a computer equipped with a general OS or the like, and executes an application. The application executed by the application server device 12 is a client that obtains authorization and makes a request (request) for a resource.

The authorization server device 14 can be realized by a computer equipped with a general OS or the like, authenticates and authorizes the resource owner, and issues tokens such as an authorization code, an access token, and a refresh token. The authorization code represents the permission to access the resource provided by the resource owner. The authorization code is also used to obtain access tokens and refresh tokens.

The access token is a token used by an application (hereinafter referred to as a client) executed by the application server device 12 to make an authenticated request on behalf of the resource owner. The refresh token is also a token used by the client to obtain a new access token for the resource owner.

The resource server device 16 can be realized by a computer equipped with a general OS or the like, receives a request for a resource from a client, and returns a response to the client. A resource is a resource with restricted access and can be retrieved by an authenticated request.

The information processing system 1 of FIG. 1 has an application server device 12 that executes an in-house application (in-house application) and an application server device 12 that executes an application (third vendor application) made by a third vendor. Is shown as an example. In-house apps are an example of services that can be considered reliable in advance. Third-vendor apps are an example of a service that cannot be considered reliable in advance. The configuration of the information processing system 1 in FIG. 1 is an example, and various configurations can be considered. For example, the authorization server device 14 and the resource server device 16 may be integrated.

<Hardware configuration>
The user terminal device 10, the application server device 12, the authorization server device 14, and the resource server device 16 of FIG. 1 are realized by, for example, a computer having a hardware configuration as shown in FIG.

FIG. 2 is a hardware configuration diagram of an example of a computer. The computer 100 of FIG. 2 includes an input device 101, a display device 102, an external I / F 103, a RAM 104, a ROM 105, a CPU 106, a communication I / F 107, an HDD 108, and the like, and each of them is connected to each other by a bus B.

The input device 101 includes a keyboard, a mouse, a touch panel, and the like, and is used by the user to input each operation signal. The display device 102 includes a display and the like, and displays a processing result by the computer 100. The input device 101 and the display device 102 may be connected and used when necessary.

The communication I / F 107 is an interface for connecting the computer 100 to the network 18. As a result, the computer 100 can perform data communication via the communication I / F 107.

The HDD 108 is a non-volatile storage device that stores programs and data. The stored programs and data include, for example, an OS that is basic software that controls the entire computer 100, application software that provides various functions on the OS, and the like. The computer 100 may use a drive device (for example, a solid state drive: SSD) that uses a flash memory as a storage medium instead of the HDD 108.

The external I / F 103 is an interface with an external device. The external device includes a recording medium 103a and the like. As a result, the computer 100 can read and / or write to the recording medium 103a via the external I / F 103. The recording medium 103a includes a flexible disk, a CD, a DVD, an SD memory card, a USB memory, and the like.

The ROM 105 is a non-volatile semiconductor memory (storage device) capable of holding programs and data even when the power is turned off. The ROM 105 stores programs and data such as BIOS, OS settings, and network settings that are executed when the computer 100 is started. The RAM 104 is a volatile semiconductor memory (storage device) that temporarily holds programs and data.

The CPU 106 is an arithmetic unit that realizes control and functions of the entire computer 100 by reading programs and data from a storage device such as a ROM 105 or an HDD 108 onto a RAM 104 and executing processing.

The user terminal device 10, one or more application server devices 12, the authorization server device 14, and the resource server device 16 of FIG. 1 can realize various processes as described later depending on the hardware configuration of the computer 100.

<Software configuration>
《App server device》
The application server device 12 according to the present embodiment is realized by, for example, the processing block shown in FIG. FIG. 3 is a processing block diagram of an example of the application server device according to the present embodiment. The application server device 12 realizes a processing block as shown in FIG. 3 by executing a program. The application server device 12 realizes an authorization request unit 21, an authorization code acquisition unit 22, an access token acquisition unit 23, an API calling unit 24, and an application processing execution unit 25.

When the resource owner needs to access the resource, the authorization request unit 21 makes an authorization request to the authorization server device 14. The authorization code acquisition unit 22 acquires an authorization code from the authorization server device 14 when access to the resource is permitted. The access token acquisition unit 23 acquires an access token from the authorization server device 14 by using the authorization code. Further, the access token acquisition unit 23 acquires a new access token from the authorization server device 14 by using the refresh token.

The API calling unit 24 uses the access token to call the API of the resource server device 16 and access the resources of the resource server device 16. The application processing execution unit 25 executes some processing using the accessed resource.

<< Authorization server device >>
The authorization server device 14 according to the present embodiment is realized by, for example, the processing block shown in FIG. FIG. 4 is a processing block diagram of an example of the authorization server device according to the present embodiment.

The authorization server device 14 realizes a processing block as shown in FIG. 4 by executing a program. The authorization server device 14 realizes an authorization request reception unit 31, an automatic authorization determination unit 32, an authorization confirmation screen display request unit 33, a redirect processing unit 34, and an access token issuing unit 35. Further, the authorization server device 14 has a client information storage unit 41, an authorization code information storage unit 42, an access token information storage unit 43, and a refresh token information storage unit 44.

The authorization request receiving unit 31 receives an authorization request from the application server device 12. The automatic authorization determination unit 32 performs an automatic authorization determination process with reference to the client information stored in the client information storage unit 41. The automatic authorization determination process determines whether the automatic authorization is valid or invalid based on the information included in the client information indicating whether or not the automatic authorization is valid (invalid). Automatic authorization omits the display of the authorization confirmation screen and proceeds with the process assuming that the resource owner has authorized.

If the automatic authorization is invalid, the automatic authorization determination unit 32 instructs the authorization confirmation screen display request unit 33 to display the authorization confirmation screen. The authorization confirmation screen display request unit 33 causes the user terminal device 10 to display the authorization confirmation screen, and causes the resource owner to select whether to allow / deny the authorization. If the automatic authorization is valid, the automatic authorization determination unit 32 omits the instruction to display the authorization confirmation screen to the authorization confirmation screen display request unit 33, and it is assumed that the resource owner approves the authorization.

When the resource owner approves the authorization, the redirect processing unit 34 issues an authorization code and redirects to the redirect URL together with the authorization code. The authorization code information regarding the issued authorization code is stored in the authorization code information storage unit 42.

The access token issuing unit 35 receives an access token request using the authorization code from the application server device 12. The access token issuing unit 35 issues an access token and a refresh token. The access token information regarding the issued access token is stored in the access token information storage unit 43. The refresh token information regarding the issued refresh token is stored in the refresh token information storage unit 44. The access token issuing unit 35 returns the issued access token and refresh token to the application server device 12 that requests the access token.

<< User terminal equipment >>
The user terminal device 10 according to the present embodiment is realized by, for example, the processing block shown in FIG. FIG. 5 is a processing block diagram of an example of the user terminal device according to the present embodiment. The user terminal device 10 realizes the processing block shown in FIG. 5 by executing the program. The user terminal device 10 of FIG. 5 realizes an authorization confirmation screen display unit 51 and an authorization request permission / rejection response unit 52.

The authorization confirmation screen display unit 51 displays the authorization confirmation screen described later based on the request from the authorization server device 14. The authorization confirmation screen can accept the option of permitting or denying authorization from the resource owner. The authorization request permission / rejection response unit 52 returns to the authorization server device 14 the selection of authorization permission or denial received from the resource owner.

"information"
FIG. 6 is a configuration diagram of an example of client information. The client information of FIG. 6 has an internal ID, a company ID, a client ID, a client secret, a redirect URI, a client name, a client type, and automatic authorization as items.

The internal ID is a primal key (primary key) in the table and is for internal management. The company ID is the internal ID of the company that created the client. A company is an example, and may be a unit of a group such as a school, an organization, or a department. The client ID is an ID that identifies an application (client) executed by the application server device 12. The client secret is the client's secret. The redirect URI is a redirect URI used when authorizing OAuth. The client name is the name of the client. The client type is the client type.

The automatic authorization is information indicating whether or not the automatic authorization is valid (invalid). In the client information of FIG. 6, when the client is an in-house application, valid (true) for automatic authorization is set. Further, in the client information of FIG. 6, when the client is a third-vendor application, invalidity (false) is set for automatic authorization. The client information in FIG. 6 is set by the administrator of the authorization server device 14. Therefore, the administrator of the authorization server device 14 enables the automatic authorization of the client information of FIG. 6 to be enabled in advance when the client is an in-house application.

FIG. 7 is a configuration diagram of an example of authorization code information. The authorization code information in FIG. 7 has an internal ID, a client internal ID, an authorization code, a redirect URI, a scope, a creation date and time, and a code challenge as items.

The internal ID is a primal key (primary key) in the table and is for internal management. The client internal ID is an internal ID that identifies the client. The authorization code is the issued authorization code. The redirect URI is the redirect URI specified at the time of authorization request. The scope is the scope of the authorization request. The creation date and time is the date and time when the authorization code was created. A code challenge is a code challenge used for authorization.

FIG. 8 is a configuration diagram of an example of access token information. The access token information of FIG. 8 has an internal ID, a user internal ID, a client internal ID, a refresh token internal ID, a token, a scope, and a creation date and time as items.

The internal ID is a primal key (primary key) in the table and is for internal management. The user internal ID is an internal ID that identifies the user (resource owner). The client internal ID is an internal ID that identifies the client. The refresh token internal ID is an internal ID that identifies the refresh token. The token is the value of the issued access token. The scope is the scope associated with the access token. The creation date and time is the date and time when the access token was created.

FIG. 9 is a configuration diagram of an example of refresh token information. The refresh token information of FIG. 9 has an internal ID, a user internal ID, a client internal ID, a token, a scope, and a creation date and time as items.

The internal ID is a primal key (primary key) in the table and is for internal management. The user internal ID is an internal ID that identifies the user (resource owner). The client internal ID is an internal ID that identifies the client. The token is the value of the issued refresh token. The scope is the scope associated with the refresh token. The creation date and time is the date and time when the refresh token was created.

<Details of processing>
Hereinafter, the authorization process of the information processing system 1 according to the present embodiment will be described separately for the case where the automatic authorization is not valid and the case where the automatic authorization is valid.

<< When automatic authorization is not valid >>
FIG. 10 is a sequence diagram of an example of authorization processing when automatic authorization is not valid. FIG. 10 shows a sequence diagram when an access token is issued using the authorization code flow of OAuth 2.0 as an example.

In step S11, the user terminal device 10 operated by the resource owner requests the application server device 12 to start authorization of OAuth 2.0. The authorization request unit 21 of the application server device 12 proceeds to steps S12 and S13, causes the user terminal device 10 to access the authorization server device 14 by redirect, and makes an authorization request.

Proceeding to step S14, the automatic authorization determination unit 32 of the authorization server device 14 performs the automatic authorization determination process with reference to the client information shown in FIG. 6 stored in the client information storage unit 41. The automatic authorization determination unit 32 determines whether the automatic authorization is valid or invalid depending on whether the item "automatic authorization" of the client information in FIG. 6 is valid "true" or invalid "false".

In FIG. 10, since the client is a third-vendor application, it is determined that the automatic authorization is invalid. Since the automatic authorization determination unit 32 determines that the automatic authorization is invalid, the automatic authorization determination unit 32 instructs the authorization confirmation screen display request unit 33 to display the authorization confirmation screen. Proceeding to step S15, the authorization confirmation screen display requesting unit 33 requests the user terminal device 10 to display the authorization confirmation screen as shown in FIG.

FIG. 11 is an image diagram of an example of the authorization confirmation screen. The authorization confirmation screen of FIG. 11 is a screen presented to the resource owner who operates the user terminal device 10. The resource owner can select the authorization permission by pressing the "permit" button on the authorization confirmation screen of FIG. In addition, the resource owner can select to deny the authorization by pressing the "not permit" button on the authorization confirmation screen of FIG. The authorization confirmation screen display unit 51 of the user terminal device 10 displays, for example, the authorization confirmation screen of FIG. 11 and accepts the selection of authorization permission or denial from the resource owner. Then, the process proceeds to step S16, and the authorization request permission / rejection response unit 52 notifies the authorization server device 14 of the selection of authorization permission or denial received from the resource owner.

When the redirection processing unit 34 of the authorization server device 14 receives the authorization of authorization from the resource owner, it issues an authorization code. Proceeding to the processing of steps S17 and S18, the redirect processing unit 34 redirects the redirect URI included in the client information of FIG. 6 together with the authorization code.

Proceeding to step S19, the access token acquisition unit 23 of the application server device 12 requests the access token from the authorization server device 14 using the acquired authorization code. Proceeding to step S20, the access token issuing unit 35 of the authorization server device 14 issues an access token and a refresh token to the application server device 12 based on the access token request using the authorization code. In step S21, the API calling unit 24 of the application server device 12 can access the resources of the resource server device 16 by calling the API of the resource server device 16 using the access token.

<< When automatic authorization is enabled >>
FIG. 12 is a sequence diagram of an example of authorization processing when automatic authorization is enabled. Similar to FIG. 10, FIG. 12 shows a sequence diagram when an access token is issued using the authorization code flow of OAuth 2.0 as an example.

The processing of steps S31 to S34 is the same as that of steps S11 to S14 of FIG. In FIG. 12, since the client is an in-house application, it is determined that automatic authorization is effective. Since the automatic authorization determination unit 32 has determined that the automatic authorization is valid, the display of the authorization confirmation screen of FIG. 11 is skipped, and the process after step S35 is proceeded assuming that the resource owner has authorized the authorization. The processing of steps S35 to S39 is the same as that of steps S17 to S21 of FIG.
[Other Embodiments]
The automatic authorization of client information is not limited to the example in which the automatic authorization is enabled when the client is an in-house application and the automatic authorization is invalidated when the client is a third-vendor application. For example, for automatic authorization of client information, automatic authorization may be enabled when it is considered to be reliable by inspection or the like in advance, and other automatic authorization may be invalidated.

Further, the automatic authorization determination unit 32 may, for example, confirm whether the application is an in-house application or a third vendor application from the domain part of the redirect URI included in the client information, and determine whether the automatic authorization is enabled or disabled. Good.

(Summary)
According to this embodiment, it is possible to set a service that omits authorization confirmation in the information processing system 1 realized by a plurality of services. Conventionally, in the cloud service of one company realized by a plurality of services, the resource owner needs to confirm the authorization for each service, which impairs the convenience of the resource owner. In addition, conventionally, the unnaturalness of displaying the authorization confirmation screen many times while using the cloud service of one company may confuse the resource owner and further impair convenience.

According to the present embodiment, since the authorization confirmation of the service deemed to be reliable in advance, such as an in-house manufactured application, is omitted, the convenience of the resource owner can be improved while ensuring the security safety.

The present invention is not limited to the above-described embodiment disclosed specifically, and various modifications and modifications can be made without departing from the scope of claims. The authorization server device 14 is an example of the information processing device described in the claims. The authorization request receiving unit 31 is an example of the authorization request receiving means. The automatic authorization determination unit 32 is an example of determination means. The redirect processing unit 34 and the access token issuing unit 35 are examples of means for delegating usage authority. The user terminal device 10 is an example of a terminal device operated by the user. The authorization confirmation screen display request unit 33 is an example of the authorization confirmation screen display request means. Authorization codes, access tokens, and refresh tokens are examples of credentials. Further, the client information item "automatic authorization", which is information indicating whether or not automatic authorization is valid (invalid), is an example of information indicating whether or not to omit the display of the authorization confirmation screen.

1 Information processing system 10 User terminal device 12 App server device 14 Authorization server device 16 Resource server device 18 Network 21 Authorization request unit 22 Authorization code acquisition unit 23 Access token acquisition unit 24 API call unit 25 Application processing execution unit 31 Authorization request reception unit 32 Automatic authorization judgment unit 33 Authorization confirmation screen display request unit 34 Redirect processing unit 35 Access token issuing unit 41 Client information storage unit 42 Authorization code information storage unit 43 Access token information storage unit 44 Refresh token information storage unit 51 Authorization confirmation screen display unit 52 Authorization request permission / rejection response unit 100 Computer 101 Input device 102 Display device 103 External I / F
103a Recording medium 104 RAM
105 ROM
106 CPU
107 Communication I / F
108 HDD
B bus

Japanese Unexamined Patent Publication No. 2015-95056

Claims (4)

An information processing device that performs authorization processing for delegating the usage authority from a user who has the usage authority of the service to a client who uses the service.
An authorization request receiving means for receiving an authorization request from the client,
The display of the authorization confirmation screen is omitted based on the information indicating whether or not to omit the display of the authorization confirmation screen that is set in the information processing device in advance and accepts the approval or denial of the authorization from the user for each client. Judgment means for determining whether or not to do
When it is determined that the display of the authorization confirmation screen is omitted, the display of the authorization confirmation screen on the terminal device operated by the user is omitted, and the user has the right to use the license as if the authorization was accepted from the user. And the means of delegating usage authority to delegate
It has an authorization confirmation screen display requesting means for requesting the terminal device to display the authorization confirmation screen when it is determined that the display of the authorization confirmation screen is not omitted.
When the authorization confirmation screen receives the authorization permission from the user, the usage authority delegation means is limited to the client by issuing the qualification information indicating the limited usage authority of the service to the client. An information processing device characterized in that the authority to use the service is delegated . The client is an application running on the server apparatus, according to claim 1 Symbol placement of the information processing apparatus, characterized in that it is utilized from the electronic device is the terminal device. It is an authorization method executed in an information processing device that performs authorization processing for delegating the usage authority from a user who has the usage authority of the service to a client who uses the service.
An authorization request acceptance step for accepting an authorization request from the client,
The display of the authorization confirmation screen is omitted based on the information indicating whether or not to omit the display of the authorization confirmation screen that is set in the information processing device in advance and accepts the approval or denial of the authorization from the user for each client. Judgment step to determine whether to do
When it is determined that the display of the authorization confirmation screen is omitted, the display of the authorization confirmation screen on the terminal device operated by the user is omitted, and the user has the right to use the license as if the authorization was accepted from the user. And the usage authority delegation step to delegate
It has an authorization confirmation screen display request step for requesting the terminal device to display the authorization confirmation screen when it is determined that the display of the authorization confirmation screen is not omitted.
The usage authority delegation step is limited to the client by issuing a qualification information indicating the limited usage authority of the service to the client when the authorization permission is received from the user on the authorization confirmation screen. An authorization method characterized by delegating the authority to use the service . An information processing device that performs authorization processing for delegating the usage authority from a user who has the usage authority of the service to a client who uses the service.
An authorization request receiving means for receiving an authorization request from the client,
The display of the authorization confirmation screen is omitted based on the information indicating whether or not to omit the display of the authorization confirmation screen that is set in the information processing device in advance and accepts the approval or denial of the authorization from the user for each client. Judgment means for determining whether or not to do
When it is determined that the display of the authorization confirmation screen is omitted, the display of the authorization confirmation screen on the terminal device operated by the user is omitted, and the user has the right to use the license as if the authorization was accepted from the user. Delegation of usage authority,
When it is determined that the display of the authorization confirmation screen is not omitted, the terminal device is made to function as an authorization confirmation screen display requesting means for requesting the display of the authorization confirmation screen.
When the authorization confirmation screen receives the authorization permission from the user, the usage authority delegation means is limited to the client by issuing the qualification information indicating the limited usage authority of the service to the client. To delegate the authority to use the service
A program featuring .

Images