USE OF UNIT-BOUND AUTHORIZATION CERTIFICATES FOR IMPROVED AUTHORIZATION SECURITY IN NATIVE APPLICATIONS

Abstract

Procedure that includes: Received by an authorization server (201) and by a native application (202) on a unit, an initial authorization grant, a public key of a private / public key pair generated on the unit, and an acknowledgment of the authenticity of the native application (202); Received by the authorization server (201) and by the native application (202) on the unit, an update token and a digital signature of the update token created with the private key, wherein the authorization server (201) recognizes the update token only when the update token is verified with the public key that was previously registered; Validate, by the authorization server (201), the digital signature of the update token; In response to the validation of the update token from the native application (202) on the unit, the authorization server (201) transmits a new access token and a new update token from the authorization server (201) to the native application (202) on the unit, the new access token enabling the native application (202) on the unit to access the computer resource; Input into a neural network (757) the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token, and the digital signature of the update token, wherein the neural network (757) is trained to generate an access token generated by the neural network (757) and an update token generated by the neural network (757); and Compare, by one or more processors, the new access token and the new update token generated by the authorization server (201) with the access token and the update token generated by the neural network (757) to validate the new access token and the new update token generated by the authorization server (201).

Description

BACKGROUND

[0001] The present invention relates to the security of computer resources. More precisely, one or more embodiments of the present invention provide secure access to a specific computer resource. Even more precisely, one or more embodiments of the present invention provide a novel and useful solution to ensure that update tokens presented by a native application during an Open Authorization (OAuth) update are sent from the same entity to which they were issued. SUMMARY

[0002] In one or more embodiments of the present invention, an authorization server receives from a native application on a device an initial authorization, a public key of a private / public key pair generated on the device, and confirmation of the authenticity of the native application. The authorization server receives from the native application on the device an update token and a digital signature of the update token, which is created using the private key. The authorization server recognizes the update token only when it is verified against the previously registered public key. The authorization server validates the digital signature of the update token.In response to the validation of the update token by the native application on the unit, the authorization server transmits a new access token and a new update token to the native application on the unit, so that the new access token enables the native application on the unit to access the computer resource.

[0003] In one or more embodiments, the method(s) described herein is / are carried out by executing a computer program product on a computer system.

[0004] US 2021 / 0 044 976 A1 describes a process for mobile-initiated authentication to web services in which user credentials are generated in a trusted execution environment of the mobile device and transmitted to a server to enable access to the web service without directly entering the web service credentials on a dependent device.

[0005] US 2021 / 0 051 015 A1 describes a system for creating a hybrid token architecture in which unique tokens are generated and stored based on authentication identifiers to link successive authentication sessions and thus enable a chain of secure interactions. BRIEF DESCRIPTION OF THE DRAWINGS Fig. 1 represents an exemplary system and network in which the present disclosure can be carried out; Fig. 2 provides an overview of one or more embodiments of the present invention, which is implemented within an Open Authorization (OAuth) system; Fig. 3 is a general schedule of one or more operations that are performed in one or more embodiments of the present invention; Fig. Figure 4 illustrates an exemplary blockchain network, shown to be used in one or more embodiments of the present invention; Fig. 5 represents an exemplary blockchain ledger as used in one or more embodiments of the present invention; Fig. Figure 6 illustrates a general set of operations using a blockchain according to one or more embodiments of the present invention; Fig. Figure 7 illustrates an exemplary neural network as used in one or more embodiments of the present invention; Fig. Figure 8 represents a cloud computing environment according to an embodiment of the present invention; and Fig. Figure 9 represents abstraction model layers of a cloud computing environment according to an embodiment of the present invention. DETAILED DESCRIPTION

[0006] As described herein, one or more embodiments of the present invention utilize entity-bound Public Key Infrastructure (PKI) credentials to sign an Open Authorization (OAuth) update token in the message payload of the update token. Therefore, in one or more embodiments of the present invention, registration of the public key of a credential pair is performed during the creation of an initial grant, and the addition of a signature via the update token is provided during any subsequent update token flow.

[0007] One or more embodiments of the present invention utilize patterns such as Fast Identity Online (FIDO) to create a unit-bound key pair including the validation of such a key pair, and require nothing other than application-level payloads (i.e., no Transport Layer Security (TLS) extensions).

[0008] In one or more embodiments of the present invention, in which an OAuth system is used, a FIDO confirmation payload, which uses the update token itself as a challenge, is added to the parameters of the update token payload and validated on the server to ensure that the signature is performed with a key that was previously registered on a unit-bound basis.

[0009] Such OAuth systems provide an identity security pattern in native applications, so that after installing an application, a user participates in a registration process to create a long-term OAuth grant (first refresh token and access token) so that the application can act as that user when calling application programming interfaces (APIs) to a computer resource, such as data, programs, hardware, etc.

[0010] An example OAuth registration process for a user begins with the user entering a user profile (e.g., name, address, etc.) for initial identification. In one or more registration scenarios, multi-factor authentication (MFA) is used, where the user provides not only a password but also biometric information (e.g., the user's fingerprint); the user's current location, determined by a Global Positioning System (GPS) sensor in an electronic device used by the user; a current transmission connection to a specific cell tower in a mobile network; access to a security token, such as a dongle that generates constantly changing characters which a security system knows to be valid at any given time; and so on.

[0011] Once the user enters their user profile, MFA credentials, etc., this information is exchanged for an initial OAuth authorization from an authorization server.

[0012] A native application can launch a system browser on the device where a user authenticates via browser-based mechanisms to initiate a permission code granting flow, or a native application can offer this functionality built into the application itself for initial OAuth granting. The native application respects any redirect Uniform Resource Identifier (URI), which is a registered, custom launch URI for the app.

[0013] The user authenticates in another device browser (e.g., on a laptop) and is shown a Quick Response (QR) code containing the authorization code, allowing the native application to scan the QR code.

[0014] Regardless of the specific flow (of the variants described above or similar), an initial token is issued for the application on the unit. The update token is then stored in an app-specific secure storage area to prevent disclosure to other apps.

[0015] After registration, whenever the native application on the device (e.g., a mobile device such as a smartphone) requires a new access token to call APIs, an update token flow is performed by the native application calling the token endpoint of the authorization server. Only the update token itself serves to indicate the authorization being updated.

[0016] The problem with the OAuth process just described, which one or more embodiments of the present invention overcome in a novel and meaningful way, is that no proof is provided that the update token is being presented by the entity to which it was originally issued. Therefore, without the present invention, the authentication server cannot detect / distinguish a scenario in which the update token has been compromised by the entity, the native application, and / or the network, such that the update token is being presented by a different entity or program.

[0017] To address this problem, one or more embodiments of the present invention allow the native application to use an asymmetric, unit-bound credential that the application creates during the registration phase to sign the refresh token each time a refresh token flow is performed. By ensuring that the signing operation can only take place on the unit where the grant is first created, the server has a much higher level of confidence that the OAuth grant is being used by the application on the unit to which it was issued.

[0018] One or more embodiments of the present invention offer a clear improvement over token binding. Token binding uses cryptographic certificates but requires the use of a Transport Layer Security (TLS) extension to obtain cryptographic certificates on both sides of a TLS connection (e.g., between a client and an authorization server). Therefore, user instrumentation of such a system requires a high level of expertise, time, and computing resources, which the present invention does not require. Furthermore, token binding does not require that the credential created on the client be entity-bound, making it less secure. Therefore, one or more embodiments of the present invention provide a resource security solution that resides at the application data layer (e.g., by...extra parameters used in OAuth payloads) and is not dependent on token binding implementations in TLS.

[0019] At a high level, two or more embodiments of the present invention have two phases: a registration phase and a subsequent grant refresh. Registration phase

[0020] During registration, the native application receives or captures "initial grant data" from the user. In one or more embodiments of the present invention, this initial grant data consists of Resource Owner Password Credentials (ROPC) user authentication information, such as a username / password, which is provided to the native application on the client unit via a user interface.

[0021] In one or more embodiments of the present invention, this initial grant data is an authorization code that is either obtained from a handover (calling a user-defined start URI) from the system browser or scanned via a QR code.

[0022] Before the native application sends this initial grant data to the token endpoint to obtain its first grant, the native application creates a local, entity-bound public / private key credential.

[0023] In one or more embodiments of the present invention, the operating system of the Fast Identity Online - 2 (FIDO2) platform authenticator unit provides application programming interfaces (APIs) that are used to create the credential.

[0024] In one or more embodiments of the present invention, platform APIs (e.g. the Secure Enclave APIs) create the credentials.

[0025] The generated credential may require user verification before it can be created and used. This choice depends on the security requirements (policies) of the organization providing the API services and the desired user experience. In the terminology and specifications of Fast Identity Online (FIDO), user verification is optional, and this remains the case with the concepts described herein.

[0026] After generating the key pair, the native application creates a FIDO attestationObject, which is appended to the initial attestation data in a request to the OAuth token endpoint on the authentication server. In one or more embodiments of the present invention, a packed attestation format is used, such that the clientDataJSON input into the attestation object creation is the initial attestation data (rather than a challenge provided by a server).

[0027] In one or more embodiments of the present invention, the private authentication key is embedded within the native application source itself. The protection of the private authentication key is achieved using a technology such as white-box encryption and secure native code distribution practices.

[0028] One or more embodiments of the present invention utilize an attestation protocol such as FIDO2 attestation.

[0029] An attestation, such as FIDO2 attestation, provides the authentication server with proof of the make / model of the client authenticator used. In the case of a native application acting as the client authenticator, this confirms the application's integrity by stating that the provider and version of the native application match those specified by the application developer, thus establishing trust that the application performs as intended.

[0030] In one or more embodiments of the present invention, the authentication server must be able to prove that the newly created credential, which is used to sign update token flows, is unit-bound, so that the private key is used only on the unit on which it is created. Without such confirmation, the server does not know that the client exchanging data with it is a legitimate installation of the application. If the application uses native FIDO2 APIs provided by the client unit's operating system, the confirmation is provided by the platform. Otherwise, the confirmation is provided in the native application code.

[0031] The native application then submits the initial grant data, the attestationObject (which includes the public key of the entity-bound attestation), and the signature of the initial grant data (to verify the public key) to the OAuth authorization server's token endpoint.

[0032] The OAuth authorization server verifies the attestation using preconfigured metadata, including the trusted signer of the private attestation key. This verification includes checking that the authenticator data in the attestation object indicates that user verification has been performed, provided this is the server's policy. Initial grant data is also verified. The public key of the entity-bound credential is associated with the OAuth grant server-side, and the initial refresh token and access token are returned to the client of the native application. Subsequent grant update

[0033] From time to time, the native application performs new refresh token flows as access tokens expire. In one or more embodiments of the present invention, the refresh token flow includes, in addition to the FIDO authenticatorData refresh token, a signature (of the refresh token's hash) created using the private key of the entity-bound credential, which was registered during the initial grant creation. This provides the server with proof at each refresh that the request originated from the entity that created the grant. The clientDataJSON described in the FIDO authentication documentation, on the other hand, includes the refresh token as the challenge provided by a server.

[0034] In one or more embodiments of the present invention, the refresh_token is assigned a unique type. An example pseudocode for the clientDataJSON is: { "type": "urn:mycustomapp:oauth", "refresh_token": "RT_value"}

[0035] Therefore, no WebAuthn-defined challenge, origin, or token binding fields are required.

[0036] The entire post body of the refresh token flow is then described as: POST / oauth / token client_id=public_client&grant_type=refresh_token&refresh_token=RT_value&authenticator Data=b64url_authenticator_data&signature=b64url_sig

[0037] The authentication server ensures that the RT_value is valid and represents a refresh token (RT) known to the server. The authentication server locates the associated public key that was registered for granting when the grant was created (this is the allowCredentials list in FIDO terminology) and then ensures that the rest of the validation procedure is successful when verifying an authentication assertion, taking some minor considerations regarding data values ​​(such as the origin, which in one or more embodiments of the present invention is a Uniform Resource Name - URN), since this is a native scenario and not a browser-based WebAuthn-only scenario.

[0038] In one or more embodiments of the present invention, and to prevent Man In The Middle (MITM) attacks at the application level, other risk-reducing measures such as Certificate Pinning are also used as part of the overall solution.

[0039] Referring to the characters and especially to Fig. Figure 1 shows a block diagram of an exemplary system and network that can be used by and / or in the execution of one or more embodiments of the present invention. It should be noted that part or all of the exemplary architecture, including both the hardware and software shown for and within a server 101, can be accessed by a client unit 123 and / or a software delivery server 149 and / or a computer resource server 151 and / or computer resource(s) 153 and / or an application validation service server 155 and / or an artificial intelligence (AI) system 157 and / or a blockchain network 159, which are located in Fig. 1 are shown, and / or by a resource owner 200 and / or an authorization server 201 and / or a client unit 223 and / or a computer resource server 251 and / or (a) computer resource(s) 253 and / or an application validation service server 255, which are in Fig. 2 shown, and / or other processing units shown in other figures, which belong to one or more embodiments of the present invention, can be used.

[0040] The example server 101 includes a processor 103 connected to a system bus 105. The processor 103 can utilize one or more processors, each with one or more processor cores. A video adapter 107, which drives / supports a screen 109, is also connected to the system bus 105. The system bus 105 is connected via a bus bridge 111 to an input / output (I / O) bus 113. An I / O interface 115 is connected to the I / O bus 113. The I / O interface 115 enables data exchange with various I / O units, including a keyboard 117, a mouse 119, a slot 121 (which can include storage units such as CD-ROM drives, multimedia interfaces, etc.), and an external USB port 125.While the format of the ports connected to the I / O interface 115 can be any format known to those skilled in the art in computer architecture, in a single embodiment some or all of these ports are Universal Serial Bus (USB) ports.

[0041] As shown, server 101 can exchange data with network 127 using network interface 129. Network interface 129 is a hardware network interface, such as a network interface card (NIC). Network 127 can be an external network, such as the internet, or an internal network, such as Ethernet or a virtual private network (VPN).

[0042] A hard disk drive interface 131 is also connected to the system bus 105. The hard disk drive interface 131 forms the interface to a hard disk drive 133. In one embodiment, the hard disk drive 133 occupies a system memory 135, which is also connected to the system bus 105. The system memory is defined as the lowest level of volatile memory in the server 101. The volatile memory includes additional higher levels of volatile memory (not shown), including, but not limited to, cache memory, registers, and buffer memory. Data occupying the system memory 135 includes an operating system (OS) 137 of the server 101 and application programs 143.

[0043] OS 137 includes a shell 139 to provide transparent user access to resources, such as application programs 143. In general, the shell 139 is a program that provides an interpreter and an interface between the user and the operating system. More specifically, the shell 139 executes commands entered into a command-line user interface or commands from a file. Thus, the shell 139, also known as the command processor, is generally the highest level of the operating system software hierarchy and acts as a command interpreter. The shell provides a prompt, interprets commands entered via the keyboard, mouse, or other user input devices, and sends the interpreted command(s) to the appropriate lower levels of the operating system (e.g., a kernel 141) for processing.It should be noted that although Shell 139 is a text-based, line-oriented user interface, one or more embodiments of the present invention equally support other user interface modes, such as graphical, speech-based, gesture-based, etc.

[0044] As shown, OS 137 also includes the kernel 141, which includes lower levels of functionality for OS 137, including the provision of important services required by other parts of OS 137 and application programs 143, including memory management, process and task management, disk management, and mouse and keyboard management.

[0045] The application programs 143 include a renderer, shown by way of example as a browser 145. The browser 145 comprises program modules and instructions that enable a World Wide Web (WWW) client (i.e., the server 101) to send and receive network messages to and from the Internet using Hypertext Transfer Protocol (HTTP) messaging, thus enabling data exchange with the client unit 123 and / or the software delivery server 149 and / or the computer resource server 151 and / or the computer resource(s) 153 and / or the application confirmation service server 155 and / or other computer systems.

[0046] The application programs 143 in the system memory of server 101 also include a Program for Secure Access to Computer Resources (PSACR) 147. The PSACR 147 includes code for executing the processes described below, including the one in the Fig. 2, Fig. 3, Fig. 4, Fig. 5, Fig. 6 to Fig. 7 described. In one or more embodiments of the present invention, the server 101 can download the PSACR 147 from the software delivery server 149, among other things on an on-demand basis, wherein the code in the PSACR 147 is only downloaded when it is needed for execution. It should also be noted that in one or more embodiments of the present invention, the software delivery server 149 performs all of the functions belonging to the present invention (including the execution of the PSACR 147), so that the server 101 consequently no longer needs to use its own internal data processing resources to execute the PSACR 147.

[0047] It should be noted that the hardware elements shown in Server 101 are not intended to be exhaustive, but rather representative, in order to highlight important components required by one or more embodiments of the present invention. For example, Server 101 may include alternative main storage units such as magnetic tape cartridges, DVDs (digital versatile disks), Bernoulli cartridges, and the like. These and other variations are said to be within the scope of the present invention.

[0048] With reference to Fig. Figure 2 shows an overview of one or more embodiments of the present invention, which is carried out within a modified Open Authorization (OAuth) system 206.

[0049] As shown in steps 1 and 2, a resource owner 200, which is either a human user connected to the client unit 223 via a user interface or a computer used by a user to present initial grant credentials to the client unit via an application programming interface (API), presents initial grant credentials to the native application 202. Examples of such credentials include, but are not limited to, a permission code, a username, and a password, etc.

[0050] As described in step 2a (which is shown to take place within the client unit 223 and in connection with the application acknowledgment service server 255, which is the one in Fig. (As shown in step 1, the application validation service server 155 corresponds), the native application 202 sends the credentials received from the resource owner 200 for initial granting to the application validation service server 255. The application validation service server 255 provides a validation service for the native application, which checks whether the native application 202 is unmodified and running on an authorized client unit 223. It provides a cryptographic proof of this validation, which is included in the payload of step 3a.

[0051] As shown in step 2b, the client unit 223 then generates a public / private key pair 204, which is used as described below.

[0052] As shown in step 3a, the native application 202 sends the initial authorization, the confirmation result (generated by the native application's confirmation service), the public key (generated by the native application 202), and the initial authorization signature, signed with the corresponding private key, to the authorization server 201.

[0053] As shown in step 3b, the authorization server verifies the application's verification result using the application verification service. If the verification is not confirmed by the verification service, the registration is aborted.

[0054] As shown in step 3c, the authorization server 201 verifies the public key with the initial authorization signature and stores the public key, which is used in the following steps to grant access to the computer resource(s) 253.

[0055] As shown in step 4, the authorization server 201 generates an initial access token and a refresh token and returns them to the native application. The initial access token allows the native application 202 to access the computer resource(s) 253, and the refresh token allows the authorization server 201 to update / renew the access token.

[0056] As shown in step 5, the native application 202 uses an access token (i.e., either the initial access token or a new access token whose creation by the authorization server 201 was approved by the update token) to access the computer resource(s) 253 through the native application 202 on behalf of the resource owner 200.

[0057] Access tokens have a limited validity period (e.g. less than five minutes) and therefore need to be updated at regular intervals using an update token.

[0058] Therefore, and as shown in step 6, the native application 202 periodically exchanges a current refresh token for a new access token and a new refresh token with the authorization server 201. This means that a refresh token is used only once; consequently, a new refresh token replaces an old / current refresh token. In the request from the native application 202 to the authorization server 201 to generate a new refresh token, the old refresh token is signed by the native application 202 with a private key, and the signature is sent to the authorization server 201 as part of the token refresh flow. Thus, the authorization server 201 only generates and returns a new access token and a new refresh token when the signature for the old refresh token is verified with the public key received in step 3a.

[0059] With reference to Fig. Figure 3 is a general flow chart of one or more operations that are performed in one or more embodiments of the present invention.

[0060] Following initiator block 301, an authorization server receives from a native application on a device an initial authorization request, a public key of a private / public key pair generated on the device, and an acknowledgment of the native application's authenticity, as shown in block 303 and in Fig. 2 is described in detail.

[0061] As shown in Block 305 and in Fig. As described in detail in Section 2, the authorization server receives an update token and a digital signature of the update token created with the private key from the native application on the unit. In one or more embodiments of the present invention, the authorization server recognizes the update token only if the update token is verified with the public key that was previously registered.

[0062] As shown in Block 307 and in Fig. As described in detail in section 2, the authorization server then validates the digital signature of the update token.

[0063] As shown in Block 309 and in Fig. As described in detail in section 2, in response to the validation of the update token by the native application on the device, the authorization server transmits a new access token and a new update token from the authorization server to the native application on the device. This new access token enables the native application on the device to access the computer resource.

[0064] The schedule ends at the final block, 311.

[0065] In one or more embodiments of the present invention, and as described herein, the public / private key is generated on the unit, and the private key is protected against unauthorized use or extraction by being bound to the unit. That is, the private key cannot be "hacked" by a malicious actor, since only the client unit that generated the public / private key pair can access it.

[0066] In one or more embodiments of the present invention, the authorization server and the client are components of an Open Authorization (OAuth) architecture (e.g., the one described in Fig. 2 modified Open Authorization (OAuth) systems shown 206), which were modified by the present invention.

[0067] In one or more embodiments of the present invention, an update authorization is verified as originating from the entity to which it was issued, wherein data in an application payload is used by the client without the use of a Transport Layer Security (TLS) protocol extension, as described above.

[0068] In one or more embodiments of the present invention, one or more processors (e.g., within the in Fig. 2. The authorization server shown (201) establishes an entity identity by applying Fast Identity Online (FIDO) authentication as part of processing an update authorization request. Details regarding FIDO and / or FIDO2 are described above.

[0069] In one or more embodiments of the present invention, the identity of the unit is established and / or confirmed by an identifier of that particular unit, such as an Internet Protocol (IP) address used by that particular unit and specified by a lookup table that assigns that particular unit to a specific IP address; a Media Access Control (MAC) assigned to a network interface controller for use by that particular unit as a network address in transmissions within a network segment; a Uniform Universal Identifier (UUID) generated for and specific to that particular unit, etc.

[0070] Therefore, in one or more embodiments of the present invention, the authorization server validates the update token from the native application on the device only if the update token originated from a specific device that generated the initial authorization and the public key of a private / public key pair. In one or more embodiments of the present invention, the authorization server identifies this specific device by its IP address, MAC address, UUID, etc., which are currently used by the specific device.an, which is part of a header that is sent by this specific entity to the authorization server when this specific entity sends the initial authorization, the public key of a private / public key pair generated on the entity, the confirmation of the authenticity of the native application, and the update token to the authorization server.

[0071] Therefore, in one or more embodiments of the present invention, the authorization server validates the update token from the native application on the unit only if the update token came from a specific unit that created the initial authorization and the public key of a private / public key pair, regardless of which application within that unit or within another unit sent the update token, the initial authorization and / or the public key of a private / public key pair to the authorization server.

[0072] In one or more embodiments of the present invention, a blockchain system is used to ensure that data / elements / factors generated by the system are securely stored and transmitted. Fig. The authorization servers shown in 201 are used to generate access tokens and / or update tokens, which are valid by storing these data / elements / factors in a blockchain ledger.

[0073] Thus, with reference to Fig. 4, in one or more embodiments of the present invention, a blockchain network 459 (which corresponds to the one described in Fig. Blockchain network 459 (shown in Figure 1) is used to provide the infrastructure (e.g., chaincode execution) and services (e.g., membership services such as identity management) to securely and transparently store, track, and manage transactions on a single point of truth. Blockchain network 459 maintains a verifiable record (the single point of truth) of every single transaction ever conducted within the system. Once data is entered into the blockchain, it can never be deleted (immutability) or modified. That is, any change to a record would be considered issuing / introducing a new transaction. By preventing this, the verifiability and auditability of data are ensured.

[0074] The 459 blockchain network (also known as "blockchain fabric," "blockchain system," "open blockchain," or "Hyperledger fabric") is based on a distributed database of records of all transactions or digital events that have been executed and shared among participants. A single transaction on the blockchain is validated or verified through a consensus mechanism involving a majority of the participants in the system. This allows the participating entities to be certain that a digital event has occurred by creating an irrefutable record in an approved public ledger.

[0075] When a transaction is executed, its corresponding chaincode is executed by several validating peers of the system. For example, as in Fig. As shown in Figure 4, peers 418a to 418d verify the validity of the transaction parameters, and once they reach consensus, a new block is created and appended to the blockchain network. This means that an application process 408 (e.g., the OAuth process, which is carried out on authentication server 201, which is located in...) Fig. 2), which runs on a supervisor computer 401 (e.g., the one described in ). Fig. 2 shown authentication server 201 and / or the one in Fig. 1 server 101) is running, executes an application such as the app 403 shown (e.g. an OAuth application), which instructs a software development kit (SDK) 410 to exchange data using general remote procedure calls (grpc) from membership services 409 that support the peer-to-peer network 404, which supports the blockchain 416 using peers 418a to 418d.

[0076] With reference to Fig. Figure 5 is an exemplary blockchain ledger 500 within blockchain 416 as used in one or more embodiments of the present invention.

[0077] In one or more embodiments of the present invention, the blockchain ledger 500 comprises an identifier of the supervisor computer (shown in block 502), such as the one shown in Fig. 2 shown authentication server 201 and / or the one in Fig. Server 101, shown in 1, which also includes the one in Fig. Figure 4 shows a peer-to-peer network 404 that supports and / or utilizes this network. For example, in one or more embodiments of the present invention, block 502 includes an Internet Protocol (IP) address, a Uniform Resource Locator (URL), etc., of the supervisor computer. This information is shared by peers in the network shown in Figure 4. Fig. The peer-to-peer network 404 shown in Figure 4 is used to receive transactions relating to the process flow described herein.

[0078] In one or more embodiments of the present invention, the blockchain ledger 500 also includes a copy of the initial authorization (block 504), the public key (block 506), the confirmation of the authenticity of the native application (block 508), the update token (block 510), and the digital signature of the update token (block 512), which are used by the authentication server to generate a first new access token and a first new update token. The information is then retrieved from the blockchain ledger 500 in a form that ensures it remains unchanged since it was first presented to (though not necessarily used by) the authentication server.This means that as soon as the initial authorization, the public key of a private / public key pair generated on the device, and the confirmation of the native application's authenticity are created, they are sent in parallel to both the authorization server and the blockchain. However, there is a possibility that the initial authorization, the public key of a private / public key pair generated on the device, and the confirmation of the native application's authenticity could become corrupted before they are used by the authorization server. Therefore, an undamaged version of the initial authorization, the public key of a private / public key pair generated on the device, and the confirmation of the native application's authenticity are stored on the blockchain, where they are kept in a blockchain system that prevents any data corruption.

[0079] An exemplary company of the in Fig. The blockchain network 459 shown in section 4 is in Fig. 6 is shown. As described in step 601, a data processing unit (e.g., the one in Fig. 4 Supervisor computer 401 shown, which in one or more embodiments is the one described in Fig. Server 101 shown in 1 and / or the one in Fig. 2 authorization server 201 shown) a transaction by (e.g. receiving a native application on a unit, an initial authorization grant, a public key of a private / public key pair generated on the unit, confirmation of the authenticity of the native application, an update token, a digital signature of the update token created with the private key, etc., as above in Fig. 2 is described). As shown in step 603, the supervisor computer 401 converts the transaction into a hash value using a hash algorithm, such as the Secure Hash Algorithm (SHA-2), and then signs the hash with a digital signature. This signature is then broadcast to the in Fig. The data is transferred to the peer-to-peer network 404 shown in step 605, as described in step 605. A peer in the peer-to-peer network 404 (e.g., peer 418a) summarizes the transaction(s) to which the data is shown in step 605. Fig. Blockchain 416, as shown in step 607, is merged with the four blocks shown, as shown in block 609. Each block contains a link to a previous block. The newly revised Blockchain 416 is validated by one or more of the other peers in peers 418a to 418d and / or by other peers from other authorized blockchain systems (step 611). The validated block is then broadcast to peers 418b to 418d, as described in step 613. These peers 418b to 418d listen for and receive the new blocks and merge them into their copies of Blockchain 416 (step 615).

[0080] Thus, this describes in Fig. 4 to Fig. Section 6 describes a blockchain fabric as a blockchain implementation topology that provides a distributed ledger persistently storing and managing digital events called transactions. These events are shared among multiple participants, each of whom holds a share in them. The ledger can only be updated by consensus among the participants. Furthermore, once recorded, transactions can never be altered (they are immutable). Each recorded transaction is cryptographically verifiable with proof of consent from the participants, thus providing a robust provenance mechanism that traces its origin.

[0081] Therefore, a blockchain fabric uses a distributed network to manage a digital ledger of events, thus providing very high security for the digital ledger, as the blockchain stored in each peer depends on previous blocks that provide protected data for subsequent blocks in the blockchain.

[0082] This means that the blockchain fabric described herein provides a decentralized system, where each node in a decentralized system has a copy of the blockchain. This eliminates the need for a centralized database managed by a trusted third party. Transactions are broadcast to the network using software applications. Network nodes can validate transactions, add them to their copy, and then broadcast these additions to other nodes. As mentioned above, however, the blockchain is still extremely secure because each new block is protected (e.g., converted into a hash value) based on one or more previous blocks.

[0083] Thus, in one or more embodiments of the present invention, it is assumed that the above described Fig. The 3 described new access tokens are specified as a first new access token and the new update token as a first new update token.

[0084] In one or more embodiments of the present invention, a blockchain architecture (e.g., the one described in) stores Fig. 1 shown server 101 and / or the one in Fig. 2 shown authorization servers 201 and / or the supervisor computer 401 and / or the blockchain network 459, which are in Fig. 4 shown) a stored blockchain which includes the initial authorization, the public key, the confirmation of the authenticity of the native application, the update token and the digital signature of the update token, which are used by the authentication server to generate the first new access token and the first new update token.

[0085] The supervisor computer (e.g., the authorization server 201) retrieves the stored blockchain from the blockchain architecture and generates a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application, the update token, and the update token digital signature from the stored blockchain.

[0086] One or more processors compare the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token match the second new access token and the second new update token.

[0087] In response to the finding that the first new access token and the first new update token match the second new access token and the second new update token, one or more processors authorize the transfer of the first new access token and the first new update token, generated by the authorization server, from the authorization server to the native application.

[0088] In one or more embodiments of the present invention, the new access token is a first new access token and the new update token is a first new update token; the blockchain described above comprises the initial authorization, the public key, the confirmation of the authenticity of the native application, the update token, and the digital signature of the update token, which are used by the authentication server to generate the first new access token and the first new update token; the stored blockchain is retrieved from the blockchain architecture;The authentication server generates a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application, the update token, and the digital signature of the update token from the stored blockchain.

[0089] However, in this one or more embodiments, one or more processors compare the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token do not match the second new access token and the second new update token. Therefore, and in response to the determination that the first new access token and the first new update token do not match the second new access token and the second new update token, one or more processors block the transmission of the first new access token and the first new update token, generated by the authorization server, from the authorization server to the native application.

[0090] Thus, the contents of the blockchain are used to confirm that the initial authorization, the public key, the confirmation of the authenticity of the native application, the update token, and the digital signature of the update token, which are used by the authentication server to generate the first new access token and the first new update token, are valid, as ensured by their prior storage in the blockchain.

[0091] In one or more embodiments of the present invention, artificial intelligence (e.g. a neural network) is used to validate the access token and the update token generated by the authorization server.

[0092] With reference to Fig. Figure 7 shows an exemplary AI system used in one or more embodiments of the present invention, which is a deep neural network (DNN) 757 (similar to the one described in Figure 7). Fig. 1 corresponds to the AI ​​system 157 shown in Figure 1, as used in one or more embodiments of the present invention. The nodes within the DNN 757 represent hardware processors, virtual processors, software algorithms, or a combination of hardware processors, virtual processors, and / or software algorithms.

[0093] In one or more embodiments of the present invention, the DNN 757 is trained to generate a neural network-generated access token and / or a neural network-generated update token, as shown in Block 702.

[0094] The DNN 757 was trained to use authorization server data 700 (e.g., the initial authorization grant, the public key, the confirmation of the authenticity of the native application, the update token, and the digital signature of the update token, which are used by the authentication server to generate the new access token and the new update token) to generate a neural network-generated access token and / or a neural network-generated update token, as shown in block 702.The DNN 757 is trained by using various known types of initial permissions, types of public keys, types of native application authenticity confirmations, types of update tokens, and types of update token digital signatures, which are used to generate known neural network-generated access tokens and / or neural network-generated update tokens.

[0095] The DNN 757 is an exemplary type of neural network used in one or more embodiments of the present invention. Other neural networks that may be used in one or more embodiments of the present invention include convolutional neural networks (CNNs) and neural networks that employ other forms of deep learning.

[0096] A neural network, as the name suggests, is roughly modeled after a biological neural network (e.g., a human brain). A biological neural network consists of a series of interconnected neurons that influence each other. For example, a first neuron can be electrically connected to a second neuron via a synapse through the release of neurotransmitters (from the first neuron), which are received by the second neuron. These neurotransmitters can cause the second neuron to be excited or inhibited. A pattern of excited / inhibited, interconnected neurons ultimately leads to a biological outcome, including thoughts, muscle movements, memory retrieval, and so on.While this description of a biological neural network is greatly simplified, it can be summarized as follows: one or more biological neurons influence the function of one or more other bioelectrically connected biological neurons.

[0097] An electronic neural network consists of electronic neurons. Unlike biological neurons, however, electronic neurons are never actually "inhibitory," but rather only "excitatory" to varying degrees.

[0098] The electronic neurons (referred to herein simply as "neurons" or "nodes") in DNN 757 are arranged in layers designated as input layer 703, hidden layers 705, and output layer 707. Input layer 703 comprises neurons / nodes that receive input data and send it to a series of hidden neuron layers (e.g., hidden layers 705), with neurons from one layer in the hidden layers being connected to all neurons in the next layer in the hidden layers 705. The final layer in the hidden layers 705 then outputs a computational result to output layer 707, which is often a single node holding vector information.

[0099] As just mentioned, each node in the depicted DNN 757 represents an electronic neuron, such as the depicted neuron 709. As shown in block 711, each neuron (including neuron 709) functionally comprises at least four features: an algorithm, an output value, a weight, and a bias value.

[0100] The algorithm is a mathematical formula for processing data from one or more upstream neurons. For example, suppose that one or more of the neurons depicted in the middle hidden layers 705 send data values ​​to neuron 709. Neuron 709 then processes these data values ​​by executing the mathematical function shown in block 711 to generate one or more output values, which are then sent to another neuron, such as another neuron within hidden layers 705 or a neuron in output layer 707. Each neuron also has a weight specific to that neuron and / or to other connected neurons. Furthermore, the output value(s) are added to the bias value(s), which increases or decreases the output value, allowing for further fine-tuning of the DNN 757.

[0101] For example, suppose that neuron 713 sends the results of its analysis of a data unit to neuron 709. Neuron 709 has an initial weight that defines the importance of data coming from neuron 713 in particular. If the data is important, the data coming from neuron 713 is heavily weighted and / or its bias is increased, causing the mathematical function(s) within neuron 709 to produce a higher output that has a greater impact on neurons in the output layer 707. Similarly, if neuron 713 is determined to be important for the operations of neuron 709, its weight is increased, so that neuron 709 receives a higher value for the output of its mathematical function. Alternatively, the output of neuron 709 can be minimized by reducing the weight and / or bias applied to it.The weights / biases used to influence the output of neuron 709 are reduced. These weights / biases are adjustable for one neuron, some, or all neurons in the DNN 757, resulting in a reliable output from output layer 707. In one or more embodiments of the present invention, the search for weight and bias values ​​is performed automatically by training the neural network. In one or more embodiments of the present invention, manual adjustments are applied to optimize hyperparameters such as learning rate, dropout, regularization factor, etc. Therefore, training a neural network involves performing forward and backward propagation on multiple datasets until the optimal weights and bias values ​​are achieved to minimize a loss function.The loss function measures the difference between the values ​​predicted by a neural network and the actual labels for the various inputs.

[0102] During manual adjustments while training DNN 757, the weights are repeatedly adjusted until the output from output layer 707 meets expectations.

[0103] In manual adjustments, the weights (and / or mathematical functions) are modified using backpropagation, where neuron weight values ​​are adjusted using a gradient descent method that determines the direction in which each weight value should be adjusted. This gradient descent process shifts the weight in each neuron in a specific direction until the output from output layer 707 improves (e.g., until it accurately generates the appropriate access tokens and update tokens).

[0104] As in Fig. As shown in Figure 7, different neuron layers are shaded differently, indicating that in one or more embodiments of the present invention they are specifically trained to recognize different aspects of information used by an authentication server when generating update tokens.

[0105] Thus, in one or more embodiments of the present invention, within the hidden layers 705 there is a layer 706 containing neurons intended to evaluate types of authorization grants; a layer 708 containing neurons intended to evaluate types of public keys; and a layer 710 containing neurons intended to evaluate types of confirmation of the authenticity of native applications.

[0106] The outputs from neurons in layer 710 then control the value found in output layer 707.

[0107] Thus, one or more embodiments of the present invention input the initial authorization, the public key, the confirmation of the authenticity of the native application, the update token, and the digital signature of the update token into a neural network, wherein the neural network is trained to generate an access token and an update token generated by the neural network. One or more processors then compare the new access token and the new update token generated by the authorization server with the access token and the update token generated by the neural network in order to validate the new access token and the new update token generated by the authorization server.

[0108] In one or more embodiments of the present invention, one or more processors determine that the new access token and the new update token match the access token and the update token generated by the neural network. Upon determining that the new access token and the new update token match the access token and the update token generated by the neural network, one or more processors transmit the new access token and the new update token to the native application.

[0109] In one or more embodiments of the present invention, one or more processors detect that the new access token and the new update token do not match the access token and the update token generated by the neural network. In response to this detection, one or more processors block the transmission of the new access token and the new update token to the native application.

[0110] Thus, in one or more embodiments of the present invention, the neural network either validates or invalidates the work performed by the authentication server described above.

[0111] Therefore, and as described in various embodiments presented here, the verification of the authenticity of the native application ensures the integrity and authenticity of the native application and the entity.

[0112] In one or more embodiments, the present invention is implemented using cloud computing. However, it should be clarified from the outset that the implementation of the teachings presented herein is not limited to a cloud computing environment, although this disclosure contains a detailed description of cloud computing. Rather, embodiments of the present invention can be implemented together with any other type of data processing environment, now known or subsequently invented.

[0113] Cloud computing is a service delivery model that enables seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, main memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management overhead or interaction with a service provider. This cloud model comprises at least five characteristics, at least three service models, and at least four implementation models.

[0114] The properties are as follows: On-Demand Self-Service: A cloud user can unilaterally and automatically provide data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider. Broad Network Access: Functions are available over a network, accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g. mobile phones, laptops and PDAs). Resource pooling: The provider's data processing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources being dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control over or knowledge of the exact location of the provided resources, but is nevertheless able to define a location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling (scale out), in some cases automatically, and released quickly for rapid scale-in. To the user, the available features often appear unlimited and can be purchased in any quantity at any time. Measured Service: Cloud systems automatically control and optimize resource usage by employing a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, thereby creating transparency for both the provider and the user of the service. Software as a Service (SaaS): The functionality provided to the user consists of using the provider's applications running in a cloud infrastructure. These applications are accessible from various client devices via a thin-client interface, such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The function provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, within the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and potentially over configurations of the application hosting environment. Infrastructure as a Service (IaaS): The functionality provided to the user consists of supplying processing, storage, networking, and other basic data processing resources, enabling the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and potentially limited control over selected network components (e.g., host firewalls).

[0115] The following are the deployment models: Private Cloud: The cloud infrastructure is operated solely for one organization. In one or more implementations, it is managed by the organization or a third party and is located on the organization's own premises or on external premises. Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with shared concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). In one or more implementations, it is managed by the organizations or a third party and is located on the organization's own premises or in external premises. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community or public) that remain separate entities but are connected by a standardized or proprietary technology that enables data and application portability (e.g. cloud audience distribution for load balancing between clouds).

[0116] A cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure that comprises a network of interconnected nodes.

[0117] With reference to Fig. Figure 8 illustrates a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local data processing units used by cloud users, such as an electronic assistant (PDA) or a mobile phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automotive computer system 54N, exchange data. The nodes 10 exchange data with each other. In a single embodiment, these nodes are physically or virtually grouped together in one or more networks, such as private, community, public, or hybrid clouds described above, or in a combination thereof (not shown).This allows the cloud computing environment to offer infrastructure, platforms, and / or software as services, for which a cloud user does not need to maintain resources on a local data processing unit. It should be noted that the types of [in ] Fig. The data processing units 54A to 54N shown in Figure 8 are for illustrative purposes only, and the data processing nodes 10 and the cloud computing environment 50 can exchange data with any type of computer unit via any type of network and / or any type of network-accessible connection (e.g., using a web browser).

[0118] With reference to Fig. Figure 9 shows a set of functional abstraction layers that are used by the cloud computing environment 50 ( Fig. 9) will be provided. It should be clear from the outset that the in Fig.The components, layers, and functions shown in the diagram are for illustrative purposes only, and embodiments of the invention are not limited to them. As shown, the following layers and corresponding functions are provided:

[0119] A hardware and software layer 60 comprises hardware and software components. Examples of hardware components include: mainframe computers 61; servers 62 based on the RISC (Reduced Instruction Set Computer) architecture; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0120] A virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities are provided in one or more embodiments: virtual servers 71; virtual memory 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0121] In one example, an administration layer 80 provides the functions described below. A resource provisioning layer 81 provides the dynamic procurement of data processing resources and other resources used to perform tasks within the cloud computing environment. A metering and pricing layer 82 provides cost tracking when using resources within the cloud computing environment and billing for the consumption of these resources. In one example, these resources include application software licenses. A security layer provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service scope management (84) provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment (85) provides the advance planning and procurement of cloud computing resources for which a future requirement is anticipated, in accordance with an SLA.

[0122] A workload layer 90 provides examples of the functionality for which the cloud computing environment is used in one or more embodiments. Examples of workloads and functions provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; provision of training in virtual classrooms 93; data analytics processing 94; transaction processing 95; and secure processing 96 of access to computer resources, which performs one or more of the features of the present invention described herein.

[0123] The present invention may be a system, a method, and / or a computer program product. The computer program product may comprise a computer-readable storage medium (or media) containing computer-readable program instructions to induce a processor to execute aspects of the present invention.

[0124] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by a system to execute instructions. For example, a computer-readable storage medium can be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a removable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), removable compact storage disk-read-only memory (CD-ROM), a DVD (digital versatile disc), a USB flash drive, a floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium shall not, in its use herein, be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses traveling through an optical fiber cable), or electrical signals transmitted by a wire.

[0125] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0126] Computer-readable program instructions for executing the steps of the present invention can be assembly instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., as well as conventional procedural programming languages ​​such as C or similar languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter case, the remotely located computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be established with an external computer (for example, via the internet using an internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

[0127] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams or charts of methods, devices (systems), and computer program products according to embodiments of the invention. It is pointed out that each block of the flowcharts and / or block diagrams or charts, as well as combinations of blocks in the flowcharts and / or block diagrams or charts, can be executed by means of computer-readable program instructions.

[0128] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or another programmable data processing device to create a machine, such that the instructions executed via the processor of the computer or other programmable data processing device generate a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device, and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams or charts.

[0129] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause the execution of a series of process steps on the computer, other programmable device, or other unit in order to create a process implemented on a computer, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0130] The terminology used herein serves only to describe certain embodiments and is not to be construed as limiting the present invention. In its use herein, the singular forms "a", "an" and "the" shall also include the plural forms unless the context clearly indicates otherwise. It is further noted that the terms "has" and / or "having" when used in this specification denote the presence of specified features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other / further features, integers, steps, operations, elements, components, and / or groups thereof.

[0131] The corresponding structures, materials, processes, and equivalents of all means or step-plus-function elements in the following claims shall comprise any structure, material, or process for carrying out the function in combination with other claimed elements, which are claimed individually. The description of various embodiments of the present invention is provided for illustrative and explanatory purposes; however, it is not intended to be exhaustive or limited to the present invention as disclosed. Many modifications and variations are apparent to a person skilled in the art without departing from the scope of the present invention.The embodiment was chosen and described in order to best explain the basic ideas of the present invention and its practical application, and to enable other skilled persons to understand the present invention with regard to various embodiments with different modifications as are suitable for the respective intended use.

[0132] In one or more embodiments of the present invention, each method described herein is executed using a VHDL (Hardware Description Language) program and a VHDL chip. VHDL is an exemplary entry-level design language for field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and other similar electronic devices. Thus, in one or more embodiments of the present invention, each software-executed method described herein is emulated by a hardware-based VHDL program, which is then applied to a VHDL chip, such as an FPGA.

[0133] Having thus described embodiments of the present invention of the present application in detail and by reference to illustrative embodiments thereof, it is evident that modifications and variants are possible without deviating from the scope of the present invention as defined in the attached claims.

Claims

[1] Procedure that includes: Received by an authorization server (201) and by a native application (202) on a unit, an initial authorization grant, a public key of a private / public key pair generated on the unit, and an acknowledgment of the authenticity of the native application (202); Received by the authorization server (201) and by the native application (202) on the unit, an update token and a digital signature of the update token created with the private key, wherein the authorization server (201) recognizes the update token only when the update token is verified with the public key that was previously registered; Validate, by the authorization server (201), the digital signature of the update token; In response to the validation of the update token from the native application (202) on the unit, the authorization server (201) transmits a new access token and a new update token from the authorization server (201) to the native application (202) on the unit, the new access token enabling the native application (202) on the unit to access the computer resource; Input into a neural network (757) the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token, and the digital signature of the update token, wherein the neural network (757) is trained to generate an access token generated by the neural network (757) and an update token generated by the neural network (757); and Compare, by one or more processors, the new access token and the new update token generated by the authorization server (201) with the access token and the update token generated by the neural network (757) to validate the new access token and the new update token generated by the authorization server (201). [2] Method according to claim 1, wherein the confirmation of the authenticity of the native application (202) ensures the integrity and authenticity of the native application (202) and the unit. [3] Method according to claim 1, wherein the public / private key is generated on the unit and the private key is protected against unauthorized use or removal by being bound to the unit. [4] Method according to claim 1, wherein the authorization server (201) and the client are components of an Open Authorization, OAuth, architecture. [5] Method according to claim 1, wherein an update authorization is verified as originating from the entity to which it was issued, wherein data in an application payload is used by the client without the use of a Transport Layer Security, TLS, protocol extension. [6] The method of claim 1, further comprising: Confirm, by one or more processors, an entity's identity by applying Fast Identity Online, FIDO, authentication as part of an update authorization process. [7] The method of claim 1, further comprising: Determine, by one or more processors, that the new access token and the new update token match the access token and the update token generated by the neural network (757); and In response to the finding that the new access token and the new update token match the access token and update token generated by the neural network (757), the new access token and the new update token are transmitted, by one or more processors, to the native application (202). [8] The method of claim 1, further comprising: Determine, by one or more processors, that the new access token and the new update token do not match the access token and the update token generated by the neural network (757); and In response to the finding that the new access token and the new update token do not match the access token and the update token generated by the neural network (757), blocking, by one or more processors, a transmission of the new access token and the new update token to the native application (202). [9] Method according to claim 1, wherein the new access token is a first new access token and the new update token is a first new update token and wherein the method further comprises: Store, in a blockchain architecture (459), a stored blockchain (416) which contains the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature, which are used by the authentication server to generate the first new access token and the first new update token; Retrieve from the blockchain architecture (459), the stored blockchain (416); Generating, by the authentication server, a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature from the stored blockchain (416); Compare, using one or more processors, the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token match the second new access token and the second new update token; and In response to the finding that the first new access token and the first new update token match the second new access token and the second new update token, authorize, by one or more processors, a transfer of the first new access token and the first new update token generated by the authorization server (201) from the authorization server (201) to the native application (202). [10] Method according to claim 1, wherein the new access token is a first new access token and the new update token is a first new update token, and wherein the method further comprises: Store, in a blockchain architecture (459), a stored blockchain (416) which contains the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature, which are used by the authentication server to generate the first new access token and the first new update token; Retrieve from the blockchain architecture (459), the stored blockchain (416); Generating, by the authentication server, a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature from the stored blockchain (416); Compare, by one or more processors, the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token do not match the second new access token and the second new update token; and In response to the finding that the first new access token and the first new update token do not match the second new access token and the second new update token, blocking, by one or more processors, a transmission of the first new access token and the first new update token generated by the authorization server (201) from the authorization server (201) to the native application (202). [11] Computer program product comprising a computer-readable storage medium containing program code, wherein the computer-readable storage medium is not a volatile signal in itself and wherein the program code is readable and executable by a processor to perform a procedure comprising: Receiving, from a native application (202) on a unit, an initial authorization, a public key of a private / public key pair generated on the unit and an acknowledgment of the authenticity of the native application (202); Received from the native application (202) on the unit, an update token and a digital signature of the update token created with the private key, wherein the authorization server (201) recognizes the update token only when the update token is verified with the public key that was previously registered; Validating the digital signature of the update token; and In response to the validation of the update token by the native application (202) on the unit, a new access token and a new update token are transferred from the authorization server (201) to the native application (202) on the unit, the new access token enabling the native application (202) on the unit to access the computer resource; where: the new access token is a first new access token and the new refresh token is a first new refresh token; and the procedure further includes: Store, in a blockchain architecture (459), a stored blockchain (416) which contains the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature, which are used by the authentication server to generate the first new access token and the first new update token; Retrieve from the blockchain architecture (459), the stored blockchain (416); Generating, by the authentication server, a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature from the stored blockchain (416); Compare, by one or more processors, the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token do not match the second new access token and the second new update token; and In response to the finding that the first new access token and the first new update token do not match the second new access token and the second new update token, blocking, by one or more processors, a transmission of the first new access token and the first new update token generated by the authorization server (201) from the authorization server (201) to the native application (202). [12] Computer program product according to claim 11, wherein the confirmation of the authenticity of the native application (202) ensures the integrity and authenticity of the native application (202) and the unit. [13] Computer program product according to claim 11, wherein the public / private key is generated on the unit and the private key is protected against unauthorized use or removal by being bound to the unit. [14] Computer program product according to claim 11, wherein the authorization server (201) and the client are components of an Open Authorization, OAuth, architecture. [15] Computer program product according to claim 11, wherein an update authorization is verified as originating from the entity to which it was issued, wherein data in an application payload is used by the client without the use of a Transport Layer Security, TLS, protocol extension. [16] Computer program product according to claim 11, wherein the program code is provided as a service in a cloud environment. [17] A computer system comprising one or more processors, one or more computer-readable main memories, and one or more computer-readable non-transient storage media, as well as program instructions stored on at least one of the computer-readable non-transient storage media for execution by at least one of the processors via at least one of the computer-readable main memories, wherein the stored program instructions are executed to perform a method comprising: Receiving, from a native application (202) on a unit, an initial authorization, a public key of a private / public key pair generated on the unit and an acknowledgment of the authenticity of the native application (202); Received from the native application (202) on the unit, an update token and a digital signature of the update token created with the private key, wherein the authorization server (201) recognizes the update token only when the update token is verified with the public key that was previously registered; Validating the digital signature of the update token; and In response to the validation of the update token by the native application (202) on the unit, a new access token and a new update token are transferred from the authorization server (201) to the native application (202) on the unit, the new access token enabling the native application (202) on the unit to access the computer resource; where: the new access token is a first new access token and the new refresh token is a first new refresh token; and the procedure further includes: Store, in a blockchain architecture (459), a stored blockchain (416) which contains the initial authorization, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature, which are used by the authentication server to generate the first new access token and the first new update token; Retrieve from the blockchain architecture (459), the stored blockchain (416); Generating, by the authentication server, a second new access token and a second new update token by using the initial authorization grant, the public key, the confirmation of the authenticity of the native application (202), the update token and the update token digital signature from the stored blockchain (416); Compare, by one or more processors, the first new access token and the first new update token with the second new access token and the second new update token to determine that the first new access token and the first new update token do not match the second new access token and the second new update token; and In response to the finding that the first new access token and the first new update token do not match the second new access token and the second new update token, blocking, by one or more processors, a transmission of the first new access token and the first new update token generated by the authorization server (201) from the authorization server (201) to the native application (202). [18] Computer system according to claim 17, wherein the authorization server (201) and the client are components of an Open Authorization (OAuth) architecture and wherein an update authorization is verified as originating from the entity to which it was issued, wherein data in an application payload is used by the client without the use of a Transport Layer Security (TLS) protocol extension. [19] Computer system according to claim 17, wherein the stored program instructions are provided as a service in a cloud environment.

Images