KR102519627B1 - Method for authenticating legacy service based on token and platform service server supporting the same - Google Patents

Abstract

A token-based legacy service authentication method for providing a platform-based integrated authentication service for one or more legacy services is provided. In the token-based legacy service authentication method, a service token issued by any one of a service-independent platform common authentication manager and an identity authentication manager of one or more legacy services and stored in a user terminal of a first user is a service-independent service token. stored in a token key manager, a service independent API manager, in response to receiving a service use request related to the legacy service including the service token from a user terminal of the first user, token verification of the service token Sending the token verification request to the token key manager without sending a request to the legacy service, and calling an API included in the legacy service when the API manager receives a token verification success message from the token key manager It may include a step of allowing.

Description

Token-based legacy service authentication method and platform service server supporting it

The present invention relates to a token-based legacy service authentication method and a platform service server supporting the same. More specifically, it relates to a method of providing a service token-based integrated authentication service for one or more legacy services and a platform service server performing the method.

As the service development environment evolves into a cloud environment, today's services are being developed in a form that is called from a client through an application programming interface (API) and executed in an API server. In particular, with the introduction of the MSA (Micro Service Architecture) concept, changes in the form of service development are accelerating, and API gateways are becoming essential components of various platforms.

The API gateway not only routes the client's API call to the API server, but also authenticates the client in conjunction with the integrated authentication server and the API authentication server on the API server side. Specifically, when a client calls an API associated with a service of a specific API server, the API gateway performs authentication on the client in association with the integrated authentication server. In addition, the API gateway forwards the authentication result (e.g. authentication token) to the API authentication server, so that the API authentication server issues a service token to the client. At this time, since each API server generally works with different API authentication servers, a separate service token is issued for each service.

However, the above authentication process may cause various problems as the number of API servers (ie, the number of services) increases.

The first problem is that authentication-related traffic increases unnecessarily. Since a separate service token is issued for each service and service token verification is performed whenever a service is switched, authentication-related traffic inevitably increases as the number of API servers increases. In particular, since the issuance and verification of service tokens are performed through each API authentication server independently of the integrated authentication procedure, authentication-related traffic inevitably increases even in an environment where an integrated authentication platform is built.

The second problem is that platform-wide session maintenance is not possible. This is a problem that occurs because a separate session is maintained for each service based on the service token. For example, assume that a specific client uses multiple services. Then, while the specific client uses the first service, the session for the second service may expire. In this case, in order for the specific client to use the second service again, an authentication procedure must be re-performed and a service token for the second service must be reissued.

Korean Patent Publication No. 10-2017-0011469 (published on February 2, 2017)

A technical problem to be solved by the present invention is to provide a method for providing a platform-based integrated authentication service for one or more services and a platform service server that performs the method.

Another technical problem to be solved by the present invention is to provide a method for minimizing authentication-related traffic and a platform service server that performs the method in providing a platform-based integrated authentication service for one or more services.

Another technical problem to be solved by the present invention is a method for providing a session maintenance function regardless of service switching and a platform service that performs the method in providing a platform-based integrated authentication service for one or more services. to provide the server.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the description below.

In order to solve the above technical problem, a token-based legacy service authentication method according to an embodiment of the present invention is a method of providing a platform-based integrated authentication service for one or more legacy services, a service independent platform common authentication manager. and storing the service token issued by any one of the identity authentication managers of the one or more legacy services and stored in the user terminal of the first user in a service independent token key manager. In response to receiving a service use request related to the legacy service including the service token from the user terminal of the first user, the token verification request of the service token is not transmitted to the legacy service and the token key manager Transmitting a verification request, and allowing the API manager to call an API included in the legacy service when receiving a token verification success message from the token key manager.

In one embodiment, the service token is a platform service token, and the platform service token may be issued by the platform common authentication manager as a result of platform login by the first user.

In one embodiment, the service token is a platform service token, and the platform service token may be issued by an identity authentication manager of the legacy service as a result of login to the legacy service by the first user.

In one embodiment, the step of sending the token verification request to the token key manager may include, by the token key manager updating the validity period of the service token included in the token verification request regardless of the legacy service to be used, the platform A step of providing a session maintaining function may be further included.

In one embodiment, the sending of the token verification request to the token key manager may include, in response to the token key manager determining that the service token is invalid, authentication of the first user by the platform common authentication manager. It may further include sending the request.

In one embodiment, the service token is a token issued by an identity authentication manager of the legacy service as a result of login to a legacy service by the first user, and sending the token verification request to the token key manager comprises: In response to determining that the service token is valid, by the token key manager, the service token is reissued through a common platform authentication manager, wherein the reissued service token is usable by the first user. Information on legacy services may be included.

A platform service server according to another embodiment of the present invention for solving the above technical problem is a token storage for storing service tokens related to legacy services, a token key manager for performing token verification for the service tokens, and the user's In response to receiving a service use request for the legacy service including the service token from a terminal, an API manager that transmits a token verification request for the service token to the token key manager without sending it to the legacy service; and A platform common authentication manager performing platform authentication for a user, wherein the API manager, in response to receiving a token verification success message from the token key manager, allows calling of an API included in the legacy service, The service token may be issued by at least one of the platform common authentication manager and the identity authentication manager of the legacy service.

1 illustrates an exemplary system environment that may be applied to a token-based legacy service authentication method according to some embodiments of the present invention.
2 is a block diagram showing a platform service server according to an embodiment of the present invention.
3 is a flowchart illustrating a token-based legacy service authentication method according to the first embodiment of the present invention.
4 is a flowchart illustrating a token-based legacy service authentication method according to a second embodiment of the present invention.
5 is a flowchart illustrating a token-based legacy service authentication method according to a third embodiment of the present invention.
6 is a flowchart illustrating a token-based legacy service authentication method according to a fourth embodiment of the present invention.
7 is a flowchart illustrating a token-based legacy service authentication method according to a fifth embodiment of the present invention.
8 illustrates an exemplary computing device capable of implementing a platform service server in accordance with one embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. Advantages and features of the present invention, and methods of achieving them, will become clear with reference to the detailed description of the following embodiments taken in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below, but may be implemented in various different forms, and only these embodiments make the disclosure of the present invention complete, and common knowledge in the art to which the present invention belongs. It is provided to completely inform the person who has the scope of the invention, and the present invention is only defined by the scope of the claims.

In adding reference numerals to components of each drawing, it should be noted that the same components have the same numerals as much as possible even if they are displayed on different drawings. In addition, in describing the present invention, if it is determined that a detailed description of a related known configuration or function may obscure the gist of the present invention, the detailed description will be omitted.

Unless otherwise defined, all terms (including technical and scientific terms) used in this specification may be used in a meaning commonly understood by those of ordinary skill in the art to which the present invention belongs. In addition, terms defined in commonly used dictionaries are not interpreted ideally or excessively unless explicitly specifically defined. Terminology used herein is for describing the embodiments and is not intended to limit the present invention. In this specification, singular forms also include plural forms unless specifically stated otherwise in a phrase.

In addition, in describing the components of the present invention, terms such as first, second, A, B, (a), and (b) may be used. These terms are only used to distinguish the component from other components, and the nature, order, or order of the corresponding component is not limited by the term. When an element is described as being “connected,” “coupled to,” or “connected” to another element, that element is directly connected or connectable to the other element, but there is another element between the elements. It will be understood that elements may be “connected”, “coupled” or “connected”.

As used herein, "comprises" and/or "comprising" means that a stated component, step, operation, and/or element is the presence of one or more other components, steps, operations, and/or elements. or do not rule out additions.

Hereinafter, some embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 illustrates an exemplary system environment to which a token-based legacy service authentication method according to some embodiments of the present invention may be applied.

As shown in FIG. 1 , the exemplary system environment may include a platform service server 100 , at least one legacy service server 200 or 210 and a user terminal 300 . However, this is only a preferred embodiment for achieving the object of the present invention, and it goes without saying that some components may be added or deleted as needed. In particular, although FIG. 1 illustrates a system environment in which two legacy service servers 200 and 210 exist, this is only for convenience of understanding, and the number of legacy service servers may vary.

In addition, it should be noted that each component of the system environment shown in FIG. 1 represents functionally differentiated functional elements, and a plurality of components may be implemented in a form integrated with each other in an actual physical environment. For example, the first legacy service server 200 and the second legacy service server 210 may be implemented in the form of different logics within the same physical device. Hereinafter, each component of the system environment shown in FIG. 1 will be described.

The platform service server 100 is a computing device that provides an integrated authentication service for legacy services. The computing device may be a notebook, a desktop, or a laptop, but is not limited thereto, and may include all types of devices having a computing function and a communication function. However, in an environment in which an integrated authentication service is provided to a plurality of user terminals 300 in conjunction with a plurality of legacy service servers 200 and 210, it is preferable that the platform service server 100 be implemented as a high-performance server-class computing device. can Alternatively, in order to provide integrated authentication services at high speed, the functions of the platform service server 100 may be processed in parallel by a plurality of processors or distributed through a plurality of computing devices.

Specifically, the platform service server 100 may provide integrated authentication for users, service token issuance and management, routing functions for service use requests (eg API calls), and the like. The platform service server 100 may provide such functions independently of legacy services. That is, the platform service server 100 can be easily deployed in various system environments where any legacy service exists without being affected by changes on the legacy service server side. A detailed description of each function of the platform service server 100 will be described later with reference to the drawings below in FIG. 2 .

Next, the legacy service servers 200 and 210 are computing devices that provide predetermined legacy services to the user terminal 300 . Here, the legacy service means a service that is not easy to change as a previously built service, and does not mean a service implemented based on an old technology.

As shown in FIG. 3 and below, the first legacy service server 200 issues a service token and a service module 201 that provides a service in response to a service use request, authenticates the user terminal 300, and /or may include an identity authentication manager 203 that performs authorization. In this case, the service module 201 may correspond to the API server and the identity authentication manager 203 may correspond to the API authentication server, but the scope of the present invention is not limited thereto.

According to embodiments, the identity authentication manager 203 may be implemented separately from the first legacy service server 200 and independently.

The second legacy service server 210 may have a configuration similar to that of the first legacy service server 200 and perform similar operations.

Hereinafter, for convenience of description, a service provided by the first legacy service server 200 is referred to as a first legacy service, and a service provided by the second legacy service server 200 is referred to as a second legacy service. do.

Next, the user terminal 300 is a client-side device that uses legacy services provided by the legacy service servers 200 and 210 .

Each component of the system environment shown in FIG. 1 may communicate through a network. Here, the network is a local area network (LAN), a wide area network (Wide Area Network; WAN), a mobile communication network (mobile radio communication network), all types of wired / wireless networks such as Wibro (Wireless Broadband Internet) can be implemented

An exemplary system environment to which the token-based legacy service authentication method according to an embodiment of the present invention can be applied has been described with reference to FIG. 1 so far. Hereinafter, the configuration and operation of the platform service server 100 according to an embodiment of the present invention will be briefly reviewed.

2 is a block diagram showing a platform service server 100 according to an embodiment of the present invention.

Referring to FIG. 2 , the platform service server 100 may include an API manager 102, a platform common authentication manager 104, a token key manager 106, and a token storage 108. However, only components related to the embodiment of the present invention are shown in FIG. 2 . Therefore, those skilled in the art to which the present invention pertains can know that other general-purpose components may be further included in addition to the components shown in FIG. 2 . Hereinafter, each component of the platform service server 100 will be described.

The API manager 102 is a module that functions as an API gateway. Specifically, in response to a service use request (e.g. API call) of the user terminal 300, verification of the service token is requested to the token key manager 106. In addition, the API manager 102 allows or blocks the service use request based on the verification result. If the service use request is allowed, the API manager 102 may route the service use request to the corresponding legacy service server (e.g. 200 or 210).

Next, the platform common authentication manager 104 is a module that performs integrated authentication functions for the user terminal 300 . When authentication is successfully performed, the platform common authentication manager 104 may issue a service token to the user terminal 300 . In this case, the service token may include at least one of issuance time, valid period, available service information, and terminal identification information (eg, IP address, MAC address, model serial number, etc.).

According to an embodiment of the present invention, the service token may be a platform service token that can be used regardless of legacy services. That is, unlike the prior art, the user terminal 300 may use a plurality of legacy services using one service token. According to the present embodiment, the traffic required for issuing a service token will be greatly reduced, and thus the problem of unnecessarily increasing traffic related to authentication can be solved. Service tokens issued by the legacy service servers 200 and 210 may also be used as platform service tokens, which will be described later.

Next, the token key manager 106 is a module that performs a function of verifying a service token and renewing a valid period of the service token.

According to an embodiment of the present invention, the token key manager 106 delegates token verification and renewal tasks for a plurality of legacy services. Accordingly, the API manager 102 transmits the token verification request to the token key manager 106 without transmitting the token verification request to the legacy service servers 200 and 210 . According to this embodiment, various technical effects can be secured by concentrating the token verification function distributed in a plurality of legacy service servers (to be precise, the identity authentication manager) in the token key manager 106 . First, since no token verification traffic is generated between the platform service server 100 and the legacy service servers 200 and 210, authentication-related traffic can be greatly reduced. Second, the validity period of the service token (ie, the session of the service) is updated by the token key manager 106, so that the platform session can be maintained. That is, the inconvenience of a user undergoing a re-authentication procedure due to the termination of a specific session according to service switching is eliminated, and thus authentication-related traffic can be further reduced.

In particular, since the task of concentrating token-related functions in the token key manager 106 hardly requires implementation changes on the legacy service side, the above-described technical concept can be easily applied even in an environment where a number of legacy services exist. In addition, as the number of legacy services increases, the above technical effects can be further improved.

Next, the token storage 108 is a storage for storing service tokens.

A detailed description of the operation of each component (102, 104, 106, 108) of the platform service server 100 will be described in more detail with reference to FIGS. 3 to 7.

Each component of FIG. 2 may mean software or hardware such as a Field Programmable Gate Array (FPGA) or an Application-Specific Integrated Circuit (ASIC). However, the components are not limited to software or hardware, and may be configured to be in an addressable storage medium or configured to execute one or more processors. Functions provided within the components may be implemented by more subdivided components, or may be implemented as a single component that performs a specific function by combining a plurality of components. Also, each component shown in FIG. 2 may be implemented as an independent computing device.

So far, the configuration and operation of the platform service server 100 according to an embodiment of the present invention has been briefly reviewed. Hereinafter, a token-based legacy service authentication method according to some embodiments of the present invention will be described with reference to FIGS. 3 to 7 .

For reference, FIGS. 3 to 7 illustrate that the token-based legacy service authentication method is performed in the exemplary system environment shown in FIG. 1 . Accordingly, in an environment different from the exemplary system environment, it goes without saying that some steps of the token-based legacy service authentication method may be modified or some order may be changed.

3 is a flowchart illustrating a token-based legacy authentication method according to a first embodiment of the present invention. The method according to the first embodiment relates to a process of using a first legacy service through the platform service server 100 .

Referring to FIG. 3 , the token-based legacy authentication method according to the first embodiment starts at step S101 in which the user terminal 100 transmits a service use request to the API manager 102 . For example, the user terminal 100 may request an API call associated with the first legacy service.

In step S103, the API manager 102 requests authentication for the user to the platform common authentication manager 104. According to the authentication request, the platform common authentication manager 104 may provide the user terminal 300 with a user interface for login. When the service token is not included in the service use request, the API manager 102 may determine that user authentication is required and request authentication of the user to the common platform authentication manager 104 .

In step S105, the user terminal 300 performs a login procedure in conjunction with the platform common authentication manager 104. Figure 3 illustrates that login is performed based on ID/password, but this is for explaining some embodiments of the present invention, and the scope of the present invention is not limited thereto. If login is successfully performed, subsequent steps S107 to S121 may be performed.

In steps S107 to S111, the platform common authentication manager 104 issues a service token. The issued service token is transmitted to the token key manager 106 and the user terminal 300, and the token key manager 106 and the user terminal 300 store the issued service token.

In step S113, the user terminal 300 transmits a service use request including the issued service token to the API manager 102.

In step S115, the API manager 102 transmits a token verification request for the service token to the token key manager 106. That is, unlike the prior art, the API manager 102 does not transmit the token verification request to the identity authentication manager 203 of the legacy service server 200 to be used, but to the token key manager 106. By doing so, authentication-related traffic can be minimized, and token verification procedures can also be performed quickly.

In steps S117 and S119, the token key manager 106 verifies the validity of the requested service token. Also, in response to the validation decision, the token key manager 106 transmits a token verification success message to the API manager 330 . For example, the token key manager 106 may transmit the token verification success message to the API manager 106 when the same service token is stored and before the validity period of the requested service token expires. For another example, the token key manager 106 may transmit the token verification success message to the API manager 106 when the first legacy service is included in available service information of the requested service token.

Although not shown in FIG. 3, when it is determined that the requested service token is not valid, the token key manager 106 may allow authentication of the user terminal 300 to be performed again through the platform common authentication manager 104. there is.

In step S121, in response to receiving the token verification success message, the API manager 330 routes the service use request to the service module 201. That is, in response to receiving the token verification success message, the API manager 330 may allow the API call of the user terminal 300 and route the API call to the service module 201 . In the opposite case, the API manager 330 may block the service use request of the user terminal 300 .

4 is a flowchart illustrating a token-based legacy authentication method according to a second embodiment of the present invention. The method according to the second embodiment relates to a process of using the first legacy service after logging in through the self-authentication module 203 of the first legacy service server 200 . For convenience of description, descriptions of overlapping contents with those of the foregoing embodiments will be omitted.

Referring to FIG. 4 , the method according to the second embodiment starts at step S131 in which the user terminal 300 performs a login procedure through the identity authentication manager 203 of the first legacy service server 200. . The user terminal 300 may perform login by directly accessing the identity authentication manager 203 . Alternatively, the API manager 102 receiving the service use request of the user terminal 300 may request authentication from the identity authentication manager 203 . If login is successfully performed, subsequent steps (S133 to S147) may be performed.

In step S133, the identity authentication manager 203 issues a service token to the user terminal 300.

In step S135, the identity authentication manager 203 issues a service token to the token key manager 106. As the service token is also issued to the token key manager 106 in this step (S135), the service token issued by the legacy service server can be used as a platform service token. Accordingly, the number of times service tokens are issued can be reduced, and authentication-related traffic can be naturally reduced. The user terminal 300 may use the second legacy service with the service token issued in step S133, which will be described later with reference to FIG. 5.

In step S137, the token key manager 106 stores the issued service token.

In step S139, the user terminal 300 transmits a service use request including a service token to the API manager 102.

In steps S141 to S147, the API manager 102 interworks with the token key manager 106 to verify the service token, and routes the service use request to the service module 201 based on the verification result.

5 is a flowchart illustrating a token-based legacy authentication method according to a third embodiment of the present invention. The method according to the third embodiment relates to a process of using a second legacy service using a service token issued from the identity authentication manager 203 (hereinafter referred to as “first identity authentication manager”) of the first legacy service server 200. will be. For convenience of description, descriptions of overlapping contents with those of the foregoing embodiments will be omitted.

Referring to FIG. 5 , in steps S151 to S156 , as login is successfully performed, a service token is issued to the user terminal 300 and the token key manager 106 .

In step S157, the token key manager 106 stores the issued service token. Accordingly, a service token issued by the legacy service server side may be used as a platform service token.

In step S159, the user terminal 300 transmits a service use request including a service token to the API manager 102.

In steps S161 and S163, the API manager 102 transmits a token verification request for the service token to the token key manager 106. In addition, in response to receiving the token verification success message, the API manager 102 routes the service use request to the service module 211 (hereinafter referred to as “second service module”) of the second legacy service server 210 .

As described above, unlike the prior art, the user terminal 300 does not need to obtain a new service token for the second legacy service, and uses the service token issued by the first legacy service server to provide the second legacy service. available. Accordingly, traffic according to service token issuance may be reduced.

6 is a flowchart illustrating a token-based legacy authentication method according to a fourth embodiment of the present invention. The method according to the fourth embodiment relates to a process of maintaining a session regardless of a legacy service to be used. For convenience of description, descriptions of overlapping contents with those of the foregoing embodiments will be omitted.

Referring to FIG. 6 , in step S171 , the user terminal 300 transmits a service use request including a service token to the API manager 102 . At this time, it is assumed that the service use request is a use request for the second legacy service.

In step S173, the API manager 102 interworks with the token key manager 106 to verify the service token.

In step S175, the token key manager 106 updates the validity period of the service token. Specifically, the token key manager 106 may renew the validity period of the service token only when the service token is verified to be valid.

Here, the token key manager 106 may renew the validity period of the service token regardless of the legacy service to be used. For example, even if the service token is issued by the first identity authentication manager 203 and the service use request is a request for a second legacy service, the token key manager 106 determines the validity period of the service token. can be updated. By doing so, even if the legacy service to be used is changed, the session is maintained and the problem of requiring repeated authentication from the user can be solved.

Meanwhile, according to an embodiment of the present invention, the token key manager 106 may further verify whether identification information of the user terminal 300 and terminal identification information included in the service token match. In addition, only when the identification information matches, the token key manager 106 may renew the validity period of the service token. This is to prevent an unauthorized terminal from using a legacy service as the service token is stolen by another terminal. According to this embodiment, security across the entire platform can be improved.

In step S177, the API manager 102 routes the service use request to the second service module 211.

In step S179, the user terminal 300 transmits a service use request including a service token to the API manager 102. In this case, the service use request is a use request for the first legacy service.

In step S181, the API manager 102 interworks with the token key manager 106 to perform token verification on the service token. Since the validity period of the service token has been updated in the previous step S175, the service token can be determined to be valid in this step S181.

In step S183, the token key manager 106 renews the validity period of the service token. Through this process, the session of the user terminal 300 can be continuously maintained, and the user terminal 300 can freely use a plurality of services while switching without cumbersome procedures. That is, when the user terminal 300 uses the first legacy service again later, the user terminal 300 may use the first legacy service without re-issuing a service token.

In step S185, the API manager 102 routes the service use request to the first service module 211.

7 is a flowchart illustrating a token-based legacy authentication method according to a fifth embodiment of the present invention. The method according to the fifth embodiment relates to a process in which the platform common authentication manager 104 reissues a service token issued by the first identity authentication manager 203 . For convenience of description, descriptions of overlapping contents with those of the foregoing embodiments will be omitted.

Referring to FIG. 7 , in steps S201 to S207 , when login is successfully performed, the first identity authentication manager 203 issues a service token to the user terminal 300 and the token key manager 106 . The user terminal 300 and the token key manager 106 store the issued service token.

In step S209, the user terminal 300 transmits a service use request including a service token to the API manager 102. At this time, it is assumed that the service use request is a use request for the second legacy service.

In step S211, the API manager 102 interworks with the token key manager 106 to verify the service token.

In step S213, the token key manager 106 reissues a service token in conjunction with the platform common authentication manager 104. Specifically, when the service token is determined to be valid, the token key manager 106 requests the platform common authentication manager 104 to reissue the service token, and the platform common authentication manager 104 may reissue the service token. . In this case, information about legacy services available to the user terminal 300 may be recorded in the re-issued service token.

The reason why the platform common authentication manager 104 reissues the service token is that the first identity authentication manager 203 cannot know information about other legacy services available to the user terminal 300 . Since the platform common authentication manager 104 can know information about available services of the user terminal 300, in this step (S213), a service token is reissued and the available service information is recorded in the service token. Of course, the available service information may vary according to the authority of the user.

For reference, the service token reissuance step (S213) may be performed immediately after the above-described step (S205). That is, according to another embodiment, when a service token is issued from a specific legacy service server 200 or 210, the token key manager 106 may operate to automatically re-issue the service token.

In step S215, the platform common authentication manager 104 transmits the re-issued service token to the user terminal 300.

In step S217, the token key manager S217 stores the re-issued service token.

In step S219, the token key manager S217 performs verification on the re-issued service token. At this time, the token key manager S217 may check whether the second legacy service is included in available service information included in the re-issued service token. In other words, the token key manager S217 may verify whether the user terminal 300 has the right to use the second legacy service.

When the service token is successfully verified, a token verification success message is transmitted to the API manager 102 (S221), and the API manager 102 routes the service use request to the second service module 211.

So far, a token-based legacy service authentication method according to some embodiments of the present invention has been described with reference to FIGS. 3 to 7 . Hereinafter, an exemplary computing device capable of implementing the aforementioned platform service server 100 or its components 102, 104, and 106 will be described with reference to FIG. 8.

Referring to FIG. 8, the computing device 300 includes one or more processors 310, a bus 350, a communication interface 370, and a memory 330 that loads a computer program executed by the processor 310. And, the storage 390 for storing the computer program 391 may be included. However, only components related to the embodiment of the present invention are shown in FIG. 8 . Accordingly, those skilled in the art to which the present invention pertains can know that other general-purpose components may be further included in addition to the components shown in FIG. 8 .

The processor 310 controls the overall operation of each component of the computing device 300 . The processor 310 includes a Central Processing Unit (CPU), a Micro Processor Unit (MPU), a Micro Controller Unit (MCU), a Graphic Processing Unit (GPU), or any type of processor well known in the art. It can be. Also, the processor 310 may perform an operation for at least one application or program for executing a method according to embodiments of the present invention. Computing device 300 may include one or more processors.

Memory 330 stores various data, commands and/or information. Memory 330 may load one or more programs 391 from storage 390 to execute a method according to embodiments of the present invention.

The bus 350 provides a communication function between components of the computing device 300 . The bus 350 may be implemented as various types of buses such as an address bus, a data bus, and a control bus.

The communication interface 370 supports wired and wireless Internet communication of the computing device 300 . Also, the communication interface 370 may support various communication methods other than internet communication. To this end, the communication interface 370 may include a communication module well known in the art.

The storage 390 may non-temporarily store the one or more programs 391 . The storage 390 may be a non-volatile memory such as read only memory (ROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, or the like, a hard disk, a removable disk, or a device well known in the art. It may be configured to include any known type of computer-readable recording medium.

Computer program 391 may include instructions that when loaded into memory 350 cause processor 310 to perform methods according to some embodiments of the invention described above. The instruction is a series of instructions grouped on the basis of function, and refers to a component of a computer program and executed by a processor.

For example, the computer program 391 may include instructions for performing the functions of the token key manager 106 described above. In this case, the token key manager 106 may be implemented through the computing device 300 .

For another example, the computer program 391 may include instructions for performing the functions of the platform service server 100 described above. In this case, the platform service server 100 may be implemented through the computing device 300.

So far, referring to FIGS. 1 to 8 , several embodiments of the present invention and effects according to the embodiments have been described. The effects of the present invention are not limited to the effects mentioned above, and other effects not mentioned will be clearly understood by those skilled in the art from the description below.

The concept of the present invention described with reference to FIGS. 1 to 8 so far can be implemented as computer readable code on a computer readable medium. The computer-readable recording medium may be, for example, a removable recording medium (CD, DVD, Blu-ray disc, USB storage device, removable hard disk) or a fixed recording medium (ROM, RAM, computer-equipped hard disk). can The computer program recorded on the computer-readable recording medium may be transmitted to another computing device through a network such as the Internet, installed in the other computing device, and thus used in the other computing device.

In the above, even though all the components constituting the embodiment of the present invention have been described as being combined or operated as one, the present invention is not necessarily limited to these embodiments. That is, within the scope of the object of the present invention, all of the components may be selectively combined with one or more to operate.

Although actions are shown in a particular order in the drawings, it should not be understood that the actions must be performed in the specific order shown or in a sequential order, or that all shown actions must be performed to obtain a desired result. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of the various components in the embodiments described above should not be understood as requiring such separation, and the described program components and systems may generally be integrated together into a single software product or packaged into multiple software products. It should be understood that there is

Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art to which the present invention pertains can be implemented in other specific forms without changing the technical spirit or essential features of the present invention. can understand that Therefore, the embodiments described above should be understood as illustrative in all respects and not limiting. The protection scope of the present invention should be construed according to the claims below, and all technical ideas within the equivalent range should be construed as being included in the scope of the present invention.

Claims (11)

In the method of providing a platform-based integrated authentication service for a plurality of legacy services,
Storing a service token issued by any one of a platform common authentication manager and a plurality of identity authentication managers associated with the plurality of legacy services and stored in a user's terminal in a token key manager - the plurality of identity authentication managers A first identity authentication manager having a token issuance and verification function for a first legacy service and a second identity authentication manager having a token issuance and verification function for a second legacy service -;
Receiving, by an API manager, a service request for the first legacy service including the service token from the terminal of the user;
Sending, by the API manager, a verification request for the service token to the token key manager instead of the first identity authentication manager, in response to the service request, wherein the API manager verifies the token for the second legacy service. send request also to the token key manager -; and
Routing, by the API manager, the service request to a server providing the first legacy service in response to receiving a token verification success message about the service request from the token key manager.
Token-based legacy service authentication method. According to claim 1,
The service token is a platform service token,
The platform service token is issued by the platform common authentication manager as a result of platform login by the user.
Token-based legacy service authentication method. According to claim 2,
Sending, by the token key manager, the token verification success message to the API manager when the platform service token is stored and before the validity period of the platform service token expires,
Token-based legacy service authentication method. According to claim 1,
The service token is a platform service token,
The platform service token is issued by the first identity authentication manager as a result of the user logging in to the first legacy service.
Token-based legacy service authentication method. According to claim 4,
The service request is a first service request,
Receiving, by the API manager, a second service request for the second legacy service including the service token from the terminal of the user; and
In response to receiving, by the API manager, a token verification success message for the second service request from the token key manager, routing the second service request to a server providing the second legacy service ,
Token-based legacy service authentication method. According to claim 1,
Further comprising, by the token key manager, providing a platform session maintenance function by updating the validity period of the service token included in the token verification request regardless of the legacy service to be used,
Token-based legacy service authentication method. According to claim 6,
The service token includes identification information of the issuance request terminal,
The step of providing the platform session maintenance function,
Providing the platform session maintenance function only when the identification information of the issuance request terminal and the identification information of the user's terminal match,
Token-based legacy service authentication method. According to claim 1,
The step of transmitting to the token key manager,
Further comprising, by the token key manager, sending an authentication request of the user to the platform common authentication manager in response to determining that the service token is invalid.
Token-based legacy service authentication method. According to claim 1,
The service request is a first service request,
The service token is a token issued by the first identity authentication manager as a result of the user logging in to the first legacy service,
In the service token, the first legacy service is recorded as available service information,
The token key manager, in response to determining that the service token is valid, issuing a platform service token through the platform common authentication manager and providing the platform service token to the terminal of the user - the platform service token includes the first legacy service and the second legacy service is recorded as available service information -;
Receiving, by the API manager, a second service request for the second legacy service including the platform service token from the terminal of the user; and
In response to receiving, by the API manager, a token verification success message for the second service request from the token key manager, routing the second service request to a server providing the second legacy service ,
Token-based legacy service authentication method. According to claim 9,
The token verification success message for the second service request,
Generated as a result of the token key manager performing token verification based on available service information recorded in the platform service token,
Token-based legacy service authentication method. a token storage for storing service tokens associated with the first legacy service and the second legacy service;
a token key manager performing token verification on the service token;
In response to receiving a service request for the first legacy service including a first service token from the user's terminal, a token verification request for the first service token is sent to the token key manager instead of the first identity authentication manager. Transmitting API manager - The first identity authentication manager is a module having a token issuance and verification function for the first legacy service, and the second identity authentication manager has a token issuance and verification function for the second legacy service. a module, wherein the API manager also transmits a token verification request for the second legacy service to the token key manager; and
Including a platform common authentication manager that performs platform authentication for the user,
The API manager routes the service request to a server providing the first legacy service in response to receiving a token verification success message regarding the first service token from the token key manager;
The first service token is issued by at least one of the platform common authentication manager, the first identity authentication manager, and the second identity authentication manager.
Platform Services Server.

Images