A system for delegating permissions to native apps that do not retain authentication information.

Abstract

Conventional encrypted communication methods such as TLS lacked a mechanism for securely transferring the permissions of an authenticated user to another device via relay nodes along the communication path. Therefore, in a configuration where the authentication browser and the native application that executes the functionality are separated, it was difficult for the server to securely grant permissions while retaining the user's identity, and it was necessary for the application to retain the authentication information. [Solution] The present invention provides an information processing system that separates the authentication layer and the authority delegation layer, which is composed of encrypted communication, and securely transfers authority between the server and the native application via a relay client having an authenticated session. As a result, the native application can securely execute functions under server authority without having to hold authentication information.

Description

Technical Field

[0001] The present invention relates to an information processing system that performs authentication processing and authorization via a server, and more particularly to a delegation system and method for relaying an authentication result by a browser and enabling a native application to securely obtain authorization from a server and operate without holding authentication information.

Background Art

[0002] Conventionally, a configuration in which user authentication is performed by a browser and the result is passed on to a native application has been widely adopted. In this case, the browser holds logged-in session information and authentication tokens, and executes functions by passing the information to the native application. However, the browser is an environment in which communication contents and script information can be easily referred to and modified by plugins, extensions, and developer tools (so-called inspectors, etc.), and it has been difficult to ensure complete confidentiality. Therefore, even if permission data or key information is encrypted and handled via the browser, there is a risk that plaintext data or encryption processing parameters may be referred to during the relay process inside the browser, and it has been difficult to guarantee secure authorization delegation.

[0003] Also, when a native application communicates directly with a server, it is common to hold an API key or an authorization token (OAuth, etc.) inside the application and use it to access the server's API. Even in the OAuth method, the client application has to save the obtained access token internally and present it during communication, so substantially, the configuration is such that authentication information is held inside the application.

[0004] This method carries the risk of keys and tokens stored on the device being duplicated or altered, and if leaked, it could allow access control on the server side to be bypassed. Furthermore, when starting to use the app or changing settings, users themselves had to obtain API keys and access tokens and manually input and configure them in the app, resulting in significant effort for implementation and operation. In addition, managing token renewal and expiration was cumbersome, placing a burden on developers in terms of key management and reissuance processes.

[0005] The applicant previously proposed Patent No. 6451963, "Communication System." This technology discloses a configuration for establishing a secure encrypted communication path even when relayed through an untrusted browser. Based on this encrypted communication structure, the present invention separates the authentication layer and the encrypted authority delegation layer, achieving secure authority delegation without making the browser a trusted entity. [Prior art documents] [Patent Documents]

[0006] [Patent Document 1] Patent No. 6451963 [Overview of the Initiative] [Problems that the invention aims to solve]

[0007] In traditional configurations, native apps could not perform their functions unless they internally stored user authentication information and API keys. This resulted in risks of information leakage and misuse, as well as the operational burden of token management and user settings. In particular, the cumbersome setup procedure, which required users to obtain and configure API keys and access tokens themselves, posed a security challenge while also reducing user convenience.

[0008] Furthermore, even in configurations using a browser, as long as the browser functions as part of the encrypted communication path, there is a risk that encrypted data and key information may be accessible within the browser, making it impossible to guarantee secure delegation of privileges. In other words, conventional encrypted communication models were based on the premise that the browser was a trusted entity, making it difficult to securely delegate authenticated privileges to native applications in untrusted environments.

[0009] The present invention aims to solve these problems and provide a configuration in which a native application can operate securely based on the permission state established on the server side, without the native application having to hold authentication information, while still using a browser as an intermediary node. In other words, by separating the "authentication layer" and the "authority delegation layer," which were conventionally handled at the same layer, and constructing the latter as an independent security layer through encryption, secure authority delegation that does not rely on the browser as the trusted entity is achieved. According to the configuration of the present invention, users can use native applications without additional settings or key input after authenticating once on the browser, eliminating the operational burden of API key and token management. [Means for solving the problem]

[0010] The present invention is an information processing system comprising a server, a browser, and a native application. The processing procedure shown below is an example in one embodiment of the present invention and does not limit the procedures or methods to those essential to the configuration of the present invention.

[0011] The essence of authority in this invention is based on the "correspondence between session identification information and encryption keys" established within the server. The authority data and authority token in this invention are merely one form of externalizing and notifying the authority status.

[0012] In this invention, "session identification information" refers to identification information held by a server to identify an authenticated session. This concept is not limited to the session ID itself, but also includes other forms of identifiers generated or issued by the server in association with the session, and derived information derived from the session ID (including hash values, encrypted values, encoded values, and random identifiers (UUIDs, etc.)). Thus, session identification information encompasses all identifiers used to associate an authenticated session with key information used for encrypted communication.

[0013] The server comprises an authentication unit for user authentication, a private key storage unit for holding private keys used for encrypted communication, and a correspondence management unit for managing the association between session identification information and the encryption keys used for encrypted communication. The server may also include an authorization issuance unit that generates authorization data based on authenticated sessions as needed.

[0014] Permission data refers to internal permission information generated by the server based on authenticated sessions, and constitutes an permission token for encoding and transmitting that permission data externally.

[0015] The correspondence management unit represents a logical structure for maintaining the correspondence between session identification information and encryption key information used for encrypted communication, and its implementation form is not limited to a database, an associative array in memory, a cache, or other data structure.

[0016] A browser includes an authentication processing unit that establishes, maintains, or relays an authenticated session with a server based on user authentication, and an encrypted data relay unit that relays encrypted data without decrypting it.

[0017] The authentication processing unit may include an authentication UI unit that accepts user authentication input, and an authentication session holding unit that holds an authenticated session established with the server.

[0018] Also, the authentication UI part is not essential, and it may be configured to automatically perform authentication processing using the authentication information held in the device or an existing authentication session. The authentication processing in the present invention is not limited to only the login operation involving user input, and can be established by any method such as confirmation of the integrity of an existing session, transmission of pre-registered authentication information, and automatic authentication processing based on terminal-specific information. Therefore, the authentication UI may be provided in either the relay client or the native app, and even if it does not involve an authentication operation, it is included in the authentication layer of the present invention.

[0019] The native app includes an encrypted communication establishment unit that generates key information corresponding to the encryption key associated based on the authenticated session on the server to establish an encrypted communication path with the server, and a privilege application unit that decrypts and applies the privilege data received from the server. With these configurations, the native app can form a directly encrypted privilege delegation layer with the server without holding authentication information.

[0020] Here, the "key information" in the present invention refers to the encryption key used to establish encrypted communication or the information constituting the encryption key.

[0021] Also, "not holding authentication information" in the present invention means that the native app, which is the endpoint of the privilege delegation layer, does not include any configuration for receiving or storing external authentication qualification information (user ID, password, access token, refresh token, authorization code, etc.). The native app only generates a key for encrypted communication with the server internally, encrypts the key, and transmits it, without exposing authentication information or tokens to the outside.

[0022] Therefore, the app only stores the generated encryption key, and no authentication credentials. Verification of authentication status is performed by the correspondence between session identification information managed on the server side and the encryption key, allowing for secure delegation of permissions without the exchange or storage of authentication credentials.

[0023] In this invention, the authentication layer and the authority delegation layer are configured as logically separated and independent layers based on their functional roles, regardless of the physical device arrangement or the configuration of the communication path.

[0024] The term "authentication layer" here refers to a functional layer that performs authentication input via user interaction, verification of the validity of existing sessions, or alternative authentication processing. The authentication layer can be implemented in either an intermediary client, a native application, or both, regardless of the presence or absence of an authentication UI. The authentication layer is responsible only for user authentication, verification of the validity of authenticated sessions, or authentication processing associated therewith, and is not involved in the generation, sharing, or decryption of encryption keys, or the processing of encrypted permission data.

[0025] On the other hand, the "authority delegation layer" refers to the encrypted communication layer established between the server and the native application based on the authority status managed by the server's correspondence management unit, and assumes that relay nodes along the communication path operate in a form that cannot be decrypted. The authority delegation layer is only responsible for encrypted communication processing based on the correspondence between encryption keys and decryption keys, and does not directly handle authentication data such as user IDs, passwords, and authentication session information.

[0026] These two layers are structured to cooperate only indirectly through the correspondence between "session identification information" and "encryption or decryption keys" held internally by the server. Processing in either layer does not depend on the other, and the boundary between the two layers is logically clear. Therefore, the independence of the authentication layer and the authority delegation layer is always maintained, regardless of which device performs the authentication or what configuration the encrypted communication path has.

[0027] Furthermore, the authentication process also includes verification of the authentication status, such as presenting authenticated session identification information or signed identification information. Therefore, a configuration in which the browser performs authentication verification with the server without requiring an authentication UI is also included in the operation of the authentication layer of the present invention.

[0028] Therefore, even if a browser belongs to the authentication layer and has an encrypted data relay unit within it, the encrypted data relay unit logically functions as part of the authority delegation layer. In other words, the authentication layer and the authority delegation layer are configured logically independently and do not depend on their physical configuration or the form of their communication path.

[0029] Therefore, the present invention allows for flexible configurations that are independent of communication paths and device arrangements, such as configurations in which both layers are arranged on a single device, configurations in which they are distributed among multiple devices, or configurations in which the layers are logically separated on the same communication path.

[0030] Based on the above layered structure, we define "trust entity" as a concept important to the operation of the present invention. In the present invention, a "trust entity" refers to a component that performs tasks such as decrypting encrypted data, generating authentication information, or verifying the integrity of communication, and a component that does not perform these processes is considered "not to function as a trust entity."

[0031] When a user logs into the server via a browser, the server issues a session ID and responds to the browser. The browser then initiates local communication with the native app and notifies the native app of session information indicating that the browser is authenticated. The native app generates a shared key, encrypts it with the server's public key, and sends it to the server via the browser. The server decrypts it with its private key and manages the session ID and shared key in association. Subsequently, the server uses this shared key to encrypt permission data and sends it to the native app via the browser. The native app decrypts this data with the shared key it generated and executes its functions based on the decryption result.

[0032] In this configuration, the browser does not function as a trusted entity in the delegation layer, but rather as a relay node responsible only for authentication. Even in an untrusted environment, the encrypted privilege data remains undecryptable, ensuring secure delegation of privileges. [Effects of the Invention]

[0033] According to the present invention, a native application can securely receive permissions from a server and execute functions without having to store user authentication information or API keys. As a result, users can use the application simply by logging into the server, eliminating the need for tasks such as setting up and managing keys and tokens. Furthermore, since permissions are established as a session state within the server, there is no need for expiration date management or renewal processing required in conventional token systems, and no additional renewal operations are required after the initial permission delegation.

[0034] Furthermore, the encryption structure, which does not rely on the browser as the trusted entity, enables secure delegation of authority even in environments where the relay node is untrusted. In addition, by separating the authentication layer and the delegation layer, and configuring the latter as the encrypted communication layer, encryption functions not merely as communication protection, but as a structural element that guarantees the security of the delegation of authority itself.

[0035] The two layers are logically linked by the server managing session identification information and encryption key information in association, ensuring that authenticated sessions and encrypted communication paths operate while maintaining consistency. This simultaneously guarantees the legitimacy of privileges and the security of encrypted communication, even when using untrusted relay environments such as browsers.

[0036] Therefore, the present invention provides a new delegation model that simultaneously achieves security and operability by having a configuration that does not retain authentication information. [Brief explanation of the drawing]

[0037] [Figure 1] This is a functional block diagram showing the configuration of a permission delegation system to a native application that does not retain authentication information, relating to one embodiment of the present invention. [Figure 2] This is a sequence diagram of a shared key sharing process according to one embodiment of the present invention, showing the process in which a shared key generated by a native application is encrypted with a public key corresponding to a private key held by the server, and then sent to the server via the browser. [Figure 3] This is a sequence diagram of the authorization delegation process according to one embodiment of the present invention, showing the process in which the server associates a session ID with a shared key, encrypts the authorization data using the shared key, and sends it to the native application via the browser. [Figure 4] This sequence diagram integrates the symmetric key sharing process and authority delegation process shown in Figures 2 and 3, which relate to one embodiment of the present invention, and simplifies the relationships between each phase. It visually illustrates the three-tiered structure of the authentication phase, the cryptographic channel establishment phase, and the authority delegation phase. [Figure 5] This is a functional block diagram showing the configuration of an authority delegation system to an external device that does not retain authentication information, according to one embodiment of the present invention. [Modes for carrying out the invention]

[0038] Figure 1 is a functional block diagram of a permission delegation system to a native application that does not retain authentication information, according to one embodiment of the present invention.

[0039] Figure 1 shows an example of a case where an authentication UI is included, and the authentication layer does not necessarily require a UI that involves user input. Configurations in which authentication is achieved through the matching of existing sessions or automatic authentication processing, or configurations in which the authentication UI is provided on the native application side, are also included in the present invention.

[0040] For the sake of explanation, a symmetric key will be used as an example of the key used for encrypted communication below, but the encryption method is not limited to this, and configurations using public-key cryptography or hybrid methods are also included in this invention.

[0041] This system includes a native application (100), a browser (110), and a server (120). The native application (100) is connected to the browser (110) via communication path 1 (130), and the browser (110) is connected to the server (120) via communication path 2 (140). Users log in to the server (120) via the browser (110), and the browser (110) functions as a relay node that relays communication data between the server (120) and the native application (100). Communication path 1 (130) is configured as a local communication path between the native application (100) and the browser (110) (e.g., WebSocket, local IPC, or intra-terminal communication), and communication path 2 (140) is configured as a network communication path between the browser (110) and the server (120) (e.g., HTTPS communication).

[0042] The native application (100) comprises a symmetric key generation unit (101), a public key storage unit (102), a symmetric key encryption unit (103), an encrypted symmetric key transmission unit (104), and a permission application unit (105). The symmetric key generation unit (101) generates a symmetric key used for encrypted communication, and the public key storage unit (102) holds the public key corresponding to the private key storage unit (122) of the server (120). The symmetric key encryption unit (103) encrypts the generated symmetric key with the public key, and the encrypted symmetric key transmission unit (104) sends this to the server (120) via the browser (110). The permission application unit (105) decrypts the encrypted permission token sent from the server (120) with the symmetric key and controls the application's internal functions (printing, data acquisition, etc.) based on the decryption result.

[0043] The symmetric key generation unit (101) and the public key storage unit (102) constitute an encrypted communication establishment unit that establishes an encrypted communication path with the server, and the symmetric key encryption unit (103) and the encrypted symmetric key transmission unit (104) constitute an encrypted processing unit that performs encryption and decryption.

[0044] Here, the authority in this invention refers to a state that is established internally on the server side based on the correspondence between session identification information and the shared key, and is not necessarily limited to something that is transmitted externally in data format. When the encrypted shared key transmitted from the native application (100) is decrypted by the server (120) and the session identification information and the shared key are registered in the correspondence management unit (125), the authority state on the server (120) is established. Subsequently, the server (120) may generate and transmit authority data (authority token) to notify external components of the authority state as needed.

[0045] The authorization application unit (105) receives the authorization data decrypted by the encryption processing unit and controls application functions based on the authorization data.

[0046] The native application (100) is not limited to application software on the user's terminal, but may also include external devices (printers, scanners, IoT devices, etc.). Even if the symmetric key generation and decryption processes are delegated to an intermediate application, the invention is still included in the scope of technology in that an encrypted communication path using a symmetric key is established between the server (120) and the application.

[0047] The browser (110) comprises an authentication UI unit (111), an authentication session holding unit (112), and an encrypted data relay unit (113). The authentication UI unit (111) accepts user login input and communicates with the authentication unit (121) of the server (120) to perform user authentication. The authentication session holding unit (112) holds session information (session ID, etc.) with the server (120) and maintains the authenticated state. The encrypted data relay unit (113) relays encrypted data (encryption shared key, encryption permission token, etc.) sent and received between the native application (100) and the server (120). The browser (110) does not decrypt the encrypted data and operates only as a relay node. In other words, although the browser (110) has an authentication function, it is positioned as an untrusted relay environment and is not a trusted entity in encrypted communication.

[0048] The server (120) comprises an authentication unit (121), a private key storage unit (122), a shared key decryption unit (123), an authorization issuance unit (124), and a correspondence management unit (125). The authentication unit (121) receives user authentication information sent from the browser (110), issues a session ID if authentication is successful, and generates user identification session information. The private key storage unit (122) securely holds the private key used to decrypt the shared key, and this private key is paired with the public key used by the native application (100). The shared key decryption unit (123) decrypts the encrypted shared key sent from the native application (100) with the private key to obtain the plaintext shared key. The authorization issuance unit (124) determines the authorization of the authenticated user, generates authorization data (authority token), and encrypts it with the shared key. The response management unit (125) records and manages the session ID and shared key in association, so that the server (120) can properly identify the encrypted communication path.

[0049] With the above configuration, the user only needs to authenticate via the browser (110), and the native application (100) can communicate securely with the server (120) without storing authentication information. A shared-key encrypted communication path is established between the server (120) and the native application (100), and the browser (110) functions only as a relay node on that path. This structure separates the authentication layer from the encrypted authority delegation layer, enabling secure authority delegation even to devices that do not possess authentication information.

[0050] Figure 2 is a sequence diagram of a shared key sharing process according to one embodiment of the present invention, illustrating how each component shown in Figure 1 works in cooperation with each other.

[0051] First, the user enters login information 201 via the authentication UI (111) of the browser (110). The browser (110) sends an authentication request 202 to the authentication unit (121) of the server (120). The authentication unit (121) of the server (120) performs user authentication, and if authentication is successful, it returns an authentication response 203 and issues a session ID. As a result, an authenticated session is established between the server (120) and the browser (110), and the session information is stored in the authentication session holding unit (112) of the browser (110).

[0052] Next, the browser (110) initiates local communication with the native application (100) (native application connection 204). The native application (100) generates a shared key 206 for encrypted communication using its shared key generation unit (101) (shared key generation 205), and this shared key is encrypted using the public key 208 of the server (120) stored in its public key storage unit (102) (shared key encryption 207). This encryption process is performed by the shared key encryption unit (103) of the native application (100).

[0053] The encrypted shared key is sent from the encrypted shared key transmission unit (104) of the native application (100) to the browser (110). The encrypted data relay unit (113) of the browser (110) relays this encrypted shared key to the server (120) without decrypting it (encrypted shared key transmission 209 and relay 210). Although this communication path itself is plaintext communication, the confidentiality of the shared key is maintained because the shared key is encrypted before transmission. The authenticated session ID held by the browser (110) is transmitted along with this relay communication via the usual session management mechanism (cookie, etc.).

[0054] The server (120) stores the private key 212 in its private key storage unit (122), and the symmetric key decryption unit (123) uses this private key to decrypt the encrypted symmetric key (symmetric key decryption 211). The symmetric key 215 (decryption key) obtained through decryption is associated with the session ID 214 and stored in the correspondence management unit (125) (symmetric key storage 213).

[0055] Furthermore, the aforementioned authorization status is established when the correspondence between the session ID and the shared key is registered in the correspondence management unit (125) on the server (120) side.

[0056] This allows the server (120) to maintain a unique shared key for each session ID. In the subsequent authorization delegation process (see Figure 3), this shared key associated with the session ID is used to encrypt the authorization data, enabling secure communication with the native application (100).

[0057] In this way, the server and native application establish encrypted communication, but the browser is only responsible for authentication and does not participate in the encrypted communication, thus maintaining the confidentiality of the encryption key even in an untrusted relay environment. Furthermore, by managing the session ID in association with the shared key, the server can securely coordinate the authentication layer (browser) and the encrypted permission delegation layer (native application).

[0058] Figure 3 shows the sequence of the authority delegation process according to one embodiment of the present invention.

[0059] This diagram illustrates the process by which the server (120), browser (110), and native application (100) components shown in Figure 1 delegate permissions after authentication.

[0060] First, the browser (110) sends an authorization request 301 to the server (120) using the session ID 302 held by the authentication session holding unit (112). The server (120) receives this session ID 302 and verifies the validity of the session using the authentication unit (121). If it is determined that the session is valid, the server (120) determines the user's authority, and the authorization issuing unit (124) generates authorization data. Furthermore, the generated authorization data is encoded into a transmission format, and an authorization token is issued (authorization token issuance 303).

[0061] Next, the server (120) uses session ID 302 as the key to refer to the correspondence management unit (125), search for the associated common key, and retrieve it (common key retrieval 304).

[0062] This process not only retrieves the key but also verifies whether the session ID in question is a currently valid authenticated session (i.e., whether the permissions are established). In other words, if the common key for the session ID in question is not registered in the response management unit (125) (due to session expiration, logout, timeout, invalid session ID, etc.), the common key cannot be retrieved here, the server determines that the permissions are not established, returns an error response, and stops further processing.

[0063] On the other hand, only if the shared key is successfully obtained, the session is determined to be a valid authenticated session, and the authorization issuing unit (124) passes the obtained shared key to the shared key decryption unit (123) to perform the encryption process of the authorization token (encryption of the authorization token using the shared key 305).

[0064] Furthermore, the authorization token generated in this invention internally holds only user authorization information corresponding to the authenticated session, and does not contain any user login credentials, authentication ID, password, or other authentication information. This prevents the authorization token itself from functioning as a substitute for or storage of authentication information, thereby enabling secure authorization delegation.

[0065] The encrypted permission token (310) is sent to the native application (100) via the browser (110) through communication path 2 (140) and communication path 1 (130) (permission token transmission 306). At this time, the browser (110) simply relays the encrypted data without decrypting it using the encrypted data relay unit (113) (permission token relay 307).

[0066] The native application (100) stores the shared key used to establish encrypted communication in the shared key generation unit (101), and uses this shared key to decrypt the received authorization token (authorization token decryption 308). If the decryption of the authorization token fails, it is determined that the authorization has not been established, and subsequent processing is stopped as an error.

[0067] On the other hand, if decryption is successful, the obtained permission data is passed to the permission application unit (105) and applied to control the execution of functions within the native application (100) (permission token application 309).

[0068] This allows the native app (100) to securely execute functions permitted by the server (120), such as printing or data retrieval.

[0069] With the above configuration, the user only needs to authenticate via the browser (110), and the native application (100) itself can communicate securely with the server (120) without storing any authentication information. A shared-key encrypted communication path is established between the server (120) and the native application (100), and the browser (110) functions only as a relay node on that path.

[0070] In this way, by separating the authentication layer and the encrypted authority delegation layer, and further mapping the two layers on the server side using session identification information and encryption key information, an authority state is established on the server side based on the consistency relationship between the two layers, and that authority state can be securely delegated. In addition, by configuring the system so that the browser is not the trusted entity for encrypted communication, the confidentiality of encryption keys and authority data can be maintained even if part of the communication path is an untrusted environment. As a result, the server can securely grant permissions to native applications based on authenticated sessions, achieving an authority delegation method that balances security and flexibility compared to conventional systems that assume the trust of the browser.

[0071] Figure 4 is a sequence diagram that integrates the shared key sharing process and authority delegation process shown in Figures 2 and 3, and simplifies the relationships between each phase.

[0072] In this diagram, the authentication phase corresponds to the browser-based authentication layer, and the cryptographic channel establishment phase corresponds to the cryptographic communication layer between the server and the native application. This cryptographic communication layer corresponds to the cryptographic communication portion that makes up the authority delegation layer. Furthermore, the authority delegation phase corresponds to the authority delegation layer that securely notifies the native application of permission data from the server.

[0073] In other words, this diagram reorganizes the operations shown in Figures 2 and 3 based on a layered structure, showing that each phase is composed of an independent functional layer.

[0074] The "Decryption Not Possible" label attached to each arrow indicates that the browser, acting as the relay node, relays the encrypted data in a form that cannot be decrypted, visually demonstrating that secure delegation of authority is possible even in an untrusted environment.

[0075] The embodiments shown in Figures 1 to 4 illustrate a configuration in which the native application (100) operates directly on the user's terminal. On the other hand, Figure 5 shows an example of a configuration according to another embodiment of the present invention, which illustrates a configuration in which some or all of the functions of the native application are handled by an external execution device.

[0076] Figure 5 is a functional block diagram showing the configuration of an authority delegation system via an external execution device according to another embodiment of the present invention.

[0077] In this embodiment, some of the functions of the native application (100) shown in Figure 1 are implemented on the external device (400), and an authentication terminal (410) running a browser (110) is configured as a relay node. With this configuration, the same authority delegation method can be applied even when the native application is run on an external device or when it controls an external control device (printer, IoT device, handheld terminal, etc.).

[0078] The external execution device (400) comprises a common key generation unit (401), a public key storage unit (402), a common key encryption unit (403), an encrypted common key transmission unit (404), and an authority application unit (405). The common key generation unit (401) generates a common key used for encrypted communication with the server. The generated common key is encrypted using the public key of the server (120) stored in the public key storage unit (402). The encryption process is performed by the common key encryption unit (403) and transmitted to the authentication terminal (410) via the encrypted common key transmission unit (404). The authentication terminal (410) forwards this encrypted common key to the server (120) without decrypting it. On the server side, the common key is decrypted using the private key stored in the private key storage unit (122), and recorded in the correspondence management unit (125) in association with the session ID.

[0079] The server (120), as shown in Figure 1, includes an authentication unit (121), a private key storage unit (122), a shared key decryption unit (123), an authorization issuance unit (124), and a corresponding management unit (125). Through these functions, the server (120) authenticates the user, encrypts the authorization data based on the session ID, and securely transmits it over an encrypted communication path.

[0080] The authentication terminal (410) is a terminal with browser functionality and comprises an authentication UI unit (411), an authentication session holding unit (412), and an encrypted data relay unit (413). The authentication UI unit (411) accepts user login input and communicates with the authentication unit (121) of the server (120) to perform user authentication. The authentication session holding unit (412) maintains the authenticated session established with the server (120). The encrypted data relay unit (413) relays encrypted data between the external execution device (400) and the server (120) without decryption.

[0081] Communication path 1 (420) connects the authentication terminal (410) and the external execution device (400) via short-range wireless communication such as Bluetooth or local communication. Communication path 2 (430) connects the server (120) and the authentication terminal (410) via a wide-area communication channel such as the Internet.

[0082] Thereafter, the server (120) encrypts the authorization data generated based on the authenticated session using the shared key and sends it to the external execution device (400) via the authentication terminal (410). The external execution device (400) decrypts this authorization data using the shared key it generated, and the authorization application unit (405) applies the decrypted authorization information to execute the processes permitted by the server (printing, data acquisition, device control, etc.).

[0083] This configuration allows for the establishment of a shared-key-based encrypted communication path between the server (120) and the external execution device (400), thus maintaining the confidentiality of the encryption key and authorization data even without designating the authentication terminal (410) as a trusted entity. Furthermore, even if the authentication terminal (410) is a general-purpose device such as a PC or smartphone, the server can securely delegate authority to the external device. Therefore, the present invention can be easily applied to environments where external devices, such as printers, IoT devices, and handheld terminals, perform functions.

[0084] The following describes modifications related to each configuration of the present invention. In these modifications as well, it is assumed that the relay node cannot decrypt the encrypted data, and the configuration in which the authentication layer and the encrypted authority delegation layer are separated is maintained. Furthermore, the encryption method, key type, communication path configuration, and specific format of the identification information are not limited to any particular form, and each modification shown below is applicable within the scope of these common requirements.

[0085] Furthermore, the separation structure of the authentication layer and the authority delegation layer in this invention is achieved through logical layer separation, where authentication information is not stored on the native application side, even when both layers reside on the same physical device (e.g., in a browser execution environment, local IPC configuration).

[0086] In other words, physical separation is not an essential component of this invention; even on a single device, secure delegation of authority in an untrusted environment can be achieved as long as the relay node relays encrypted data in an undecryptable state.

[0087] On the other hand, when the authentication layer (relay client) and the authority delegation layer (native application) are configured to be physically separated, session identification information and encryption keys are physically separated and held separately. Therefore, authority cannot be established by simply seizing one device, and resilience against hostile environments is further enhanced.

[0088] A. Variations of relay configuration and communication path

[0089] (1) Regarding the "configuration of the relay client," the above embodiment shows an example in which a browser is used as a relay node, but the present invention is not limited thereto, and other relay clients can also be used. For example, a dedicated desktop application, a mobile app, or a relay module (including built-in or external) that works in conjunction with an IoT device may function as an authentication device. What is important is that the relay client is structured in such a way that it cannot decrypt encrypted communication data, and that the authentication layer and the encrypted authority delegation layer are independent.

[0090] (2) Regarding "Variations in the communication path configuration," the communication paths 1 and 2 shown in Figure 1 are not limited to physical networks, but may be virtual networks, WebSocket communication, Bluetooth communication, local IPC, or any other communication path. Furthermore, a local configuration in which the server and native application reside on the same network and the browser acts as a relay on the same terminal is also included within the scope of the present invention.

[0091] (3) Regarding the "multi-stage configuration of relay paths," even if there are multiple relay clients, the spirit of the present invention is not impaired as long as each relays the encrypted data in a form that cannot be decrypted. For example, it can be applied to multi-stage relay paths such as a configuration in which a browser relays data to an external device via a desktop application.

[0092] (4) With regard to "configuration via a cloud gateway," even if the relay client is a relay server on the cloud (MQTT broker, Web relay service, etc.), if the relay server has a structure that prevents it from decrypting encrypted data, it falls within the technical scope of the present invention.

[0093] (5) Regarding the "authority delegation configuration using a physical dual path," the present invention can also be applied to configurations in which the authentication path and the authority application path are physically separated without going through an intermediary client. That is, after the authentication process is completed by the intermediary client, the server holds identification information corresponding to the authentication result, and the native application can directly communicate encrypted with the server by presenting session certificate data based on this identification information. The session certificate data is identification information generated by the server using any method such as signing or encryption. It is passed from the server to the native application via the intermediary client after authentication, and the native application presents the data to the server. The server can verify the correspondence with the authenticated session by confirming the integrity of the received session certificate data, and secure authority delegation is realized even in configurations that do not go through an intermediary node.

[0094] B. Variations of encryption key structure and sharing scheme

[0095] (6) Regarding the "entity for generating the shared key," the above embodiment shows an example where the native application generates the shared key, but conversely, the server may generate the shared key and securely share it with the native application using public-key cryptography. In this case as well, even if the shared key sharing path goes through an intermediary client, as long as the intermediary client has a structure that makes decryption impossible, the spirit of the present invention (secure delegation of authority in an untrusted environment) is not impaired. In the system of the present invention, a configuration in which the shared key is already shared between the server and the native application may be adopted. In this case, the method of sharing the shared key (e.g., public-key cryptography, key distribution protocol, or pre-distribution method) is not particularly limited.

[0096] (7) Regarding the "correspondence between encryption and decryption keys," the symmetric key generation method described in (6) above is an example of a key pair in encrypted communication, and this section describes the general correspondence between encryption and decryption keys, including this example. Regardless of whether the symmetric key is generated by the server or the native application, encrypted communication is constructed based on the correspondence between the encryption key and the decryption key. In symmetric key cryptography, the same key is shared and used, while in public key cryptography, one functions as the public key and the other as the private key. In other words, the configuration of the present invention does not depend on the entity that generates the encryption and decryption keys (server or native application), and guarantees the confidentiality and integrity of encrypted data through this correspondence. This abstract configuration is applicable to any key configuration, such as symmetric key cryptography, public key cryptography, or hybrid cryptography combining the two. In this modified example, the server may also constitute a "correspondence management unit" that maintains the correspondence between session identification information and the encryption or decryption key. This correspondence management unit records the correspondence between the symmetric key in the case of a symmetric-key cryptography scheme and the encryption key and decryption key in the case of a public-key cryptography scheme, and is used to identify and maintain the encrypted communication path for each session. This ensures that the logical consistency between the authentication layer and the authority delegation layer is maintained, regardless of the form of the encryption key configuration.

[0097] (8) Regarding the "authority delegation configuration by generating a key pair on the application side," the above embodiment shows a configuration in which a common key is shared and permission data is encrypted. Alternatively, the native application may hold its own public and private keys and send the public key to the server. In this case, the server encrypts the permission data (authority token) using the native application's public key and sends the encrypted data to the native application via the browser. The native application decrypts the data using its own private key and securely obtains and applies the permission information notified by the server, thereby establishing an encrypted communication path. This makes it possible to achieve secure authority delegation even through untrusted relay nodes without sharing a common key between the server and the native application.

[0098] (9) Regarding the "authority delegation configuration by server-side key pair generation," the above embodiment shows an example where the native application generates a shared key or public key. Alternatively, the server may generate its own public and private keys and distribute the public key to the native application. In this case, the server may encrypt the authorization data (authority token) using the private key, or add a signature before sending it. The native application can securely obtain authorization by using the distributed public key to decrypt if it is encrypted, or to verify the signature if it is signed. With this configuration, secure authorization delegation can be achieved even through untrusted relay nodes, while the server takes the lead in establishing an encrypted communication layer without sharing a shared key.

[0099] (10) Regarding the "shared key cache retention configuration," in the above embodiment, the shared key generated by the native application may be temporarily stored in memory and reused during the session validity period. This allows for the immediate restoration of a secure communication relationship without regenerating the shared key when re-establishing the encrypted communication path with the server, even when the application is restarted or a temporary interruption in communication occurs. The shared key is not stored on an external recording medium or third-party device, but is stored exclusively in a secure storage area within the application. On the server side, session identification information and the shared key are managed in association, and legitimate reconnection can be confirmed by verifying key integrity. This configuration allows for the re-establishment of the encrypted communication path without requiring re-authentication, maintaining security without compromising the user experience. Furthermore, the cache period for the shared key may be limited to the session validity period or a predetermined expiration date, and it is automatically discarded after the expiration date. This avoids the risks associated with long-term storage while achieving both reconnectivity and security in a realistic operating environment.

[0100] (11) With respect to the “authority delegation configuration including app user identification information,” as a modification of the present invention, the app may generate app user identification information to identify the target app user when establishing encrypted communication or during the authority delegation process, and send the identification information to the server together with encrypted data. The server records the received app user identification information in the correspondence management unit along with the correspondence relationship with the authenticated session identification information and the encryption key. Subsequently, the server generates permission data including the app user identification information, encrypts it based on the encryption key, and sends it to the native app via the browser. The native app can identify which app user the permission corresponds to by decrypting the received encrypted data. The app user identification information may be used for state management, display control, logging, or function branching within the app. Furthermore, if the native app is a third-party app provided by another company, the app user identification information may be information that identifies the app user specific to the third-party app. In that case, the app user identification information may be used to identify the billing target user or for other purposes.

[0101] C. Variations of Authentication Configuration and Layer Separation

[0102] (12) Regarding the "separation configuration of authentication devices," the device that performs authentication is not limited to a browser; it may also be a separate dedicated terminal (such as a smartphone or security token), and the result may be relayed to the native application via a relay client. In this case, even if the user authentication device and the application execution device are physically separated, authority can be delegated through an encrypted communication path.

[0103] (13) Regarding "Use of the same communication path in a physically distributed configuration," the authority delegation configuration of the present invention can be applied to a configuration in which the relay client (browser) that performs authentication and the native application that executes the authority delegation layer are distributed on different physical devices, while both devices communicate with the server using the same physical communication path. That is, the browser communicates directly with the server, and the native application communicates with the server encrypted via the browser. Since the browser does not hold the encryption key and does not perform decryption processing, it relays the encrypted message sent by the native application in an undecryptable form and does not become a trusted entity in the authority delegation layer. In this configuration, the relay client holds an authenticated session but does not hold the encryption key, and the native application holds the encryption key but does not hold the session ID. Even if both exist on the same communication path, if an attacker seizes only one of the devices, the session ID and encryption key will not be available, and the exercise of authority will not be established. Therefore, even if the native application is captured during the period in which the authority is valid and the encryption key is extracted from memory, the device alone will not have the session ID necessary for server communication and will therefore not be able to function as an authority entity. In other words, the leakage of encryption keys alone is insufficient to seize privileges, and the attacker cannot reconfigure them. This configuration structurally prevents privilege leaks even in environments where devices such as drones, unmanned transport vehicles, and field sensor nodes may be captured by adversaries. In short, the present invention possesses high resistance to physical breaches that cannot be overcome by a one-sided seizure.

[0104] (14) Regarding the "in-browser execution device configuration," the above embodiment illustrates a configuration in which a native application runs outside the browser. However, the present invention is not limited thereto, and an execution module that runs inside the browser (for example, a program executed by WebAssembly, Service Worker, or a browser extension mechanism) can also be configured as the native application layer. In this case, the in-browser execution device performs decryption of encrypted data and enforcement of permissions internally, but it configures an encrypted communication path independent of the browser's TLS layer, and maintains a structure in which the browser itself cannot decrypt the encrypted data. Therefore, even in an in-browser execution environment using WebAssembly, etc., a structure in which the authentication layer (browser UI) and the encrypted permission delegation layer (internal execution module) are logically separated can be established, and the effect of the present invention, "secure permission delegation in an untrusted environment," can be similarly realized. Alternatively, the browser extension mechanism itself may be configured to relay encrypted data. In this case, the browser extension relays the encrypted common key and permission data in an undecryptable form and functions as a logical layer independent of the browser itself.

[0105] (15) Regarding the "inverted authority delegation configuration," the authority delegation structure of the present invention is also applicable to a normal web application environment that does not use authorization tokens. That is, by reversing the conventional "browser authentication → app permission" flow to "app authentication → browser operation," a secure login state can be established without the browser being the trusted entity. In the basic configuration shown in Figure 1, the relay client (browser) is equipped with an authentication UI unit, accepts the user's login operation, and performs authentication communication with the server (120). On the other hand, in this modified example, this configuration is reversed, and the native app (100) accepts the user's login operation on its own login UI and performs authentication communication directly with the server (120). That is, the login UI unit of the native app in this modified example has a functionally equivalent role to the authentication UI unit of the relay client in the above configuration. In the present invention, even if authentication is performed on the native app, the authentication layer and the authority delegation layer within the native app are configured logically independently. After establishing an authenticated session through the above authentication communication, the native app generates an encryption key to be used for encrypted communication with the server and registers it with the server. The server maintains an association between the encryption key and session identification information (correspondence management unit). This correspondence serves as the basis for the server to identify the authorized entity, and the authority is not transferred as data to the browser or externally, but is maintained as the encryption key consistency relationship itself established between the server and the native application. Based on this consistency information, the server issues temporary identification data to identify browser access, and the native application adds this to the browser and sends an access request to the server via the browser. The browser only relays the identification data and does not hold the encryption key and does not function as the authorized entity. After decrypting the received identification data and verifying its consistency, the server uniquely associates the browser communication with the authenticated communication path established by the native application (browser session association). As a result, even with communication via a browser, the server can identify the legitimate authorized entity through the consistency of the encryption key.From this point forward, the browser does not retain authentication information and simply performs normal web operations, but the server refers to internal consistency information (encryption key and session identification information) to determine the legitimacy of each communication. This configuration allows authentication and authorization to be centrally controlled at the cryptographic communication layer between the server and the native application without using authorization tokens such as OAuth. A normal HTTP session (session identification by cookies) is used between the browser and the server, but since the session ID is aligned with the communication path of the authenticated application via the corresponding management unit, the actual authentication information and permissions are always kept outside the browser as an encryption key consistency relationship. This structurally prevents unauthorized access such as phishing.

[0106] (16) Regarding the "App-mediated API call configuration in browser function operation", in the above inverted authority delegation configuration, when the browser calls a server API from a web page, the browser may not directly communicate with the server in encrypted form, but rather encrypt the API call request via the native application and send it to the server. That is, in this modified example, the browser (110) generates an API call request based on user operation (e.g., data retrieval request, update request, etc.), but the request does not have authentication information attached, and the browser alone does not have integrity as an authorized entity. The browser forwards the API call request to the native application (100), the native application encrypts the request based on a shared key, and sends it to the server (120). The server decrypts the received encrypted API packet and verifies the shared key consistency value or signature value attached to the packet to confirm that the API call was legitimately generated by an authenticated native application. On the other hand, an API call request sent directly from the browser (110) to the server does not contain shared key consistency information, and is therefore discarded by the server as invalid communication. The same applies to API response data from the server; the server encrypts the response data and sends it back to the native app (100), which then decrypts the encrypted data and provides the plaintext data to the browser. This allows the browser (110) to receive only the minimum information necessary to build the user interface without directly handling the encrypted response data. With this configuration, even if a backdoor script or malicious code is inserted into the browser page, the browser does not hold the shared key or permission information and cannot directly execute the server API. In other words, the "executor" of the API is always limited to the native app, and the browser functions merely as a relay client specialized in UI display and the exchange of plaintext data. By applying this modified example, the assumption of "browser = authentication entity" seen in conventional web applications can be completely eliminated, and a robust API execution platform that does not rely on tampering with the browser or script insertion can be built.Therefore, attacks such as session hijacking, session fixation attacks, or unauthorized API calls using tampering scripts can be structurally eliminated.

[0107] D. Variations of Server Configuration and Operational Design

[0108] (17) Regarding the "server-to-server encrypted communication configuration," this modified example is based on the configuration of claim 1 and is an application example in which a part of the authority delegation layer is extended to an external execution environment (server-side environment) based on an authenticated session established in the authentication layer (server and relay client). The server shares an encryption key with the external server execution environment and forms an encrypted communication path based on that key within the authority delegation layer. Even if a relay client is present on the communication path, the relay client cannot decrypt the encrypted data, so the security of the encrypted communication layer is maintained. Furthermore, since the relay client does not hold the encryption key and the external server execution environment does not hold the authentication session ID, even if one is compromised, the authority is not established. If the external execution environment is a serverless function execution platform, the configuration may be such that the encryption key is temporarily generated or restored when the function is started and discarded when the function finishes. With this configuration, an authority delegation layer that does not hold authentication information can be realized even if the server-side environment does not have a resident process. If the encryption key is a public-key cryptography scheme, the configuration may be such that the external execution environment temporarily holds its own private key and registers the corresponding public key with the server. The server encrypts the authorization data using the public key, and the external execution environment decrypts it using its own private key, thereby forming an encrypted communication path for the authorization delegation layer. Alternatively, the external execution environment may permanently maintain the public and private key pair, in which case stable authorization delegation communication can be established during long-term operation.

[0109] (18) Regarding the "Server-to-Server Encrypted Communication Configuration in an SPA Configuration," this modified example is based on the server-to-server encrypted communication configuration shown in (17) above, and is an application example where an SPA (Single Page Application) is used as a relay client for user operations. The SPA operates on a browser, but cannot perform any encryption or decryption processing, and only relays encrypted data between the server and the external execution environment. The SPA creates plaintext data in response to user operations and sends it to the external execution environment. The external execution environment encrypts the data based on the encryption key it holds. The encryption result is returned to the SPA, which forwards the encrypted data to the server as is, and the server decrypts the data based on the encryption key it holds. The server encrypts authorization data or application data as needed and sends the encrypted data to the SPA. The SPA forwards the encrypted data to the external execution environment as is, and the external execution environment decrypts it using its own encryption key. The decryption result is returned to the SPA and rendered on the SPA. This modification maintains a physically separated structure for the authentication layer and the authority delegation layer, even when the SPA acts as an intermediary, achieving a high level of resilience where authority cannot be established through a single node compromise. This structurally eliminates attack points that are problematic in conventional OAuth-type authorization methods and BFF (Backend for Frontend) methods, such as token storage, signature processing, and proxy execution on the browser.

[0110] (19) Regarding the "authority delegation configuration with measures against encryption key leakage," the authority delegation structure of the present invention may be configured such that, in order to prevent unauthorized use due to the leakage of encryption keys, when a native application establishes encrypted communication with a server, it generates application identification information to identify itself and sends the application identification information to the server at the same time as the encryption key exchange. The server stores the application identification information in a corresponding management unit in association with session identification information and encryption keys, and verifies the consistency with the application identification information when decrypting and verifying encrypted data received in subsequent communications. As a result, even if an encryption key is leaked to a third party, communication requests that do not have the corresponding application identification information will not be recognized as legitimate communications, and unauthorized connections and session hijacking can be prevented. The application identification information may be any identifier that is securely generated or maintained within the native application, and may be a hash value of a public key, signature data based on terminal-specific information, a signed identifier issued by the server, or other equivalent identification means. In addition, a challenge-response method may be adopted in which the server sends challenge data in addition to verifying the consistency of the application identification information, and the native application encrypts it and responds. This configuration allows the server to verify whether communications using the encryption key originated from a legitimate native application, even if the encryption key is leaked on its own, and maintain a secure delegation of authority regardless of the physical path configuration.

[0111] (20) Regarding the "server-initiated push communication configuration," the authority delegation structure of the present invention can also be applied as a so-called push communication configuration in which the server initiates encrypted communication to a native application or device, as an application form that utilizes the encrypted communication relationship established in the authority delegation layer. In this modified example, the server may hold application identification information to identify the native application, along with the encryption key used for encrypted communication established with the native application or device in the authority delegation layer. The server can send encrypted data, i.e., event information or control information, etc., based on the encryption key, to a specific native application or device. The native application or device verifies that the received encrypted data is genuine communication from the server by decrypting it with the encryption key, and performs predetermined control or response processing. With this configuration, the server can initiate direct communication to a client with a specific authority relationship via the encrypted communication relationship established in the authority delegation layer, without using authentication information or authorization tokens. In other words, secure server-initiated communication can be realized without requiring session maintenance by the authentication layer, and only clients sharing the encrypted communication layer can decrypt and respond. Furthermore, because the server can notify event information, update information, or control commands without waiting for communication requests from native apps or devices, it can be applied to uses that were difficult to achieve with conventional client-initiated communication, such as controlling IoT devices, notifying software license renewals, and real-time control commands. In addition, in this configuration, native apps or devices do not hold authentication information and decrypt received data only based on the encrypted communication relationship managed by the server, so spoofed data sent by a third party without the encryption key cannot be correctly received or decrypted. On the other hand, because the server performs decryption and verification based on the encrypted communication relationship, it will not accept response data generated by a third party without the encryption key as a legitimate encrypted response. As a result, both spoofed communication and impersonation communication are effectively impossible in both directions of communication.As described above, this configuration extends the encrypted communication relationship established between the server and the native application to bidirectional communication, maintaining the same authority relationship and encrypted communication layer regardless of the direction in which communication is initiated. This enables secure one-way communication (push communication) from the server side without additional authorization procedures.

[0112] (21) Regarding the "unidirectional communication configuration from native app to server," the authority in this invention is established internally by the correspondence between session identification information and encryption keys managed by the server. Therefore, the native app can initiate encrypted communication with the server without the server sending an authorization token, which is a means of notifying authority, to the native app. With this configuration, IoT devices and control devices can securely transmit measurement data, etc., to the server without having to hold an authorization token. On the server side, the server can receive data while confirming that the communication is based on a legitimate authorization state by identifying the corresponding encryption key based on the session identification information for the received encrypted data and decrypting it.

[0113] E. Variations related to authorization information and data management

[0114] (22) Regarding the "form of authorization information," authorization information (authorization tokens) for notifying the authorization status managed by the server's response management unit is not limited to a single token data, but may be configured as an API access key, device operation authorization code, or temporary execution policy information. All of this authorization information is securely exchanged via encrypted communication, and its authenticity and correspondence can be guaranteed by the server assigning signature information or identification code when it is generated. Furthermore, by controlling the expiration date and scope of use of authorization tokens on the server side, temporary or limited authorization delegation can be securely implemented.

[0115] F. General handling of terminology

[0116] In this specification, the terms "server," "relay client," and "native application" all refer to the functional roles or logical configuration layers of the present invention and do not limit the device configuration, software configuration, communication protocol, or physical arrangement. These components may be implemented in any form, such as a program running on a single terminal, processing modules distributed across multiple devices, a service in a cloud environment, an in-browser execution environment (WebAssembly, etc.), or an execution device in an external device (printer, IoT device, etc.). In other words, the configuration names in this specification are based on the functional roles played in the authentication layer and the authority delegation layer, and the technical scope is not limited by differences in implementation method or physical form. [Explanation of symbols]

[0117] 100 Native Apps 101 Common key generation unit (encrypted communication establishment unit) 102 Public Key Storage Unit 103 Common key encryption section 104 Encryption symmetric key transmission unit 105 Authority Application Section 110 Browser 111 Authentication UI Section 112 Authentication Session Retention Unit 113 Encrypted Data Relay Unit 120 servers 121 Authentication Department 122 Private Key Storage Unit 123 Common Key Decryption Unit 124 Authorization Issuance Department 125 Response Management Department 130 Communication path 1 (between native app and browser) 140 Communication path 2 (browser-server) 208 Server Public Key 212 Server private key 214 Session ID 215 Common key 200-215 Sequence signals in Figure 2 (login input, authentication request, shared key generation, encrypted transmission, etc.) 300-309 Sequence signals in Figure 3 (authorization request, shared key acquisition, encrypted transmission, decryption, application, etc.) 310 Permission token (encrypted permission data) 400 External execution device 401 Common key generation unit 402 Public Key Storage 403 Common key encryption section 404 Encryption Symmetric Key Transmission Unit 405 Authority Application Section 410 Authentication terminal (relay terminal) 411 Authentication UI Section 412 Authentication Session Retention Section 413 Encrypted Data Relay Unit 420 Communication path 1 (between external execution device and authentication terminal) 430 Communication path 2 (authentication terminal - server) The symbols described in this explanation are added to facilitate understanding of the present invention and do not limit the technical scope of the present invention.

Claims

1. An information processing system comprising a server, a relay client, and a native application, The server comprises an authentication unit that authenticates a user and establishes an authenticated session, a key storage unit that holds an encryption key used for encrypted communication, and a correspondence management unit that maintains the correspondence between session identification information associated with the authenticated session and the encryption key. The relay client comprises an authentication processing unit that establishes or relays the authenticated session with the server, The native application includes an encrypted communication establishment unit that generates or stores key information corresponding to the encryption key, Based on the authenticated session, the server sets the encryption key in the correspondence management unit, associating it with the session identification information associated with the authenticated session. The server and the native application constitute an authority delegation layer that performs encrypted communication based on the correspondence between the encryption key and the key information associated with the authenticated session. The server and the relay client constitute an authentication layer that performs authentication processing based on the authenticated session. An information processing system characterized in that the authentication layer and the authority delegation layer are formed logically independently.

2. In the system according to claim 1, the relay client in the authority delegation layer, which is configured independently of the authentication layer, Without having a function to decrypt encrypted data sent and received between the server and the native application, An information processing system characterized by relaying encrypted data in a manner that does not involve the interpretation or application of authorization data.

3. In the system according to claim 1, the server is An information processing system further comprising a transmission unit that transmits encrypted data to the native application using encrypted communication in the authority delegation layer.

4. In the system according to claim 1, the native application is An information processing system further comprising an encrypted transmission unit that encrypts data using key information corresponding to the aforementioned encryption key and transmits it to the server.

5. In the system according to claim 1, the authentication UI that accepts user authentication operations is: An information processing system characterized by being provided in either a relay client or a native application.

6. In the system described in claim 1, the authentication unit, the relay client, and the native application are: They may be placed on the same terminal or distributed across different devices. An information processing system characterized in that the configuration relationship between the authentication layer and the authority delegation layer is maintained regardless of the arrangement of the relay clients.

7. In the system according to claim 1, the native application is By connecting to an external device and based on the encrypted communication relationship established in the authority delegation layer, by encrypting and transmitting function execution requests or control data to the external device, An information processing system that controls the functions of the aforementioned external device.

8. A server program that causes a computer to perform authentication and authority delegation processes, The aforementioned server program is installed on the computer. Authentication process that authenticates the user and establishes an authenticated session. Key storage process for holding encryption keys used for encrypted communication. A correspondence management process that maintains the correspondence between session identification information associated with the authenticated session and the encryption key. The process of establishing encrypted communication with a native application that generates or holds key information corresponding to the aforementioned encryption key is performed. An authentication layer comprising the aforementioned authentication process and the aforementioned correspondence management process, The authority delegation layer, which is comprised of the encrypted communication establishment process and the authority delegation process, A server program characterized by being formed logically independently.

9. A relay client program that causes a computer to perform authentication processing and relay processing of encrypted data, The aforementioned relay client program is installed on the computer, Authentication process that establishes or relays an authenticated session with the server. Encrypted data relay processing that relays encrypted data in a manner that does not involve interpreting or applying permission data, and does not have the functionality to decrypt encrypted data sent and received with native apps. A relay client program characterized by causing the execution of [a specific action].

10. A native application program that causes a computer to perform encrypted communication establishment and permission enforcement processing, The aforementioned native application program is installed on the computer, After executing the encrypted communication establishment process, which generates or stores key information used for encrypted communication, The process of sending encrypted data to the server based on the aforementioned key information. Alternatively, the process by which the server receives and decrypts data encrypted with an encryption key corresponding to the key information, Perform one or both of the following actions: The aforementioned native app program does not retain authentication information, The authority to be granted through encrypted communication is made applicable based on the correspondence between the session identification information managed by the aforementioned server and the aforementioned key information. A native app program characterized by the following features.

11. In the server program described in claim 8, The encrypted data transmitted or received in the encrypted communication established by the aforementioned encrypted communication establishment process A server program characterized by including information regarding the setting, control, or operation instructions of application functions.

12. In the server program described in claim 8, Using the correspondence between session identification information and encryption key maintained by the aforementioned correspondence management process, The server program initiates encrypted communication with the native application. A server program characterized by further executing server push communication processing.

13. In the relay client program described in claim 9, The relay client corresponding to the aforementioned relay client program is configured with multiple relay devices, A relay client program characterized in that the encrypted data relay process is executed sequentially between these relay devices.

14. In the native application program described in claim 10, The received and decoded data is used to operate the application's functions. Includes information about settings or controls, The native app program controls the application functions based on the information. A native application program characterized by requiring further processing.

15. In the native application program described in claim 10, The native application program, in accordance with the encrypted communication relationship obtained based on the encrypted communication establishment process, A native application program characterized by causing the aforementioned native application program to further execute processing to control an external device to which it is connected.

Images