Using device-bound credentials to enhance authentication security in native applications

Abstract

The method allows an authorized native application on a client device to access computer resources. The authorization server receives from the native application on the device an initial authorization grant, a public key of a private / public key pair generated on the device, and a certificate of authenticity for the native application. The authorization server receives from the native application on the device a refresh token and a digital signature of the refresh token created using the private key from the native application on the device. The authorization server recognizes the refresh token only if the refresh token is verified using the previously registered public key. The authorization server validates the digital signature of the refresh token and sends a new access token and a new refresh token to the native application on the device, thus allowing the native application on the device to access computer resources.

Description

Technical Field

[0001] The present invention is related to protecting computer resources. More specifically, one or more embodiments of the present invention provide secure access to specific computer resources. Even more specifically, one or more embodiments of the present invention provide a new and useful solution for ensuring that a refresh token presented by a native application during the refresh of Open Authorization (OAuth) is sent from the same device that was the issuer of those refresh tokens.

Summary of the Invention

[0002] In one or more embodiments of the present invention, an authorization server receives an initial authorization grant, a public key of a secret key / public key pair generated on a device, and a certificate of trustworthiness of a native application from the native application on the device. The authorization server receives a refresh token and a digital signature of the refresh token created using the secret key from the native application on the device, and the authorization server recognizes the refresh token only if the refresh token is verified using a pre-registered public key. The authorization server confirms the validity of the digital signature of the refresh token. In response to confirming the validity of the refresh token from the native application on the device, the authorization server sends a new access token and a new refresh token to the native application on the device so that the native application on the device can access computer resources.

[0003] In one or more embodiments, the method described herein is performed by the execution of a computer program product on a computer system.

Brief Description of the Drawings

[0004] [Figure 1] This figure shows exemplary systems and networks that may be implemented in this disclosure. [Figure 2] This figure shows an overview of one or more embodiments of the present invention that are implemented within an Open Authorization (OAuth) system. [Figure 3] This is a diagram of an overview flowchart of one or more operations performed in one or more embodiments of the present invention. [Figure 4] This figure shows an exemplary blockchain network used and demonstrated in one or more embodiments of the present invention. [Figure 5] This figure shows an exemplary blockchain ledger used in one or more embodiments of the present invention. [Figure 6] This diagram shows an overview of a series of operations using blockchain according to one or more embodiments of the present invention. [Figure 7] This figure shows an exemplary neural network used in one or more embodiments of the present invention. [Figure 8] This figure shows a cloud computing environment according to an embodiment of the present invention. [Figure 9] This figure shows an abstract model layer of a cloud computing environment according to an embodiment of the present invention. [Modes for carrying out the invention]

[0005] As described herein, one or more embodiments of the present invention utilize device-bound Public Key Infrastructure (PKI) credentials to sign an Open Authorization (OAuth) refresh token in the refresh token's message payload. Thus, in one or more embodiments of the present invention, registration of the credentials pair's public key is performed during the establishment of the initial grant, and the addition of a signature on the refresh token is provided during all subsequent refresh token flows.

[0006] One or more embodiments of the present invention leverage patterns such as Fast Identity Online (FIDO) to establish a device-bound key pair, including the certificate of such key pair, requiring nothing other than an application-level payload (i.e., no Transport Layer Security (TLS) extensions).

[0007] In one or more embodiments of the present invention in which an OAuth system is used, the refresh token itself is used as a challenge to ensure that the signature is performed using a key that is pre-registered in a way that is bound to the device, and the FIDO assertion payload is added to the refresh token's payload parameters and validated by the server.

[0008] Such an OAuth system provides an identity security pattern in the native application so that, after the user installs the application, they participate in a registration ceremony, establish a long-lived OAuth grant (a first refresh token and an access token), and call Application Programming Interfaces (APIs) to computer resources such as data, programs, and hardware, allowing the application to act as its user.

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

[0010] After the user enters their user profile, MFA authentication information, etc., this information is exchanged for an initial OAuth grant from the authorization server.

[0011] A native application may launch a system browser on the device, allowing the user to authenticate via a browser-based mechanism and initiate an authorization code grant type flow, or the native application may provide this functionality built into the application itself for the initial OAuth grant. The native application adheres to any redirect URI (Uniform Resource Identifier) ​​which is the app's registered custom launch URI.

[0012] The user authenticates using a browser on another device (for example, a laptop) and is presented with a Quick Response (QR) code containing an authorization code, which the native application can then scan.

[0013] Regardless of the specific flow (the flow described above or a similar variation), an initial grant is established for the application on the device. The refresh token is then stored in app-specific secure storage to prevent disclosure to other apps.

[0014] After registration, whenever a native application on a device (e.g., a mobile device such as a smartphone) requires a new access token to call an API, the refresh token flow is executed by the native application making a call to the authorization server's token endpoint. Only the refresh token itself serves to identify the grant being refreshed.

[0015] The problem associated with the OAuth process described above, which one or more embodiments of the present invention overcome in a novel and useful way, is the lack of proof that the refresh token is presented from the device to which the refresh token was originally issued. Therefore, without the present invention, the authentication server would be unable to determine / distinguish whether the refresh token is compromised from a device, a native application, or a network, or a combination thereof, such as when the refresh token is presented from a different device or program.

[0016] To address this problem, one or more embodiments of the present invention cause a native application to sign a refresh token using asymmetric device-bound credentials created by the application during the registration phase, each time a refresh token flow is performed. By ensuring that the signing operation can only be performed on the device to which the grant was first established, the server can have a very high level of confidence that the OAuth grant is being used by an application on the device to which the grant was issued.

[0017] One or more embodiments of the present invention provide a clear improvement over token binding. Token binding uses cryptographic certificates, but requires the use of Transport Layer Security (TLS) extensions to obtain cryptographic certificates at both ends of the TLS connection (e.g., between the client and the authorization server). Therefore, user equipment in such systems requires a high level of expertise, time, and computing resources, which the present invention does not require. Furthermore, token binding does not force authentication credentials created on the client to be bound to the device, thus reducing the security of the credentials. Therefore, one or more embodiments of the present invention provide a resource security solution that is application data level (e.g., using additional parameters in the OAuth payload) and does not depend on the implementation of token binding in TLS.

[0018] From a broad perspective, one or more embodiments of the present invention include two stages: a registration stage and a subsequent grant refresh.

[0019] Registration stage

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

[0021] In one or more embodiments of the present invention, this initial grant data is an authorization code obtained from a handoff (custom launch URI call) from a system browser or scanned via a QR code (registered trademark).

[0022] Before the native application sends this initial grant data to the token endpoint to obtain the first authorization grant, the native application creates public key / secret key authentication information that is bound to the local device.

[0023] In one or more embodiments of the present invention, the device's operating system provides a Fast Identity Online-2 (FIDO2) platform authenticator application programming interface (API) that is used to create the authentication information.

[0024] In one or more embodiments of the present invention, a platform API (e.g., a secure enclave API) creates the authentication information.

[0025] The authentication information created may or may not require user verification to be created and used. This choice ultimately becomes the security requirements (policy) of the API service provided by the enterprise and the desired user experience. In the terms and specifications of Fast Identity Online (FIDO), user verification is optional, and thus the ideas described herein remain.

[0026] After creating the key pair, the native application constructs the FIDO attestationObject included in the initial grant data in a request to the OAuth token endpoint within the authentication server. In one or more embodiments of the present invention, a packed certificate format is used such that the clientDataJSON input to the creation of this certificate object becomes the initial grant data (instead of the challenge provided by the server).

[0027] In one or more embodiments of the present invention, the certificate private key is embedded in the source code of the native application itself. Protection of the certificate private key is performed using techniques such as white-box cryptography and secure native code distribution practices.

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

[0029] Certificates such as FIDO2 certificates provide the authentication server with proof of the make / model of the client authenticator being used. In the case of a native application acting as a client authenticator, this proof is to demonstrate the integrity of the application by identifying the vendor and version of the native application specified by the application developer, so that the application is trusted to be doing what it is coded to do.

[0030] In one or more embodiments of the present invention, the authentication server must be able to prove that the authentication information being created, used to sign the refresh token flow, is bound to a device so that the private key is used only on the device on which the private key was established. Without such a certificate, the server cannot know that the client communicating with it is a genuine installation of the application. If the application uses a native FIDO2 API provided by the client device's operating system, the certificate is provided by the platform. Otherwise, the certificate is provided within the native application code.

[0031] Next, the native application presents the initial grant data, the attestationObject (which includes the public key of the credentials bound to the device), and the signature of the initial grant data (for verifying the public key) to the token endpoint of the OAuth authorization server.

[0032] The OAuth authorization server verifies the certificate using pre-configured metadata that includes the trusted signer of the certificate's private key. This verification includes checking if the authenticator data within the certificate object indicates that user verification has been performed, if this is the server's policy. Initial grant data is also verified. The public key of the device-bound credentials is associated with the OAuth grant on the server side, and the initial refresh token and access token are returned to the native application client.

[0033] The subsequent Grant Refresh

[0034] Native applications occasionally execute a new refresh token flow when their access token expires. In one or more embodiments of the present invention, the refresh token flow includes a refresh token, along with FIDO authenticatorData and a signature (of the hash of the refresh token) performed using the private key of the credentials bound to the device registered during the establishment of the initial grant. This provides the server with proof that the request was generated on the device where the grant was established, with each refresh. The clientDataJSON described in the FIDO authentication document instead includes the refresh token as a challenge provided by the server.

[0035] In one or more embodiments of the present invention, the refresh_token is given a unique type. An example pseudocode of clientDataJSON is as follows: { “type”: “urn:mycustomapp:oauth”, “refresh_token”: “RT_value” }

[0036] Therefore, the challenge, origin, or tokenBinding fields defined by WebAuthn are not necessary.

[0037] Next, the entire post body of the refresh token flow is written as follows: POST / oauth / token client_id=public_client&grant_type=refresh_token&refresh_token=RT_value&authenticatorData=b64url_authenticator_data&signature=b64url_sig

[0038] The authentication server ensures that RT_value is valid and represents a refresh token (RT) known to the server. The authentication server retrieves the associated public key registered in the grant during grant establishment (this public key becomes the allowCredentials list in FIDO terminology), then verifies that the rest of the validation procedure in verifying the authentication assertion has succeeded, and since this is a native scenario and not a browser using pure WebAuthn, some non-critical considerations are given to the data value (such as origin, which is a Uniform Resource Name (URN) in one or more embodiments of the present invention).

[0039] In one or more embodiments of the present invention, other mitigation measures, such as certificate pinning, are also employed as part of the overall solution to prevent application-level man-in-the-middle (MITM) attacks.

[0040] Referring here to each figure, and in particular to Figure 1, an exemplary block diagram of a system and network that may be used by, in, or both in an implementation of one or more embodiments of the present invention is shown. With respect to server 101, some or all of the exemplary architecture, including both illustrated hardware and software shown within server 101, may be used by the client device 123 or software deployment server 149 or computer resource server 151 or computer resource 153 or application certificate service server 155 or artificial intelligence (AI) system 157 or blockchain network 159 shown in Figure 1 or a combination thereof, or by the resource owner 200 or authorization server 201 or client device 223 or computer resource server 251 or computer resource 253 or application certificate service server 255 shown in Figure 2 or a combination thereof, or by other processing devices shown in other figures associated with one or more embodiments of the present invention, or a combination thereof.

[0041] An exemplary server 101 includes a processor 103 coupled to a system bus 105. The processor 103 may utilize one or more processors, each of which includes one or more processor cores. A video adapter 107 that drives / supports a display 109 is also coupled to the system bus 105. The system bus 105 is coupled to an input / output (I / O) bus 113 via a bus bridge 111. An I / O interface 115 is coupled to the I / O bus 113 and provides communication with various I / O devices, including a keyboard 117, a mouse 119, a media tray 121 (which may include storage devices such as a CD-ROM driver and a multimedia interface), and an external USB port 125. The form of the ports connected to the I / O interface 115 may be any form known to those skilled in the art of computer architecture, but in one embodiment, some or all of these ports are universal serial bus (USB) ports.

[0042] As shown in the diagram, server 101 can communicate with network 127 using network interface 129. Network interface 129 is a hardware network interface such as a network interface card (NIC). Network 127 may be an external network such as the Internet, or an internal Internet such as Ethernet® or a virtual private network (VPN).

[0043] A hard drive interface 131 is also coupled to the system bus 105. The hard drive interface 131 interfaces with a hard drive 133. In one embodiment, the hard drive 133 inputs data into system memory 135, which is also coupled to the system bus 105. System memory is defined as the lowest level of volatile memory within the server 101. This volatile memory includes, but is not limited to, cache memory, registers, and buffers, as well as higher levels of additional volatile memory (not shown). The data input into system memory 135 includes the server 101's operating system (OS) 137 and application programs 143.

[0044] OS137 includes a shell 139 to provide transparent user access to resources such as application programs 143. Generally, the shell 139 is a program that provides an interpreter and interface between the user and the operating system. More specifically, the shell 139 executes commands entered into the command-line user interface or commands from files. Thus, the shell 139 (also called the command processor) is typically the highest level of software hierarchy in the operating system and functions as a command interpreter. The shell provides system prompts, interprets commands entered via the keyboard, mouse, or other user input medium, and sends the interpreted commands to a lower level of the operating system appropriate for processing (e.g., the kernel 141). While the shell 139 is a text-based, line-oriented user interface, note that one or more embodiments of the present invention also adequately support other user interface modes such as graphics, voice, and gestures.

[0045] As shown in the diagram, OS137 also includes kernel 141, which contains lower-level functions of OS137, including providing essential services required by other parts of OS137 and application programs 143, such as memory management, process and task management, disk management, and mouse and keyboard management.

[0046] Application program 143 includes a renderer, exemplified as browser 145. Browser 145 includes program modules and instructions that enable a World Wide Web (WWW) client (i.e., server 101) to send and receive network messages to and from the Internet using hypertext transfer protocol messaging, thereby enabling communication with client device 123 or software deployment server 149 or computer resource server 151 or computer resource 153 or application certificate service server 155 or other computer systems or combinations thereof.

[0047] The application program 143 in the system memory of server 101 also includes a Program for Secure Access to Computer Resources (PSACR) 147. PSACR 147 contains code for implementing the processes described below, including the processes illustrated in Figures 2-7. In one or more embodiments of the present invention, server 101 can download PSACR 147 from a software deployment server 149, and this download includes an on-demand download in which the code for PSACR 147 is not downloaded until it is required for execution. In one or more embodiments of the present invention, it should be further noted that server 101 does not need to use its own internal computing resources to run PSACR 147 because the software deployment server 149 performs all the functions related to the present invention (including the execution of PSACR 147).

[0048] It should be noted that the hardware elements shown for server 101 are not intended to be exhaustive, but are representative examples to highlight essential components required by one or more embodiments of the present invention. For example, server 101 may include alternative memory storage devices such as magnetic cassettes, digital versatile disks (DVDs), and Bernoulli cartridges. These and other variations are intended to fall within the scope of the present invention.

[0049] Referring now to Figure 2, an overview of one or more embodiments of the present invention implemented within the modified Open Authorization (OAuth) system 206 is shown.

[0050] As shown in steps 1 and 2, the resource owner 200 is either a human user that interfaces with the client device 223 via a user interface, or a computer used by the user to present initial grant credentials to the client device via an application program interface (API), which then presents the initial grant credentials to the native application 202. Examples of such credentials include, but are not limited to, authorization codes, usernames, and passwords.

[0051] As shown in step 2a (which occurs within client device 223 and is shown communicating with application certificate service server 255, similar to application certificate service server 155 shown in Figure 1), the native application 202 sends the initial grant credentials received from resource owner 200 to application certificate service server 255. The application certificate service server 255 provides native application certificate services to verify that the native application 202 has not been modified and is running on the genuine client device 223. The application certificate service server 255 provides a cryptographic certificate of this certificate, which is included in the payload of step 3a.

[0052] As shown in step 2b, the client device 223 then generates a public / private key pair 204 which will be used as described below.

[0053] As shown in step 3a, the native application 202 sends the initial authorization grant, the certificate result (generated by the native application certificate service), the public key (generated by the native application 202), and the signature of the initial authorization grant signed using the corresponding private key to the authorization server 201.

[0054] As shown in step 3b, the authorization server uses the application certificate service to verify the application's certificate. If the certificate service fails to verify the certificate, the registration is aborted.

[0055] As shown in step 3c, authorization server 201 verifies the public key using the signature of the initial authorization grant, stores the public key, and uses this public key in the following steps to grant access privileges to computer resource 253.

[0056] 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 253, and the refresh token allows the authorization server 201 to refresh / new the access token.

[0057] As shown in step 5, the native application 202 uses an access token (i.e., either the initial access token generated by the authorization server 201 and authorized by the refresh token, or a new access token) to access the computer resource 253 on behalf of the resource owner 200.

[0058] Access tokens have a limited validity period (e.g., less than 5 minutes), and therefore access tokens need to be refreshed periodically by using a refresh token.

[0059] Therefore, as shown in step 6, the native application 202 periodically exchanges the current refresh token for a new access token and a new refresh token using the authorization server 201. That is, since refresh tokens are disposable, a new refresh token replaces the old / current refresh token. When the native application 202 requests the authorization server 201 to generate a new refresh token, the native application 202 signs the old refresh token using its private key, and this signature is sent to the authorization server 201 as part of the token refresh flow. Therefore, the authorization server 201 generates and returns a new access token and a new refresh token only if the signature of the old refresh token is verified using the public key received in step 3a.

[0060] Referring now to Figure 3, an overview flowchart of one or more operations performed in one or more embodiments of the present invention is shown.

[0061] Following the initiation block 301, as shown in block 303 and described in detail in Figure 2, the authorization server receives an initial authorization grant, the public key of the private / public key pair generated on the device, and a certificate of trust for the native application from the native application on the device.

[0062] As shown in block 305 and described in detail in Figure 2, the authorization server receives a refresh token and a digital signature of the refresh token created using a private key from the native application on the device. In one or more embodiments of the present invention, the authorization server recognizes the refresh token only if the refresh token has been verified using a pre-registered public key.

[0063] As shown in block 307 and explained in detail in Figure 2, the authorization server then verifies the validity of the digital signature of the refresh token.

[0064] As shown in block 309 and illustrated in detail in Figure 2, in response to verifying the validity of the refresh token from the native application on the device, the authorization server sends a new access token and a new refresh 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 computer resources.

[0065] The flowchart ends at termination block 311.

[0066] In one or more embodiments of the present invention, as described herein, a public / private key is generated on the device, and the private key is protected from misuse or extraction by being bound to the device. That is, only the client device that generated the public / private key pair can access the private key, so that the private key cannot be "hacked" by a malicious actor.

[0067] In one or more embodiments of the present invention, the authorization server and client are components of the Open Authorization (OAuth) architecture modified by the present invention (for example, the modified Open Authorization (OAuth) system 206 shown in Figure 2).

[0068] In one or more embodiments of the present invention, as described above, data within the application payload from the client is used to verify that a refresh authorization grant originates from the device to which the refresh authorization grant was issued, without using Transport Layer Security (TLS) protocol extensions.

[0069] In one or more embodiments of the present invention, one or more processors (for example, in the authorization server 201 shown in Figure 2) verify the identity of a device by applying Fast Identity Online (FIDO) authentication as part of the refresh authorization grant process. Details of FIDO, FIDO2, or both are described above.

[0070] In one or more embodiments of the present invention, the identity of a device is determined, verified, or both determined by an identifier for that particular device, such as an Internet Protocol (IP) address used by that particular device and identified by a lookup table that associates that particular device with a particular IP address, a Media Access Control (MAC) assigned to a network interface controller for use as a network address in communications within a network segment by that particular device, or a Uniform Universal Identifier (UUID) generated for that particular device and unique to that particular device.

[0071] Therefore, in one or more embodiments of the present invention, the authorization server validates the refresh token from the native application on the device only if the refresh token comes from the specific device that created the initial authorization grant and the public key of the private / public key pair. In one or more embodiments of the present invention, the authorization server identifies the specific device by the IP address currently used by the specific device, the MAC address currently used by the specific device, the UUID of the specific device, etc., which are part of the header sent from the specific device to the authorization server when that device sends the initial authorization grant, the public key of the private / public key pair generated on the device, the certificate of trustworthiness of the native application, and the refresh token to the authorization server.

[0072] Accordingly, in one or more embodiments of the present invention, the authorization server validates the refresh token from a native application on a device only if the refresh token originates from the specific device that created the initial authorization grant and the public key of the private / public key pair, regardless of which application on that device or another device sent the refresh token, the initial authorization grant, or the public key of the private / public key pair, or a combination thereof, to the authorization server.

[0073] In one or more embodiments of the present invention, a blockchain system is used to ensure that the data / elements / coefficients used by the authorization server 201 shown in Figure 2 to generate access tokens or refresh tokens or both are valid by storing such data / elements / coefficients in a blockchain ledger.

[0074] Therefore, referring to Figure 4, in one or more embodiments of the present invention, a blockchain network 459 (similar to blockchain network 159 shown in Figure 1) is used to provide infrastructure (e.g., chaincode execution) and services (e.g., membership services such as identity management) to securely and transparently store, track, and manage transactions in a "trusted and transparent location." The blockchain network 459 maintains a verifiable record (in a trusted and transparent location) of all transactions ever performed within the system. Once data is entered into the blockchain, that data cannot be erased (immutable) or altered. That is, any alteration to the record is considered to be the issuance / introduction of a new transaction. Thus, the prohibition of such erasure or alteration ensures the auditability and verifiability of the data.

[0075] The Blockchain Network 459 (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 executed and shared among participating parties. Individual transactions within the blockchain are validated or verified through a consensus mechanism that incorporates the majority of participants in the system. In this way, participating entities can be assured that a digital event occurred by creating an irrefutable record on an authorized public ledger.

[0076] When a transaction is executed, the corresponding chaincode is executed by multiple peers validating the system. For example, as shown in Figure 4, peers 418a-418d establish the validity of the transaction parameters, and after those peers reach a consensus, a new block is generated and added to the blockchain network. That is, an application process 408 (for example, the OAuth process running on the authentication server 201 as described in Figure 2) running on the monitoring computer 401 (for example, the authentication server 201 shown in Figure 2 or the server 101 shown in Figure 1 or both) executes an application such as the app 403 shown in the figure (for example, the OAut application), causing the software development kit (SDK) 410 to communicate with the membership service 409 supporting the peer-to-peer network 404 using general remote procedure calls (grpc), and the peer-to-peer network 404 supports the blockchain 416 using peers 418a-418g.

[0077] Referring to Figure 5, an exemplary blockchain ledger 500 within a blockchain 416 is shown, as used in one or more embodiments of the present invention.

[0078] In one or more embodiments of the present invention, the blockchain ledger 500 also supports, utilizes, or both supports the peer-to-peer network 404 shown in Figure 4, and includes identifiers (shown in block 502) of monitoring computers, such as the authentication server 201 shown in Figure 2 or the server 101 shown in Figure 1, or both. For example, in one or more embodiments of the present invention, block 502 includes the Internet Protocol (IP) address, uniform resource locator (URL), etc., of the monitoring computer. This information is used by peers in the peer-to-peer network 404 shown in Figure 4 to receive transactions related to the process flow described herein.

[0079] In one or more embodiments of the present invention, the blockchain ledger 500 also includes an initial authorization grant (block 504), a public key (block 506), a certificate of trustworthiness for the native application (block 508), a refresh token (block 510), and a copy of the digital signature of the refresh token (block 512), which are used by the authentication server to generate a first new access token and a first new refresh token. The information from the blockchain ledger 500 is then retrieved in a form that is guaranteed to be unchanged from when it was first presented to the authentication server (but not necessarily used by the authentication server). That is, the initial authorization grant, the public key of the private / public key pair generated on the device, and the certificate of trustworthiness for the native application are created and sent in parallel to both the authorization server and the blockchain. However, the initial authorization grant, the public key of the private / public key pair generated on the device, and the certificate of trustworthiness for the native application may be corrupted before being used by the authorization server. Therefore, the initial authorization grant, the public key of the private / public key pair generated on the device, and an uncorrupted version of the certificate of authenticity for the native application are stored on the blockchain, which is a blockchain system that prevents any data corruption.

[0080] An exemplary operation of the blockchain network 459 shown in Figure 4 is shown in Figure 6. As described in step 601, a computing device (e.g., a monitoring computer 401 shown in Figure 4, which in one or more embodiments is the server 101 shown in Figure 1 or the authorization server 201 shown in Figure 2 or both) executes a transaction (e.g., it receives the native application on the device, an initial authorization grant, the public key of a private / public key pair generated on the device, a certificate of authenticity for the native application, a refresh token, a digital signature of the refresh token created using the private key, etc., as previously described in Figure 2). As shown in step 603, the monitoring computer 401 hashes the transaction using a hash algorithm such as the Secure Hash Algorithm (SHA-2) and then signs the hash using a digital signature. As described in step 605, this signature is then broadcast to the peer-to-peer network 404 shown in Figure 4. As shown in step 607, a peer in the peer-to-peer network 404 (e.g., peer 418a) aggregates transactions into blockchain 416 as shown in Figure 4. Each block contains a link to the previous block, as shown in block 609. The newly modified blockchain 416 is validated by one or more other peers from peers 418a-418d, or by other peers from other authorized blockchain systems, or both (step 611). As described in step 613, the validated block is then broadcast to peers 418b-418d. These peers 418b-418d listen for and receive the new blocks and merge them into their copy of blockchain 416 (step 615).

[0081] Thus, the blockchain fabric described in Figures 4-6 represents a blockchain deployment technology that provides a distributed ledger, which continuously manages digital events, called transactions, that are shared among multiple participants, each with an interest in these events. The ledger can only be updated by agreement among the participants. Furthermore, once a transaction is recorded, it cannot be altered (it is immutable). All such recorded transactions are cryptographically verifiable using proof of agreement from the participants, thus providing a robust provenance mechanism to track the origin of a transaction.

[0082] Therefore, Blockchain Fabric uses a distributed network to maintain a digital ledger of events, and thus each peer's stored blockchain relies on previous blocks, thereby providing protected data for subsequent blocks within the blockchain, thus achieving superior security for the digital ledger.

[0083] In other words, the blockchain fabric described herein provides a decentralized system in which all nodes within the decentralized system contain a copy of the blockchain. This avoids the need for a centralized database managed by a trusted third party. Transactions are broadcast to the network using a software application. Network nodes can verify the validity of transactions, add those transactions to their copy, and then broadcast these additions to other nodes. However, as mentioned above, the blockchain is still very secure because each new block is protected (e.g., hashed) based on one or more previous blocks.

[0084] Therefore, in one or more embodiments of the present invention, it is assumed that the new access token described above is identified as the first new access token in Figure 3, and the new refresh token is identified as the first new refresh token.

[0085] In one or more embodiments of the present invention, the blockchain architecture (for example, the server 101 shown in Figure 1, or the authorization server 201 shown in Figure 2, or the monitoring computer 401 or blockchain network 459 shown in Figure 4, or both, or a combination thereof) stores a stored blockchain including an initial authorization grant, a public key, a certificate of authenticity for a native application, a refresh token, and a digital signature of the refresh token, which are used by the authentication server to generate a first new access token and a first new refresh token.

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

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

[0088] In response to the determination that the first new access token and the first new refresh token match the second new access token and the second new refresh token, one or more processors authorize the authorization server to send the first new access token and the first new refresh token generated by the authorization server to the native application.

[0089] In one or more embodiments of the present invention, a new access token is a first new access token, a new refresh token is a first new refresh token, and the blockchain described hereof includes an initial authorization grant, a public key, a certificate of trust for a native application, a refresh token, and a digital signature of the refresh token, which are used by the authentication server to generate the first new access token and the first new refresh token, and the stored blockchain is retrieved from the blockchain architecture, and the authentication server generates a second new access token and a second new refresh token by using the initial authorization grant, a public key, a certificate of trust for a native application, a refresh token, and a digital signature of the refresh token from the stored blockchain.

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

[0091] Therefore, the contents of the blockchain are used to verify that the initial authorization grant, public key, certificate of authenticity for the native application, refresh token, and digital signature of the refresh token, which are used by the authentication server to generate the first new access token and the first new refresh token, are valid, as guaranteed by their previous storage within the blockchain.

[0092] In one or more embodiments of the present invention, artificial intelligence (e.g., a neural network) is used to verify the validity of access tokens and refresh tokens generated by an authorization server.

[0093] Next, referring to Figure 7, an exemplary artificial intelligence system used in one or more embodiments of the present invention is a deep neural network (DNN) 757 (similar to the artificial intelligence system 157 shown in Figure 1) used in one or more embodiments of the present invention. Nodes within the DNN 757 represent hardware processors, virtual processors, or software algorithms, or hardware processors, virtual processors, or software algorithms, or a combination thereof.

[0094] In one or more embodiments of the present invention, the DNN757 is trained to generate access tokens or refresh tokens generated by a neural network, or both, as shown in block 702.

[0095] DNN757 is trained to generate neural network-generated access tokens or neural network-generated refresh tokens, or both, using authorization server data 700 (e.g., initial authorization grants, public keys, native application trustworthiness certificates, refresh tokens, and digital signatures of refresh tokens, which are used by the authentication server to generate new access tokens and new refresh tokens) as shown in block 702. DNN757 is trained by using various known types of initial authorization grants, known types of public keys, known types of native application trustworthiness certificates, known types of refresh tokens, and known types of digital signatures of refresh tokens, which are used to generate known neural network-generated access tokens or neural network-generated refresh tokens, or both.

[0096] DNN757 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 use other forms of deep learning.

[0097] As the name suggests, neural networks are roughly modeled after biological neural networks (e.g., the human brain). Biological neural networks consist of a series of interconnected neurons that influence each other. For example, a first neuron may be electrically connected to a second neuron via synapses, through the release of neurotransmitters received by the second neuron (from the first neuron). These neurotransmitters can cause excitation or inhibition of the second neuron. The patterns of interconnected neurons in excitation / inhibition ultimately lead to biological outcomes, including thought, muscle movement, and memory retrieval. While this explanation of biological neural networks is highly simplified, the overarching idea is that one or more biological neurons influence the behavior of one or more other bioelectrically connected biological neurons.

[0098] Electronic neural networks are similarly composed of electronic neurons. However, unlike biological neurons, electronic neurons cannot be technically "inhibitory," but rather "excitatory" to varying degrees.

[0099] The electronic neurons (hereinafter also simply referred to as “neurons” or “nodes”) within the DNN757 are arranged in layers known as the input layer 703, the hidden layer 705, and the output layer 707. The input layer 703 contains neurons / nodes that receive input data and transmit it to a series of hidden layers of neurons (e.g., the hidden layer 705), where neurons from one of the hidden layers are interconnected with all neurons in the next layer of the hidden layer 705. The final layer of the hidden layer 705 then outputs the computation result to the output layer 707, which is often a single node that holds vector information.

[0100] As mentioned above, each node in the DNN757 shown in the figure represents an electronic neuron, such as neuron 709 shown in the figure. As shown in block 711, each neuron (including neuron 709) functionally contains at least four features: algorithm, output value, weight, and bias value.

[0101] The algorithm is a mathematical formula for processing data from one or more upstream neurons. For example, suppose one or more neurons shown in the central hidden layer 705 send data values ​​to neuron 709. Neuron 709 then processes these data values ​​by executing the mathematical function shown in block 711 to produce one or more output values, and these output values ​​are then sent to another neuron, such as another neuron in the hidden layer 705 or a neuron in the output layer 707. Each neuron also has weights that are unique to that neuron, other connected neurons, or both. Furthermore, the output values ​​are added to bias values ​​to increase or decrease the output values, allowing the DNN757 to be further "fine-tuned".

[0102] For example, suppose neuron 713 sends the results of an analysis of a portion of the data to neuron 709. Neuron 709 has a first weight that defines how important the data coming from neuron 713 is in particular. If this data is important, the data coming from neuron 713 is weighted more heavily, increased by a bias value, or both, so that the mathematical function in neuron 709 produces a larger output that has a greater impact on the neurons in output layer 707. Similarly, if it is determined that neuron 713 is important to the operation of neuron 709, the weight of neuron 713 is increased so that neuron 709 receives a larger value of the output of the mathematical function in neuron 713. Alternatively, the output of neuron 709 can be minimized by reducing the weight or bias, or both, used to influence the output of neuron 709. These weights / biases can be adjusted for one, some, or all of the neurons in all of DNN757 so that reliable outputs come from output layer 707. In one or more embodiments of the present invention, finding 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 tune hyperparameters such as the learning rate, dropout, and regularization coefficient. Therefore, training the neural network involves performing forward and backward propagation on multiple datasets until optimal weight and bias values ​​are reached to minimize the loss function. The loss function measures the difference between the neural network's predictions and the actual labels for various inputs.

[0103] If the DNN757 is manually adjusted during training, the weights are adjusted in a manner that is repeated until the output from the output layer 707 matches the expected value.

[0104] When automatic adjustment is performed, the weights (or mathematical functions or both) are adjusted using "backpropagation," which adjusts the weights of neurons by using the "gradient descent" method to determine which direction each weight value should be adjusted in. This gradient descent process moves the weights in each neuron in a specific direction until the output from output layer 707 improves (for example, until it accurately generates the appropriate access tokens and refresh tokens).

[0105] As shown in Figure 7, individual layers of neurons are shaded differently, indicating that in one or more embodiments of the present invention, these layers are specifically trained to recognize different aspects of the information used by the authentication server when generating a refresh token.

[0106] Accordingly, in one or more embodiments of the present invention, within the hidden layer 705, there is a layer 706 containing neurons designed to evaluate the type of authorization grant, a layer 708 containing neurons designed to evaluate the type of public key, and a layer 710 containing neurons designed to evaluate the type of certificate of authenticity of the native application.

[0107] Next, the output of neurons from layer 710 controls the value detected in output layer 707.

[0108] Accordingly, one or more embodiments of the present invention input an initial authorization grant, a public key, a certificate of authenticity for a native application, a refresh token, and a digital signature of the refresh token into a neural network, which is then trained to generate an access token and a refresh token. Next, one or more processors compare the new access token and the new refresh token generated by the authorization server with the access token and the refresh token generated by the neural network in order to verify the validity of the new access token and the new refresh token generated by the authorization server.

[0109] In one or more embodiments of the present invention, one or more processors determine that a new access token and a new refresh token match an access token and a refresh token generated by a neural network. In response to the determination that the new access token and the new refresh token match an access token and a refresh token generated by a neural network, one or more processors send the new access token and the new refresh token to a native application.

[0110] In one or more embodiments of the present invention, one or more processors determine that a new access token and a new refresh token do not match an access token and a refresh token generated by a neural network. In response to the determination that the new access token and the new refresh token do not match an access token and a refresh token generated by a neural network, one or more processors block the transmission of the new access token and the new refresh token to a native application.

[0111] Therefore, in one or more embodiments of the present invention, the neural network validates or invalidates the work performed by the aforementioned authentication server.

[0112] Therefore, as described in the various embodiments presented herein, a certificate of authenticity for a native application guarantees the integrity and reliability of the native application and the device.

[0113] In one or more embodiments, the present invention is implemented using cloud computing. Nevertheless, although this disclosure includes a detailed description of cloud computing, it should be understood in advance that implementations of the contents described herein are not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in combination with any other type of computing environment that is currently known or may be developed in the future.

[0114] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), allowing these resources to be provisioned and released quickly with minimal administrative effort or interaction with service providers. This cloud model includes at least five features, at least three service models, and at least four deployment models.

[0115] The features are as follows:

[0116] On-demand self-service: Cloud users can unilaterally and automatically provision server time and computing power such as network storage as needed, without requiring human interaction with the service provider.

[0117] Broad network access: This capability is available over a network and can be accessed using standard mechanisms, thus facilitating use by heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0118] Resource Pooling: A provider's computing resources are pooled and delivered to multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reallocated as needed. Users typically have a sense of location independence in that they have neither control nor know the exact location of the resources provided, although they can still specify a location (e.g., country, state, or data center) at a higher level of abstraction.

[0119] Rapid Adaptability: Capabilities can be provisioned quickly and flexibly, sometimes automatically, scale out rapidly, and be released quickly to scale in rapidly. The capacity available for provisioning often appears to the user as if they can purchase any amount at any time without limit.

[0120] Measured Services: Cloud systems leverage metering capabilities to automatically control and optimize resource usage at an appropriate level of abstraction for each service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both service providers and users.

[0121] SaaS (Software as a Service): The capability provided to the user is the use of the provider's applications running on cloud infrastructure. These applications can be accessed from various client devices via thin client interfaces such as web browsers (e.g., web-based email). Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or individual application functions, except for the possibility of making limited user-specific application configuration settings.

[0122] PaaS (Platform as a Service): The ability provided to the user is to deploy applications created or acquired by the user, using programming languages ​​and tools supported by the provider, onto a cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but can control the configuration of the deployed application and, in some cases, the application hosting environment.

[0123] IaaS (Infrastructure as a Service): The capabilities provided to users include provisioning of processing, storage, networking, and other basic computing resources, allowing users to deploy and run any software, including operating systems and applications. Users do not manage or control the underlying cloud infrastructure, but they can control the operating system, storage, and deployed applications, and in some cases, have limited control over selected network components (e.g., host firewalls).

[0124] The deployment model is as follows:

[0125] Private Cloud: This cloud infrastructure operates solely for the organization. In one or more embodiments, this cloud infrastructure is managed by this organization or a third party, or resides on-premises, off-premises, or both.

[0126] Community Cloud: This cloud infrastructure is shared by multiple organizations and supports a specific community that shares common interests (e.g., missions, security requirements, policies, and compliance considerations). In one or more embodiments, this cloud infrastructure is managed by these organizations or third parties, or resides on-premises, off-premises, or both.

[0127] Public Cloud: This cloud infrastructure is available for use by general users or large industry groups and is owned by the organization that sells the cloud service.

[0128] Hybrid Cloud: This cloud infrastructure is a combination of two or more clouds (private, community, or public) that are joined together while retaining their own distinct entities, through standardized or proprietary technologies that enable the portability of data and applications (e.g., cloud bursting to adjust load balancing between clouds).

[0129] Cloud computing environments are service-oriented environments that emphasize statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure consisting of a network of interconnected nodes.

[0130] Referring now to Figure 8, an exemplary cloud computing environment 50 is shown. As illustrated, the cloud computing environment 50 includes one or more cloud computing nodes 10 on which local computing devices used by cloud users (e.g., personal digital assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automotive computer systems 54N, or a combination thereof) communicate with each other. Furthermore, the nodes 10 communicate with each other. In one embodiment, these nodes are grouped physically or virtually (not shown) within one or more networks, such as the private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof. This allows the cloud computing environment 50 to provide an infrastructure, platform, or SaaS, or a combination thereof, that does not require cloud users to maintain resources on their local computing devices. The types of computing devices 54A to 54N shown in Figure 8 are intended for illustrative purposes only, and it is understood that the computing node 10 and the cloud computing environment 50 can communicate with any type of computer-controlled device via any type of network or network-addressable connection (e.g., a connection using a web browser) or both.

[0131] Referring here to Figure 9, a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 9) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 8 are intended for illustrative purposes only, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

[0132] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include a mainframe 61, RISC (Reduced Instruction Set Computer) architecture-based servers 62, 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0133] The virtualization layer 70 comprises an abstraction layer in which virtual entities such as virtual servers 71, virtual storage 72, virtual networks 73 including a virtual private network, virtual applications and operating systems 74, and virtual clients 75 are provided in one or more embodiments.

[0134] For example, the management layer 80 provides the following functions: Resource provisioning 81 dynamically procures computing and other resources used to perform tasks within the cloud computing environment. Measurement and pricing 82 tracks the costs of using resources within the cloud computing environment and sends invoices or bills for the use of those resources. For example, those resources include application software licenses. Security verifies the identity of cloud users and tasks and protects data and other resources. The user portal 83 provides users and system administrators with access to the cloud computing environment. Service level management 84 allocates and manages cloud computing resources to meet the required service levels. Service Level Agreement (SLA) planning and execution 85 prepares and procures cloud computing resources in advance of anticipated future demands in accordance with SLAs.

[0135] Workload layer 90 shows examples of functions used in a cloud computing environment in one or more embodiments. Examples of workloads and functions provided from this layer include mapping and navigation 91, software development and lifecycle management 92, delivery of virtual classroom education 93, data analysis processing 94, transaction processing 95, and secure computer resource access processing 96 that performs one or more of the features of the present invention described herein.

[0136] The present invention may be a system, method, or computer program product, or a combination thereof. The computer program product may include one or more computer-readable storage media containing computer-readable program instructions for causing a processor to perform an aspect of the present invention.

[0137] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction-executing device. A computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of further specific examples of computer-readable storage media includes portable floppy disks, hard disks, random-access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punched cards or grooved raised structures on which instructions are recorded, and any suitable combination thereof. When used herein, computer-readable storage media should not be interpreted as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through optical fiber cables), or electrical signals transmitted through wires.

[0138] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing device / processing device, or to an external computer or external storage device via a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). This network may include copper transmission cables, optical transmission fibers, wireless transmitters, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing device / processing device receives computer-readable program instructions from the network and transfers those computer-readable program instructions for storage on a computer-readable storage medium within each computing device / processing device.

[0139] The computer-readable program instructions for performing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java®, Smalltalk, and C++, and conventional procedural programming languages ​​such as the C programming language or similar programming languages. The computer-readable program instructions may be executed as a whole on the user's computer, partially as a standalone software package on the user's computer, partially on the user's computer and on a remote computer, respectively, or entirely on a remote computer or on a server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or the connection may be made to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, to carry out aspects of the present invention, an electronic circuit including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions to customize the electronic circuit by utilizing state information of computer-readable program instructions.

[0140] Aspects of the present invention will be described herein with reference to flowcharts or block diagrams, or both, of methods, apparatuses (systems), and computer program products, according to embodiments of the present invention. It will be understood that each block in a flowchart or block diagram, or both, and combinations of blocks contained in a flowchart or block diagram, or both, can be implemented by computer-readable program instructions.

[0141] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to create a machine, so that instructions executed via the processor of a computer or other programmable data processing device can create means to perform functions / operations specified in one or more blocks of a flowchart or block diagram or both. These computer-readable program instructions may be stored on a computer-readable storage medium containing instructions that include instructions to perform modes of functions / operations specified in one or more blocks of a flowchart or block diagram or both, and can instruct a computer, a programmable data processing device, or other device, or a combination thereof, to function in a particular manner.

[0142] Computer-readable program instructions may be read into a computer, another programmable data processing device, or other device so that instructions executed on a computer, another programmable device, or other device perform functions / operations specified in one or more blocks of a flowchart or block diagram or both, thereby causing a series of operable steps to be executed on a computer, another programmable device, or other device that generates a computer implementation process.

[0143] The terms used herein are for the sole purpose of describing specific embodiments and are not intended to limit the invention. Where used herein, the singular forms “a,” “an,” and “the” are intended to include the plural form unless otherwise explicitly indicated in the context. It will be further understood that the terms “equipped with” or “equipped with” or both, where used herein, indicate the presence of a described function, integer, step, operation, element, or component, or a combination thereof, but do not exclude the presence or addition of one or more other functions, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0144] All means or steps and functional elements within the following claims, along with their corresponding structures, materials, actions, and equivalents, are intended to include any structures, materials, or actions for performing a function in combination with other specifically claimed elements. The descriptions of various embodiments of the Invention are presented for illustrative and explanatory purposes, but are not intended to be exhaustive and are not limited to the Invention in the disclosed forms. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the Invention. Embodiments have been selected and described to best illustrate the principles and practical applications of the Invention, and to enable others skilled in the art to understand the Invention in relation to a variety of embodiments with various modifications suitable for specific intended uses.

[0145] In one or more embodiments of the present invention, any method described herein is implemented by using a VHDL (VHSIC Hardware Description Language) program and a VHDL chip. VHDL is an example of a design input language for field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and other similar electronic devices. Accordingly, in one or more embodiments of the present invention, any method implemented by software described herein is emulated by a hardware-based VHDL program and then applied to a VHDL chip such as an FPGA.

[0146] Therefore, as the embodiments of the present invention described in detail in this application and by referring to the examples thereof, it will be clear that modifications and variations are possible without departing from the scope of the invention as defined in the appended claims.

Claims

1. The authorization server receives an initial authorization grant, the public key of the private / public key pair generated on the device, and a certificate of trustworthiness for the native application from the native application on the device. The authorization server receives a refresh token and a digital signature of the refresh token created using the private key from the native application on the device, and the authorization server recognizes the refresh token only if the refresh token has been verified using the public key that has been registered in advance. The authorization server verifies the validity of the digital signature of the refresh token, In response to verifying the validity of the refresh token from the native application on the device, the authorization server transmits a new access token and a new refresh token from the authorization server to the native application on the device, wherein the new access token allows the native application on the device to access computer resources. Methods that include...

2. The method according to claim 1, wherein the certificate of authenticity of the native application guarantees the integrity and reliability of the native application and the device.

3. The method according to claim 1, wherein the public key / private key is generated on the device, and the private key is protected from misuse or extraction by being bound to the device.

4. The method according to claim 1, wherein the authorization server and client are components of an Open Authorization (OAuth) architecture.

5. The method according to claim 1, wherein, without using Transport Layer Security (TLS) protocol extensions, data within the application payload from the client is used to verify that a refresh authorization grant originates from the device to which the refresh authorization grant was issued.

6. The method according to claim 1, further comprising verifying the identity of the device by applying Fast Identity Online (FIDO) authentication as part of a refresh authorization grant process using one or more processors.

7. The input of the initial authorization grant, the public key, the certificate of trustworthiness of the native application, the refresh token, and the digital signature of the refresh token into a neural network, wherein the neural network is trained to generate an access token and a refresh token generated by the neural network, One or more processors verify the validity of the new access token and the new refresh token generated by the authorization server by comparing the new access token and the new refresh token generated by the authorization server with the access token and the refresh token generated by the neural network. The method according to claim 1, further comprising:

8. One or more processors determine that the new access token and the new refresh token match the access token and the refresh token generated by the neural network, The method according to claim 7, further comprising transmitting the new access token and the new refresh token to the native application by one or more processors in response to a determination that the new access token and the new refresh token match the access token and the refresh token generated by the neural network.

9. One or more processors determine that the new access token and the new refresh token do not match the access token and the refresh token generated by the neural network, In response to a determination that the new access token and the new refresh token do not match the access token and the refresh token generated by the neural network, one or more processors prevent the transmission of the new access token and the new refresh token to the native application. The method according to claim 7, further comprising:

10. The new access token is a first new access token, the new refresh token is a first new refresh token, and the method is Storing a stored blockchain in a blockchain architecture includes the initial authorization grant used by the authentication server to generate the first new access token and the first new refresh token, the public key, the certificate of trustworthiness of the native application, the refresh token, and the digital signature of the refresh token; Retrieving the stored blockchain from the aforementioned blockchain architecture, The authentication server generates a second new access token and a second new refresh token by using the initial authorization grant, the public key, the certificate of authenticity of the native application, the refresh token, and the digital signature of the refresh token from the stored blockchain. One or more processors compare the first new access token and the first new refresh token with the second new access token and the second new refresh token in order to determine that the first new access token and the first new refresh token match the second new access token and the second new refresh token. In response to the determination that the first new access token and the first new refresh token match the second new access token and the second new refresh token, one or more processors authorize the authorization server to send the first new access token and the first new refresh token generated by the authorization server to the native application. The method according to claim 1, further comprising:

11. The new access token is a first new access token, the new refresh token is a first new refresh token, and the method is Storing a stored blockchain in a blockchain architecture, which includes the initial authorization grant used by the authentication server to generate the first new access token and the first new refresh token, the public key, the certificate of trustworthiness of the native application, the refresh token, and the digital signature of the refresh token; Retrieving the stored blockchain from the aforementioned blockchain architecture, The authentication server generates a second new access token and a second new refresh token by using the initial authorization grant, the public key, the certificate of authenticity of the native application, the refresh token, and the digital signature of the refresh token from the stored blockchain. One or more processors compare the first new access token and the first new refresh token with the second new access token and the second new refresh token in order to determine that the first new access token and the first new refresh token do not match the second new access token and the second new refresh token. The method according to claim 1, further comprising: in response to a determination that the first new access token and the first new refresh token do not match the second new access token and the second new refresh token, one or more processors preventing the authorization server from sending the first new access token and the first new refresh token generated by the authorization server to the native application.

12. A computer program comprising program code that is read and executed by a processor in order to perform a method, wherein the method is Receiving an initial authorization grant, the public key of a private / public key pair generated on the device, and a certificate of trust for the native application from the native application on the device, Receiving a refresh token and a digital signature of the refresh token created using the private key from the native application on the device, wherein the authorization server recognizes the refresh token only if the refresh token has been verified using the public key that has been registered in advance, and the receiving of the refresh token. The validity of the digital signature of the refresh token, In response to verifying the validity of the refresh token from the native application on the device, the authorization server transmits a new access token and a new refresh token to the native application on the device, wherein the new access token allows the native application on the device to access computer resources. A computer program that includes [this].

13. The computer program according to claim 12, wherein the program code is provided as a service within a cloud environment.

14. A computer-readable storage medium recording the computer program described in claim 12.

15. A computer system comprising one or more processors, one or more computer-readable memories, and one or more computer-readable non-transient storage media, wherein program instructions are stored in at least one of the one or more computer-readable non-transient storage media for execution by at least one of the one or more processors via at least one of the one or more computer-readable memories, and the stored program instructions Receiving an initial authorization grant, the public key of a private / public key pair generated on the device, and a certificate of trust for the native application from the native application on the device, Receiving a refresh token and a digital signature of the refresh token created using the private key from the native application on the device, wherein the authorization server recognizes the refresh token only if the refresh token has been verified using the public key that has been registered in advance, and the receiving of the refresh token. The validity of the digital signature of the refresh token, In response to verifying the validity of the refresh token from the native application on the device, the authorization server transmits a new access token and a new refresh token to the native application on the device, wherein the new access token allows the native application on the device to access computer resources. A computer system that is executed to carry out methods including [a certain action].

16. The computer system according to claim 15, wherein the stored program instructions are provided as a service in a cloud environment.

Images