JP2016115260A - Authority transfer system, authorization server used for authority transfer system, resource server, client, mediation device, authority transfer method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an authority transfer system capable of changing non-functional requirements linked with an authority by change of client authorities.SOLUTION: A resource server issues an authentication identifier to a client request, an authorization server receives the authentication identifier, and destination information of a mediation device from a client, and issues certification information for certifying a client authority based on information preliminarily registered in the authorization server. The mediation device issues the certification information based on the authentication identifier and the information preliminarily registered in the authorization server when the certification information is transmitted from the client, the resource server receives the certification information issued by the mediation device from the client, and provides the client with a resource based on the authentication identifier. The authorization server preliminarily registers pieces of destination information of a plurality of mediation devices corresponding to a plurality of resource servers with different performances for the same resource, and makes any destination information possible to be selected by the client.SELECTED DRAWING: Figure 6

Description

  It relates to the authority selection method in the authorization flow, and in particular to the function and resource selection method by the client authority in OAuth implicit grant.

  In recent years, services for creating electronic documents in PDF format on the Internet, services for storing electronic documents, and the like have been provided. By using such a service, users can create PDFs even if they do not have a PDF creation function on their own device, and can also store electronic documents beyond the storage capacity of the device. . Furthermore, in recent years, as the cloud has become more common, opportunities to create added value by linking multiple services as described above are increasing. By linking the services, the service provider can provide added value to the user. For example, a created electronic document in PDF format can be stored directly on the Internet without going through a terminal owned by the user.

  On the other hand, several issues are born by the cooperation of services. That is, since more information than the user desires is exchanged between services, there is a risk of leakage of user data and personal information. For example, there are multiple services on the Internet, and service cooperation is realized between various services, but it is not desirable for services other than services that provide the results desired by the user to acquire user data, personal information, etc. . On the other hand, from the service provider, it is preferable that the service cooperation mechanism can be easily implemented.

  In such a situation, a standard protocol called OAuth has been developed to realize authorization cooperation. OAuth will be explained in more detail later. According to OAuth, for example, an external service B approved by a user can access user data managed by a service A. At this time, the service A is to clarify the range accessed from the external service B, and obtain an explicit authorization of the user for access by the external service B. The explicit authorization by the user is called “authorization operation”.

  When the user performs an authorization operation, the external service B receives a token (hereinafter referred to as “access token”) certifying that the access is permitted from the service A, and subsequent access can be realized using the access token. . If the access token is used here, the external service B can access the service A with the authority of the authorized user without user authentication information. For this reason, the external service B that has been authorized by the user and has acquired the access token is responsible for managing the access token strictly and properly.

  Some recent devices provide added value to users by using OAuth and linking with cloud services. For example, there is a service called a social networking service (hereinafter referred to as “SNS”). These services can be used from a smartphone. There are various types of SNS, but installing a specific application on a smartphone may make it easier to use the SNS. For example, a user who wants to regularly post his / her whereabouts on SNS may find it convenient to use an application that uses the positioning function of a smartphone to periodically position and post to SNS.

  Here, the application installed on the smartphone will access the SNS on behalf of the user. OAuth may be used in such cases. The user can use the SNS through the application by allowing the application to submit the minimum function necessary for using the SNS, for example, an article.

  By the way, in OAuth, an access token acquisition flow called “implicit grant”, which is optimized for a client executed on a browser using a script language such as JavaScript (registered trademark), is defined. After the authorization of the resource owner, the client as described above receives an access token directly instead of an authorization code that is an intermediary credential for obtaining an access token. This grant type is called an implicit grant because it does not use a credential that mediates access token acquisition such as an authorization code.

  A characteristic of the implicit grant is that it is not necessary to present the credentials of the client that is the access subject to the authorization server. Therefore, the implicit grant cannot make a difference in non-functional requirements depending on the authority of the client. That is, since there is no presentation of client credentials, non-functional requirements cannot be changed based on authority. In implicit grants, access tokens can be easily intercepted by users (resource owners). “Non-functional requirements” refers to the general aspects other than functional aspects, such as requirements and system requirements, in requirements analysis for system design and information system development.

  When using a service linked with the cloud service as described above from the current Web browser, the authentication session is routed with a cookie etc. and authentication is not performed explicitly like OAuth.

  By the way, a form of using a service linked with the cloud service by an API access using jQuery or the like from a web browser is now becoming a de facto standard. This is influenced by trends such as the spread of mobile and the appearance of browser OS.

The advantages of the above solution are as follows.
(1) By unifying the server side with RESTful JSON API, it is possible to support not only calls from Web browsers with UI but also calls from other applications without UI (service disclosure).
(2) No server-side template or rendering process is required, and the server-side processing load can be reduced.

The architectural support is as follows.
(1) Server side: Server side architecture that performs non-blocking processing asynchronously like Node, which can respond to a large number of simultaneous accesses (processing requests) from clients. (A large amount of I / O processing is processed synchronously, and CPU bound processing without network I / O is turned to asynchronous processing.)
(2) Client side: AJAX of asynchronous processing library, JQuery that enables rich UI processing. Javascript (registered trademark) library such as Globalize plug-in (JQuery plug-in) that enables multilingual support. Javascript (registered trademark) engine that can execute the library at high speed on the client side.

"The OAuth 1.0 Protocol", [online] E. Hammer-Lahav, September 2012 <URL http://tools.ietf.org/html/rfc5849> "The OAuth 2.0 Authorization Framework", [online] D. Hardt, May 2013 <URL http://tools.ietf.org/html/rfc6749>

  In the case of using a cloud service by API access using jQuery, which is currently becoming the standard method, OAuth will be used as the authorization flow. At that time, OAuth implicit grant may be used, such as when the client using the service is a Web browser. When implicit grant is used, non-functional requirements (performance) associated with authority cannot be changed by changing client authority.

  When using OAuth implicit grant, unlike authorization code grant, there is no client authentication. Therefore, non-functional requirements (for example, performance) cannot be changed by changing the authority of the client. (Even if the client authority is changed, it is not possible to check the client authority without authenticating the client)

  The reason why the client authority check is necessary is as follows. In order for the client to use the contract service, authority (role associated with) is required. The service provider must not use the service that the user (client) contracts without confirming the authority.

  The present invention has been made in view of the above-described problems, and includes a resource server that provides resources, an authorization server that performs client authentication and resource authorization, and an intermediary device that mediates communication between the client and the authorization server. The resource delegation system used in the network, the resource server issues an authentication identifier used to authenticate the client to the client in response to a request from the client for the protected resource, and the authorization server Identification information for identifying, authentication identifier issued by the resource server, destination information indicating the destination of the intermediary device is received from the client, the client is authenticated based on information registered in advance in the authorization server, and if the authentication is successful, Clients to protected resources If the verification is successful, the authentication information is issued to the client, and the intermediary device issues the certification information issued by the authorization server to the destination indicated by the destination information from the client. Is sent, it verifies whether the client has authority over the protected resource based on the authentication identifier and the information registered in advance in the authorization server, and if the verification succeeds, proves that it has authority Certificate information is issued to the client, and the resource server receives the certificate information issued by the intermediary device from the client, verifies whether the request from the client is permitted based on the authentication identifier, and protects if the verification is successful. Provided to the client, and the authorization server uses multiple resources with different performance for the same resource. Previously registered the destination information of a plurality of intermediary devices corresponding to the over scan server provides authority transfer system characterized by a selectable one of the destination information of which the clients.

  In a cloud service that provides a print service through the Web API and uses the OAuth Implicit flow, one of multiple redirect URLs can be selected by contract when registering a Client. You can specify which of the resource server endpoints with different non-functional requirements (performance, etc.) to use when the client is running. In addition, by registering a plurality of redirect URIs in association with one client at the time of client registration, the endpoint of the resource server can be selected, and the convenience for the user is improved.

1 is a system configuration diagram of Embodiment 1. FIG. FIG. 2 is a hardware configuration diagram of each device according to the first embodiment. FIG. 2 is a module configuration diagram of each device according to the first embodiment. FIG. 3 is an authorized client registration processing sequence diagram according to the first embodiment. The authorized client registration screen of Example 1. FIG. 3 is a sequence diagram of an authentication authorization flow according to the first embodiment. 5 is a flowchart of authorization server processing according to the first embodiment. The authorization confirmation screen of Example 1. 10 is a flowchart of Web-Hosted client processing according to the first embodiment. 10 is a flowchart of Web-Hosted client nonce value verification processing of the authorization server according to the first embodiment. 6 is a flowchart of client script processing of the authorized client according to the first embodiment. 6 is a flowchart of resource server nonce value verification processing of the authorization server according to the first embodiment. The authorized client registration screen of Example 2. FIG. 10 is a sequence diagram of an authentication authorization flow according to the second embodiment.

  The best mode for carrying out the present invention will be described below with reference to the drawings. In the present embodiment, it is assumed that a form service that generates form data on the Internet and a print service that acquires and prints data on the Internet are installed on a server on the Internet. Hereinafter, services that provide functions on the Internet, such as form services and printing services, are referred to as “resource services”.

  In this embodiment, it is assumed that a print application and a form application installed on the image forming apparatus use a resource service. Hereinafter, an application that uses a resource service, such as a printing application or a form application, is referred to as a “resource service cooperation application”. Of course, the resource service is not limited to the form service and the print service, and the application is not limited to the form application and the print application.

  Furthermore, in the transfer of authority in this embodiment, an OAuth mechanism is used. In OAuth, certification information called “token” is used as information to prove the authority transferred from the user.

<Example 1> (Resource server non-functional requirement selection with single redirect URI)
The authority transfer system according to the present embodiment is realized on a network having a configuration as shown in FIG. Reference numeral 100 denotes a wide area network (WAN 100). In this embodiment, a World Wide Web (WWW) system is constructed. Reference numerals 101 and 102 denote local area networks (LAN 101 and LAN 102) that connect the respective components.

  The authorization server 500 is a server for realizing OAuth, and an authorization service module is installed. Web-Hosted clients 300, 301, and 302 are clients that implement Web-Hosted client resources in OAuth. In this embodiment, the Web-Hosted clients 300, 301, and 302 function as an intermediary device that mediates communication between the authorization server 500 and the client PC 200. Specifically, the Web-Hosted clients 300, 301, and 302 are designated as redirect URIs of response destinations of access tokens for the client PC 200 from the authorization server 500. Further, it corresponds to each of resource servers 400, 401, 402 having different non-functional requirements to be described later.

  The resource servers 400, 401, and 402 are servers on which resource service cooperation applications such as a printing service and a form service are installed. Note that one or more resource service cooperation applications may be installed in one resource server. The resource servers 400, 401, and 402 provide the same resource service cooperation application, but are servers having different specifications related to non-functional requirements such as CPU processing speed, memory capacity, disk capacity, and the number of allowable simultaneous connections. . In this embodiment, the specification of the resource server is 400 for high specifications, 401 for intermediate specifications, and 402 for low specifications. In the present embodiment, the difference in the specifications of the resource servers 400, 401, and 402 represents the difference in the capabilities of the resource server cooperation application. For example, in a printing service, a free service is guided to a low-spec resource server 402. A service that requires a performance guarantee for a fee is guided to a resource server 401 having an intermediate performance or a resource server 400 having a high performance in accordance with the contracted service performance.

  The client PC 200 is a PC operated by the user. The client PC 200 executes a client script (to be described later) with a Web browser on the PC, and uses a service such as a print service or a form service by using a resource of one of the resource servers by selecting a client registration to be described later. As a feature of the present embodiment, Web-Hosted clients 300, 301, 302 and resource servers 400, 401, 402 are connected to the same LAN 101 as the authorization server 500. Further, the Web-Hosted clients 300, 301, 302, the resource servers 400, 401, 402, and the authorization server 500 are connected without going through the WAN 100. For this reason, in this embodiment, these are regarded as the same security domain, and the service cooperation between the Web-Hosted clients 300, 301, 302 and the resource servers 400, 401, 402 is covered by the same authentication.

  The client PC 200, Web-Hosted clients 300, 301, and 302, and resource servers 400, 401, and 402 are connected via the WAN 100, LAN 101, and LAN 102, respectively. The client PC 200 and each service may be configured on separate LANs or on the same LAN. Further, they may be configured on the same PC.

  FIG. 2 is a diagram illustrating the configuration of the client PC 200 according to the present embodiment. The configuration of the server computers of the Web-Hosted clients 300, 301, 302, resource servers 400, 401, 402, and authorization server 500 is the same. The hardware block diagram shown in FIG. 2 corresponds to the hardware block diagram of a general information processing apparatus, and the hardware configuration of a general information processing apparatus is used for the client PC 200 and the server computer of this embodiment. Can be applied.

  In FIG. 2, the CPU 201 executes a program such as an OS or an application stored in the program ROM of the ROM 203 or loaded from the hard disk (HD) 211 to the RAM 202. The OS is an operating system that runs on a computer. The processing of each flowchart to be described later can be realized by executing this program. The RAM 202 functions as a main memory and work area for the CPU 201. A keyboard controller (KBC) 205 controls key input from a keyboard (KB) 209 or a pointing device (not shown). A CRT controller (CRTC) 206 controls display on the CRT display 210. A disk controller (DKC) 207 controls data access in a hard disk (HD) 211 and a floppy (registered trademark) disk (FD) for storing various data. The NC 212 is connected to the network and executes communication control processing with other devices connected to the network.

  In the following description, unless otherwise specified, the subject on execution hardware is the CPU 201, and the subject on software is an application program installed in the hard disk (HD) 211.

  FIG. 3 is a diagram illustrating module configurations of the authorization server 500, the resource servers 400, 401, and 402, the client PC 200, and the Web-Hosted clients 300, 301, and 302 according to the present embodiment. The authorization server 500, resource servers 400, 401, 402, client PC 200, and Web-Hosted clients 300, 301, 302 are the same as those in FIG.

  The authorization server 500 includes an authorization server module 510, which includes a user identification unit 610, a client registration unit 620, a nonce value verification unit 630, a client verification unit 520, a token verification unit 530, and a token issue unit 540. Note that “nonce” is a disposable random value used in cryptographic communication, and is usually used in the authentication process and has a function of preventing replay attacks. Hereinafter, it is used in the meaning of a disposable authentication identifier.

  The resource servers 400, 401, and 402 have the same module configuration. Hereinafter, the resource server 400 will be described as a representative. The resource server 400 includes a resource server module 410, which includes a token authority confirmation unit 420, a resource request processing unit 430, and a nonce value confirmation unit 440, which will be described later.

  The client PC 200 controls each application by the CPU 201 executing the OS 220 stored in the ROM 203 or the external memory 211. A real-time OS is generally used as the OS, but a general-purpose OS such as Linux (registered trademark) may be used recently. Further, the client PC 200 includes a web browser 230 that is a user agent for using the WWW.

  Web-Hosted clients 300, 301, and 302 have the same module configuration. Hereinafter, the Web-Hosted client 300 will be described as a representative. The Web-Hosted client 300 includes a Web-Hosted client module 310, which includes a nonce value confirmation unit 330 described later. The module also has a function of receiving a redirect URI request for an access token response from the client PC 200 and returning a client script 320 for obtaining an access token and a resource request, which will be described later.

  Tables 1 to 5 below show data tables that the authorization server 500 stores in the external memory. These data tables may be stored not in the external memory of the authorization server 500 but in another server configured to be communicable via the LAN 101.

  The user management table in Table 1 includes a user ID (identification information), a password, and a user type. The authorization server 500 has a function of authenticating each user or client by verifying a set of user ID and password information and generating authentication information if it is correct.

  The client management table in Table 2 includes a client ID, a client name, and a redirect URI. The client ID, client name, and redirect URI are values used in the OAuth sequence described later.

  The token management table in Table 3 includes a token ID, an expiration date, a scope, a client ID, and a user ID. Details of processing of the token management table will be described later.

  The nonce value management table in Table 4 includes a nonce value, a token ID, and an expiration date. Details of processing of the nonce value management table will be described later.

  The client / resource server management table of Table 5 includes a Web-Hosted Client URI and a resource server URI. This management table is registered in advance by the server system builder of the Web-Hosted clients 300, 301, 302, resource servers 400, 401, 402, and authorization server 500 when the server system is constructed. The resource server 400 is registered in association with the Web-Hosted client 300. Further, similarly for the Web-Hosted clients 301 and 302, the resource servers 401 and 402 are registered in association with each other. If a resource server is added, add the same number of corresponding Web-Hosted clients and register them in the management table of Table 5 in the same manner as described above. Details of processing of the client and resource server management table will be described later.

  Here, a sequence representing a client registration flow according to the present embodiment for performing a client registration process necessary for enabling selection of resource servers having different non-functional requirements will be described with reference to FIGS. The client registration flow in FIG. 4 is a flow in which the extension unique to the present embodiment is added to the client registration in the OAuth 2.0 specification generally used in OAuth 2.0.

  In the flow of FIG. 4, first, the client registrant 1001 performs client registration for the client referred to in the OAuth 2.0 specification necessary for resource access in this embodiment. The resource owner 1000 to be described later performs resource access using a client registered in advance by this flow. The client registrant 1001 requests a client registration screen from the authorization server 500 using the Web browser 230 (S4.1). The authorization server 500 returns a client registration screen as shown in FIG. 5 in response to the request of S4.1 (S4.2).

  FIG. 5 is a client registration screen for registering a client in the OAuth 2.0 specification. The client registration screen includes a client registration parameter display 5000 for displaying and selecting parameters necessary for client registration by the authorization server 500, and the following two buttons. That is, an OK button 5005 for confirming the client registration parameters and registering them in the authorization server 500, and a cancel button 5006 for canceling the client registration parameter display 5000.

  The client registration parameter display 5000 includes a client name input line 5007, a client ID display line 5001, and a redirect URI selection line 5002, 5003, 5004. In the client ID display line 5001, the authorization server 500 that has received the client registration screen request (S4.1) generates and displays a random and unique value in UUID format when the client registration screen is returned (S4.2). To do. For example, the value is '9237ee87-1d58-4b0d-a7ed-a4042402df52'. In the client name input line 5007, the client registrant 1001 inputs an arbitrary client name at the time of client registration. The redirect URI selection lines 5002, 5003, and 5004 display the choices prepared in advance for the redirect URI as referred to in the OAuth 2.0 specification, which are valid at the time of this client registration. Furthermore, a radio button is displayed on each of the redirect URI selection lines 5002, 5003, and 5004 so that the client registrant 1001 selects one of a plurality of redirect URI options to register with the authorization server 500. One can be selected.

  A plurality of redirect URI selection lines 5002, 5003, and 5004 are redirect URIs for guiding the client to the resource servers 400, 401, and 402 having different non-functional requirements. Among these, the redirect URI 5002 is a URI for accessing the resource server 400. Similarly, a redirect URI 5003 is a redirect URI for accessing the resource server 401, and 5004 is a redirect URI for accessing the resource 402. These relationships are defined in advance by the client and resource server management table shown in Table 5.

  Returning to the flow of FIG. 4, the client registrant 1001 refers to the client registration screen of FIG. 5 returned from the authorization server 500 in S4.2, and inputs the client registration content (S4.3). Specifically, confirm the client ID, select a redirect URI from the options shown in Fig. 5 (redirect URI 5002, 5003, 5004) by selecting a radio button, and press the OK button 5006 To do. When the client registrant 1001 presses the OK button 5006, the Web browser 230 transmits a client registration processing request to the authorization server 500 (S4.4).

  Upon receiving the client registration processing request (S4.4), the authorization server 500 performs client registration processing (S4.5). Specifically, the client registration unit 620 of the authorization server 500 stores the client name, client ID, and redirect URI from the received client registration processing request (S4.4) in the client management table (Table 2) on the authorization server 500. sign up. When the registration of the client name, client ID, and redirect URI in the client management table is completed, the authorization server 500 returns the registered content (not shown) to the Web browser 230 and ends the process (S4.6). In this embodiment, the client registration process to the authorization server by the client registrant is a process using a Web browser, but the registration process to the authorization server may use a dedicated registration application.

  Here, a sequence representing an authorization flow according to the present embodiment for using a resource service using a browser application on the client PC 200 will be described with reference to FIG. In the OAuth 2.0 specification, multiple protocol sequences corresponding to various clients are called grant types. The authorization flow in FIG. 6 is a grant type obtained by adding an extension unique to this embodiment to the implicit grant of the OAuth 2.0 specification.

  In the flow of FIG. 6, first, an authorization cooperation service start request is generated from a user who needs access to a protected resource (S6.1). This service request is made by the user who is the resource owner 1000 to the resource server 400 using the HTTP protocol via the browser application on the client PC 200 which is a user agent operated by the resource owner 1000. Specifically, the user who is the resource owner 1000 operates the client PC 200 to access an application screen (not shown) of the resource server 400 (S6.1). This application screen is, for example, a screen for selecting a document to be printed when the resource cooperation application of the resource server 400 is a print application, and a screen for selecting a form to be created when the resource application is a form application. Here, accessing the application screen means, for example, that the application screen is displayed in a selectable manner on the browser on the client PC 200 and that the application is selected. By selecting the application, the resource owner 1000 transmits an authorization cooperation service start request to the resource server 400 (S6.1).

  In this embodiment, the resource cooperation application is on the resource server 400. However, in general, the resource cooperation application may exist in a client application server or the like other than the resource server 400. In this embodiment, a client application that cooperates with a resource service such as a print Web application and a form Web application is installed as a resource service cooperation application. Note that one or more resource service cooperation applications may be installed in one resource server.

When the resource server 400 accepts the start of authorization cooperation by the authorization cooperation service start request (S6.1), the resource server 400 processes as follows. That is, a nonce value represented by a hexadecimal character string is set based on the random number calculated by the resource server 400 as a cookie for the URL of the authentication endpoint of the authorization server 500 possessed by the resource server 400 (S6.2). . This nonce value is represented by a UUID (Universally Unique Identifier), and is, for example, the following value.
nonce = 7172f4bd-b332-4cfe-85cf-e4a73fe6ff98

  Then, the resource server 400 requests the Web browser 230 of the client PC 200 to redirect the HTTP / 1.1 status code 302 so as to make an OAuth authorization request (S6.3). The HTTP Location header of this redirect request includes the ID of the resource server 400, the type of authentication flow, and the URL of the authentication endpoint of the authorization server 500, resulting in the following redirect request.

https://auth.a01.example.com/authorize?response_type=token&client_id=ztr1JhRGa5
& state = xyz & redirect_uri = https% 3A% 2F% 2Fclient% 2Eexample% 2Ecom% 2Fcb
& scope = scopeA
HTTP method: GET
Content-Type: application / x-www-form-urlencoded

  In the request parameter, specify “token” fixed character string as response_type. As client_id, the application ID of the client application on the resource server 400 registered in advance in the authorization server 500 as a client application is designated. Furthermore, the URL (destination information) of the Web-Hosted client 300 registered in advance in the authorization server 500 as a client application is specified as redirect_uri. OAuth can also be configured so that the authorization request includes a scope indicating the scope of authority to be authorized. In the present embodiment, description will be made assuming that scope A is requested as the scope.

  The client PC 200 that has received the redirect request makes a user authentication / authorization request to the authorization server 500 in accordance with the request (S6.5). Upon receiving the authorization request, the authorization server 500 responds to the web browser 230 on the client PC 200 with a login screen 2000 shown in FIG. 8A in order to authenticate the user (S6.6). The user who is the resource owner 1000 inputs the user ID (2001) and the password (2002) on the login screen 2000 displayed on the Web browser 230, and executes login (2003) (S6.7). The authorization server 500 verifies whether the received user ID / password combination matches the information registered in the user management table of Table 1 (S6.8).

  Here, the user authentication screen display (S6.6), user authentication (S6.7), redirect URI and cookie domain parameter comparison (S6.8) will be described using the flowcharts of FIGS. 7 (a) and 7 (b). To do. Also, the authorization confirmation screen display (S6.9), authorization confirmation (S6.10), and access token response (S6.11), which are the features of this embodiment, will be described.

  FIG. 7A is a processing flowchart of the authorization server module 510 on the authorization server 500 when the authorization server 500 accepts a user authentication / authorization request. This flow starts when the authorization server module 510 receives a redirect request from the client PC 200 (S7.1). The authorization server 500 acquires a nonce value from the cookie included in the redirect request received from the client PC 200 (S7.2).

  The authorization server module 510 responds to the web browser 230 on the client PC 200 with a login screen 2000 shown in FIG. The user who is the resource owner 1000 inputs the user ID and password on the login screen 2000 displayed on the web browser 230 and executes login (S6.7). The authorization server 500 verifies whether the received user ID / password combination matches the information registered in the user management table of Table 1 (S7.3).

  If the combination of the user ID and password is not registered in the user management table of Table 1 as a result of the verification (S7.4), a user authentication error screen (not shown) is notified to the client PC 200 and the process is terminated ( S7.10). If, as a result of the verification, a combination of user ID and password is registered in the user management table (S7.4), an authorization confirmation process (S7.5) is performed.

  FIG. 7B is a flowchart showing details of the authorization confirmation process (S7.5) of FIG. First, the authorization server module 510 checks the request parameter of the redirect request from the client PC 200 received in S7.1 (S7.11). Further, the nonce value parameter of the Cookie included in the request, for example, nonce = 7172f4bd-b332-4cfe-85cf-e4a73fe6ff98 is acquired (S7.12).

  Next, the authorization server module 510 refers to the client management table of Table 2 and checks whether the client management table includes the values of the request parameters client_id and redirect_uri of the redirect request (S7.13). If this value is not included in the client management table, the authorization server module 510 returns an authorization confirmation failure shown in FIG. 8C and ends the processing (S7.17). On the other hand, if the values of the request parameters client_id and redirect_uri are included in the client management table, the server module 510 returns the authorization confirmation screen shown in FIG. 8B to the client PC 200 (S7.14).

  Here, the authorization server module 510 waits for a response from the client PC 200, and if authorization confirmation fails (S7.15), returns authorization confirmation failure and ends the process (S7.17). On the other hand, if the authorization confirmation is successful (S7.15), the authorization confirmation success is returned and the process is terminated (S7.16).

  Returning to the flow of FIG. After the authorization confirmation process (S7.5) in FIG. 7B, if authorization confirmation fails (S7.6), the authorization server module 510 notifies the client PC 200 of a user authentication error screen (not shown). Then, the process ends (S7.10). On the other hand, if the authorization confirmation process is successful (S7.6), the authorization server module 510 performs an access token issuing process (S7.7) for generating an access token that enables access to the resource server 400.

  The access token generated in the access token issuing process (S7.7) is registered in the token management table in Table 3. That is, the access token character string “AT_000001” is stored in the token ID column, and the expiration date of the access token predetermined by the authorization server is stored in the expiration date column. The scope information included in the record of the authentication token registered in the token table is stored in the scope column, and the user ID is stored in the user ID column.

  Further, using the access token issuing unit 540, the authorization server module 510 associates and stores the acquired nonce value, the access token character string of the issued access token, and the token expiration date in the nonce value management table of Table 4 ( S7.8). In this case, the nonce value is nonce = 7172f4bd-b332-4cfe-85cf-e4a73fe6ff98, and the access token character string is “AT_000001”. When the saving process is completed, the authorization server module 510 uses the access token issuing unit 540 to transmit an access token to the client as an access token response (S6.11) (S7.9).

  Returning to the flow of FIG. The response of the access token (S6.11) sent from the authorization server module 510 to the client PC 200 follows the OAuth 2.0 specification as follows. That is, using the application / x-www-form-urlencoded format, for example, the following parameters are assigned to the fragment component of the redirect URI and a response is transmitted to the client PC 200. According to the OAuth 2.0 specification, the parameters given to the access token response are access_token, token_type, expires_in, scope, and state as described below.

HTTP / 1.1 302 Found
Location: http://client.example.com/cb#access_token=AT_000001&state=xyz
& token_type = example & expires_in = 3600

  As described above, the access token response (S6.11) of the Implicit grant authorization flow as in the present embodiment causes the Web browser 230 of the client PC 200 to acquire the access token. Therefore, the access token is temporarily redirected to the Web-Hosted client 300. The web browser 230 on the client PC 200 that has received the access token response redirects the access token response to the Web-Hosted client 300 (S6.12). Here, the redirect of S6.12 does not include the fragment component parameters according to the HTTP specifications.

  The Web-Hosted client module 310 of the Web-Hosted client 300 that has received the redirect makes a nonce value verification request to the authorization server 500 (S6.13). Upon receiving the nonce value verification request, the authorization server 500 compares the redirect URI with the nonce value to verify the nonce value (S6.14). Then, the response of the verification result is returned to the Web-Hosted client 300 (S6.15). If the verification is successful, the Web-Hosted client 300 returns an access token acquisition script response to the Web browser 230 (S6.16).

  Hereinafter, the Web-Hosted client process will be described with reference to FIGS. FIG. 9 is a flowchart showing Web-Hosted client processing. This flowchart starts when the Web-Hosted client module 310 of the Web-Hosted client 300 receives an access token redirect response from the Web browser 230 on the client PC 200 (S9.1). The Web-Hosted client module 310 acquires the nonce value included in the redirect response cookie (S9.2).

  Next, the Web-Hosted client module 310 uses the nonce value confirmation unit 330 to request the nonce value verification processing from the authorization server 500 using the acquired nonce value and the URI of the Web-Hosted client itself as arguments (S9. 3). The processing on the authorization server 500 side of the nonce value verification processing (S9.3) will be described with reference to the flowchart of FIG. If the nonce value verification processing is successful (S9.4), the Web-Hosted client module 310 generates a script for acquiring an access token that can be executed on the Web browser 230 on the client PC 200 (S9. Five). Then, a response including the script is returned (S9.6). On the other hand, if the nonce value verification process fails (S9.4), the Web-Hosted client module 310 returns a screen (not shown) indicating an authorization error to the access token redirect response.

  FIG. 10 is a flowchart of nonce value verification processing in the authorization server 500 corresponding to the nonce value verification processing (S9.3) of FIG. This flowchart is executed by the authorization server module 510 of the authorization server 500 using the nonce value verification unit 630.

  First, the URI and nonce value of the Web-Hosted client passed as the above argument are acquired (S10.1). The authorization server module 510 refers to the client management table in Table 2 to check whether the acquired nonce value exists in the nonce value of the client management table (S10.2). If the nonce value does not exist, the authorization server module 510 returns a failure to the calling Web-Hosted client 300 of this process and ends the process (S10.5).

  On the other hand, if a nonce value exists in S10.2, the authorization server module 510 refers to the redirect URI corresponding to the matched nonce value in the client management table. Then, it is confirmed whether the redirect URI matches the acquired Web-Hosted client URI (S10.3). If it does not match the URI of the Web-Hosted client, the authorization server module 510 returns a failure to the Web-Hosted client 300 that is the call source of this processing (S10.5), and ends the processing. On the other hand, if it matches the URI of the Web-Hosted client, the authorization server module 510 returns success to the calling Web-Hosted client 300 (S10.4) and ends the processing.

  Returning to the flow of FIG. As described above, the Web-Hosted client 300 performs the Web-Hosted client processing shown in FIGS. 9 and 10, and when the nonce value verification is successful, returns an access token acquisition script response (S6.16) to the client PC 200. In this way, the Web-Hosted clients 300, 301, and 302 prevent unauthorized requests other than the normal redirect URI request (S6.12) by verifying the nonce value.

  The script included in the above-described access token acquisition script response (S6.16) is generally Javascript (registered trademark) that can be executed by the web browser 230, but may be a script that can be executed by another browser. The client script 320 operating on the Web browser 230 that has received the access token acquisition script acquires the access token by executing the script (S6.17). Thereby, the resource server 400 can be accessed (S6.18).

  FIG. 11 is a flowchart of a script for obtaining an access token and accessing a resource server. The Web browser 230 on the client PC 200 that has received the script from the Web-Hosted client executes this processing. First, the Web browser 230 parses the query string associated with the URI that is the redirect destination of the access token response (S6.11), and acquires the fragment value (S11.1). In the Javascript (registered trademark) of the present embodiment, the value of the fragment component of the access token response redirected to the Web-Hosted client 300 is acquired using, for example, the location.hash function. Further, an access token access_token = AT_000001 included in the acquired fragment component is acquired (S11.2). Then, by executing this script, the Web browser 230 accesses the resource server 400 using the acquired access token (S11.3).

  With the processing in FIG. 11, the script operating on the Web browser 230 receives the access token “AT_000001” and the scope “resource A” in S6.16 and S6.17. Then, a resource access request is made by including the access token “AT_000001” and the scope “resource A” in the request parameters to the resource server 400 (S6.18). Further, when making this resource access request, the nonce value included in the cookie of the redirect URI request (S6.12) to the Web-Hosted client 300 is also included in this resource access request. The resource server 400 that has received the resource access request makes a nonce value verification request to the authorization server 500 (S6.19), and receives the response (S6.21).

  FIG. 12 is a flowchart of nonce value verification processing in the authorization server 500 corresponding to the nonce value verification processing (S6.20) of the resource server 400. This process is executed by the authorization server module 510 of the authorization server 500 using the nonce value verification unit 630. First, the authorization server module 510 acquires the URI and nonce value of the resource server passed as the argument (S12.1). The authorization server module 510 refers to the client management table in Table 2 and checks whether the acquired nonce value exists in the nonce value of the client management table (S12.2). If the nonce value does not exist, the authorization server module 510 returns a failure to the calling Web-Hosted client 300 of this process (S12.5) and ends the process. On the other hand, if the nonce value exists, the process proceeds to S12.3.

  In S12.3, the authorization server module 510 refers to the redirect URI corresponding to the matched nonce value in the client management table, and further refers to the client and resource server management table in Table 5. Based on the result, it is confirmed whether or not the resource server URI corresponding to the redirect URI matches the acquired URI of the resource server 400 (S12.3). If the URI does not match the URI of the resource server, the authorization server module 510 returns a failure to the calling Web-Hosted client 300 of this processing (S12.5) and ends the processing. On the other hand, if it matches the URI of the Web-Hosted client, the authorization server module 510 returns success to the caller resource server 400 (S12.4) and ends the process.

  Returning to the flow of FIG. The resource server 400 that acquired the access token information “AT_000001” and the scope “resource A” determines whether to permit or deny access to the resource for which the request has been received based on the acquired information. Here, it is assumed that an application ID accessible to the resource server 400 is set in advance. Then, whether the access is permitted is verified by comparing the set application ID with the application ID acquired from the access token information “AT_000001”. This verification is performed by the resource server 400 acquiring token information from the authorization server 500 using the access token “AT_000001” and the scope “resource A” as arguments (S6.22).

  The authorization server 500 refers to the token management table in Table 3 and verifies that the acquired access token “AT_00001” has not expired and that the requested scope “resource A” is within the scope. . If there is no problem as a result of the verification, the verification success is returned (S6.23). As a result, when it is determined that access is permitted, the resource server 400 responds to the web browser 230 with a resource (S6.24). Here, the resource is, for example, a list of documents that can be printed when the resource server 400 is a print service, and a list of forms that can be created when the resource server 400 is a form service.

  In the above-described embodiment, the processing from S6.22 to S6.23 has been described so that the token verification is performed by the authorization server 500 and the resource server 400, respectively. However, it is also possible to configure such that an application that can access resources is managed by the authorization server 500 and all verification is performed by the authorization server 500. Further, in the present embodiment, it has been described that an accessible application is determined using an application ID. However, the Web browser 230 on the client PC 200 can be identified based on the serial number or client ID that can be acquired from the token information, and the access can be determined. Similarly, it can be configured to determine whether or not access is possible based on a scope or user ID that can be acquired from token information.

  The web browser 230 on the client PC 200 that has received the resource response (S6.24) configures the aforementioned application screen based on the received data, and responds to the user who is the resource owner 1000.

<Example 2> (Resource server non-functional requirement selection by multiple redirect URIs)
In the method shown in the first embodiment, there is only one redirect URI that can be selected at the time of client registration in the client registration process necessary for enabling selection of resource servers having different non-functional requirements. In the second embodiment, a method capable of selecting a plurality of redirect URIs for a client ID at the time of client registration will be specifically described.

  Here, a sequence representing a client registration flow according to the present embodiment for performing a client registration process necessary for enabling selection of resource servers having different non-functional requirements will be described with reference to FIGS. The client registration flow in FIG. 4 is a flow in which the extension unique to the present embodiment is added to the client registration in the OAuth 2.0 specification generally used in OAuth 2.0. Also in the second embodiment, the client registration flow itself shown in FIG. 4 is the same as that of the first embodiment.

  In the flow of FIG. 4, first, the client registrant 1001 performs client registration for the client referred to in the OAuth 2.0 specification necessary for resource access in this embodiment. The resource owner 1000 to be described later performs resource access using a client registered in advance by this flow. The client registrant 1001 requests a client registration screen from the authorization server 500 using the Web browser 230 (S4.1). The authorization server 500 returns a client registration screen as shown in FIG. 13 in response to the request of S4.1 (S4.2).

  FIG. 13 is a client registration screen for registering a client in the OAuth 2.0 specification. The client registration screen includes a client registration parameter display 13000 for displaying and selecting parameters necessary for client registration by the authorization server 500, and the following two buttons. That is, an OK button 13005 for confirming the client registration parameter and registering it in the authorization server 500, and a cancel button 13006 for canceling the client registration parameter display 13000.

  The client registration parameter display 13000 includes a client name input line 13007, a client ID display line 13001, and redirect URI selection lines 13002, 13003, and 13004. In the client ID display line 13001, the authorization server 500 that has received the client registration screen request (S4.1) generates and displays a random and unique value in UUID format when the client registration screen is returned (S4.2). . For example, the value is '9237ee87-1d58-4b0d-a7ed-a4042402df52'. In the client name input line 13007, the client registrant 1001 inputs an arbitrary client name at the time of client registration. In the redirect URI selection lines 13002, 13003, and 13004, options prepared in advance for the redirect URI referred to in the OAuth 2.0 specification that are valid at the time of client registration are displayed. In addition, a multiple-selectable check button is displayed on each line of the redirect URI selection line so that the client registrant 1001 selects one or more of the multiple redirect URI options to register with the authorization server 500. One or more can be selected.

  A plurality of redirect URI selection lines 13002, 13003, and 13004 are redirect URIs for guiding a client to resource servers 400, 401, and 402 having different non-functional requirements. Among these, the redirect URI 13002 is a URI for accessing the resource server 400. Similarly, a redirect URI 13003 is a redirect URI for accessing the resource server 401, and a redirect URI 13004 is for accessing 402. These relationships are defined in advance by the client and resource server management table shown in Table 5.

  Returning to the flow of FIG. 4, the client registrant 1001 refers to the client registration screen of FIG. 13 returned from the authorization server 500 in S4.2, and inputs the client registration content (S4.3). Specifically, after confirming the client ID, select one or more redirect URIs from the options shown in FIG. 13 (redirect URIs 13002 to 13004) by selecting a check button that allows multiple selection, and OK. A button 13005 is pressed. When the client registrant 1001 presses the OK button 13005, the Web browser 230 transmits a client registration processing request to the authorization server 500 (S4.4).

  Upon receiving the client registration processing request (S4.4), the authorization server 500 performs client registration processing (S4.5). Specifically, the client registration unit 620 of the authorization server 500 receives the client name, client ID, and redirect URI from the received client registration processing request (S4.4), and the client management table on the authorization server 500 (Table 2). Register with. When the registration of the client name, client ID, and redirect URI in the client management table is completed, the authorization server 500 returns the registered content (not shown) to the Web browser 230 and ends the process (S4.6). In this embodiment, the client registration process to the authorization server by the client registrant is a process using a Web browser, but the registration process to the authorization server may use a dedicated registration application.

  Here, a sequence representing an authorization flow according to the present embodiment for using a resource service using a browser application on the client PC 200 will be described with reference to FIG. In the OAuth 2.0 specification, multiple protocol sequences corresponding to various clients are called grant types. The authorization flow in FIG. 14 is a grant type obtained by adding an extension unique to this embodiment to the implicit grant of the OAuth 2.0 specification. Since S14.2 to S14.22 are the same as S6.2 to S6.22 in FIG.

  In the flow of FIG. 14, first, an authorization cooperation service start request is generated from a user who needs access to a protected resource (S14.1). This service request is made by the user who is the resource owner 1000 to the resource server 400 using the HTTP protocol via the browser application on the client PC 200 which is a user agent operated by the resource owner 1000. Specifically, the user who is the resource owner 1000 operates the client PC 200 to access an application screen (not shown) of the resource server 400 (S14.1). This application screen is, for example, a screen for selecting a document to be printed when the resource cooperation application of the resource server 400 is a print application, and a screen for selecting a form to be created when the resource application is a form application. Here, accessing the application screen means, for example, that the application screen is displayed in a selectable manner on the browser on the client PC 200 and that the application is selected. By selecting the application, the resource owner 1000 transmits an authorization cooperation service start request to the resource server 400 (S14.1).

  In this embodiment, the resource server can be selected on the application screen. The selectable resource server is a resource server indicated by a resource server URI corresponding to a plurality of redirect URIs selected on the client registration screen shown in FIG.

  In this embodiment, the resource cooperation application is on the resource server 400. However, in general, the resource cooperation application may exist in a client application server other than the resource server 400. In this embodiment, a client application that cooperates with a resource service such as a print Web application and a form Web application is installed as a resource service cooperation application. Note that one or more resource service cooperation applications may be installed in one resource server.

  As described above, in the present invention, the nonce value is confirmed by the Web-Hosted client module 310 and the resource server module 410. As a result, it is possible to prevent the access token acquisition script and the resource request from responding to a browser unrelated to the series of processes as described above. Thereby, even if the access token is stolen by the browser as described above, access to the Web-Hosted client 300 or the resource server 400 becomes an error, and the use of the stolen access token can be prevented. In this way, unauthorized access to the resource server 400 can be prevented.

<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.

200 client PC
300 Web-Hosted client
400 resource server
500 authorization server

Claims (13)

An authority delegation system used in a network, comprising: a resource server that provides a resource; an authorization server that authenticates and authorizes a client; and an intermediary device that mediates communication between the client and the authorization server;
The resource server issues an authentication identifier used for client authentication to the client in response to a request from the client for a protected resource,
The authorization server receives identification information for identifying the client, the authentication identifier issued by the resource server, and destination information indicating the destination of the intermediary device from the client, and is based on information registered in the authorization server in advance. Authenticate the client, verify that the client has authority over the protected resource if authentication is successful, and, if successful, provide proof information certifying that the client has authority Issued to
When the certification information issued by the authorization server is sent from the client to a destination indicated by the destination information, the intermediary device, based on the authentication identifier and information registered in the authorization server, the client Verify whether it has authority to the protected resource, and if the verification is successful, issue certification information to the client to prove the authority;
The resource server receives the certification information issued by the intermediary device from the client, verifies whether the request from the client is permitted based on the authentication identifier, and if the verification succeeds, the protection server Provided resources to the client,
The authorization server registers in advance destination information of a plurality of intermediary devices corresponding to a plurality of resource servers having different performances for the same resource, and allows any one of the destination information to be selected by the client. Authority transfer system.   2. The authority transfer system according to claim 1, wherein when the client accesses any of the plurality of resource servers, the resource server can be selected based on the plurality of destination information.   The authority transfer system according to claim 1 or 2, wherein any one or a plurality of the plurality of pieces of destination information can be selected by the client. In an authority delegation system used in a network, including a resource server that provides resources, an authorization server that performs authentication and authorization of clients, and an intermediary device that mediates communication between the client and the authorization server.
The resource server issues an authentication identifier used for client authentication to the client in response to a request from the client for a protected resource,
The authorization server receives identification information for identifying the client, the authentication identifier issued by the resource server, and destination information indicating the destination of the intermediary device from the client, and is based on information registered in the authorization server in advance. Authenticate the client, verify that the client has authority over the protected resource if authentication is successful, and, if successful, provide proof information certifying that the client has authority Issued to
When the certification information issued by the authorization server is sent from the client to a destination indicated by the destination information, the intermediary device, based on the authentication identifier and information registered in the authorization server, the client Verify whether it has authority to the protected resource, and if the verification is successful, issue certification information to the client to prove the authority;
The resource server receives the certification information issued by the intermediary device from the client, verifies whether the request from the client is permitted based on the authentication identifier, and if the verification succeeds, the protection server Provided resources to the client,
The authorization server registers in advance destination information of a plurality of intermediary devices corresponding to a plurality of resource servers having different performances for the same resource, and allows any one of the destination information to be selected by the client. Authorization server. In an authority delegation system used in a network, including a resource server that provides resources, an authorization server that performs authentication and authorization of clients, and an intermediary device that mediates communication between the client and the authorization server.
The resource server issues an authentication identifier used for client authentication to the client in response to a request from the client for a protected resource,
The authorization server receives identification information for identifying the client, the authentication identifier issued by the resource server, and destination information indicating the destination of the intermediary device from the client, and is based on information registered in the authorization server in advance. Authenticate the client, verify that the client has authority over the protected resource if authentication is successful, and, if successful, provide proof information certifying that the client has authority Issued to
When the certification information issued by the authorization server is sent from the client to a destination indicated by the destination information, the intermediary device, based on the authentication identifier and information registered in the authorization server, the client Verify whether it has authority to the protected resource, and if the verification is successful, issue certification information to the client to prove the authority;
The authorization server registers in advance destination information of a plurality of intermediary devices corresponding to a plurality of resource servers having different performance for the same resource, and allows any one of the destination information to be selected by the client,
The resource server receives the certification information issued by the intermediary device from the client, verifies whether the request from the client is permitted based on the authentication identifier, and if the verification succeeds, the protection server A resource server, wherein the resource server is provided to the client. In an authority delegation system used in a network, including a resource server that provides resources, an authorization server that performs authentication and authorization of clients, and an intermediary device that mediates communication between the client and the authorization server.
The client sends a request for a protected resource to the resource server, receives an authentication identifier used to authenticate the client from the resource server;
The client transmits identification information for identifying the client, the authentication identifier received from the resource server, and destination information indicating a destination of the intermediary device to the authorization server. Receiving proof information from the authorization server certifying that it has authority;
The client transmits the certification information received from the authorization server to a destination indicated by the destination information of the intermediary device, and provides certification information for certifying that the client has authority over the protected resource. Received from the intermediary device,
The client sends the certification information received from the intermediary device to the resource server, receives the protected resource from the resource server;
The client is capable of selecting one of destination information of a plurality of intermediary devices registered in advance in the authorization server corresponding to a plurality of resource servers having different performance for the same resource. Client. In an authority delegation system used in a network, including a resource server that provides resources, an authorization server that performs authentication and authorization of clients, and an intermediary device that mediates communication between the client and the authorization server.
The resource server issues an authentication identifier used for client authentication to the client in response to a request from the client for a protected resource,
The authorization server receives identification information for identifying the client, the authentication identifier issued by the resource server, and destination information indicating the destination of the intermediary device from the client, and is based on information registered in the authorization server in advance. Authenticate the client, verify that the client has authority over the protected resource if authentication is successful, and, if successful, provide proof information certifying that the client has authority Issued to
The authorization server registers in advance destination information of a plurality of intermediary devices corresponding to a plurality of resource servers having different performance for the same resource, and allows any one of the destination information to be selected by the client,
When the intermediary device receives the certification information issued by the authorization server from the client to the destination indicated by the destination information, the mediator performs the protection based on the authentication identifier and information registered in advance in the authorization server. Verifying the authorization to the authorized resource, and if the verification is successful, issue certification information to prove the authorization to the client,
The intermediary device, wherein the certification information issued by the intermediary device is transmitted from the client to the resource server, and the protected resource is provided from the resource server to the client. Authority used in an authority delegation system used in a network, including a resource server that provides resources, an authorization server that performs authentication and authorization of clients, and an intermediary device that mediates communication between the client and the authorization server A transfer method,
In response to a request from a client for a protected resource, the resource server issues an authentication identifier used for client authentication to the client.
The authorization server receives identification information for identifying the client, the authentication identifier issued by the resource server, and destination information indicating the destination of the intermediary device from the client, and is based on information registered in the authorization server in advance. Authenticate the client, verify that the client has authority over the protected resource if authentication is successful, and, if successful, provide proof information certifying that the client has authority Issued to
In the intermediary device, when the certification information issued by the authorization server is sent from the client to a destination indicated by the destination information, based on the authentication identifier and information registered in advance in the authorization server, the client Verify whether it has authority to the protected resource, and if the verification is successful, issue certification information to the client to prove the authority;
The resource server receives the certification information issued by the intermediary device from the client, verifies whether the request from the client is permitted based on the authentication identifier, and if the verification is successful, the protection Provided resources to the client,
In the authorization server, destination information of a plurality of intermediary devices corresponding to a plurality of resource servers having different performance for the same resource is registered in advance, and any one of the destination information can be selected by the client Authority transfer method.   The program for making a computer perform the authority transfer system of any one of Claims 1-3.   The program for implement | achieving the authorization server of Claim 4 with a computer.   A program for realizing the resource server according to claim 5 on a computer.   A program for realizing the client according to claim 6 on a computer.   The program for implement | achieving the mediation apparatus of Claim 7 with a computer.

Images