Method and System for Integrating Authentication Based on an Internal Authentication Process Using a Session State Machine
Patent Information
- Application Number
- KR1020260008459
- Authority / Receiving Office
- KR · KR
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2026-01-16
- Publication Date
- 2026-09-18
Smart Images
Figure PAT00003_ABST
Abstract
Description
Technology Field
[0001] The present invention relates to an authentication integration method in an artificial intelligence agent system using a Large Language Model (LLM), and more specifically, to an authentication integration method and system that efficiently manages the authentication and session states required when an LLM agent accesses external tools or resources using an internal authentication server for the integration of various authentication methods and secure session management. Background Technology
[0002] Existing Large Language Model (LLM)-based systems primarily operate by providing answers based on pre-trained data, but recently, methods that access and utilize external resources, such as external tools, are emerging.
[0003] Application Programming Interface (API) integration is utilized as a method for large-scale language models to access external resources, and authentication and session management are essential for such API integration.
[0004] Conventional authentication and session management methods for accessing external resources include hardcoding tokens into the external tool itself, having a large-scale language model receive and utilize tokens directly from the user, or delegating tokens to an external service.
[0005] However, these conventional technologies have issues regarding security and usability. Specifically, if tokens are hardcoded into the tool itself, all users may be recognized as a single user with the same authority. This makes user-specific permission management impossible and allows for data access and viewing between users, thereby posing a serious security risk. In the case of large-scale language models that directly receive and utilize tokens from users, there is a risk that such information may be exposed externally through external monitoring tools. Furthermore, if conversational data is reused as training data, there is a concern that token information may be leaked through malicious attacks such as prompt injection. In the case of delegating tokens to external services, if the security of the external service itself is weak, it can lead to additional security vulnerabilities where users' sensitive authentication information is exposed.
[0006] Therefore, there is a growing need for authentication integration technology that can overcome these conventional problems and limitations.
[0007] *8 Prior art literature
[0008] Korean Patent Publication No. 10-2023-0147840 (Publication Date: Oct. 24, 2023) The problem to be solved
[0009] To solve the problems of the prior art described above, one embodiment of the present invention aims to provide an authentication linkage method and system using an internal authentication process in a large-scale language model application environment, which can fundamentally block the possibility of token leakage, eliminate dependency on external services, and minimize the possibility of token leakage by centrally storing and managing authentication tokens securely without directly transmitting user authentication information to the large-scale language model through session management independent of the workflow of the large-scale language model.
[0010] One embodiment of the present invention aims to provide an authentication integration method and system using an internal authentication process in a large-scale language model application environment, which integrates the lifecycle of an LLM agent and an authentication session so that authentication is naturally processed in the middle of the LLM agent's lifecycle, thereby providing a protocol-independent authentication session to perform authentication processing flexibly and stably.
[0011] One embodiment of the present invention aims to provide an authentication linkage method and system using an internal authentication process in a large-scale language model application environment, which can manage various authentication subjects in parallel even within the same thread by defining a profile unit.
[0012] However, the technical problems that the present disclosure aims to solve are not limited to the technical problems described above, and other technical problems may exist. means of solving the problem
[0013] One feature of the present disclosure proposes an authentication integration method based on an internal authentication process using a session state machine. The authentication integration method is performed in an authentication integration system in a large-scale language model application environment and comprises the steps of: a user client providing a request to a Large Language Model (LLM) agent; the LLM agent receiving an authentication resource identifier for a user to access the external tool by integrating with an external tool, and transmitting the authentication resource identifier to the user client; the user client performing an authentication process with an authentication server based on the authentication resource identifier; if the authentication process is successfully performed, the authentication server generating an authentication code and redirecting to an authentication integration server; and the authentication integration server receiving the authentication code integrating with the authentication server to issue and store an access token. The authentication integration server includes the step of setting or transitioning an authentication session state according to the progress state of the authentication process based on a session state machine—the session state machine includes a plurality of session states that are differently configured according to changes in the session—and the session state machine distinguishes and sets the session using at least one of a user profile, a thread identifier, and a provider.
[0014] The above authentication resource identifier is a string URI (Uniform Resource Identifier) for identifying a specific resource on the Internet, and may include an address URL (Uniform Resource Locator) indicating the location of the specific resource.
[0015] The step of the user client performing an authentication process with an authentication server based on the above authentication resource identifier may include: the user client providing the authentication resource identifier to a resource owner who is a user; the resource owner performing an authentication request through a user agent, and the user agent providing the authentication request of the resource owner to the authentication server; and the authentication server generating a resource owner authentication in response to the authentication request and providing it to the user agent.
[0016] The step of the authentication server generating an authentication code and redirecting to the authentication integration server when the above authentication process is successfully performed may include the step of the authentication server generating the authentication code when the resource owner responds to the resource owner authentication.
[0017] When the above authentication process is successfully performed, the step of the authentication server generating an authentication code and redirecting to the authentication integration server may further include the step of the authentication server redirecting the generated authentication code to the user agent.
[0018] The step of the authentication server generating an authentication code and redirecting to the authentication integration server when the above authentication process is successfully performed may further include the step of the user agent redirecting the authentication code to the authentication integration server.
[0019] The step of the user agent redirecting the authentication code to the authentication integration server may include: the step of the user agent redirecting the authentication code to the server; and the step of the server redirecting the authentication code to the authentication integration server.
[0020] The above authentication linkage method may further include the step of the authentication linkage server individually managing user authentication sessions according to the session state machine.
[0021] Another feature of the present disclosure proposes an authentication linkage system based on an internal authentication process using a session state machine. The authentication linkage system comprises: a user client providing a request; a Large Language Model (LM) agent that receives the request, receives an authentication resource identifier for a user to access the external tool in conjunction with an external tool, and transmits the authentication resource identifier to the user client; an authentication server that performs an authentication process with the user client based on the authentication resource identifier, and if the authentication process is successfully performed, generates an authentication code and redirects to an authentication linkage server; and an authentication linkage server that receives the authentication code, issues and stores an access token in conjunction with the authentication server, and sets or transitions an authentication session state according to the progress status of the authentication process based on a session state machine—the session state machine includes a plurality of session states that are set differently according to changes in the session. The session state machine can distinguish and set the session using at least one of a user profile, a thread identifier, and a provider. Effects of the invention
[0022] According to embodiments of the present invention, the effect of preventing the leakage of authentication information and implementing a secure authentication session management system is provided.
[0023] According to embodiments of the present invention, user authentication information is not directly transmitted to the LLM through a session management system independent of the workflow of a large-scale language model, thereby effectively preventing the possibility of token leakage at the source.
[0024] According to embodiments of the present invention, authentication tokens are stored and managed securely in a central location, and the necessary tokens are inserted directly into the tool without reference to the LLM, thereby providing a more secure authentication management effect.
[0025] According to embodiments of the present invention, by placing components required for authentication on the workflow of a large-scale language model, the effect is to eliminate dependencies on external services and minimize the possibility of token leakage.
[0026] According to embodiments of the present invention, the effect of defining an authentication session lifecycle independent of the protocol and precisely implementing it is provided. Through this, in an authentication session management system operating independently of an LLM agent, the lifecycle of an authentication session, such as creation, renewal, and expiration, can be systematically defined, and a consistent session lifecycle can be applied across various protocols, such as OAuth2 and Token-based authentication, thereby providing flexible authentication management that is not dependent on a specific protocol.
[0027] According to embodiments of the present invention, by utilizing an authentication session lifecycle independent of the protocol, the effect of preventing the exposure of sensitive user information due to external attacks, such as prompt injection, is provided.
[0028] According to embodiments of the present invention, the effect of providing independent session management by provider and profile is provided. Through this, by defining profile units, the effect of managing various authentication subjects—e.g., providers, scopes of authority, etc.—in parallel within the same thread can be provided. In addition, the effect of effectively performing updates and re-authentication is provided by separating scopes and authority by profile.
[0029] The effects according to the present disclosure are not limited to those exemplified above, and a wider variety of effects are included within the present disclosure. Brief explanation of the drawing
[0031] FIG. 1 is a diagram illustrating an authentication linkage system utilizing a session state machine in a large language model application environment according to one embodiment of the present disclosure. FIG. 2 is a conceptual diagram illustrating an authentication linkage device utilizing a session state machine in a large language model application environment according to one embodiment of the present disclosure. FIG. 3 is a flowchart illustrating a method for authorizing a user's API access using an OAuth protocol according to an embodiment of the present invention. FIG. 4 is a flowchart illustrating a method for authorizing a user's API access using a large-scale language model (LLM) and a tool according to an embodiment of the present invention. FIG. 5 is a flowchart illustrating an example of an authentication linkage method using an external authentication service in a large-scale language model environment according to an embodiment of the present invention. FIG. 6 is a flowchart illustrating an example of an authentication linkage method using an internal authentication process in a large-scale language model environment according to an embodiment of the present invention. FIG. 7 is a flowchart illustrating an example of a specific process of the authentication linkage method shown in FIG. 6. FIG. 8 is a diagram illustrating an example of a state transition diagram explaining a session state machine according to one embodiment of the present disclosure. Figure 9 is a table illustrating an example of a state transition for a session state of a session state machine. FIG. 10 is a drawing illustrating an example of the configuration of multiple profiles and thread IDs according to one embodiment of the present disclosure. FIG. 11 is a block diagram illustrating an authentication linkage server using an internal authentication process in a large-scale language model application environment according to one embodiment of the present disclosure. Specific details for implementing the invention
[0032] Specific structural or functional descriptions of embodiments according to the concept of the present invention disclosed herein are provided merely for the purpose of explaining embodiments according to the concept of the present invention, and embodiments according to the concept of the present invention may be implemented in various forms and are not limited to the embodiments described herein.
[0033] Embodiments according to the concept of the present invention may be subject to various modifications and may take various forms; therefore, embodiments are illustrated in the drawings and described in detail in this specification. However, this is not intended to limit the embodiments according to the concept of the present invention to specific disclosed forms, and includes modifications, equivalents, or substitutions that fall within the spirit and scope of the present invention.
[0034] Terms such as "first" or "second" may be used to describe various components, but said components shall not be limited by said terms. For the sole purpose of distinguishing one component from another, for example, without departing from the scope of rights according to the concept of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component.
[0035] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. Conversely, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between. Expressions describing the relationships between components, such as "between," "exactly between," or "directly adjacent to," should be interpreted in the same way.
[0036] The terms used herein are used merely to describe specific embodiments and are not intended to limit the invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as “comprising” or “having” are intended to specify the existence of the described features, numbers, steps, actions, components, parts, or combinations thereof, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.
[0037] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this specification.
[0038] In this specification, the term "processor" may refer to hardware capable of performing functions and operations according to each name described in this specification, computer program code capable of performing specific functions and operations, or an electronic recording medium loaded with computer program code capable of performing specific functions and operations.
[0039] In other words, the term "processor" may refer to a functional and / or structural combination of hardware for carrying out the technical concept of the present invention and / or software for driving said hardware.
[0040] Hereinafter, embodiments will be described in detail with reference to the attached drawings. However, the scope of the patent application is not limited or restricted by these embodiments. Identical reference numerals in each drawing denote identical components.
[0042] FIG. 1 is a diagram illustrating an authentication linkage system using an internal authentication process in a large-scale language model application environment according to one embodiment of the present disclosure.
[0043] In FIG. 1, an authentication linkage system using an internal authentication process in a large-scale language model application environment (hereinafter abbreviated as ‘authentication linkage system’) may include a user terminal (100) and an authentication linkage server (300) existing within an intranet such as the user terminal (100). According to an embodiment, the authentication linkage system may further include an authentication server (not shown).
[0044] The authentication linkage system can operate based on the large-scale language model (500) by linking with the large-scale language model (500) and external tools (700) outside or inside the intranet.
[0045] The authentication integration system manages authentication information per user profile or thread, integrates the lifecycle of authentication sessions, and can perform authentication independently of the protocol. To this end, the authentication integration system can perform updates or authentication based on provider- or profile-independent session management.
[0046] The authentication linkage system may include an authentication server and an authentication linkage server (300). The authentication server performs functions such as performing authentication in the authentication flow and issuing an access token, and the authentication linkage server (300) may perform functions such as requesting and storing an access token from the authentication server based on an authentication code by linking with the authentication server. In FIG. 3 and below, the authentication server and the authentication linkage server are distinguished and each function is described in detail, but depending on the embodiment, the authentication server and the authentication linkage server may be implemented as detailed functions of a single server.
[0047] The user is a target that performs various services utilizing a large-scale language model (500) through a user terminal (100). The user terminal (100) is an electronic device such as a smart device (e.g., a smartphone), a PC (personal computer), or a portable laptop computer.
[0048] In FIG. 1, the user terminal (100) is represented as an integrated unit, but in FIG. 3 and below, the user and the user terminal (100) are distinguished by their respective roles, such as Resource Owner, Client, and User Agent, and explained more specifically.
[0050] FIG. 2 is a conceptual diagram for explaining an authentication linkage device (hereinafter abbreviated as ‘authentication linkage device’) using an internal authentication process in a large-scale language model application environment according to one embodiment of the present disclosure.
[0051] The authentication linkage device (300) may include a processor (310) and a memory (320).
[0052] The authentication linkage device (300) may further include a communication module for being communicated to a user device (100) via wireless communication or wired communication. The communication module may include communication circuitry.
[0053] The processor (310) may include, as an example, at least one of a microprocessor, a central processing unit, a processor core, a multi-core processor, a multiprocessor, an ASIC (Application-Specific Integrated Circuit), or an FPGA (Field Programmable Gate Array), but is not limited thereto.
[0054] Memory (320) can store instructions (or programs) that can be executed by the processor (310). Memory (320) may include volatile memory or non-volatile memory. Volatile memory may be implemented as dynamic random access memory (DRAM), static random access memory (SRAM), thyristor RAM (T-RAM), zero capacitor RAM (Z-RAM), or twin transistor RAM (TTRAM). Non-volatile memory can be implemented as EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, MRAM (Magnetic RAM), Spin-Transfer Torque (STT)-MRAM, Conductive Bridging RAM (CBRAM), FeRAM (Ferroelectric RAM), PRAM (Phase change RAM), Resistive RAM (RRAM), Nanotube RRAM, Polymer RAM (PoRAM), Nano Floating Gate Memory (NFGM), holographic memory, Molecular Electronic Memory Device, or Insulator Resistance Change Memory.
[0055] The authentication linkage device (300) may perform session management by having a session state machine. This session state machine may be an artificial intelligence model or software module that operates individually, and may be implemented as part of a processor (310), but is not limited thereto, and a separate processor may be used for each module.
[0056] The user terminal (100) is a device used by a user, and the user can be communicated with the authentication linkage device (300) through the user terminal (100). The user terminal (100) is a device such as a smart device (e.g., a smartphone), a PC (personal computer), or a portable laptop computer, and can run a user agent (110) (or program).
[0057] The authentication linkage device (300) can operate interactively with the user terminal (100) and the large-scale language model (500) to perform authentication processing for requests occurring at the user terminal (100).
[0058] This authentication linkage device (300) may be an authentication linkage server described below, and depending on the embodiment, it may be a device that operates including the functions of an authentication server and an authentication linkage server.
[0060] Hereinafter, with reference to FIGS. 3 to 9, various embodiments of an authentication linkage method and system using an internal authentication process in a large-scale language model application environment according to the present invention will be described.
[0062] In the following, when describing each component and authentication method of the authentication integration system, terms are defined and explained as follows.
[0063] Open Authentication refers to an authentication / authorization protocol designed to allow third-party applications (clients) to access resources with limited authority without directly exposing user credentials. In the following diagrams and detailed descriptions, it may be abbreviated as 'OAuth'. For example, Open Authentication may be the OAuth 2.0 standard protocol and enables clients to securely access protected resources through the Access Token issuance process.
[0064] The Open Authentication Flow refers to the OAuth authentication process, which can also be expressed as the Authorization Code Grant Flow. In the diagrams and detailed descriptions below, it may be abbreviated as 'OAuth Flow'. It includes the process of authentication requests from the client to the Authorization Server and the issuance of an Access Token, and may utilize a redirect URI and an Authorization Code in which the Resource Owner approves the authentication.
[0065] In the OAuth Flow, a resource owner refers to an end user who holds access rights to data or resources. For example, when a user utilizing a specific API grants access to their account to a third-party application (client), that user can become the resource owner.
[0066] An Authorization Server is a server that performs authentication on behalf of the resource owner in the OAuth Flow and issues access tokens to client applications. For example, OAuth authentication endpoints provided by Google, GitHub, Slack, etc., can serve as authorization servers.
[0067] The Internal Auth Server can manage authentication information by user profile or thread, integrate the lifecycle of authentication sessions, and perform authentication independently of the protocol. For example, it can request an access token from the authentication server, store the access token provided therefrom, and manage authentication information.
[0068] A token refers to a string used by a client to prove authentication or authorization. It can encompass OAuth-based access tokens and refresh tokens, as well as API tokens issued and delivered directly by the user. Examples of API tokens include Slack Bot Tokens and GitHub Personal Access Tokens.
[0070] Hereinafter, with reference to FIGS. 3 to 7, various embodiments of an API authentication method during the operation of an application will be described.
[0072] FIG. 3 is a flowchart illustrating a method for authorizing a user's API access using an OAuth protocol according to an embodiment of the present invention.
[0073] When a client initiates an authentication request, the UserAgent can redirect the authentication request to the Authorization Server (Step (A)).
[0074] The authentication server can obtain authorization—e.g., login—by performing grant access from the resource owner through an authentication process with the resource owner (Step (B)).
[0075] Afterwards, the authentication server may issue an authorization code based on the granted authority and provide it to the client (Step (C)).
[0076] The client connects to the authentication server based on the authentication code and requests and receives an access token (Step (D)), and thereafter, the client can be granted access to the protected resource based on the access token.
[0077] In one embodiment illustrated in FIG. 3, access authentication to a target resource server is possible by issuing an authentication code and issuing a user's access token based on it, without accessing actual authorization information—e.g., an ID and password for actual login—from the client.
[0078] In other words, it is a method that dynamically issues and utilizes access tokens by requesting only the permissions required by the application, enabling secure and granular permission management.
[0080] FIG. 4 is a flowchart illustrating a method for authorizing a user's API access using a large-scale language model (LLM) and a tool according to an embodiment of the present invention.
[0081] Since general LLM systems are limited by pre-learned content regarding user input, LLM agent systems that enable functions for interacting with external data—such as API calls or interaction with external databases—are being utilized in recent years. LLM agents can provide action planning and execution functions, such as interacting with external resources through API calls or database searches, calling specific tools according to user requests, or planning and performing executable tasks.
[0082] Tools are used as external functions that interact with these LLM agents; in other words, a tool is a module designed to extend the capabilities of the LLM agent, providing diverse utility such as performing calculations, searches, and automation tasks based on user input.
[0083] The combination of such LLM agents and tools opens up possibilities as behavior-based interfaces beyond simply providing answers and can significantly improve the user experience; however, for the integration of external APIs for using tools with LLM, authentication and authorization processes must be performed to prove that the LLM is the user's agent.
[0084] Figure 4 is a diagram illustrating the LLM workflow sequence process between the client, server, LLM, and tool.
[0085] Referring to Fig. 4, when a client provides a request to a server, the server generates a Request Generate Response based on the request received from the client and provides it to the LLM. The LLM invokes a tool required for the Request Generate Response to request additional information, generates a response based on the Tool Result provided by the tool, and provides it to the server. The server delivers the response received from the LLM to the client.
[0086] In this process, the LLM agent system can call external tools to perform additional tasks depending on the situation during the LLM workflow sequence. Furthermore, authentication logic is essential to access external resources during this process. Therefore, authentication can be performed using tokens during these requests. In other words, authentication for each request can be performed using a token directly issued to the user.
[0087] For example, if a user enters a request to 'view today's meeting schedule in Google Calendar,' the LLM agent system may call the Google Calendar API to process the request. In this process, authentication can be completed using a token that proves the system is acting as the user's agent to retrieve the user's Google Calendar data. In other words, this applies to cases where the LLM agent directly receives and utilizes a token from the user. As previously explained, this poses a risk of such information being exposed externally through external monitoring tools. Furthermore, if conversational data is reused as training data, there is a concern that token information could be leaked through malicious attacks such as prompt injection. Due to these limitations, there are significant restrictions on the LLM agent system retrieving user authentication information.
[0089] FIG. 5 is a flowchart illustrating an example of an authentication method using external tool authentication in a large-scale language model environment according to an embodiment of the present invention.
[0090] Referring to FIG. 5, the LLM agent calls a tool in response to a user request, as described above with reference to FIG. 4. Meanwhile, in this embodiment, OAuth authentication is performed during the tool calling process.
[0091] In other words, when an External Tool Auth. service is required to perform authentication, it generates an Authorization URI and delivers it to the user, i.e., the resource owner. This delivery process can proceed to the resource owner via an LLM, a server, and a client.
[0092] Subsequently, the OAuth authentication process can be performed. That is, the user can perform the authentication process with the Authorization Server through a user agent—e.g., a browser or app—using an Authorization Resource Identifier (Authorization URI). Specifically, the user requests authentication from the Authorization Server through the user agent (Request Authorization), and the Authorization Server can authenticate the user, who is the resource owner, in response (Authenticate Resource Owner). If authentication is successful, the Authorization Server requests an authentication redirection while providing the Authorization Code to the user agent, and the user agent can perform the authentication procedure by requesting an access token from an External Tool Auth. service based on the received Authorization Code and receiving it.
[0093] Until this authorization process is completed, LLM requests transition to a waiting and retry state. After the access token is issued, requests requiring authentication can be retried to generate an LLM response.
[0094] In the case of this embodiment, there is a limitation that user token information can be stored in an external system, so there may be security risks such as token leakage.
[0096] FIG. 6 is a flowchart illustrating an example of an authentication linkage method using an internal authentication process in a large-scale language model environment according to an embodiment of the present invention, and FIG. 7 is a flowchart illustrating an example of a specific process of the authentication linkage method shown in FIG. 6.
[0097] An embodiment illustrated in FIGS. 6 and 7 relates to a method for performing authentication linkage using an internal authentication process, that is, an internal authentication server, in order to compensate for authentication security vulnerabilities in existing LLM agent systems.
[0098] In addition, an embodiment illustrated in FIGS. 6 and 7 can solve various problems that existed in conventional session management, such as the following.
[0099] In other words, as an example of existing session management, in the case of OAuth2 authentication sessions, there is a problem in that there is no way to clearly define or manage the lifecycle of the created authentication session.
[0100] Consequently, there is a limitation in that if an authenticated session expires, it is impossible to refresh the existing session or re-authenticate it, making it impossible to process the re-authentication of the expired session.
[0101] Furthermore, in existing session management, there was a limitation in that consistent session management for different authentication protocols was impossible when using authentication protocols other than OAuth2 (such as token-based authentication), as the authentication protocols differed.
[0102] Furthermore, existing session management had a limitation in that the process of requesting additional permissions or re-authenticating was not effectively implemented when an authenticated session did not meet the permission scope required for a specific request, resulting in insufficient re-authentication functionality for expanding the permission scope.
[0103] Furthermore, in existing session management, when multiple resource owners were involved within a single conversation in the LLM agent system, session selection between multiple resource owners was impossible, and due to the absence of multi-profile management, there was a problem in that complex authentication requirements between multiple profiles could not be satisfied.
[0104] In FIGS. 6 and 7, the aforementioned problems can be solved by converting the authentication process into an internal process using an authentication linkage server (300), which is an internal authentication server.
[0105] Referring to FIG. 6, when a client of a user terminal (100) provides a request to an LLM agent (S601), the server (700) can generate a request for response generation and provide it to the LLM agent (500) (S602).
[0106] The LLM agent (500) receives an authentication resource identifier (URI) for a user to access the external tool by linking with the external tool (S603), and can transmit this authentication resource identifier (URI) to the user's client via the server (S604, S605).
[0107] Here, the authentication resource identifier is a string URI (Uniform Resource Identifier) for identifying a specific resource on the Internet, and may include an address URL (Uniform Resource Locator) indicating the location of said specific resource.
[0108] The user's client performs an authentication process with the authentication server (301) to verify the authentication and session connection from the user, who is the resource owner (6S06), and if the verification is successful, generates an authentication code and redirects the authentication code to the authentication linkage server (300) (S607, S608). In the embodiment of FIG. 6, an example is illustrated in which the authentication code redirection is performed via the server (700), but it is not limited thereto, and depending on the embodiment, the redirection from the authentication server (301) to the authentication linkage server (300) may be performed directly.
[0109] Afterwards, an access token is issued between the authentication linkage server (300) and the authentication server (301), and lifecycle management of the access token is performed at the authentication linkage server (300).
[0110] Specifically, the authentication linkage server (300) requests an access token from the authentication server (301) based on an authentication code (S609), and the authentication server (301) verifies the authentication code and provides the corresponding access token to the authentication linkage server (300) (S610). The authentication linkage server (300) stores the access token and can perform authentication, etc., for a request from a user client based on the stored access token.
[0112] FIG. 7 is a flowchart illustrating an example of a specific process of the authentication linkage method shown in FIG. 6.
[0113] Referring to Fig. 7, when a client of a user terminal, i.e., a user client, provides a request to an LLM agent through a server, the server can generate a request for response generation and provide it to the LLM agent.
[0114] The LLM agent can receive an authentication resource identifier (URI) for a user to access the external tool by integrating with an external tool (External Tool Auth.) from the external tool, and transmit this authentication resource identifier (URI) to the user's client via a server.
[0115] The user's client can perform an authentication process (OAuth Authorization Process) with the authentication server.
[0116] Specifically, a user client provides an authentication resource identifier to a user resource owner (Send Authorization URI), the resource owner performs an authentication request through a user agent, and the user agent can provide the resource owner's authentication request to an authentication server (Request Authorization).
[0117] The authentication server generates an Authenticate Resource Owner in response to an authentication request and provides it to the user agent, and the resource owner verifies this and performs Grant Access to the Resource Owner Authentication, thereby successfully completing the authentication process.
[0118] If the authentication process is successfully performed, the authentication server can generate an authorization code and redirect to the Internal Auth. Server.
[0119] Specifically, when the resource owner responds to the resource owner authentication, the authentication server can generate an authentication code. Subsequently, the authentication server redirects the generated authentication code to the user agent, and the user agent can redirect the authentication code to the authentication integration server. In FIG. 7, the user agent redirects the authentication code to the authentication integration server via a server, but this is not limited thereto.
[0120] When the authentication integration server receives an authentication code, it can link with the authentication server based on the authentication code to issue and store an access token.
[0121] Specifically, the authentication integration server requests an access token from the authentication server based on an authentication code (Request Access Token), and the authentication server verifies the authentication code and provides the corresponding access token to the authentication integration server (Return Access Token). The authentication integration server stores the access token and can perform authentication for a request from a user client based on the stored access token.
[0122] The authentication integration server stores and manages access tokens and related authentication information, and the authentication integration management performed by this authentication integration server can be performed based on a session state machine.
[0123] For example, an authentication integration server can configure a session state machine that includes multiple session states configured differently depending on changes in the session, and can manage user authentication sessions individually according to the session state machine.
[0125] Here, the session state machine can be configured to distinguish sessions using at least one of a user profile, a thread identifier, and a provider.
[0126] Through this, tracking and management of previous authentication status, management of multiple profiles and providers, and management of session expiration and permission scopes can be provided. This will be explained in more detail with reference to FIG. 8.
[0128] FIG. 8 is a diagram illustrating an example of a state transition diagram explaining a session state machine according to one embodiment of the present disclosure, and FIG. 9 is a table illustrating an example of a state transition for a session state of a session state machine.
[0129] The session state machine systematically manages the complex authentication process of the LLM agent system, clearly defines each state, and can handle transitions between states.
[0130] The session state machine includes multiple session states, and for example, the session states may include NO_SESSION, PENDING_RESOLVED, RESOLVED, SKIP_AUTH, DO_AUTH, and DO_REFRESH.
[0131] The session state NO_SESSION signifies a state where there is no user authentication at all. The initiation condition is when the user makes an authentication request for the first time or when the previous session expires, and the transition condition is that the session state transitions to PENDING_RESOLVE when an Authorization URI is issued to the user and an authentication request is made.
[0132] The session state PENDING_RESOLVED refers to a state where the system waits for the user to complete authentication in an external browser after the authentication URI has been issued. The initiation condition is when the authentication resource identifier is delivered to the user and the authentication process is in progress, and the transition condition is that the session state switches to RESOLVED upon receiving the authentication code.
[0133] The session state RESOLVED means that authentication is complete and the access token is ready to be issued via the authentication code. The start condition is initiated when the server receives the authentication code, and the transition condition is to the session state SKIP_AUTH when the access token is issued.
[0134] The session state SKIP_AUTH signifies a state where authentication is complete, the necessary scope is met, and the access token is valid. The initiation condition is when the access token is issued and all request conditions are met, and the transition condition is that the session state transitions to DO_REFRESH upon the access token's expiration. Alternatively, it transitions to DO_AUTH if additional permissions are required.
[0135] The session state DO_AUTH indicates a state where authentication information exists, but the scope or provider authentication required for the current request is lacking. The initiation condition is when the current session does not meet the authorization requirements or requires authentication from another provider, and the transition condition is to transition to the session state PENDING_RESOLVE after reissuing the authentication resource identifier and requesting authentication.
[0136] The session state DO_REFRESH means that the access token has expired and an attempt is made to refresh it with a Refresh Token. The start condition is the expiration of the access token, and the transition condition is that if the refresh with the Refresh Token is successful, the session state is switched to SKIP_AUTH, or if the refresh with the Refresh Token fails, the session state is returned to NO_SESSION and a new session can be created.
[0137] These session states allow for tracking of previous authentication states. In other words, user authentication progress can be clearly tracked through state-based transitions. For instance, if a user fails to complete authentication, the authentication progress can be checked by waiting in the PENDING_RESOLVE state.
[0138] In addition, session expiration and renewal can be automated. For example, expiration and renewal can be automated by attempting automatic renewal with a refresh token in the DO_REFRESH state, or by returning to NO_SESSION upon refresh failure to prompt user authentication again.
[0139] In addition, it is possible to handle permission expansion and scope addition. For example, when an additional permission request is made, it switches to DO_AUTH, allowing the permission scope to be dynamically expanded through a new authentication request.
[0140] In addition, multiple profiles and providers can be supported. FIG. 10 illustrates an example of the configuration of such multiple profiles and thread IDs, and as shown in the example of FIG. 10, sessions can be managed independently based on at least one of a user-specific thread ID, provider, and profile. Through this, various workflows can be reliably processed even within the same thread.
[0142] FIG. 11 is a block diagram illustrating an authentication linkage server using an internal authentication process in a large-scale language model application environment according to one embodiment of the present disclosure.
[0143] FIG. 11 illustrates an example in which a server (300) is used as an authentication linkage device, and the server (300) may include a memory (320) including an operating system (330), a processor (310), a storage device (340), an input device (350), an output device (360), or a communication device (370).
[0144] System memory (320) may include RAM (Random Access Memory) and may provide a temporary storage space where operating systems and program modules are executed. System memory (320) may temporarily store data and instructions and allow the processor (310) to quickly access and process the data.
[0145] The operating system (330) may include software. The operating system may include memory management, file system management, processor management, and device management, and may control programs running within the device. The operating system (330) may include program modules, and the program modules are software modules for performing specific functions, and may provide or manage user interfaces or networks, etc.
[0146] The processor (310) may include, but is not limited to, a CPU. The processor (310) can execute instructions stored in system memory (320), process input data to generate results, or perform computational operations.
[0147] The storage device (340) may include a device that stores data and programs semi-permanently.
[0148] The input device (350) is a device for receiving data from a user or another system and may include a keyboard, a mouse, a touchscreen, or a display panel including a touch panel.
[0149] The output device (360) is a device that transmits data processed through the processor (310) to a user or another system, and may include a monitor, a speaker, or a display panel.
[0150] The communication device (370) can enable the server (300) to be communicated to an external network or another device (e.g., semantic similar content search device (100)).
[0152] The device described above may be implemented as a hardware component, a software component, and / or a combination of a hardware component and a software component. For example, the device and components described in the embodiments may be implemented using one or more general-purpose or special-purpose computers, such as, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing unit may execute an operating system (OS) and one or more software applications executed on said operating system. Additionally, the processing unit may access, store, manipulate, process, and generate data in response to the execution of the software. For ease of understanding, the processing unit may be described as being used as a single unit, but those skilled in the art will understand that the processing unit may include multiple processing elements and / or multiple types of processing elements. For example, the processing unit may include multiple processors or one processor and one controller. In addition, other processing configurations, such as parallel processors, are also possible.
[0153] Software may include computer programs, code, instructions, or a combination of one or more of these, and may configure a processing unit to operate as desired or command the processing unit independently or collectively. Software and / or data may be permanently or temporarily embodied in any type of machine, component, physical device, virtual equipment, computer storage medium or device, or transmitted signal wave so as to be interpreted by the processing unit or to provide instructions or data to the processing unit. Software may be distributed over networked computer systems and may be stored or executed in a distributed manner. Software and data may be stored on one or more computer-readable recording media.
[0154] The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the medium may be those specifically designed and configured for the embodiment, or they may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes; optical recording media such as CD-ROMs and DVDs; magneto-optical media such as floptical disks; and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The hardware devices described above may be configured to operate as one or more software modules to perform the operation of the embodiment, and vice versa.
[0155] Although the embodiments have been described above with reference to limited examples and drawings, those skilled in the art can make various modifications and variations from the description above. For example, suitable results can be achieved even if the described techniques are performed in a different order than described, and / or the components of the described system, structure, device, circuit, etc. are combined or assembled in a form different from described, or replaced or substituted by other components or equivalents.
[0156] Therefore, other implementations, other embodiments, and equivalents to the claims also fall within the scope of the claims set forth below.
Claims
Claim 1 An authentication linkage method performed in an authentication linkage system in a large-scale language model application environment, comprising: a step in which a user client provides a request to a Large Language Model (LLM) agent; a step in which the LLM agent links with an external tool to receive an authentication resource identifier for a user to access the external tool and transmits the authentication resource identifier to the user client; a step in which the user client performs an authentication process with an authentication server based on the authentication resource identifier; a step in which, if the authentication process is successfully performed, the authentication server generates an authentication code and redirects to an authentication linkage server; a step in which the authentication linkage server, having received the authentication code, links with the authentication server to issue and store an access token; and a step in which the authentication linkage server sets or transitions an authentication session state according to the progress state of the authentication process based on a session state machine—the session state machine includes a plurality of session states that are set differently according to changes in the session—the session state machine distinguishes and sets the session using at least one of a user profile, a thread identifier, and a provider. Claim 2 In claim 1, the authentication resource identifier is a string URI (Uniform Resource Identifier) for identifying a specific resource on the Internet, and includes an address URL (Uniform Resource Locator) indicating the location of the specific resource, an authentication linkage method based on an internal authentication process using a session state machine. Claim 3 In claim 1, the step of the user client performing an authentication process with an authentication server based on the authentication resource identifier comprises: the step of the user client providing the authentication resource identifier to a resource owner who is a user; the step of the resource owner performing an authentication request through a user agent, and the step of the user agent providing the authentication request of the resource owner to the authentication server; and the step of the authentication server generating a resource owner authentication in response to the authentication request and providing it to the user agent; an authentication linkage method based on an internal authentication process using a session state machine. Claim 4 In paragraph 3, the step of the authentication server generating an authentication code and redirecting to the authentication integration server when the authentication process is successfully performed includes the step of the authentication server generating the authentication code when the resource owner responds to the resource owner authentication; an authentication integration method based on an internal authentication process using a session state machine. Claim 5 In claim 4, the step of the authentication server generating an authentication code and redirecting to the authentication linkage server when the authentication process is successfully performed further comprises the step of the authentication server redirecting the generated authentication code to the user agent; an authentication linkage method based on an internal authentication process using a session state machine. Claim 6 In claim 5, the step of the authentication server generating an authentication code and redirecting to the authentication integration server when the authentication process is successfully performed further comprises the step of the user agent redirecting the authentication code to the authentication integration server. An authentication integration method based on an internal authentication process using a session state machine. Claim 7 An authentication linkage method based on an internal authentication process using a session state machine, wherein, in claim 6, the step of the user agent redirecting the authentication code to the authentication linkage server comprises: the step of the user agent redirecting the authentication code to the server; and the step of the server redirecting the authentication code to the authentication linkage server. Claim 8 An authentication linkage method based on an internal authentication process using a session state machine, wherein, in claim 1, the authentication linkage server individually manages user authentication sessions according to the session state machine. Claim 9 A computer-readable recording medium having a computer program stored therein for performing a method described in any one of claims 1 to 8, combined with hardware. Claim 10 An authentication integration system in a large-scale language model application environment, comprising: a user client providing a request; an LLM (Large Language Model) agent that receives the request, receives an authentication resource identifier for a user to access the external tool by linking with the external tool, and transmits the authentication resource identifier to the user client; an authentication server that performs an authentication process with the user client based on the authentication resource identifier, and if the authentication process is successfully performed, generates an authentication code and redirects to an authentication integration server; and an authentication integration server that receives the authentication code, links with the authentication server to issue and store an access token, and sets or transitions an authentication session state according to the progress status of the authentication process based on a session state machine—the session state machine includes a plurality of session states that are set differently according to changes in the session—the authentication integration system based on an internal authentication process using a session state machine, wherein the session state machine distinguishes and sets the session using at least one of a user profile, a thread identifier, and a provider.