Personal authentication system and personal authentication method

Abstract

To provide a pan-personal authentication system and method for specifying and cooperating with personal data of another relying party application by a base ID for securing the identity of a user even across relying party applications.SOLUTION: The pan-personal authentication system includes a request token generation unit that generates a request token in response to a request from a client terminal of a user who uses the relying party applications 10 and 11 and transmits the request token to the client terminal, a cooperation token generation unit that makes an authentication request to an ID provider and acquires an ID token on the pan-personal authentication system side and generates a cooperation token based on the ID token, an information transmission / reception unit that transmits the cooperation token to the relying party application, and a cooperation information transmission / reception unit that transmits a base ID that can identify the user across the relying party applications and a link ID that specifies cooperation between the user and the relying party application based on the cooperation token transmitted from the pan-personal authentication system.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The present invention relates to a universal individual authentication system and a universal individual authentication method. [Background technology]

[0002] Conventionally, in order to receive a predetermined service in a smartphone or personal computer application, an account corresponding to the predetermined service is required. For example, an ID (identification) and password for logging in to the account corresponding to the predetermined service are entered, and once authentication is successful, the corresponding predetermined service can be received.

[0003] As an example of a general user authentication system, a user authentication system that "guarantees confirmation of identity without changing the format of the existing authentication system" has been disclosed (for example, Patent Document 1).

[0004] The abstract of Patent Document 1 discloses that "the terminal logs in by sending a public key certificate and a private key to the intermediate authentication server, and sends a service usage request to the service site. When the service site receives the service usage request from the terminal, it sends a redirect to the OpenID authentication server for authentication mediation. When the OpenID authentication server receives the redirect from the service site for authentication mediation, it requests the terminal to enter an ID and password, notifies the intermediate authentication server of the user's handle, and sends an authentication request. In response to the authentication request from the OpenID authentication server, the intermediate authentication server performs authentication by checking the user's login status. The OpenID authentication server receives the authentication result from the intermediate authentication server and sends it to the service site. When the service site receives the authentication result from the OpenID authentication server indicating that authentication was successful, it provides the service to the user's mobile terminal" (see Patent Document 1). [Prior art documents] [Patent documents]

[0005] [Patent Document 1] Japanese Patent Application Laid-Open No. 2009-282561 Summary of the Invention [Problem to be solved by the invention]

[0006] In conventional authentication methods, by performing OpenID authentication, a relying party (the service site of Patent Document 1) can provide services to a terminal or the like.

[0007] However, conventional authentication methods such as the user authentication system of Patent Document 1 can perform authentication by an external authentication server for each relying party app, but depending on the ID provider, different user identifiers are returned to the relying party app, making it impossible to guarantee the identity of the user across relying parties that provide services.

[0008] The present invention has been made in consideration of the above circumstances, and aims to solve the problem that the identity of a user cannot be guaranteed across relying parties. [Means for solving the problem]

[0009] The pan-personal authentication system of the present invention comprises a request token generation unit that requests the pan-personal authentication system to issue a linked token in response to a request from a client terminal of a user who uses a relying party app, generates a request token, and sends it to the client terminal; a linked token generation unit that makes an authentication request to an ID provider and obtains an ID token on the pan-personal authentication system side, and generates a linked token based on the ID token; an information transmission / reception unit that sends the linked token to the relying party app; and a link information transmission / reception unit that transmits, based on the linked token sent from the pan-personal authentication system, a base ID that can uniquely identify a user even across relying parties, and a link ID that identifies the link between the user and the relying party. [Effects of the Invention]

[0010] According to the present invention, personal data of other relying party apps can be identified and linked using a base ID that ensures user identity even across relying parties. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a block diagram showing an outline of a universal personal authentication system according to an embodiment of the present invention; [Figure 2] 1 is a block diagram illustrating an information linkage system according to an embodiment of the present invention. [Figure 3A] FIG. 2 is a block diagram showing the hardware configuration of a client terminal. [Figure 3B] FIG. 2 is a functional block diagram showing functions of a client terminal. [Figure 3C] FIG. 2 is a functional block diagram showing the functions of a browser implemented on a client terminal. [Figure 4A] FIG. 2 is a block diagram showing the hardware configuration of a front-end server. [Figure 4B] FIG. 2 is a functional block diagram showing functions of a front-end server. [Figure 5A] FIG. 2 is a block diagram showing the hardware configuration of a back-end server. [Figure 5B] FIG. 2 is a functional block diagram showing functions of a back-end server. [Figure 6A] FIG. 2 is a block diagram showing the hardware configuration of an ID provider. [Figure 6B] FIG. 2 is a functional block diagram illustrating functions of an ID provider. [Figure 7A] FIG. 2 is a block diagram showing the hardware configuration of an association API server. [Figure 7B] FIG. 2 is a functional block diagram showing the functions of an association API server. [Figure 8A] FIG. 1 is a sequence diagram showing the operation of the information linkage system according to the present embodiment (part 1). [Figure 8B] FIG. 2 is a sequence diagram showing the operation of the information linkage system according to the present embodiment (part 2). [Figure 8C] FIG. 3 is a sequence diagram showing the operation of the information linkage system according to the present embodiment (part 3). [Figure 8D] FIG. 4 is a sequence diagram showing the operation of the information linkage system according to the present embodiment (part 4). [Figure 9A] FIG. 1 is an explanatory diagram showing a conventional technique as a comparative example. [Figure 9B] FIG. 10 is an explanatory diagram showing how the problem in the comparative example is solved. [Figure 10] FIG. 10 is an explanatory diagram showing an example of claim information of an ID token issued by an ID provider that complies with the OIDC standard. DETAILED DESCRIPTION OF THE INVENTION

[0012] Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In the description of the drawings, the same elements are given the same reference numerals, and redundant description will be omitted as appropriate.

[0013] <Comparative Example> FIG. 9A is an explanatory diagram showing a conventional technique as a comparative example to explain this embodiment. FIG. 9A illustrates relying party applications 10P and 11P and ID providers 400P1 and 400P2 of different client terminals. Each relying party application 10P and 11P complies with the OIDC (OpenID Connect) standard. The ID providers 400P1 and 400P2 are configured by external authentication servers.

[0014] Each relying party app 10P, 11P provides a corresponding service to the user by performing authentication with the corresponding ID provider 400P1, 400P2, respectively. For example, when relying party app 10P requests authentication from ID provider 400P1, the ID provider 400P1 returns user identifier #1 to relying party app 10P. On the other hand, when relying party app 11P requests authentication from ID provider 400P2, the ID provider 400P2 returns user identifier #2 to relying party app 11P.

[0015] In this case, each of the relying party applications 10P and 11P can provide the corresponding service to the user, so that the same user having different client terminals can receive the corresponding service for each client terminal.

[0016] However, since ID providers 400P1 and 400P2 return different user identifiers #1 and #2 for each relying party application 10P and 11P, each relying party application 10P and 11P cannot determine whether target users having different client terminals are the same user.

[0017] Fig. 9B is an explanatory diagram showing a solution to the problem of the comparative example of Fig. 9A. Fig. 9B is provided with a new general-purpose personal authentication system 600, which identifies a person who is the same user for relying party applications 10 and 11.

[0018] 9B, when pan-personal authentication system 600 receives an authentication request from relying party app 10, it makes an authentication request to ID provider 400. When ID provider 400 performs authentication, it returns user identifier #3 to pan-personal authentication system 600. When ID provider 400 authenticates the user and returns user identifier #3, pan-personal authentication system 600 uses user identifier #3 as a base ID that uniquely identifies the user related to relying party app 10.

[0019] When the all-personal authentication system 600 receives an authentication request from the relying party application 11, it makes an authentication request to the ID provider 400. When the ID provider 400 performs the authentication, it returns the user identifier #3 to the all-personal authentication system 600. When the ID provider 400 authenticates the user and returns the user identifier #3, the all-personal authentication system 600 uses the user identifier #3 as a base ID that uniquely identifies the user related to the relying party application 11.

[0020] As a result, in the general-personal authentication system 600, by managing a base ID that uniquely identifies a user and a link ID that specifies the connection between the user and relying party apps 10 and 11, it is possible to ensure the identity of the user of relying party app 10 and the user of relying party app 11.

[0021] Therefore, the general personal authentication system 600 can identify and link personal data of other relying party applications 11 using the base ID that ensures the identity of the user even across relying party applications 10.

[0022] Note that a relying party refers to a scheme (framework) that uses certificates. For example, it refers to a service in which personal information is transferred between services operated by completely different business entities based on the individual's permission. Furthermore, relying party applications 10 and 11 refer to, for example, functional units that are realized by executing an application program that provides a service to a user. Relying party applications 10 and 11 provide services to users by accessing the servers of each relying party via the Internet.

[0023] Specifically, a relying party app may include a healthcare service provided by Company A. The relying party app may also include a local currency application that can be used in a specific region. In this case, each relying party app can receive the corresponding specific service by linking data between the healthcare service and the local currency application.

[0024] Similarly, the Relying Party app includes a local currency application provided by Company B and a childcare service provided in a specific area. In this case, just like the healthcare service, the Relying Party app can receive the corresponding specific service by linking data between the local currency application and the childcare service.

[0025] 10 is an explanatory diagram showing an example of claim information of an ID token 402 issued by an ID provider that complies with the OIDC standard. This ID token 402 is obtained from a specific ID provider using an ID that complies with the OIDC standard.

[0026] As shown in Fig. 10, this ID token 402 contains an audience registration claim aud that identifies the recipient of the ID token 402, email that indicates the user's email address, iat that indicates the issuance time of the ID token 402, exp that indicates the expiration date of the ID token 402, and the value of sub that is a subject registration claim. The subject registration claim identifies the principal that is the subject of the ID token 402. Because this token is for an application, the value of the subject registration claim sub is a unique identifier for the user. The values ​​of this subject registration claim sub correspond to the user identifiers #1, #2, and #3 shown in Fig. 9A.

[0027] 9A, the value of the subject registration claim "sub" is information that uniquely identifies a user for each ID provider 400P1, 400P. However, depending on the ID provider 400P1, 400P, different values ​​are returned for each relying party app 10P, 11P, so it is not possible to guarantee that the user is the same across relying party apps 10P, 11P.

[0028] Therefore, in this embodiment, a pan-personal authentication system and a pan-personal authentication method are provided that can identify and link personal data of other relying party apps using a base ID that ensures user identity even across relying party apps.

[0029] <Outline of the universal personal authentication system> FIG. 1 is a block diagram showing an outline of a universal personal authentication system 600 according to this embodiment.

[0030] 1, general-personal authentication system 600 is configured to newly include federated authentication unit 610. Federated authentication unit 610 has a function to authenticate each of relying party applications 10, 11, and a function to link each of relying party applications 10, 11.

[0031] Once federated authentication unit 610 authenticates relying party app 10, it generates a base ID that uniquely identifies the user of relying party app 10. Here, the base ID is an ID that uniquely identifies the user, who is a natural person. When the same user requests federation with different relying party apps 11, pan-personal authentication system 600 can uniquely identify the user by using the user's base ID. As a result, pan-personal authentication system 600 can feed relying party app 11 with relying party app 10 by using the user's base ID.

[0032] Note that pan-personal authentication federation request screens 21 and 22 are screens displayed on a client terminal owned by a user, and are screens on which each relying party app 10 and 11 makes a federation request to pan-personal authentication system 600. That is, pan-personal authentication system 600 receives an authentication and federation request from relying party app 10 via pan-personal authentication federation request screen 21. Also, pan-personal authentication system 600 receives an authentication and federation request from relying party app 11 via pan-personal authentication federation request screen 22.

[0033] In this embodiment, even if the user identifier (i.e., the value of the subject registration claim sub) differs for each client terminal, the all-personal authentication system 600 can acquire a base ID that uniquely identifies a user by redirecting an authentication request from each client terminal to the all-personal authentication system 600. As a result, even if the user identifier differs for each client terminal, the all-personal authentication system 600 can identify and link personal data of other relying party apps by the base ID that ensures user identity even across relying party apps 10 and 11, and provide a predetermined service corresponding to the user.

[0034] <Outline of the information sharing system> Fig. 2 is a block diagram showing an information linkage system 700 according to this embodiment. As shown in Fig. 2, the information linkage system 700 is configured to include relying party applications 10 and 11, an ID provider 400, a general-purpose personal authentication system 600, the Internet 801, and a P2P (Peer to Peer) network 802. The general-purpose personal authentication system 600 is configured to include a front-end server 200, a back-end server 300, and a linkage API server 500, which will be described later.

[0035] Note that, in the information linkage system 700 according to this embodiment, the front-end server 200, the back-end server 300, and the linkage API server 500 are used as an example for description, but this embodiment is not limited to this. That is, in the general-personal authentication system 600, the front-end server 200, the back-end server 300, and the linkage API server 500 may be realized by, for example, a single server, or two or more servers may be arbitrarily combined to realize the various functions of the general-personal authentication system 600.

[0036] The information linking system 700 includes relying party applications 10 and 11, a client terminal 100, a front-end server 200, a back-end server 300, an ID provider 400, and a linking API server 500, which constitute a cloud computing system.

[0037] The relying party applications 10 and 11 are web applications that run on a client terminal 100 owned by a user. The relying party applications 10 and 11 entrust authentication to an ID provider (Identify Provider) 400, and by trusting the authentication information provided by the ID provider 400, access the relying party and provide a service to the user.

[0038] The pan-personal authentication collaboration button 19 is a button displayed on the browser screen (for example, the pan-personal authentication collaboration request screens 21, 22, etc.) of the user's client terminal 100. When the user connects to the relying party apps 10, 11 with the client terminal 100, the pan-personal authentication collaboration button 19 is displayed on the browser screen. When the user presses the pan-personal authentication collaboration button 19 displayed on the browser screen, authentication and collaboration request processing for the pan-personal authentication system 600 is started.

[0039] The ID provider 400 is a service provider or server that stores and manages authentication information for logging in to a cloud service. The ID provider 400 has an authentication unit 401 that performs authentication between the ID provider 400 and the client terminal 100 using a challenge-response method.

[0040] The general-personal authentication system 600 is configured to include a request token generation unit 601, a federation token generation unit 602, an information transmission and reception unit 603, and a federation information transmission and reception unit 604. The request token generation unit 601, the federation token generation unit 602, the information transmission and reception unit 603, and the federation information transmission and reception unit 604 configure a federation authentication unit 610.

[0041] In response to a request from the client terminal 100 of a user who uses the relying party applications 10 and 11, the request token generation unit 601 makes a linkage token issuance request to the general personal authentication system 600, generates a request token, and transmits it to the client terminal 100.

[0042] Here, the general-personal authentication federation request screens 21 and 22 are displayed on the client terminal 100. That is, the general-personal authentication federation request screens 21 and 22 constitute a browser screen for a federation request by displaying the federation request screen information, which is html data transmitted from the general-personal authentication system 600, on the display unit 115 of the client terminal 100.

[0043] The linkage token generation unit 602 makes an authentication request to the ID provider 400 and acquires an ID token on the general-personal authentication system 600 side, and generates a linkage token based on the ID token.

[0044] The information transmitting / receiving unit 603 transmits the link token generated in the general-personal authentication system 600 to the relying party applications 10 and 11 of the client terminal 100 via the Internet 801 .

[0045] Based on the link token transmitted from pan-personal authentication system 600, link information transmitting / receiving unit 604 transmits a base ID that can uniquely identify the user even across relying party apps 10 and 11, and a link ID that specifies the link between the user and the relying party app. Here, the link ID is an ID that uniquely specifies the link between the user and the relying party. Therefore, the link ID makes it possible to know which relying party the user is linked to.

[0046] The Internet 801 refers to a network that connects computers together and enables the exchange of information.

[0047] The P2P network 802 is, for example, a service provided in a foreign country and is a highly confidential tool built using electronic solutions. In other words, the P2P network 802 corresponds to a highly secure network. The P2P network 802 is configured with, for example, a center server, a security server, an information system, a timestamp authority, a certification authority, a configuration proxy, an operation monitoring daemon, and the like, all of which are not shown.

[0048] Furthermore, the general-personal authentication system 600 is configured to include a front-end server 200, a back-end server 300, and an association API server 500. By including the front-end server 200, the back-end server 300, and the association API server 500, the general-personal authentication system 600 embodies a request token generation unit 601, an association token generation unit 602, an information transmission / reception unit 603, and an association information transmission / reception unit 604.

[0049] The front-end server 200, the back-end server 300, and the linked API server 500 that constitute the general-purpose personal authentication system 600 will be described below with reference to FIGS. 3A to 7B.

[0050] <Client terminal configuration> Fig. 3A is a block diagram showing the hardware configuration of the client terminal 100. As shown in Fig. 3A, the client terminal 100 is configured to include a CPU (Central Processing Unit) 110, a ROM (Read Only Memory) 111, a RAM (Random Access Memory) 112, a storage unit 113, an input unit 114, a display unit 115, and a communication unit 116.

[0051] The client terminal 100 is configured by, for example, a smartphone, a notebook computer, a desktop computer, a tablet terminal, or the like.

[0052] The CPU 110 performs overall control of the client terminal 100. The CPU 110 reads out various programs, such as system programs and processing programs, stored in the ROM 111 or the storage unit 113, loads them into the RAM 112, and executes the loaded programs. In this way, the CPU 110 embodies functions for executing each process of the client terminal 100. Details of the functions of the client terminal 100 will be described with reference to FIG. 3B.

[0053] The RAM 112 functions as a work area for temporarily storing various programs, input or output data, parameters, etc. that are read from the ROM 111 or the storage unit 113 and can be executed by the CPU 110 during various processes executed and controlled by the CPU 110.

[0054] The storage unit 113 is configured by, for example, a hard disk drive (HDD) or a semiconductor nonvolatile memory.

[0055] The input unit 114 is configured to include a keyboard having cursor keys, numeric input keys, various function keys, etc., and a pointing device such as a mouse. The input unit 114 outputs press signals of keys pressed on the keyboard and operation signals from the mouse as input signals to the CPU 110. The CPU 110 executes various processes based on the operation signals from the input unit 114.

[0056] The display unit 115 is configured to include a display such as a CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display), etc. The display unit 115 displays various screens in accordance with instructions of a display signal input from the CPU 110.

[0057] The communication unit 116 includes a communication interface, and communicates with the front-end server 200, the back-end server 300, and the linked API server 500 via, for example, the Internet 801 or a P2P network 802, to send and receive data.

[0058] Fig. 3B is a functional block diagram showing the functions of client terminal 100. Fig. 3B illustrates a case where relying party app 10 is embodied in client terminal 100. Fig. 3C illustrates a case where relying party app 10 is embodied by browser 101.

[0059] Client terminal 100 embodies a relying party app 10 and a browser 101. Relying party app 10 includes a collaboration request receiving unit 1, a data generation receiving unit 2, a calculation unit 3, an API request unit 4, an information acquisition unit 5, and an API server connection unit 6. Browser 101 includes an authentication request unit 120 and an issuance request unit 130.

[0060] The federation request receiving unit 1 receives a federation request when the user presses a general-personal authentication federation button 19 displayed on the general-personal authentication federation request screens 21 and 22.

[0061] When the federation request receiving unit 1 receives a press of the pan-personal authentication federation button 19, the data generation receiving unit 2 generates a state. The data generation receiving unit 2 stores the generated state in the storage unit 113. After generating the state, the data generation receiving unit 2 generates a code verification (code verifier). The data generation receiving unit 2 stores the generated code verification in the storage unit 113.

[0062] The calculation unit 3 calculates a code challenge from the code verification generated by the data generation and reception unit 2.

[0063] The API request unit 4 starts a browser connected to the general-purpose personal authentication system 600 and transmits the client ID, redirect URL, status, and code challenge to the backend server 300 via the Internet 801 .

[0064] The information acquisition unit 5 acquires the linkage token, the status, and the redirect URL from the front-end server 200 via the Internet 801 .

[0065] If the state received from the front-end server 200 and the state stored in the memory unit 113 are correct, the API server connection unit 6 redirects the linkage token obtained from the front-end server 200 and the code verification stored in the memory unit 113 to the linkage API server 500 via the P2P network 802.

[0066] The authentication request unit 120 requests authentication from the authentication unit 401 of the ID provider 400 . When the issuance request unit 130 acquires an ID token from the ID provider 400, it issues a linkage token issuance call and transmits the ID token and the request token to the front-end server 200.

[0067] Fig. 3C is a functional block diagram showing the functions of browser 101. In Fig. 3C, relying party app 102 is embodied by browser 101 in the same manner as in Fig. 3B. This browser 101 is embodied by CPU 110 of client terminal 100 executing a browser program.

[0068] <Front-end server configuration> 4A is a block diagram showing the hardware configuration of the front-end server 200. As shown in FIG. 4A, the front-end server 200 is configured to include a CPU 210, a ROM 211, a RAM 212, a storage unit 213, an input unit 214, a display unit 215, and a communication unit 216.

[0069] The front-end server 200 constitutes a front-end server in the general-purpose personal authentication system 600 .

[0070] The CPU 210 performs overall control of the front-end server 200. The CPU 210 reads out various programs, such as system programs and processing programs, stored in the ROM 211 or the storage unit 213, loads them into the RAM 212, and executes the loaded programs. In this way, the CPU 210 embodies functions for executing each process of the front-end server 200. Details of the functions of the front-end server 200 will be described with reference to FIG. 4B.

[0071] The RAM 212 functions as a work area for temporarily storing various programs, input or output data, parameters, etc. that are read from the ROM 211 or the storage unit 213 and can be executed by the CPU 210 during various processes executed and controlled by the CPU 210.

[0072] The storage unit 213 is configured by, for example, a HDD or a semiconductor nonvolatile memory.

[0073] The input unit 214 is configured to include a keyboard equipped with cursor keys, numeric input keys, various function keys, etc., and a pointing device such as a mouse. The input unit 214 outputs press signals of keys pressed on the keyboard and operation signals from the mouse as input signals to the CPU 210. The CPU 210 executes various processes based on the operation signals from the input unit 214.

[0074] The display unit 215 is configured to include a display such as a CRT, LCD, etc. The display unit 215 displays various screens in accordance with instructions of a display signal input from the CPU 210.

[0075] The communication unit 216 includes a communication interface, and communicates with the client terminal 100 via the Internet 801, for example, to send and receive data.

[0076] 4B is a functional block diagram showing the functions of the front-end server 200. The front-end server 200 is configured to include an association token generation unit 602 and an information transmission / reception unit 603.

[0077] The linkage token generation unit 602 makes an authentication request to the ID provider 400 and acquires an ID token on the general-personal authentication system 600 side, and generates a linkage token based on the ID token. Note that when generating a linkage token, the linkage token generation unit 602 may cause the backend server 300 to generate (issue) the linkage token.

[0078] The information transmitting / receiving unit 603 transmits the link token generated in the general-personal authentication system 600 to the relying party applications 10 and 11 of the client terminal 100 via the Internet 801 .

[0079] <Backend server configuration> 5A is a block diagram showing the hardware configuration of backend server 300. As shown in FIG. 5A, backend server 300 is configured to include CPU 310, ROM 311, RAM 312, storage unit 313, input unit 314, display unit 315, and communication unit 316.

[0080] The back-end server 300 constitutes a back-end server in the general-purpose personal authentication system 600 .

[0081] The CPU 310 performs overall control of the backend server 300. The CPU 310 reads out various programs, such as system programs and processing programs, stored in the ROM 311 or storage unit 313, loads them into the RAM 312, and executes the loaded programs. In this way, the CPU 310 embodies functions for executing each process of the backend server 300. Details of the functions of the backend server 300 will be described using FIG. 5B.

[0082] The RAM 312 functions as a work area for temporarily storing various programs, input or output data, parameters, etc. that are read from the ROM 311 or the storage unit 313 and can be executed by the CPU 310 during various processes executed and controlled by the CPU 310.

[0083] The storage unit 313 is configured by, for example, a HDD or a semiconductor nonvolatile memory.

[0084] The input unit 314 is configured to include a keyboard equipped with cursor keys, numeric input keys, various function keys, etc., and a pointing device such as a mouse. The input unit 314 outputs press signals of keys pressed on the keyboard and operation signals from the mouse as input signals to the CPU 310. The CPU 310 executes various processes based on the operation signals from the input unit 314.

[0085] The display unit 315 is configured to include a display such as a CRT, LCD, etc. The display unit 315 displays various screens in accordance with instructions of a display signal input from the CPU 310.

[0086] The communication unit 316 includes a communication interface, and communicates with the client terminal 100 via the Internet 801, for example, to send and receive data.

[0087] 5B is a functional block diagram showing the functions of the backend server 300. The backend server 300 is configured to include a request token generation unit 601 and an association token issuance unit 301.

[0088] The request token generation unit 601, in response to a request from the client terminal 100 of a user who uses the relining partner applications 10 and 11, makes a linked token issuance request to the general personal authentication system 600, generates a request token, and transmits it to the client terminal 100. This request token is generated based on an ID conforming to a predetermined OIDC standard and a predetermined user identifier. By generating the request token by the general personal authentication system 600P, it is possible to always generate a request token based on a combination of an ID and a user identifier conforming to the same OIDC standard.

[0089] When the linked token issuance unit 301 determines that the request token received from the client terminal 100 matches the parameters of the request token stored in the storage unit 313, the linked token issuance unit 301 issues a linked token.

[0090] <Configuration of ID Provider> FIG. 6A is a block diagram showing the hardware configuration of the ID provider 400. As shown in FIG. 6A, the ID provider 400 includes a CPU 410, a ROM 411, a RAM 412, a storage unit 413, an input unit 414, a display unit 415, and a communication unit 416.

[0091] The ID provider 400 includes an authentication unit 401 that authenticates with the client terminal 100 using a challenge response method.

[0092] The CPU 410 controls the ID provider 400 in an overall manner. The CPU 410 reads out various programs such as system programs and processing programs stored in the ROM 411 and the storage unit 413, expands them in the RAM 412, and executes the expanded programs. Thereby, the CPU 410 realizes functions for executing each process of the ID provider 400. Note that the details of the functions of the ID provider 400 will be described using FIG. 6B.

[0093] The RAM 412 functions as a work area for temporarily storing various programs, input or output data, parameters, etc. that are read from the ROM 411 or storage unit 413 and can be executed by the CPU 410 during various processes executed and controlled by the CPU 410.

[0094] The storage unit 413 is configured by, for example, a HDD or a semiconductor nonvolatile memory.

[0095] The input unit 414 is configured to include a keyboard equipped with cursor keys, numeric input keys, various function keys, etc., and a pointing device such as a mouse. The input unit 414 outputs press signals of keys pressed on the keyboard and operation signals from the mouse as input signals to the CPU 410. The CPU 410 executes various processes based on the operation signals from the input unit 414.

[0096] The display unit 415 is configured to include a display such as a CRT, LCD, etc. The display unit 415 displays various screens in accordance with instructions of a display signal input from the CPU 410.

[0097] The communication unit 416 includes a communication interface, and communicates with the client terminal 100 or the front-end server 200 via the Internet 801, for example, to perform authentication.

[0098] 6B is a functional block diagram showing the functions of the ID provider 400. The ID provider 400 is configured to include an authentication unit 401.

[0099] The authentication unit 401 performs authentication between itself and the client terminal 100 using a challenge-response method.

[0100] <Configuration of the integration API server> 7A is a block diagram showing the hardware configuration of linked API server 500. As shown in FIG. 7A, linked API server 500 is configured to include CPU 510, ROM 511, RAM 512, storage unit 513, input unit 514, display unit 515, and communication unit 516.

[0101] The linked API server 500 provides predetermined services to the client terminal 100 via the general-purpose personal authentication system 600 between the linked API server 500 and the client terminal 100 .

[0102] The CPU 510 performs overall control of the linked API server 500. The CPU 510 reads out various programs, such as system programs and processing programs, stored in the ROM 511 or storage unit 513, expands them in the RAM 512, and executes the expanded programs. In this way, the CPU 510 embodies functions for executing each process of the ID provider 400. Details of the functions of the linked API server 500 will be described with reference to FIG. 7B.

[0103] The RAM 512 functions as a work area for temporarily storing various programs, input or output data, parameters, etc. that are read from the ROM 511 or the storage unit 513 and can be executed by the CPU 510 during various processes executed and controlled by the CPU 510.

[0104] The storage unit 513 is configured by, for example, a HDD or a semiconductor nonvolatile memory.

[0105] The input unit 514 is configured to include a keyboard equipped with cursor keys, numeric input keys, various function keys, etc., and a pointing device such as a mouse. The input unit 514 outputs press signals of keys pressed on the keyboard and operation signals from the mouse as input signals to the CPU 510. The CPU 510 executes various processes based on the operation signals from the input unit 514.

[0106] The display unit 515 is configured to include a display such as a CRT, LCD, etc. The display unit 515 displays various screens in accordance with instructions of a display signal input from the CPU 510.

[0107] The communication unit 516 has a communication interface, and communicates with the client terminal 100 via the P2P network 802, for example, to provide a predetermined service.

[0108] 7B is a functional block diagram showing the functions of the linked API server 500. The linked API server 500 is configured to include a linked information transmitting / receiving unit 604.

[0109] Based on the link token transmitted from the general-personal authentication system 600, the link information transmission / reception unit 604 transmits a base ID that can uniquely identify the user even across relying party applications 10 and 11, and a link ID that specifies the link between the user and the relying party application.

[0110] In this way, the general-personal authentication system 600 can embody the request token generation unit 601, the linkage token generation unit 602, the information transmission and reception unit 603, and the linkage information transmission and reception unit 604 by including the front-end server 200, the back-end server 300, and the linkage API server 500. Note that the general-personal authentication system 600 is not limited to these server configurations, and the request token generation unit 601, the linkage token generation unit 602, the information transmission and reception unit 603, and the linkage information transmission and reception unit 604 may be embodied on any number of servers, and is not limited thereto.

[0111] <Information linkage system processing> The operation of information linkage system 700 configured as described above will be described using sequence diagrams in FIGS. 8A to 8D with reference to FIGS. 3A to 7B.

[0112] 8A to 8D are sequence diagrams showing the operation of the information linkage system 700 according to this embodiment.

[0113] When a user having client terminal 100 starts relying party app 10, a pan-personal authentication federation request screen 21 is displayed on display unit 115 of client terminal 100. Pan-personal authentication federation request screen 21 is provided with a pan-personal authentication federation button 19.

[0114] The user presses the general-personal authentication federation button 19 displayed on the general-personal authentication federation request screen 21, and the federation request receiving unit 1 receives the federation request. The data generation receiving unit 2 generates a state (sequence SQ001). The data generation receiving unit 2 stores the generated state in the memory unit 113.

[0115] After generating the state, the data generation reception unit 2 generates a code verification (code verifier) ​​(sequence SQ003). The data generation reception unit 2 stores the generated code verification in the storage unit 113.

[0116] The calculation unit 3 calculates a code challenge from the generated code verification (sequence SQ005).

[0117] The API request unit 4 starts a browser that connects to the general-purpose personal authentication system 600 (sequence SQ007). The API request unit 4 transmits the client ID, redirect URL, status, and code challenge to the backend server 300 via the Internet 801 (sequence SQ009).

[0118] The request token generation unit 601 of the backend server 300 receives the client ID, the redirect URL, the status, and the code challenge. In response to a request from the client terminal 100, the request token generation unit 601 generates a request token for making an authentication request to the ID provider 400 and obtaining an ID token, and transmits the request token to the client terminal 100. Specifically, the request token generation unit 601 executes sequences SQ011 to SQ015.

[0119] The request token generation unit 601 determines whether the received client ID and redirect URL are correct (sequence SQ011). If the client ID and redirect URL are incorrect (No in sequence SQ011), the request token generation unit 601 displays an error (status code: 400) on the display unit 115 of the client terminal 100, indicating that the invalid request could not be processed (sequence SQ017).

[0120] On the other hand, if the client ID and redirect URL are correct (Yes in sequence SQ011), the request token generation unit 601 determines whether the other parameters are correct (sequence SQ013). If the other parameters are incorrect (No in sequence SQ013), the request token generation unit 601 displays the redirect URL on the display unit 115 of the client terminal 100 (status code: 302) (sequence SQ019), moves to a new URL, and performs error processing (sequence SQ021).

[0121] If the other parameters are correct (Yes in sequence SQ013), the request token generation unit 601 generates a request token (sequence SQ015) and transmits the request token to the client terminal 100 (sequence SQ023). In this case, the request token generation unit 601 stores the request token, the redirect URL, the state, and the code verification in the storage unit 313.

[0122] The request token generating unit 601 displays the redirect URL on the display unit 115 of the client terminal 100 (status code: 302), and moves to the new URL (sequence SQ025).

[0123] The authentication request unit 120 of the client terminal 100 makes an authentication request to the authentication unit 401 of the ID provider 400 (sequence SQ027).

[0124] Upon receiving the authentication request from the client terminal 100, the authentication unit 401 of the ID provider 400 generates an authentication screen and performs authentication between the ID provider 400 and the client terminal 100 using a challenge-response method (sequence SQ029).

[0125] If the authentication unit 401 of the ID provider 400 is successful in authenticating the client terminal 100 (sequence SQ031), the client terminal 100 acquires an ID token (sequence SQ033). The client terminal 100 also acquires the value of the subject registration claim "sub" of the ID token.

[0126] Upon acquiring the ID token, the issuance request unit 130 of the client terminal 100 issues a linkage token issuance call (sequence SQ035), and transmits the ID token and the request token to the front-end server 200 (sequence SQ037).

[0127] The association token generation unit 602 of the front-end server 200 receives the ID token from the client terminal 100 and generates an association token based on the ID token. Specifically, the association token generation unit 602 executes sequences SQ39 to SQ67.

[0128] When the association token generation unit 602 receives an ID token from the client terminal 100, it verifies whether the ID token is correct (sequence SQ039). If the ID token received from the client terminal 100 is incorrect (No in sequence SQ039), the association token generation unit 602 displays an error on the display unit 115 of the client terminal 100 (sequence SQ041), and causes the client terminal 100 to acquire an ID token again (sequence SQ033).

[0129] On the other hand, if the ID token received from the client terminal 100 is valid (Yes in sequence SQ039), the association token generation unit 602 acquires the base ID (sequence SQ043). At this time, the association token generation unit 602 associates the value of the subject registration claim sub of the ID token with the base ID and stores them in the storage unit 213.

[0130] When the association token generation unit 602 of the front-end server 200 acquires the ID token (sequence SQ045), it transmits the base ID and the request token to the back-end server 300 (sequence SQ047).

[0131] Upon receiving the base ID and the request token, the association token issuing unit 301 of the backend server 300 verifies the request token and parameters stored in the storage unit 313 (sequence SQ049).

[0132] If the linkage token issuance unit 301 determines that the request token received from the client terminal 100 does not match the parameters of the request token stored in the storage unit 313 (No in sequence SQ049), the linkage token generation unit 602 of the front-end server 200 performs linkage token issuance error processing (sequence SQ051). The linkage token generation unit 602 displays the error, an explanation of the error, and details on the client terminal 100 using a redirect URL (status code: 302) (sequence SQ053). Then, the relying party application 10 performs error processing (sequence SQ055).

[0133] On the other hand, if the request token received from the client terminal 100 matches the parameters of the request token stored in the storage unit 313 (Yes in sequence SQ049), the linkage token issuance unit 301 issues a linkage token (sequence SQ057). The linkage token issuance unit 301 associates the issued linkage token with the base ID and stores them in the storage unit 313.

[0134] When the linkage token generation unit 602 of the front-end server 200 acquires the linkage token issued by the linkage token issuance unit 301 (sequence SQ059), it determines whether the linkage token result is pass or fail (sequence SQ061). If the determination result is fail (No in sequence SQ061), the linkage token generation unit 602 displays the error, an explanation of the error, and details on the client terminal 100 via the Internet 801 in a redirect URL (status code: 302) (sequence SQ063). Then, the relying party application 10 performs error processing (sequence SQ055).

[0135] On the other hand, if the determination result is successful (Yes in sequence SQ061), the information transmitting / receiving unit 603 of the front-end server 200 transmits the issued association token, the status, and the redirect URL to the client terminal 100 via the Internet 801 (sequence SQ067).

[0136] The client terminal 100 acquires the issued link token, the status, and the redirect URL via the Internet 801, and displays the redirect URL (status code: 302) (sequence SQ069).

[0137] Relying party application 10 determines whether the state received from front-end server 200 is correct and the state stored in storage unit 113 (sequence SQ071). If the received state and the stored state are incorrect (No in sequence SQ073), relying party application 10 performs error processing (sequence SQ075).

[0138] On the other hand, if the state received from the front-end server 200 and the state stored in the memory unit 113 are correct (Yes in sequence SQ073), the API server connection unit 6 of the relying party application 10 redirects (sequence SQ077) and transmits the collaboration token obtained from the front-end server 200 and the code verification stored in the memory unit 113 to the collaboration API server 500 via the P2P network 802 (sequence SQ079).

[0139] The cooperation information transmitting / receiving unit 604 of the cooperation API server 500 transmits a link ID that identifies the cooperation between the user and the relying party based on the cooperation token transmitted from the client terminal 100. Specifically, the cooperation information transmitting / receiving unit 604 executes sequences SQ081 to SQ089.

[0140] When the collaboration API server 500 receives the collaboration token and the code verification, it verifies whether they are correct (sequences SQ079 and SQ081). If the collaboration token is incorrect (NG in sequence SQ081), the collaboration information transmitting / receiving unit 604 causes the relying party application 10 to perform error processing via the P2P network 802 (sequence SQ083).

[0141] On the other hand, if the collaboration token is correct (OK in SQ081), the collaboration information transmitting and receiving unit 604 performs code verification (sequence SQ085). If the code verification is incorrect (NG in sequence SQ085), the collaboration information transmitting and receiving unit 604 causes the relying party application 10 to perform error processing via the P2P network 802 (sequence SQ083).

[0142] On the other hand, if the code verification is correct (OK in sequence SQ085), the association information transmitting and receiving unit 604 registers the association token and base ID as association information for each association ID (sequence SQ087).The association information transmitting and receiving unit 604 also transmits the link ID and base ID that identify the client terminal 100 to the relying party application 10 via the P2P network 802 (sequence SQ089).

[0143] Upon receiving the link ID and base ID via P2P network 802, relying party application 10 performs completion processing (sequence SQ091) and ends the processing of FIGS. 8A to 8D.

[0144] As described above, the information linkage system 700 according to this embodiment is configured to include a request token generation unit 601, a linkage token generation unit 602, an information transmission / reception unit 603, and a linkage information transmission / reception unit 604.

[0145] In response to a request from client terminal 100 of a user who uses relying party apps 10 and 11, request token generation unit 601 requests general-personal authentication system 600 to issue a linked token and generates a request token. Request token generation unit 601 transmits the generated request token to client terminal 100. Linked token generation unit 602, on the general-personal authentication system 600 side, requests authentication from ID provider 400 and acquires an ID token, and generates a linked token based on the ID token. Information transmission / reception unit 603 transmits the linked token generated in general-personal authentication system 600 to relying party apps 10 and 11. Linked information transmission / reception unit 604 transmits a base ID that can uniquely identify the user across relying party apps 10 and 11, and a link ID that specifies the link between the user and relying party apps 10 and 11, based on the link token transmitted from general-personal authentication system 600.

[0146] According to this embodiment, in information linkage system 700, even if the user identifier (value of subject registration claim sub) is different, relying party applications 10 and 11 can be linked based on the base ID issued by front-end server 200 and the link ID that identifies the link between the user and relying party applications 10 and 11. Because the base ID is not leaked onto the Internet 801, account spoofing can be prevented, and because predetermined services can be provided to relying party application 10 using P2P network 802, verifiability can be ensured.

[0147] The base ID can uniquely identify a user in the general-purpose individual authentication system 600. Therefore, the general-purpose individual authentication system 600 can identify a user by the base ID and link relying party applications 10 and 11. [Explanation of symbols]

[0148] 1. Collaboration request reception unit 2. Data generation reception section 3 Calculation section 4 API request part 5 Information acquisition department 6 API Server Connection 21, 22 General personal authentication linkage request screen 10,10P,11,11P,102 Relying Party App 100 client terminals 101 Browser 120 Authentication Request Section 130 Issuance Request Department 200 Front-end Server 300 Backend Server 301 Collaboration Token Issuance Department 400 Identity Provider 401 Authentication 402 ID Token 500 Collaboration API Server 600 Universal Personal Authentication System 601 Request Token Generation Unit 602 Linkage token generation unit 603 Information Transmitter / Receiver 604 Collaboration Information Transmitter / Receiver 610 Cooperative Authentication Department 700 Information Collaboration System

Claims

1. a request token generation unit that issues a linkage token issuance request to the general personal authentication system in response to a request from a client terminal of a user who uses the relying party app, generates a request token, and transmits the request token to the client terminal; a linkage token generation unit that requests authentication from an ID provider and acquires an ID token on the side of the universal personal authentication system, and generates a linkage token based on the ID token; an information transmitting / receiving unit that transmits the link token to the relying party app; a link information transmitting / receiving unit that transmits, based on the link token transmitted from the pan-personal authentication system, a base ID that can uniquely identify the user even across the relying party applications, and a link ID that identifies the link between the user and the relying party application; A universal personal authentication system.

2. an authentication unit that performs authentication between the client terminal and the device using a challenge-response method; The universal personal authentication system according to claim 1 .

3. In response to a request from a client terminal of a user who uses the relying party app, making a linkage token issuance request to the general personal authentication system, generating a request token, and transmitting the request token to the client terminal; a step of making an authentication request to an ID provider and acquiring an ID token on the general personal authentication system side, and generating a linkage token based on the ID token; sending the link token to the relying party app; transmitting a base ID that can uniquely identify the user across the relying party apps and a link ID that identifies the collaboration between the user and the relying party app, based on the collaboration token transmitted from the pan-personal authentication system; A pan-personal authentication method that performs the above.

Images