JP2018180692A - Authentication authorization system, authentication authorization server, authentication method and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To leak an access token when one of a plurality of resource servers is an open redirector in an OAuth authorization flow, and an attacker may be able to illegally access all resource servers. SOLUTION: An authentication / authorization server receives a token issuance request from a client, and limits the redirect URI and the requested authority of the received client by the authority information associated with the redirect URI given in advance. Issue tokens with limited client privileges. [Selection diagram] Fig. 5

Description

  The present invention relates to a method for narrowing down authorization in an authorization flow, and more particularly to a proof-of-authorization system, authentication authorization server, authentication method and program for narrowing down authorization associated with tokens issued in an OAuth Implicit Grant flow.

  With the spread of the cloud, there is an increasing opportunity to provide application services using virtual servers on the cloud without managing server machines at hand. Furthermore, in recent years, there is a cloud service that provides a general function group (hereinafter referred to as a framework) of an application that can provide an application service without holding a server even in the cloud. An application developer designs / implements an application programming interface (application programming interface, hereinafter referred to as an API) for accessing an application service hosted on a cloud service using a framework provided by the cloud service. In this way, maintenance costs can be reduced because there is no application server to be maintained by the server administrator. When a user uses an application on the cloud, the user needs to be authenticated or authorized by an authentication / authorization server.

  BASIC authentication is one of the methods for authenticating a user. Here, with regard to BASIC authentication, an overview will be described by taking an authentication method when a user uses an application on a Web browser as an example. After the authentication / authorization server asks the user for a username and password via a web browser, the user sends the username and password to the authentication / authorization server. The authentication / authorization server verifies whether the user name and password received from the user are included in the user management table associated with the previously given user name and password. If the user name and password received from the web browser are included, a token certifying that the web browser has been authenticated (hereinafter referred to as an authentication token) is returned. The above procedure is an outline of BASIC authentication.

  In order for a client to use an application hosted on a cloud service after BASIC authentication, the client must clarify the range of application services that the client wants to access, and then receive approval from the authentication / authorization server. The client requests authorization from the authentication / authorization server via a web browser. This request includes the authentication token of the user operating the browser, the information of the client for approval, and the scope of the application service for authorization (hereinafter referred to as a scope). The authentication / authorization server verifies that the authentication token received from the client is valid. When the authentication token is valid, the authentication / authorization server proves that the access token request from the client is permitted to use the application hosted on the cloud service (hereinafter referred to as an access token). Issue). The client authorized by using the access token issued in the above procedure can use the application hosted on the cloud service.

  A standard protocol called OAuth, which is a method for authorizing a client and delegating the authority of a user, has been developed to realize coordination of authorization. Here, we will give an overview of OAuth.

  OAuth is a method for realizing access to data managed by an application on a cloud service on behalf of the user by a client authorized by the user who is the owner of the data. At this time, the application hosted on the cloud service reveals the range accessed by the client. To be clear, the client must obtain explicit delegation of the user's authority for access by the client from the authentication / authorization server. When a user explicitly delegates authority is referred to as authority delegation. When the user transfers the authority, the authentication / authorization server issues an access token indicating that the access to the application service hosted on the cloud service has been granted in response to the access token request from the client. With the above procedure, the client can use the API for accessing the application service hosted on the cloud service.

  As described above, in order to use the application hosted on the cloud service, the implementation method differs depending on whether the user is authenticated or the client whose authority is delegated is authorized.

  However, due to limitations of the cloud service or framework that hosts the application, it may not be possible to implement the application so that either an authentication token or an access token can be received. In this case, the application developer must create separate APIs for the authentication token and the access token. Because it is inefficient to make the same, it is desirable to use access tokens even in web browsers that use authentication tokens.

  However, Web browsers have the disadvantage that it is difficult to maintain the confidentiality of client authentication information (hereinafter referred to as credentials), and OAuth does not maintain the confidentiality of credentials as Web browsers do. An Implicit Grant flow is defined that allows the authentication / authorization server to issue an access token.

  Give an overview of the Implicit Grant flow. After receiving an authorization request from a client (for example, a script executed by a Web browser), the authentication / authorization server matches the redirect URI included in the authorization request with the redirect URI given in advance to the authentication / authorization server. Verify if you want to If the verification results match, the authentication / authorization server receives an authorization from the user and then issues an access token in response to the client's authorization request.

  At this time, when the authentication / authorization server receives the authorization by the user, the authentication / authorization server redirects the web browser using the redirect URI for which the match is confirmed. The Web browser retrieves the information of the fragment in which the access token identifier is described from the redirect URI and holds it locally. The web browser sends a request with the fragment removed to the web-hosted client resource according to the redirect instruction. When a Web-Hosted client resource receives a request, it usually returns a Web page containing embedded scripts to the Web browser. The web browser accesses the complete redirect URL including the fragment being held, and extracts the access token contained in the fragment. The web browser executes the script contained in the web page locally, extracts the access token identifier, and sends it to the client.

  Thus, the Implicit Grant flow realizes that the user's authority is delegated to the client by user intervention and verification of a specific redirect URI registered in advance in the authentication / authorization server. . By applying this Implicit Grant flow, clients running on Web browsers can use access tokens. The application developer can unify the overlapping design / development flow of the access token and the authentication token into the design / development flow of the access token.

JP, 2015-228068, A

  However, in the Implicit Grant flow, the access token may be leaked under the following conditions. A plurality of resource servers exist, and each resource server holds at least one Web-Hosted client resource. Here, consider the case where the URI of a specific Web-Hosted client resource executes redirection to an arbitrary server (hereinafter referred to as an open redirector) in at least one of a plurality of resource servers. In addition, it is assumed that the Web browser executing the Implicit Grant flow inherits the fragment to the redirect destination URI. Furthermore, suppose that a client having the URI of the specific Web-Hosted client resource described above as the redirect URI requests the authentication / authorization server for the scope of all privileges for all resource servers.

  In such a case, the authentication / authorization server issues an access token with the scope of all privileges to all resource servers, in response to the client's request. At this time, there is a possibility that an attacker-managed server at the redirect destination included in the above-described Web-Hosted client resource URI may read a fragment and obtain an access token. As a result, an attacker could gain unauthorized access to all resource servers using the obtained access token. Here, it is not desirable that unauthorized access occurs to servers other than the open redirector. Patent Document 1 describes a technique for extending an Implicit Grant flow. According to Patent Document 1, when performing user authentication so as not to impair user convenience, the authentication / authorization server omits the authorization confirmation for the user only when the redirect URI matches, and the access token is Is issued.

  However, even in Patent Document 1, since the authentication / authorization server issues an access token if the redirect URIs match, the problem that all of the resource servers are at risk remains.

  The present invention has been made in view of the above-mentioned problems, and it is an object of the present invention to prevent the expansion of unauthorized access even if a token leak occurs in an implicit grant flow.

  In order to achieve the above object, the present invention has the following configuration.

According to one aspect of the invention, the invention is
Receiving means for receiving from the client an access token request together with the client's redirect URI and the requested client's authority;
Authority restriction means for restricting the requested authority by the authority information linked to the redirect URI;
And an issuing means for issuing an access token of the right limited by the right limiting means.

According to another aspect, the present invention provides:
An authentication and authorization system comprising a client, a resource server for providing resources, and an authentication and authorization server, comprising:
The authentication and authorization server is
Receiving means for receiving, from the client, an access token request together with the client's redirect URI and the requested client's authority;
Authority restriction means for restricting the requested authority by the authority information linked to the redirect URI;
And issuing means for issuing an access token of the right limited by the right limiting means,
The resource server validates the access token received from the client together with a request for resources, and provides the requested resource to the client if validation is successful.

  According to the present invention, even if a token leak occurs in an Implicit Grant flow, it is possible to prevent the expansion of unauthorized access.

It is a sequence diagram showing the Implicit Grant flow of OAuth. FIG. 1 is a network configuration diagram of a first embodiment. FIG. 2 is a hardware configuration diagram of each device of the first embodiment. FIG. 2 is a module configuration diagram of each device of the first embodiment. FIG. 7 is a sequence diagram showing an authorization flow of the first embodiment. FIG. 7 is a flowchart showing processing of an authentication / authorization server of the first embodiment. FIG. FIG. 16 is a flowchart showing processing in an authentication / authorization server of Example 2. FIG. It is a figure which shows the approval confirmation screen of Example 2. FIG.

Embodiment 1
In the present embodiment, it is assumed that a form service for generating form data on the Internet and a print service for acquiring and printing data on the Internet are installed in a server on the Internet. Hereinafter, a service that provides a function on the Internet, such as a form service and a printing service, is called a resource service. Further, in the present embodiment, it is assumed that the print application and the form application installed in the portable terminal use the resource service. Hereinafter, an application that uses a resource service, such as a print application and a form application, will be 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 the present embodiment, the OAuth mechanism is used. OAuth uses information called access token as information to prove the authority delegated from the user. The authority transfer system according to the present embodiment is implemented on a network configured as shown in FIG.

<Configuration of Authentication and Authorization System>
In FIG. 2, a WAN 702 is a wide area network, and in the present embodiment, a World Wide Web (WWW) system is constructed on the network 702. A LAN 701 and a LAN 703 are Local Area Networks connecting respective components. The authentication / authorization server 400 is a server that performs user authentication and access token issuance.

  The resource servers 600, 601, and 602 are provided with resource services such as a print service and a form service. Here, it includes Web-Hosted client resources in OAuth. Note that one or more Web-Hosted client resources may be included in one resource server. Furthermore, one or more resource services may be included in the resource server.

  Web-Hosted client resources 500, 501, 502 are Web-Hosted client resources in OAuth. The portable terminal 201 is a portable terminal used by a user. Here, the client 230 and the web browser 300 in OAuth are included. Further, connection to the resource servers 600, 601, and 602 is not limited to the portable terminal 201. The client 230 is a client that makes a request for a resource located on a protected server on behalf of the user, and is software executed on the web browser 300 in a script language such as JavaScript (registered trademark), for example. .

  The authentication / authorization server 400 and the resource servers 600, 601, and 602 are connected to the WAN 702 via the LAN 701, respectively. Similarly, the portable terminal 201 is connected to the WAN 702 via the LAN 703. The authentication / authorization server 400 and the resource servers 600, 601, and 602 may be configured on separate LANs, or may be configured on the same LAN. It may also be configured on the same PC or server.

<Hardware configuration of authentication and authorization server>
FIG. 3 is a diagram showing a hardware configuration of the authentication / authorization server 400 according to the present embodiment. In addition, the configurations of the resource servers 600, 601, and 602, and the portable terminal 201 are the same. In FIG. 3, the CPU 801 executes a program such as an OS or an application stored in the program ROM of the ROM 803 or loaded from the hard disk 811 into the RAM 802. Here, OS is an abbreviation of an operating system operating on a computer, and the operating system is hereinafter referred to as an OS. The processing of each flowchart to be described later can be realized by executing this program by the CPU 801. A RAM 802 functions as a main memory, a work area, and the like of the CPU 801. A keyboard controller (KBC) 805 controls key input from a keyboard (KB) 809 or a pointing device (not shown). A CRT controller (CRTC) 806 controls the display of the CRT display 810. A disk controller (DKC) 807 controls data access to a hard disk (HD) 811 storing various data, an optical disk capable of exchanging media, a flexible disk (FD), a recording medium using a non-volatile memory, and the like. The NC 812 is connected to the network and executes communication control processing with other devices connected to the network.

  In all the descriptions below, unless otherwise specified, the subject of execution on the hardware is the CPU 801, and the subject on software is the application program installed on the hard disk (HD) 811.

<Cause of access token leakage>
Here, before giving a detailed description for practicing the present invention, details of the possibility of the access token being leaked in the Implicit Grant flow, which is also described in the above-mentioned problem, will be described using FIG.
It is assumed that at least one Web-Hosted client resource is inherent in the resource server, and the resource server 600, the resource server 601, and the resource server 602 are on the LAN 701. Here, Table 1 shows the relationship between the scope of the authority to be verified by the authentication / authorization server and the redirect URI. This scope is the scope of the client authority. In the present embodiment, when simply referring to the right, it refers to the client right.

In Table 1, the resource server 600 is linked to the scope scopeA of the client authority to be verified and the URI https://xxx.example.com of the Web-Hosted client resource. The resource server 601 is linked to the scope scope B of the client authority to be verified and the URI https://yyy.example.com of the Web-Hosted client resource. The resource server 602 is linked to the scope scope C and scope D of the client authority to be verified, and the URI “https://zzz.example.com” of the Web-Hosted client resource.

  The portable terminal 201 is located on a LAN 703 different from the LAN 701 across the WAN 702. The portable terminal 201 requests the authentication / authorization server 400 for the scope of the authority to the resource server 600. However, it is assumed that the portable terminal 201 once requests the scope of all the rights because it also wants to access other resource servers 601 and 602 in the future. That is, the client 230 requests the authentication / authorization server, the client identifier is client 230, the scope of the authority to request is scopeA, scopeB, scopeC, scopeD, and the authorization request specifies https://xxx.example.com as the redirect URI. And request an access token. It is assumed that the client management table in which the client identifier is linked to the redirect URI is given to the authentication / authorization server 400 in advance. Table 2 shows the client management table.

In Table 2, for the client identifier client 230 of the client 230, three redirect URIs https://xxx.example.com, https://yyy.example.com, https://zzz.example.com It is tied.

  Here, the Web-Hosted client resource 500 of the resource server 600 shown in FIG. 2 is an open redirector that performs redirection to the outside of the resource server 600, and the Web browser 300 is also the URI of the redirect destination. Suppose that a fragment is taken over. The problems occurring at this time will be described in detail according to the Implicit Grant flow shown in FIG. In FIG. 1, user 100 is the owner of a resource located on a protected server. The client 230 makes a request for a resource on a protected server on behalf of the user 100, and is software executed on the Web browser 300 in a script language such as JavaScript (registered trademark), for example. The web browser 300 is, for example, a user agent for using the WWW on a computer. The authentication / authorization server 400 is a server that issues an access token to the client 230 upon confirming that the user 100 has authorized the client 230 to transfer authority. The web-hosted client resource 500 is a module hosted on a server that receives a redirect URI request from the web browser 300 and returns a script to the web browser 300 in order for the client 230 to obtain an access token. The resource server 600 is a server that hosts resources on a protected server, accepts requests for resources using access token identifiers, and returns responses.

In S1.1, the user 100 accesses the resource server 600 via the web browser 300.
At S1.2, the resource server 600 receives the access token request from the user 100, and distributes the client 230 operating on the web browser to the user 100 via the web browser 300. The distributed client 230 is executed by the web browser 300.
At S1.3, the client 230 sends an authorization request to the authentication / authorization server 400. The authorization request includes the client 230 as the client identifier, scope A, scope B, scope C, scope D as the scope of the authority requested, and https://xxx.example.com as the redirect URI.
At S1.4, the authentication / authorization server 400 collates the client identifier and redirect URI presented from the client 230 at S1.3 with the client management table shown in Table 2 given in advance. Then, it is determined whether a combination of the client identifier of the authorization request and the client identifier and the redirect URI matching the redirect URI is stored in the client management table. The client identifier and redirect URI included in the authorization request received from the client 230 are one of the client identifier client 230 in Table 2 and https://xxx.example.com that is the redirect URI linked thereto. If you do, go to S1.5.
In S1.5, the authentication / authorization server 400 transmits, to the Web browser 300, a script for displaying an authorization confirmation screen.
When the user 100 performs the authorization operation on the authorization confirmation screen in which the authorization confirmation is displayed in S1.5 in S1.6, the Web browser 300 transmits an authorization confirmation message to the authentication / authorization server 400.
In S1.7, the authentication / authorization server 400 that has received the authorization confirmation redirects the web browser 300 using the redirect URI (https://xxx.example.com) whose match is confirmed in S1.4. In this redirect URI, the requested access token identifier is described as a fragment. Further, in the authentication / authorization server 400, in order to manage the issued access token, a record will be described later that associates the client identifier of the client of the issue destination with the access token identifier and the scope of the requested authority. Add to the access token management table shown in 3. Here, the access token identifier is AT_000201. The redirect URI issued by the authentication / authorization server 400 is configured by writing an access token identifier in a fragment, and is, for example, https://xxx.example.com/#token_id=AT_000201. Furthermore, in the access token management table, as shown in Table 3 by the authentication / authorization server 400, the access token identifier AT_000201, the client identifier client 230 associated therewith, and scopes of privileges scopeA, scopeB, scopeC, scopeD. Contains records are added.

In step S1.8, the web browser 300 extracts fragment information from the redirect URI and holds it locally.
In step S1.9, the web browser 300 transmits the request with the fragment removed to the web-hosted client resource 500 specified by the redirect URI in accordance with the redirect instruction.

Here, originally, when the Web-Hosted client resource 500 receives a request, it returns a Web page (usually, an HTML document including an embedded script) to the Web browser (S1. 10). In the web page, the complete redirect URL including the fragment held by the web browser 300 is accessed, and the access token (and other parameters) included in the fragment are extracted (S1.11).
The web browser 300 locally executes the script included in the web page received in S1.10, extracts the access token identifier, and transmits it to the client 230 (S1.12).
The client 230 can acquire the access token identifier by the above procedure. Also, by using the access token identifier acquired here, the client can access the resource on the resource server.

On the other hand, the case where the attacker abuses the open redirector and directs the Web browser 300 to the attacker's server from the redirect URI (indicating the Web-Hosted client resource 500) will be described.
In S1.9, the web browser 300 sends a request to the web-hosted client resource 500 indicated by the redirect URI according to the redirect instruction. Here, if the Web-Hosted client resource 500 has become an open redirector, it is further redirected to the server of an attacker (not shown). At this time, the Web browser 300 holds the fake Web-Hosted client resource (for example, a web page including a script) downloaded from the server of the attacker in S1.10 in the fake Web-Hosted client resource. The fragment is stolen. Then, a fake Web-Hosted client resource may traverse the fragment to the attacker, who may read the fragment and obtain the access token identifier AT_000201.

  An attacker can exploit the obtained access token identifier and illegally access not only the resource server 600 but also the resource server 601 and the resource server 602. There is a possibility that the access token may leak in the above procedure.

  The best mode for carrying out the present invention will be described in order not to spread the damage from the attacker other than the server of the open redirector.

<Software configuration of server and terminal>
FIG. 4 is a diagram showing module configurations of the authentication / authorization server, the resource server, and the portable terminal according to the present embodiment. The authentication / authorization server 400, the resource server 600, and the portable terminal 201 are the same as those in FIG. The authentication / authorization server 400 includes an authentication server module 410 and an authorization server module 420. The authentication server module 410 is a module for authenticating a user.

  The authorization server module 420 has a client verification unit 430, an authority limitation unit 440, an authorization confirmation unit 460, a token issuing unit 470, and a token verification unit 480. The client verification unit 430 is a module for verifying the client. The authority limiting unit 440 is a module for narrowing down the authority associated with the access token. The authorization confirmation unit 460 is a module for displaying an authorization confirmation screen and performing authorization confirmation. The token issuing unit 470 is a module for issuing a token. The token verification unit 480 is a module for verifying the legitimacy of the token.

  The resource server 600 includes a Web-Hosted client resource module 510 and a resource server module 610. The web-hosted client resource module 510 has a client script 520. The resource server module 610 has a token authority confirmation unit 620 and a resource request processing unit 630.

  The portable terminal 201 controls each application by the CPU 801 executing the OS 210 stored in the ROM 803 or the external memory 811. Furthermore, the portable terminal 201 has a web browser 300 which is a user agent for using the WWW, and a client 230.

  Table 4, Table 5, Table 6, and Table 7 shown below are data tables stored in the external memory by the authentication / authorization server 400. These data tables can also be configured to be stored not in the external memory of the authentication / authorization server 400 but in another server configured to be communicable via the LAN 701.

Table 4 is a user management table used by the authentication server module 410. The user management table of Table 4 consists of a user identifier and a password. The authentication / authorization server 400 has a function of authenticating each user or client by verifying a set of information of a user identifier and a password, and generating authentication information if correct.

Table 5 is a client management table used by the client verification unit 430. The client management table of Table 5 comprises a client identifier and a redirect URI associated with it.

Table 6 is a redirect URI scope tying management table used by the authority limiting unit 440. The redirect URI scope tying management table in Table 6 is a scope that indicates the redirect URI and the scope of the permission granted to the client that is the source of the authorization request when executing the Implicit Grant flow via the redirect URI. (Hereinafter referred to as client scope, also referred to as client authority information). Details of processing of the redirect URI scope tying management table of Table 6 will be described later.

Table 7 is an access token management table generated by the token issuing unit 470. The access token management table of Table 7 is composed of an access token identifier, a client identifier, a user identifier, a scope of the client, and a record in which an expiration date is associated. Details of processing of the access token management table of Table 7 will be described later.

<Authorization Sequence of This Embodiment>
Here, a sequence representing an authorization flow according to the present embodiment for using a resource service using a web browser on the portable terminal 201 will be described with reference to FIG. FIG. 5 is an authorization flow obtained by adding an extension unique to the present embodiment to the Implicit Grant flow of the OAuth 2.0 specification.

First, the user 100 tries to access the resource server 600 for resource usage start via the web browser 300 (S5.1).
The resource server 600 receives the access token request from the user 100 in S5.1, and distributes the client 230 executed on the web browser to the user 100 via the web browser 300 (S5.2).
The client 230 executed by the web browser 300 transmits an authorization request to the authentication / authorization server 400 via the web browser 300 (S5.3). The authorization request includes the client identifier, the scope of the authority to request, and the redirect URI (S5.3). Here, the redirect URI means a URI for the authentication / authorization server 400 to return the web browser 300 to the web-hosted client resource 500.
The authentication server module 410 of the authentication / authorization server 400 receives the authorization request from the client 230 (S5.4).

When the authentication server module 410 of the authentication / authorization server 400 receives the authorization request in S5.4, if the user is unauthenticated, it performs S5.5, S5.6, and S5.7 described later.
The authentication server module 410 of the authentication / authorization server 400 sends a script (not shown) for displaying a user authentication screen (S5.5). A specific example of the user authentication screen may be a screen prompting the user to enter a user identifier and a password (S5.5).
The user 100 performs an authentication operation on the user authentication screen displayed in S5.5 for the user identifier and password (S5.6)
The authentication server module 410 of the authentication / authorization server 400 determines whether the user identifier and password received in S5.6 match the combination of the user identifier and password in the user management table shown in Table 4 (S5.7) . If it is determined in S5.7 that the combination of the matching user identifier and password is registered in the user management table, the process proceeds to the next sequence.

The client verification unit 430 of the authentication / authorization server 400 determines whether the client identifier and the redirect URI received from the client 230 in S5.3 match the combination of the client identifier and the redirect URI in the client management table shown in Table 5. (S5.8). When the combination of the matching client identifier and the redirect URI is registered in the client management table in S5.8, the process proceeds to the next sequence.
The authority limiting unit 440 of the authentication / authorization server 400 determines whether or not the redirect URI included in the authorization request received from the client 230 in S5.3 is included in the redirect URI scope tying management table shown in Table 6. (S5.9). When it is included, the authority limiting unit 440 corresponds to the scope of the requesting authority included in the authorization request received from the client 230 in S5.3 in the redirect URI scope tying management table shown in Table 6. Filter by client scope linked to redirect URI (S5.9). That is, the scope included in the authorization request rejects the request and the part of the redirect URI scope tying management table shown in Table 6 other than the client scope linked to the corresponding redirect URI. Furthermore, in other words, it is possible to deny authority only to the common part between the requested scope and the scope set in advance for the redirect URI specified by the request. In addition, in order to prevent unauthorized access from reaching the resource server that is an open redirector, the scope registered in the redirect URI scope tying management table limits the access authority to the resource server that is an open redirector. Is desirable.

If there is one or more scopes narrowed down in S5.9, the authorization confirmation unit 460 of the authentication / authorization server 400 transmits a script for displaying the authorization confirmation screen to the Web browser 300 (S5.10). ). Specific examples of the authorization confirmation screen include a screen displaying a content asking whether the user is permitted or denied to transfer the user's authority to the client, and a screen prompting the user to input a button.
The user 100 performs the authorization operation on the authorization confirmation screen displayed in S5.10 (S5.11). The authorization confirmation unit 460 of the authentication / authorization server 400 receives that the user 100 performs the authorization operation in S5.11 (S5.11). If an authorization operation is received, it proceeds to the next sequence.
The token issuing unit 470 of the authentication / authorization server 400 issues an access token in response to the reception of the authorization operation (S5.12). Specifically, in the access token management table shown in Table 7, the access token identifier of the issued access token, the client identifier that is the request source of the access token, the user identifier that has authorized the transfer of the authority, and the issued access The client scope which is the scope of the authority granted to the token and the record of the expiration date of the issued access token are added (S5.12).
The token issuing unit 470 of the authentication / authorization server 400 transmits an access token response for redirecting the web browser 300 to the web browser 300 (S5.13). In the access token response, a redirect URI is specified in which the access token identifier issued by the token issuing unit 470 is added as a fragment to the redirect URI determined in S5.8 when it matches the redirect URI included in the authorization request. .

The web browser 300 extracts fragment information from the redirect URI and holds it locally (S5.14).
The web browser 300 transmits a redirect URI request with the fragment removed to the Web-Hosted client resource 500 to the designated redirect URI according to the redirect instruction (S5.15).

When the Web-Hosted client resource 500 receives the request, it returns a Web page (usually, an HTML document containing embedded script), that is, an access token acquisition script response to the Web browser (S5.16).
In the web page, at S5.14, the complete redirect URI including the fragment held by the web browser 300 is accessed, and the access token identifier (and other parameters) included in the fragment are extracted (S5. 17).
The web browser 300 transmits the access token identifier to the client 230 (S5.18).
The client 230 sends a resource request to the resource server 600 for access to a resource located on a server protected using the access token issued by the token issuing unit 470 of the authentication / authorization server 400. (S5.19). The resource request contains an access token identifier (S5.19).
Based on the access token identifier received from the client 230, the token authority confirmation unit 620 of the resource server 600 determines whether to permit access to the resource requested by the resource request. The token authority confirmation unit 620 of the resource server 600 transmits a verification request to the authentication / authorization server 400 for the determination (S5.20). The verification request includes the received access token identifier and the scope of the authority necessary to use the resource in the resource server 600.
The token verification unit 480 of the authentication / authorization server 400 having received the verification request refers to the access token management table of Table 7 to verify the access token. The token verification unit 480 confirms that the access token received together with the verification request has not expired. Furthermore, the token verification unit 480 has the scope of the authority for using the resource in the resource server 600 linked to the access token identifier received from the resource server 600 in S5.20 within the scope of the client scope shown in Table 7. (S5.21).
If there is no problem in the verification result, that is, if the access token is valid and the scope associated with the access token is within the scope of the permitted scope, the token verification unit 480 of the authentication / authorization server 400 performs verification. The success is returned to the resource server 600 (S5.22).
The resource request processing unit 630 of the resource server 600 responds the resource to the client 230 (S5.23).
The above is the approval flow according to the form of the present embodiment.

<Procedure of Access Token Issue by Authentication Authorization Server>
Here, the flow until issuing an access token in the authentication / authorization server 400, which is a feature of the present embodiment, will be described in detail with reference to FIGS. 6a and 6b. Next, narrowing down of the authority associated with the access token will be described for the client 230 described above.

When the authentication server module 410 receives an authorization request from the client 230 in S601 of FIG. 6a, the processing proceeds to S602.
In S602 of FIG. 6A, the authentication server module 410 determines whether or not the user has been authenticated, and proceeds to S604 if the user has been authenticated, and proceeds to S603 if the user has not been authenticated. The user authentication process of S603 will be described later with reference to FIG. 6b.
In S604 of FIG. 6A, the client verification unit 430 extracts the client identifier and the redirect URI included in the authorization request received in S601, and stores the client identifier and the redirect URI locally in the authentication / authorization server 400. Thereafter, the process proceeds to step S605.
In S605 of FIG. 6A, the client verification unit 430 determines whether or not the combination of the client identifier and the redirect URI that matches the client identifier and the redirect URI stored in S604 is in the client management table shown in Table 5. . If the client verification unit 430 determines that they match as a result of the determination, the process advances to step S606. If they do not match, the process advances to step S690.
In S606 of FIG. 6A, the authority limiting unit 440 extracts the scope of the authority requested by the client, which is included in the authorization request received in S601, and stores the scope locally in the authentication / authorization server 400. Thereafter, the process advances to step S607.
In S607 of FIG. 6A, the authority limiting unit 440 confirms whether the redirect URI stored in S604 is included in the redirect URI scope tying management table shown in Table 6. If it is included, the authority limiting unit 440 proceeds to S608. If not included, the process proceeds to S690.
In S608 of FIG. 6A, the authority limiting unit 440 narrows down the scope of the authority requested by the client stored in S606 with the client scope linked to the redirect URI in the redirect URI scope tying management table shown in Table 6. In addition, although it expressed as narrowing down here, when including the client scope other than the client scope linked to the redirect URI of the redirect URI scope tying management table shown in Table 6, about the part out of scope linked to the redirect URI May refuse. Thereafter, the process advances to step S609.
In S609 of FIG. 6A, the authority limiting unit 440 proceeds to S610 if one or more scopes remain as a result of narrowing down in S608. On the other hand, if there is no scope that has been narrowed down, the process proceeds to S690.
In S690 of FIG. 6A, the authority limiting unit 440 notifies the client 230 of an error and ends.
In S610 of FIG. 6A, the authorization confirmation unit 460 displays an authorization confirmation screen to urge the user to perform an authorization operation. Thereafter, the process proceeds to step S611. The user inputs approval or permission or denial on the approval confirmation screen.
If the authorization confirmation unit 460 receives that the user has authorized the requested authority transfer in S611 of FIG. 6A, the processing proceeds to S612. If the user receives the rejection of the requested authority transfer, the process advances to step S691.
At S612 in FIG. 6a, the token issuing unit 470 issues an access token. In the present embodiment, as shown in the access token management table of Table 7, the token issuing unit 470 adds the access token identifier, the client identifier, the user identifier, the client scope, and the record of the expiration date. After that, it advances to S613.
At S613 in FIG. 6A, the token issuing unit 470 writes the access token identifier in the fragment and returns it to the client 230. After that, it ends.
In S691 of FIG. 6A, the token issuing unit 470 notifies the client 230 of authorization failure and ends.

Here, the processing flow of the user authentication processing of S603 will be described using FIG. 6b.
At S620 of FIG. 6b, the authentication server module 410 displays a user authentication screen to allow the user to perform user authentication.
After receiving the authentication information input by the user in S621 of FIG. 6B, the authentication server module 410 proceeds to S622.
In S622 of FIG. 6 b, the authentication server module 410 verifies the user identifier and password received in S621. Therefore, in S622, the authentication server module 410 determines whether the user identifier and password received in S621 match the combination of the user identifier and password in the user management table shown in Table 4. If it is determined that the authentication server module 410 matches as a result of the verification, the processing proceeds to step S623. If they do not match, the process advances to step S692.
In S623 of FIG. 6B, the authentication server module 410 adds a record to an authentication token management table (not shown).
At S692 of FIG. 6B, the authentication server module 410 notifies the client 230 of a login error, and ends the process.

<Specific example of processing>
Next, the process will be described in detail by taking a specific example along the process flow. Here, it is assumed that the user authenticates the user with the user identifier uid00001 and the password LigajD12f3KLG, and the user receives the client 230 from the resource server 600. Also, let us say that the identifier of the client 230 is client 230.
At S601, the authentication server module 410 receives an authorization request from the client 230, and proceeds to S602.
At S602, the authentication server module 410 proceeds to S604 because user authentication has been completed.
In S604, the client verification unit 430 stores the client identifier and the redirect URI included in the authorization request received in S601 locally in the authentication / authorization server 400. In the present embodiment, the client verification unit 430 stores the client 230 as the client identifier and https://xxx.example.com as the redirect URI locally on the authentication / authorization server 400, and proceeds to S605.
In step S605, the client verification unit 430 proceeds to step S606 because the client identifier and redirect URI extracted in step S604 match the combination of the client identifier and redirect URI in the client management table shown in Table 5.
In S606, the authority limiting unit 440 extracts the scope of the authority requested by the client included in the authorization request received in S601, and stores the scope locally in the authentication / authorization server 400. In the present embodiment, the authority limiting unit 440 stores scope A, scope B, scope C, and scope D, and proceeds to S607.
In S607, the authority limiting unit 440 confirms whether the redirect URI extracted in S604 is included in the redirect URI scope tying management table shown in Table 6. In the present embodiment, since https://xxx.example.com is a matching redirect URI, the process advances to step S608.
In S608, the authority limiting unit 440 narrows down the scope of the authority to be requested by the client scope linked to the redirect URI in the redirect URI scope tying management table shown in Table 6. The authority requested by the client 230 is scopeA, scopeB, scopeC, and scopeD, whereas scopeA is stored in the client scope in the redirect URI scope tying management table of Table 6. The scope of the authority requested by the client 230 is narrowed down to scope A by the authority limiting unit 440. Thereafter, the process advances to step S609.
In step S609, the authority limiting unit 440 advances the process to step S610 because the scope A remains as a result of narrowing down in step S608.
In S610, the authorization confirmation unit 460 displays an authorization confirmation screen, and the user performs an authorization operation. Thereafter, the process proceeds to step S611.
In step S611, the authorization confirmation unit 460 proceeds to step S612 because it has received that the user has authorized the requested authority transfer.
At S612, token issuing unit 470 issues an access token. As shown in Table 7, a record is added with the access token identifier AT_000001, the client identifier client230, the user identifier uid00001, the client scope scopeA, and the expiration date 2016/11/14/12: 00.00. After that, it advances to S613.
In S613, the token issuing unit 470 describes the access token identifier in the fragment and returns it to the client 230. At this time, the redirect URI issued from the token issuing unit 470 describes the identifier of the access token in the fragment, and becomes https://xxx.example.com/#token_id=AT_000001.

  The above is the details of the first embodiment. With the above configuration, the authentication / authorization server can realize narrowing of the authority associated with the access token to be issued. By this, even if the access token in the Implicit Grant flow is temporarily leaked, the range of unauthorized access by the attacker can be limited to the range of authority linked to the redirect destination. Thereby, even if there is unauthorized access, the expansion can be suppressed.

Second Embodiment
In the first embodiment, although the client's authority can be narrowed according to the redirect URI, the user's authority is not narrowed by the authentication / authorization server. Therefore, in the first embodiment, when the access token is leaked, there is a problem that the authority of the user who is not narrowed down is leaked. The first object of the second embodiment is to narrow down the user's authority. If this narrowing down is performed when the access token is issued, the authority of the user to be transferred displayed on the authorization confirmation screen is different from the authority of the user actually linked to the access token, and the user misrecognizes, and the usability decreases. A problem arises. The second object of the second embodiment is to prevent such erroneous recognition by listing the scopes actually associated with the access token when the authorization confirmation screen is displayed.
In this embodiment, the client authority is added to the process of narrowing down according to the redirect URI, the user right is narrowed down according to the redirect URI, and the narrowed down user's right is displayed on the authorization confirmation screen. Improve. Here, the user authority is, for example, an authority given to software executed on the mobile terminal 201, and is distinguished from a client authority given to a human user. As described above, in the present embodiment, the requested scope is further limited for each of a plurality of types of authority.

  Next, a second embodiment will be described using the drawings. The description of the parts common to the first embodiment will be omitted, and only the differences will be described below. The present embodiment is realized on the network configured as shown in FIG. 2, and the user holds the portable terminal 201, and the user holds the scopes scope K, scope L, and scope M of all rights to all resource servers. I assume. At this time, the client 230 requests the authentication / authorization server 400 from the client's authority scopeA, scopeB, scopeC, as well as the user's authority scopeK, scopeL, scopeM. The redirect URI scope tying management table shown in Table 6 is expanded in order to narrow down the authority of the user, which is a feature of the present embodiment, by the redirect URI. Specifically, in the redirect URI scope tying management table of Table 6, when executing the Implicit Grant flow via the redirect URI, a scope indicating the scope of the authority granted to the user (hereinafter, owner scope and Add and extend). The extended redirect URI scope tying management table which expanded in Table 8 is shown. Furthermore, the access token management table shown in Table 7 also extends the owner scope similarly to Table 8. Table 9 shows the expanded access token management table.

  Tables 8 and 9 are data tables stored in the external memory by the authentication / authorization server 400. These data tables may be configured to be stored not on the external memory of the authentication / authorization server 400 but on another server configured to be communicable via the LAN 701.

Table 8 is an extended redirect URI scope tying management table used by the authority limiting unit 440. An owner scope is given by scopeK for the redirect URI https://xxx.example.com. An owner scope is given by scopeL for https://yyy.example.com as the redirect URI. An owner scope is given by scopeM for https://zzz.example.com as the redirect URI. Details of processing of the extended redirect URI scope tying management table shown in Table 8 will be described later.

Table 9 is an extended access token management table generated by the token issuing unit 470. The extended access token management table of Table 9 comprises a token identifier, a client identifier, a user identifier, a client scope, an owner scope, and an expiration date.

  Here, the narrowing down of the authority and the authorization confirmation screen according to the first embodiment will be described. It is assumed that there is a user who is going to use the resource server 600. Here, it is assumed that use of the resource server 600 requires scopeA as the client authority and scopeK as the owner authority. At this time, it is assumed that the client 230 requests more scopes scope A, scope B, scope C, scope K, scope L, and scope M as described above. When receiving the authorization request, the authentication / authorization server 400 narrows down the scope of the authority requested by the client 230 using the redirect URI. As a result of the narrowing, the scope of the client is narrowed to scopeA. On the other hand, the owner's scope is still scopeK, scopeL, scopeM. Thus, when the first embodiment is applied as it is, the owner scope which is the authority of the user is not narrowed down. In light of security, it is necessary to narrow down the owner scope to be associated with the access token issued in order to minimize the damage from the attacker when the access token is leaked. In addition, if the owner scope linked to the access token to be issued is narrowed down to scopeK, the authorization confirmation screen for asking the user to transfer the authority should display scopeK which is the result of narrowing down the owner scope to which the authority is transferred in advance. .

Next, a flow of issuing an access token in the authentication / authorization server 400 according to the second embodiment will be described with reference to FIG. The details of this flow will be described first, and then a method of narrowing down the user's authority will be described. This flow is started by receiving an authorization request from a client.
Since S601 to S609 in FIG. 7 have been described in the first embodiment, the description is omitted.
In S2001 of FIG. 7, the authority limiting unit 440 extracts the owner scope which is the authority of the user requested by the client, which is included in the authorization request received in S601, and stores it in the authentication / authorization server 400 locally. After that, it advances to S2002.
In S2002 in FIG. 7, the authority limiting unit 440 narrows down the owner scope which is the authority of the user stored in S2001 by the owner scope linked to the redirect URI in the extended redirect URI scope tying management table shown in Table 8. . After that, it advances to S2003. Here, although it is expressed as narrowing down, the configuration may be such that it rejects cases including those other than the owner scope linked to the redirect URI of the extended redirect URI scope linking management table shown in Table 8.
As a result of narrowing down in S2002 in S2003 in FIG. 7, if the authority of the remaining user is one or more owner scopes as a result of narrowing down in S2002, the process proceeds to S2004. On the other hand, if there is no scope that has been narrowed down, the process proceeds to S690.
In S2004 of FIG. 7, the authorization confirmation unit 460 displays an authorization confirmation screen with an owner scope that is the authority of the narrowed user, and urges the user to perform the authorization operation. Thereafter, the process proceeds to step S611. Details of the authorization confirmation screen will be described later.
Since S611 to S613, S690, and S691 of FIG. 7 have already been described in the first embodiment, they are omitted.

Next, the details of the owner scope and the authorization confirmation screen, which are the authority of the user, will be described along the above-mentioned processing flow.
Although S601 to S609 are omitted because they have been described in the first embodiment, the scope of the authority requested by the client 230 is narrowed down to, for example, scopeA.
In S2001, the authority limiting unit 440 takes out from the owner scope which is the authority of the user requested by the client included in the authorization request received in S601, and stores it locally in the authentication / authorization server 400. In the present embodiment, scope K, scope L, and scope M are extracted. After that, it advances to S2002.
In S2002, the authority limiting unit 440 narrows down the owner scope, which is the user's authority stored in S2001, with the owner scope linked to the redirect URI in the extended redirect URI scope tying management table shown in Table 8. The owner scope which is the authority of the user requested by the client 230 is scope K, scope L, and scope M, whereas the owner scope in the extended redirect URI scope tying management table of Table 8 stores scope K . The owner scope which is the authority of the user requested by the client 230 is narrowed down to scope K by the authority limiting unit 440. After that, it advances to S2003.
In S2003, the authority limiting unit 440 advances the process to S2004 because the scope K remains as a result of narrowing down in S2003.
In S2004, the authorization confirmation unit 460 displays the scope K, which is the owner scope that is the authority of the narrowed user, on the authorization confirmation screen, and urges the user to perform the authorization operation. An example of the authorization confirmation screen in the present embodiment is shown in FIG. In FIG. 8, the user is presented with the scope of the narrowed user authority, and the user is prompted to enter permission or denial.
In S611, the token issuing unit 470 issues an access token. As shown in Table 9, a record is added with access token identifier AT_000001, client identifier client230, user identifier uid00001, client scope scopeA, owner scope scopeK, expiration date 2016/11/14/12: 00.00 Ru.

  The above is the details of the second embodiment. With the above configuration, the authentication / authorization server can realize narrowing of the authority associated with the issued access token to the authority of the user. Furthermore, the authentication / authorization server can improve usability because it can also list the scopes that are actually associated with the access token on the authorization confirmation screen. Also, not only the user authority but also other kinds of authority such as client authority may be presented to the authorizer as well.

[Other embodiments]
The present invention supplies a program that implements one or more functions of the above-described embodiments to a system or apparatus via a network or storage medium, and one or more processors in a computer of the system or apparatus read and execute the program. Can also be realized. It can also be implemented by a circuit (eg, an ASIC) that implements one or more functions.

100 Users, 230 Client PCs, 300 Web Browsers, 400 Authentication / Authorization Servers, 500 Web-Hosted Client Resources, 600 Resource Servers

Claims (7)

Receiving means for receiving from the client an access token request together with the client's redirect URI and the requested client's authority;
Authority restriction means for restricting the requested authority by the authority information linked to the redirect URI;
And a issuing means for issuing an access token of the right limited by the right limiting means. The authentication and authorization server according to claim 1, wherein
It further has a table linking redirect URI and authority information,
The authentication and authorization server, wherein the authority limiting unit is configured to limit the requested authority with the authority information associated with the redirect URI received with the access token request in the table. The authentication and authorization server according to claim 1 or 2,
The authentication and authorization server according to claim 1, wherein the authority limiting unit further restricts the authority of the user requested by the access token request with the authority information linked to the redirect URI. The authentication and authorization server according to claim 3, wherein
It further has a means for presenting the user limited by the right limiting means to the user and receiving an input of approval or rejection by the user,
The authentication and authorization server, wherein the issuing unit issues an access token of the authority limited by the authority limiting unit when the user inputs an authorization. An authentication and authorization system comprising a client, a resource server for providing resources, and an authentication and authorization server, comprising:
The authentication and authorization server is
Receiving means for receiving, from the client, an access token request together with the client's redirect URI and the requested client's authority;
Authority restriction means for restricting the requested authority by the authority information linked to the redirect URI;
And issuing means for issuing an access token of the right limited by the right limiting means,
The authentication and authorization system, wherein the resource server verifies the access token received from the client together with a request for a resource, and provides the requested resource to the client if the verification is successful. Receiving means for receiving from the client an access token request together with the client's redirect URI and the requested client's authority;
Authority restriction means for restricting the requested authority by the authority information linked to the redirect URI;
A program for causing a computer to function as issuing means for issuing an access token of a right limited by the right limitation means. An authentication method by an authentication and authorization system including a client, a resource server for providing resources, and an authentication and authorization server,
The authentication and authorization server
Receiving from the client an access token request along with the client's redirect URI and the requested client's authority;
Restricting the requested authority with the authority information linked to the redirect URI,
Issue an access token of the said limited authority,
The authentication method, wherein the resource server verifies the access token received from the client together with a request for a resource, and provides the requested resource to the client if the verification is successful.

Images