Authorization server, log-in management method, and program

Abstract

To provide an authorization server which can support a user during a phased migration from the old to the new ID system.SOLUTION: An authorization server which manages log-in of a user using an old ID or a new ID to each application in a group of applications operated by the same business operator includes: a new ID acquisition unit which acquires a new ID of the user; an old ID acquisition unit which acquires a group of old IDs of the user who acquired the new ID, for use in the group of applications that require both old and new IDs; a new-old ID association unit which associates the acquired new ID with the acquired corresponding group of old IDs; and an old ID tossing unit which tosses, when the user uses the new ID to log in to an application that requires both new and old IDs, an old ID of the application that the user tries to log in to, in the group of old IDs associated with the new ID, as a payload.SELECTED DRAWING: Figure 3

Description

[Technical Field]

[0001] The present disclosure relates to an authorization server, a login management method, and a program that support users during the transition period from an old ID system to a new ID system. [Background technology]

[0002] ID integration is a system that allows a company to centralize and manage customer IDs that were previously managed separately across multiple businesses and services. By implementing ID integration, customers no longer need to manage multiple IDs and passwords for sites and services provided by the same company, improving convenience. It also reduces the burden on companies, as they no longer need to manage customer information across multiple departments. It also allows for accurate understanding of customer behavior, purchase history, and other information across each business, which is useful for marketing.

[0003] A conventional technique for ID integration is, for example, Non-Patent Document 1. Non-Patent Document 1 discloses, as methods of ID integration, a method in which a company performs ID integration collectively, and a method in which customers perform ID integration.

[0004] The document discloses that it would be extremely costly for a company to integrate IDs en masse. The document also discloses a method for having customers integrate their IDs by maintaining their existing customer IDs while creating new IDs to be used for integration and having new users register them. The document recommends that, when having customers integrate their IDs, existing customers be encouraged to link their new IDs to facilitate a smooth transition.

[0005] The document discloses two approaches to data migration for multiple services: the "big bang approach," which completes the migration in one go, and the "phased approach," which proceeds with the migration in stages. [Prior art documents] [Non-patent literature]

[0006] [Non-Patent Document 1] Makoto Yashiro, "SAP Customer Data Cloud - Column - Customer ID Integration - What is ID integration that companies are paying attention to? Introducing the reasons for its necessity, benefits, and examples," [online], November 29, 2021, NTTCom Online Marketing Solutions Corporation, [Retrieved January 23, 2024], Internet〈 URL: https: / / www.nttcoms.com / service / ciam / column / 20211129 / 〉 Summary of the Invention [Problem to be solved by the invention]

[0007] If a company provides a large number of applications, it is not realistic to adopt a big bang approach to replacing IDs, and the only option is to adopt a phased approach in which the transition is carried out in stages.

[0008] However, if you consider gradually switching IDs, applications running with the new ID (hereafter referred to as the new ID) and applications running with the old ID (hereafter referred to as the old ID) will coexist during the switching process. 1) When a user who only has the old ID uses an application running with the new ID 2) When a user with only a new ID uses an application that is running with the old ID 3) When a user who has both an old ID and a new ID uses an application that runs with the new ID or an application that runs with the old ID This may cause problems such as being unable to log in smoothly.

[0009] Therefore, an object of the present disclosure is to provide an authorization server that can support users during the transition period from the old ID system to the new ID system using a phased approach. [Means for solving the problem]

[0010] The authorization server disclosed herein is an authorization server that manages user logins using an old ID (hereinafter referred to as the old ID) or a new ID (hereinafter referred to as the new ID) for each application in a group of applications shared by a common business owner, and includes a new ID acquisition unit, an old ID acquisition unit, a new and old ID linking unit, and an old ID tossing unit.

[0011] The old ID is a user identifier that may be set separately for each application, and the new ID is a user identifier that can be used in common for an application or group of applications that are compatible with the new ID.

[0012] The new ID acquisition unit acquires a new ID for the user. The old ID acquisition unit acquires a group of old IDs to be used for a group of applications that require both the new ID and the old ID of the user who has acquired the new ID. The new and old ID linking unit links the acquired new ID with a group of old IDs that have been acquired correspondingly. When a user who has acquired a new ID attempts to log in to an application that requires both the new ID and the old ID using the new ID, the old ID tossing unit tosses the old ID of the application that the user is attempting to log in to as payload from the group of old IDs linked to the new ID. [Effects of the Invention]

[0013] The authorization server of the present disclosure can assist users during the transition from the old ID system to the new ID system in a phased approach. [Brief explanation of the drawings]

[0014] [Figure 1] A diagram illustrating the five phases of the phased approach. [Figure 2] FIG. 1 is a block diagram showing the device configuration of a login system according to a first embodiment. [Figure 3] FIG. 2 is a block diagram showing the functional configuration of an authorization server according to the first embodiment. [Figure 4]10 is a flowchart showing the operation of the login system when a user attempts to log in to an application running with a new ID. [Figure 5] 10 is a flowchart showing the operation of the login system regarding linking a new ID with an old ID. [Figure 6] This is a diagram explaining the scene in which a user terminal exchanges information with three domains during the phase of transition from an old ID to a new ID. [Figure 7] FIG. 10 is a diagram illustrating variations in the relationship between an application and an old authentication server. [Figure 8] FIG. 10 is a diagram illustrating variations in the relationship between an authorization server and an old authentication server. [Figure 9] 10A and 10B are diagrams illustrating an example of a screen displayed on a user terminal and an example of a signature issued by an authentication server and an authorization server. [Figure 10] 10 is a flowchart showing details of the operation of the authorization server to link a new ID with a group of old IDs (group of automatically generated old IDs). [Figure 11] 10 is a flowchart showing an old ID (automatically generated old ID) tossing operation of the authorization server. [Figure 12] FIG. 2 is a diagram showing an example of the functional configuration of a computer. DETAILED DESCRIPTION OF THE INVENTION

[0015] Hereinafter, embodiments of the present disclosure will be described in detail. Note that components having the same functions are assigned the same numbers, and redundant explanations will be omitted. [Example]

[0016] The five phases of the phased approach are explained with reference to Figure 1. The five phases are: I) a period when only old IDs exist; II) a period when old IDs and new IDs coexist; III) a period when new IDs are primarily used but old IDs exist; IV) a period when only new IDs exist (unused IDs are also forcibly migrated); and V) a period when only new IDs exist (unused IDs are deleted). The illustration also shows how, in parallel with the ICT migration, measures are being implemented on the app side to enable login with the new ID. The following explanation mainly focuses on the operation of the login system in Phases II), III), and IV).

[0017] During periods II) and III), if a user (existing user) who only has the old ID attempts to log in, the login system will issue a new ID. For users who already have the new ID, the login system will skip this process.

[0018] If a user creates only a new ID during periods II) and III), the login system will automatically generate an old ID as a process invisible to the user. Hereinafter, the old ID automatically generated by the login system will be referred to as the automatically generated old ID. The login system will link the new ID and the automatically generated old ID.

[0019] During period IV), new IDs will be automatically generated for users who have not logged in during the transition period. Hereafter, new IDs automatically generated by the login system will be referred to as automatically generated new IDs. The login system will link the automatically generated new ID with the old ID, but will also include information about the forced transition.

[0020] During the V) period, the login system will be forcibly migrated, but the old IDs and automatically generated new IDs that have not been used since will be deleted.

[0021] The old ID is a user identifier that may be set separately for each application. The new ID is a user identifier that can be used in common across applications or groups of applications that support the new ID. As mentioned above, there is an automatically generated old ID as a replacement for the old ID, and an automatically generated new ID as a replacement for the new ID, but these IDs are also used as user identifiers in the same way as the old ID and new ID, respectively.

[0022] The device configuration of the login system of the first embodiment will be described below with reference to Fig. 2. As shown in the figure, the login system 1 of the present embodiment includes an authorization server 11, a user terminal 12, a previous authentication server 13, an authentication server 15, an application server 16, and a portal site server 17. The role of each device will be described below.

[0023] <Authorization Server 11> The authorization server 11 is a server that issues and transmits an authorization response and an authorization token in relation to an application running under a new ID. The authorization server 11 continues to operate even after the end of phases I) to V).

[0024] <User terminal 12> The user terminal 12 is a terminal operated by a user. The user uses the user terminal 12 to log in to one of the applications using the old ID or the new ID.

[0025] <Old authentication server 13> The old authentication server 13 is a server that issues a new old ID, and issues and transmits an authentication response and an authentication token in association with an application running under the old ID. When the process moves to phase IV), the old authentication server 13 stops operating.

[0026] <Authentication Server 15> The authentication server 15 is a server that issues a new ID, an authentication response, and an authentication token in association with an application running under the new ID. The authentication server 15 continues to operate even after the completion of phases I) to V).

[0027] <<Application Server 16>> The application server 16 is a server that controls applications that run under a new ID. Note that the application server 16 is a server that controls applications that run under an old ID in the phase before the transition to the new ID system, and when the transition to phase IV) occurs, the application server 16 transitions to applications that run under a new ID. The application server 16 continues to operate even after the completion of phases I) to V).

[0028] <Portal site server 17> The portal site server 17 is a server that controls a portal site that serves as a gateway for multiple applications.

[0029] An example of the functional configuration of the authorization server 11 will be described below with reference to Fig. 3. As shown in the figure, the authorization server 11 of this embodiment includes a new ID acquisition unit 111, an old ID acquisition unit 112, a new / old ID linking unit 113, a storage unit 11a, an old ID tossing unit 114, an automatically generated old ID acquisition unit 115, an information transmission unit 1101, an information reception unit 1102, an authorization response issuance unit 1103, an authorization token issuance unit 1104, and an ID authorization database 1105.

[0030] Although not shown in the figure, the user terminal 12 includes an information display unit that displays information to the user, an information input unit that accepts user input, an information sending unit that performs information transmission, an information receiving unit that performs information reception, a redirect unit that performs redirect processing, and a token acquisition unit that performs token acquisition.

[0031] Similarly, although not shown in the figure, the old authentication server 13 and the authentication server 15 include an information sending unit that sends information, an information receiving unit that receives information, a new ID issuing unit that issues a new ID, an authentication response issuing unit that issues an authentication response, an authentication token issuing unit that issues an authentication token, an ID authentication database, and the like.

[0032] Similarly, although not shown in the figure, the application server 16 includes an information sending unit that performs information transmission, an information receiving unit that performs information reception, an authentication processing unit that performs authentication processing, an authorization processing unit that performs authorization processing, a service providing unit that performs service provision, a redirection unit that performs redirection, and a token acquisition unit that performs token acquisition.

[0033] The operation of the login system when a user logs in to an application running with a new ID will be described below with reference to FIG.

[0034] First, the user terminal 12 accesses the portal site (S1a). Each device in the login system 1 executes a redirect to the authorization server 11 (S1b). Each device in the login system 1 executes a redirect to the authentication server 15 (S1b). The portal site server 17 executes a login request using a new ID (S1c). The authentication server 15 determines whether the user has a new ID, and if the user has a new ID, executes a login request using the new ID (S1d). The authentication server 15 executes a login confirmation using the new ID (S1e).

[0035] If the user does not have a new ID, authentication server 15 generates a new ID (S1f). If the generated new ID is a duplicate or contains an error, authentication server 15 displays an error (S1g). If the generated new ID is free of duplicates or errors, authentication server 15 issues a new ID (S1h).

[0036] The authentication server 15 and the authorization server 11 issue the necessary responses and tokens (S1i). Step S1i is the same as in the prior art, so the details of the process will be omitted. The portal site server 17 displays the portal site (S1j).

[0037] Next, with reference to FIG. 5, the operation of the login system 1 regarding linking of a new ID and an old ID will be described.

[0038] The authorization server 11 determines whether the old ID and the new ID are already associated (S1k). If the old ID and the new ID are already associated, this flow ends. If the old ID and the new ID are not associated, the authorization server 11 requests login to another application using the old ID (S1l). The old authentication server 13 determines whether the user holds the old ID. If the user holds the old ID, the old authentication server 13 requests login using the old ID (S1m). The old authentication server 13 confirms login using the old ID (S1n).

[0039] If the user does not have an old ID, the old authentication server 13 automatically generates an old ID (S1o). The automatically generated old ID is called an automatically generated old ID. If the automatically generated old ID is a duplicate or contains an error, the old authentication server 13 displays an error (S1p). If the automatically generated old ID is free of duplicates or errors, the old authentication server 13 issues the automatically generated old ID (S1q).

[0040] The old authentication server 13 issues the necessary response and token (S1r). Step S1r is the same as in the conventional technology, so details of the process will be omitted. The authorization server 11 links the new ID with the old ID (automatically generated old ID) (S1s). Details of step S1s will be described later. The portal site server 17 redisplays the portal site (S1t).

[0041] In the old ID environment (hereinafter also referred to as Version 1), the user terminal 12 exchanges information with the application server 16 (a Version 1 server). The application server 16 exchanges information with the old authentication server 13 (a Version 1 server that also serves as an authorization server). In other words, in the Version 1 environment, the user terminal 12 exchanges information with the same domain.

[0042] In the Version 1 environment, the user is prompted to enter a user name and password into the browser in the application domain, and if the username and password match, the user is identified. A session is then generated and communication takes place between the browser and application server 16 (Version 1), thereby identifying the user each time and displaying the screen and data.

[0043] Next, in an environment in which the user is in the process of transitioning from an old ID to a new ID (hereinafter also referred to as Version 2), as shown in Fig. 6, the user terminal 12 exchanges information with the authentication server 15, the authorization server 11, and the application server 16 (a Version 2 server), i.e., three domains. The authorization server 11 exchanges information with the old authentication server 13 (a Version 1 server). The old and new IDs are linked in the authorization server 11 and the old authentication server 13, which are enclosed by a dashed line.

[0044] After transitioning to the new ID (hereinafter also referred to as Version 3), the user terminal 12 will exchange information with the authentication server 15 (Version 3 server) and the application server 16 (Version 3 server), i.e., two domains.

[0045] In a Version 3 environment, a signed token (or a similar session) issued by the authorization token side is exchanged between the browser and the application server 16 (Version 3), thereby identifying the user each time and executing the process of displaying the screen and data.

[0046] It should be noted that the operation of the authorization server 11 disclosed below is executed in a Version 2 environment because the application server 16 (Version 2) requires both the new ID and the old ID to identify the user. The advantage of this configuration in Version 2 is that the system can be configured at low cost because the application can operate by changing only the part that identifies the user, without changing the core of the application. Later, by migrating to Version 3 over time, the old ID will no longer be necessary.

[0047] 7, the relationship between the application server 16 and the old authentication server 13 is not necessarily limited to a 1:1 relationship, and one old authentication server 13 may manage multiple application servers 16. Also, as shown in FIG. 8, the relationship between the authorization server 11 and the old authentication server 13 is not necessarily limited to a 1:1 relationship, and one authorization server 11 may manage multiple old authentication servers 13.

[0048] In a Version 2 environment, when a user attempts to log in using the authentication server 15 (Version 3) using the user terminal 12 as shown in Figure 9, a login screen such as Screen A is displayed, and the user enters a user name and password on the login screen. If a new ID has not yet been issued, the user proceeds to a user registration screen and performs user registration for Version 3. If authentication is successful, the authentication server 15 issues a signature X as shown in the figure.

[0049] The old ID and the new ID are also linked. In the linking process between the old ID and the new ID, a linking screen such as screen B is displayed on the user terminal 12. The user enters the membership number and password used under the old ID environment. In this case, the authorization server 11 links the old ID and the new ID and issues a signature Y. As an example of the old ID, "members:id":[123456] is tossed as the payload.

[0050] <Step S1s Details> Hereinafter, the operation of the authorization server 11 to link the new ID with the old ID group (automatically generated old ID group) (step S1s described above) will be described in detail with reference to FIG.

[0051] The new ID acquisition unit 111 of the authorization server 11 determines whether the user's new ID has been linked to the old ID group or not. If the user's new ID has been linked to the old ID group, this flow ends. If the new ID has not been linked to the old ID group, the new ID acquisition unit 111 of the authorization server 11 acquires the new ID of the user (S111). The new ID acquired here is the new ID issued in step S1h of the flowchart described in FIG. 4.

[0052] Next, the old ID acquisition unit 112 of the authorization server 11 determines whether the user holds old IDs or not, and if the user holds old IDs, acquires old IDs to be used for applications that require both new and old IDs for the user (S112). The old IDs acquired here are the old IDs acquired by executing steps S1m and S1n of the flowchart described in FIG. 5.

[0053] Next, the new and old ID linking unit 113 of the authorization server 11 links the new ID acquired in step S111 with the corresponding old ID group acquired in step S112 (S113-1). The linked new ID and old ID group are stored in the storage unit 11a.

[0054] If the user does not have all or part of the old ID group, the automatically generated old ID acquisition unit 115 acquires an automatically generated old ID group that corresponds to the old ID group that the user does not have and is used for applications that require both new IDs and old IDs (S115).

[0055] The new and old ID linking unit 113 links the new ID acquired in step S111 with the corresponding automatically generated old ID group acquired in step S115 (S113-2).

[0056] <Authorization Server 11 Old ID (Auto-Generated Old ID) Toss Operation> Hereinafter, the old ID (automatically generated old ID) tossing operation of the authorization server 11 will be described with reference to FIG.

[0057] The old ID toss unit 114 of the authorization server 11 determines whether the user is attempting to log in with the new ID to an application (Version 3) corresponding to the new ID, or whether the user is attempting to log in with the new ID to an application (Version 2) that requires both the new ID and the old ID. If the user is attempting to log in with the new ID to an application (Version 3) corresponding to the new ID, this flow ends.

[0058] When the user attempts to log in using a new ID to an application (Version 2) that requires both a new ID and an old ID, the old ID tossing unit 114 of the authorization server 11 determines whether or not the user holds the old ID of the application that the user is attempting to log in to. If the user holds the old ID of the application that the user is attempting to log in to, the old ID tossing unit 114 of the authorization server 11 tosses, as payload, the old ID of the application that the user is attempting to log in to from the group of old IDs linked to the user's new ID (S114-1).

[0059] On the other hand, if the user does not have the old ID of the application to which the user is attempting to log in, the automatically generated old ID of the application to which the user is attempting to log in from the group of automatically generated old IDs linked to the user's new ID is tossed as payload (S114-2).

[0060] As described above, according to the login system 1 of this embodiment, the authorization server 11 links the new ID with the old ID group in advance, and when a user tries to log in with a new ID to an application that requires both the new ID and the old ID, the authorization server 11 has the function of tossing the corresponding old ID (automatically generated old ID) as payload. Therefore, the user can smoothly log in to an application that requires both the new ID and the old ID simply by entering the new ID, thereby improving user convenience and supporting users during the transition period from the old ID system to the new ID system.

[0061] <Additional Notes> The functions performed by the components described herein may be implemented in circuitry or processing circuitry, including general-purpose processors, application-specific processors, integrated circuits, ASICs (Application Specific Integrated Circuits), a CPU (a Central Processing Unit), conventional circuits, and / or combinations thereof, programmed to perform the described functions. A processor includes transistors and other circuits and is considered to be circuitry or processing circuitry. A processor may also be a programmed processor that executes programs stored in memory.

[0062] In this specification, a circuitry, unit, or means is hardware that is programmed to realize or performs the described functions, which may be any hardware disclosed herein or any hardware known to be programmed to realize or perform the described functions.

[0063] If the hardware is a processor considered to be a type of circuitry, the circuitry, means, or unit is a combination of the hardware and software used to configure the hardware and / or processor.

[0064] The various processes described above can be implemented by loading a program that executes each step of the above method into the recording unit 10020 of the computer shown in Figure 12 and operating the control unit 10010, input unit 10030, output unit 10040, etc.

[0065] The program describing the processing contents can be recorded on a computer-readable recording medium, which may be, for example, a magnetic recording device, an optical disk, a magneto-optical recording medium, a semiconductor memory, or any other suitable recording medium.

[0066] The program may be distributed, for example, by selling, transferring, lending, etc. a portable recording medium such as a DVD or CD-ROM on which the program is recorded. Furthermore, the program may be stored in a storage device of a server computer, and then transferred from the server computer to another computer via a network, thereby distributing the program.

[0067] A computer that executes such a program may first temporarily store the program recorded on a portable recording medium or transferred from a server computer in its own storage device. Then, when executing a process, the computer reads the program stored on its own recording medium and executes the process in accordance with the read program. Alternatively, the computer may read the program directly from a portable recording medium and execute the process in accordance with the program. Furthermore, the computer may execute the process in accordance with the program each time a program is transferred from a server computer to the computer. The server computer may not transfer the program to the computer, but may instead execute the process through a so-called ASP (Application Service Provider) service, which realizes the processing function by issuing an execution instruction and obtaining the results. Furthermore, the server computer may execute the process on a terminal using a so-called SaaS (Software as a Service) service, which allows users to use part of the server computer along with the program. In this embodiment, the program includes information used for computer processing that is equivalent to a program (such as data that is not a direct instruction to the computer but has properties that define computer processing).

[0068] Furthermore, in this embodiment, the device is configured by executing a predetermined program on a computer, but at least a part of the processing contents may be realized by hardware.

Claims

1. An authorization server that manages user logins using an old ID (hereinafter referred to as "old ID") or a new ID (hereinafter referred to as "new ID") for each application of a group of applications shared by a business owner, The old ID is a user identifier that may be set separately for each application, and the new ID is a user identifier that can be used in common in the application or group of applications that are associated with the new ID, a new ID acquisition unit that acquires the new ID of the user; an old ID acquisition unit that acquires the old ID group used for the application group that requires both the new ID and the old ID of the user who has acquired the new ID; a new and old ID linking unit that links the acquired new ID with the group of acquired corresponding old IDs; An old ID tossing unit that, when the user attempts to log in to the application that requires both the new ID and the old ID using the new ID, tosses the old ID of the application that the user is attempting to log in to as a payload from among the old ID group linked to the new ID. Authorization server.

2. 2. The authorization server of claim 1, an automatically generated old ID acquisition unit that acquires, when the user who has acquired the new ID does not hold all or part of the group of old IDs, an automatically generated old ID group that corresponds to the group of old IDs that the user does not hold, and is used for a group of applications that require both the new ID and the old ID; The new and old ID linking unit Linking the acquired new ID with the corresponding acquired automatically generated old ID group; The old ID toss section When the user attempts to log in with the new ID to an application for which the user does not hold the corresponding old ID and which requires both the new ID and the old ID, the automatically generated old ID of the application that the user is attempting to log in to is tossed as payload from the group of automatically generated old IDs linked to the new ID. Authorization server.

3. A login management method executed by an authorization server that manages user logins using an old ID (hereinafter referred to as "old ID") or a new ID (hereinafter referred to as "new ID") for each application of a group of applications shared by a common business owner, comprising: The old ID is a user identifier that may be set separately for each application, and the new ID is a user identifier that can be used in common in the application or group of applications that are associated with the new ID, a new ID acquisition step of acquiring the new ID of the user; an old ID acquisition step of acquiring the old ID group to be used for the application group that requires both the new ID and the old ID of the user who has acquired the new ID; a new and old ID linking step of linking the acquired new ID with the group of acquired corresponding old IDs; An old ID tossing step of tossing, as a payload, the old ID of the application that the user is attempting to log in to, from the group of old IDs linked to the new ID, when the user attempts to log in to the application that requires both the new ID and the old ID using the new ID. How to manage logins.

4. The login management method according to claim 3, an automatically generated old ID acquisition step for acquiring, when the user who has acquired the new ID does not hold all or part of the old ID group, an automatically generated old ID group corresponding to the old ID group that the user does not hold, and used for applications that require both the new ID and the old ID; The new and old ID linking step includes: Linking the acquired new ID with the corresponding acquired automatically generated old ID group; The old ID toss step is When the user attempts to log in with the new ID to an application for which the user does not hold the corresponding old ID and which requires both the new ID and the old ID, the automatically generated old ID of the application that the user is attempting to log in to is tossed as payload from the group of automatically generated old IDs linked to the new ID. How to manage logins.

5. A program that causes a computer to function as the authorization server according to claim 1 or 2.

Images