System, method, and computer program product for third-party authorization

Abstract

A method, system, and computer program product for third-party authorization are provided. The method includes generating an authorization code; encrypting the authorization code with a public key associated with a first system to produce an encrypted authorization code; sending the encrypted authorization code to the first system; receiving from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verifying the digitally signed authorization code based on the public key and the authorization code; and, in response to verifying the digitally signed authorization code, sending an access token to the first system, wherein the access token is configured to authorize a user to use the first system.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 62 / 870,834, filed on July 5, 2019, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] The present disclosure relates generally to authorizing users and, in non-limiting embodiments, to systems, methods, and computer program products for third-party authorization. Background Art

[0004] Existing standards and protocols for authorizing users to access systems via third-party authorization systems have several security vulnerabilities. For example, using the Open Authorization (OAth) standard, attackers can intercept authorization codes and / or access tokens to gain unauthorized access to the system. These vulnerabilities are particularly concerning if such third-party authorization is used to access payment systems and / or conduct payment transactions. Summary of the Invention

[0005] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: generating an authorization code with at least one processor; encrypting the authorization code with at least one processor using a public key associated with a first system, thereby producing an encrypted authorization code; sending the encrypted authorization code to the first system; receiving from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verifying with at least one processor the digitally signed authorization code based on the public key and the authorization code; and sending an access token to the first system in response to verifying the digitally signed authorization code, wherein the access token is configured to authorize a user to use the first system.

[0006] In non-limiting embodiments and aspects, the method further includes receiving access permission data from the second system including a user identifier associated with the user and at least one permission, wherein an authorization code is generated and / or encrypted in response to receiving the access permission data. In non-limiting embodiments and aspects, sending the encrypted authorization code to the first system includes sending the encrypted authorization code to the second system, wherein the second system provides the encrypted authorization code to the first system. In non-limiting embodiments and aspects, the method further includes: receiving a request via a first website associated with the first system, the request initiated by a user via a computing device; redirecting the computing device of the user from the first website associated with the first system to a second website associated with the second system, wherein the second website is configured to receive credentials associated with the user; and receiving a request for the authorization code from the second system. In non-limiting embodiments or aspects, the method further includes: receiving from the first system a digitally signed access token generated by the first system based on the access token and a private key; verifying the digitally signed access token using at least one processor based on the public key and the access token; and authorizing the user to use the second system in response to verifying the digitally signed access token.

[0007] According to a non-limiting embodiment or aspect, a system is provided, comprising at least one processor programmed or configured to: generate an authorization code; encrypt the authorization code with a public key associated with a first system, thereby producing an encrypted authorization code; send the encrypted authorization code to the first system; receive from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and, in response to verifying the digitally signed authorization code, send an access token to the first system, wherein the access token is configured to authorize a user to use the first system.

[0008] In a non-limiting embodiment or aspect, the at least one processor is further programmed or configured to receive access permission data from a second system comprising a user identifier and at least one permission associated with the user, wherein an authorization code is generated and / or encrypted in response to receiving the access permission data. In a non-limiting embodiment or aspect, sending the encrypted authorization code to the first system comprises sending the encrypted authorization code to the second system, which provides the encrypted authorization code to the first system. In a non-limiting embodiment or aspect, the at least one processor is further programmed or configured to: receive a request via a first website associated with the first system, the request initiated by a user via a computing device; redirect the user's computing device from the first website associated with the first system to a second website associated with the second system, wherein the second website is configured to receive credentials associated with the user; and receive a request for the authorization code from the second system. In a non-limiting embodiment or aspect, the at least one processor is further programmed or configured to: receive from the first system a digitally signed access token generated by the first system based on the access token and a private key; verify the digitally signed access token with the at least one processor based on the public key and the access token; and, in response to verifying the digitally signed access token, authorize the user to use the second system.

[0009] According to a non-limiting embodiment or aspect, a computer program product is provided that includes at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium including program instructions that, when executed by at least one processor, cause the at least one processor to: generate an authorization code; encrypt the authorization code with a public key associated with a first system, thereby producing an encrypted authorization code; send the encrypted authorization code to the first system; receive from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and, in response to verifying the digitally signed authorization code, send an access token to the first system, wherein the access token is configured to authorize a user to use the first system.

[0010] According to a non-limiting embodiment or aspect, a computer-implemented method is provided, comprising: receiving, with at least one processor of a first system, an encrypted authorization code from an authorization system; decrypting, with the at least one processor, the encrypted authorization code based on a private key associated with the first system, thereby generating an authorization code; digitally signing, with the at least one processor, the authorization code based on the private key, thereby generating a digitally signed authorization code; sending the digitally signed authorization code to the authorization system; and receiving, with the at least one processor, an access token from the authorization system, the access token being configured to authorize a user to use the first system. In a non-limiting embodiment or aspect, the method further comprises: digitally signing, with the at least one processor, the access token based on the private key, thereby generating a digitally signed access token; and sending the digitally signed access token to the authorization system.

[0011] In a non-limiting embodiment or aspect, the method further comprises: receiving a request initiated by a user via a first website associated with a first system; and redirecting a computing device of the user from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user. In a non-limiting embodiment or aspect, receiving an encrypted authorization code from the authorization system comprises receiving the encrypted authorization code from the second system, wherein the second system receives the encrypted authorization code from the authorization system.

[0012] According to a non-limiting embodiment or aspect, a system is provided, comprising at least one processor programmed or configured to: receive an encrypted authorization code from an authorization system; decrypt the encrypted authorization code based on a private key associated with a first system, thereby generating an authorization code; digitally sign the authorization code based on the private key, thereby generating a digitally signed authorization code; send the digitally signed authorization code to the authorization system; and receive an access token from the authorization system, the access token being configured to authorize a user to use the first system.

[0013] In a non-limiting embodiment or aspect, the at least one processor is further programmed or configured to: digitally sign the access token based on the private key, thereby generating a digitally signed access token; and send the digitally signed access token to the authorization system. In a non-limiting embodiment or aspect, the at least one processor is further programmed or configured to: receive a request initiated by a user via a first website associated with a first system; and redirect the user's computing device from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user. In a non-limiting embodiment or aspect, receiving an encrypted authorization code from the authorization system includes receiving the encrypted authorization code from the second system, wherein the second system receives the encrypted authorization code from the authorization system.

[0014] According to a non-limiting embodiment or aspect, there is provided a computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive an encrypted authorization code from an authorization system; decrypt the encrypted authorization code based on a private key associated with a first system, thereby generating an authorization code; digitally sign the authorization code based on the private key, thereby generating a digitally signed authorization code; send the digitally signed authorization code to the authorization system; and receive an access token from the authorization system, the access token being configured to authorize a user to use the first system.

[0015] Other non-limiting embodiments or aspects are set forth in the following numbered clauses:

[0016] Clause 1: A computer-implemented method comprising: generating an authorization code with at least one processor; encrypting the authorization code with at least one processor using a public key associated with a first system to produce an encrypted authorization code; sending the encrypted authorization code to the first system; receiving from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verifying the digitally signed authorization code with at least one processor based on the public key and the authorization code; and sending an access token to the first system in response to verifying the digitally signed authorization code, wherein the access token is configured to authorize a user to use the first system.

[0017] Clause 2: The computer-implemented method of clause 1, further comprising receiving access permission data comprising a user identifier associated with the user and at least one permission from a second system, wherein the authorization code is generated and / or encrypted in response to receiving the access permission data.

[0018] Clause 3: The computer-implemented method of clause 1 or 2, wherein sending the encrypted authorization code to the first system comprises sending the encrypted authorization code to a second system, wherein the second system provides the encrypted authorization code to the first system.

[0019] Clause 4: The computer-implemented method of any one of clauses 1-3, further comprising: receiving a request through a first website associated with the first system, the request being initiated by the user through a computing device; redirecting the computing device of the user from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user; and receiving a request for the authorization code from the second system.

[0020] Clause 5: The computer-implemented method according to any one of clauses 1-4, further comprising: receiving from the first system a digitally signed access token generated by the first system based on the access token and the private key; verifying the digitally signed access token based on the public key and the access token using at least one processor; and authorizing the user to use the second system in response to verifying the digitally signed access token.

[0021] Clause 6: A system comprising at least one processor programmed or configured to: generate an authorization code; encrypt the authorization code with a public key associated with a first system, thereby producing an encrypted authorization code; send the encrypted authorization code to the first system; receive from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and in response to verifying the digitally signed authorization code, send an access token to the first system, wherein the access token is configured to authorize a user to use the first system.

[0022] Clause 7: The system of clause 6, wherein the at least one processor is further programmed or configured to receive access permission data comprising a user identifier associated with the user and at least one permission from a second system, wherein the authorization code is generated and / or encrypted in response to receiving the access permission data.

[0023] Clause 8: The system of clause 6 or 7, wherein sending the encrypted authorization code to the first system comprises sending the encrypted authorization code to a second system, wherein the second system provides the encrypted authorization code to the first system.

[0024] Clause 9: A system according to any of clauses 6-8, wherein the at least one processor is further programmed or configured to: receive a request through a first website associated with the first system, the request being initiated by the user through a computing device; redirect the computing device of the user from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user; and receive a request for the authorization code from the second system.

[0025] Clause 10: The system of any one of clauses 6-9, wherein the at least one processor is further programmed or configured to: receive from the first system a digitally signed access token generated by the first system based on the access token and the private key; verify the digitally signed access token based on the public key and the access token with at least one processor; and in response to verifying the digitally signed access token, authorize the user to use the second system.

[0026] Clause 11: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: generate an authorization code; encrypt the authorization code using a public key associated with a first system, thereby producing an encrypted authorization code; send the encrypted authorization code to the first system; receive from the first system a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verify the digitally signed authorization code based on the public key and the authorization code; and, in response to verifying the digitally signed authorization code, send an access token to the first system, wherein the access token is configured to authorize a user to use the first system.

[0027] Clause 12: A computer-implemented method comprising: receiving, with at least one processor of a first system, an encrypted authorization code from an authorization system; decrypting, with the at least one processor, the encrypted authorization code based on a private key associated with the first system, thereby generating an authorization code; digitally signing, with the at least one processor, the authorization code based on the private key, thereby generating a digitally signed authorization code; sending the digitally signed authorization code to the authorization system; and receiving, with the at least one processor, an access token from the authorization system, the access token being configured to authorize a user to use the first system.

[0028] Clause 13: The computer-implemented method of clause 12, further comprising: digitally signing, with at least one processor, the access token based on the private key, thereby generating a digitally signed access token; and sending the digitally signed access token to the authorization system.

[0029] Clause 14: The computer-implemented method of clause 12 or 13, further comprising: receiving a request initiated by the user through a first website associated with the first system; and redirecting the user's computing device from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user.

[0030] Clause 15: The computer-implemented method of any of clauses 12-14, wherein receiving the encrypted authorization code from the authorization system comprises receiving the encrypted authorization code from a second system, wherein the second system receives the encrypted authorization code from the authorization system.

[0031] Clause 16: A system comprising at least one processor programmed or configured to: receive an encrypted authorization code from an authorization system; decrypt the encrypted authorization code based on a private key associated with the first system, thereby generating an authorization code; digitally sign the authorization code based on the private key, thereby generating a digitally signed authorization code; send the digitally signed authorization code to the authorization system; and receive an access token from the authorization system, the access token being configured to authorize a user to use the first system.

[0032] Clause 17: The system of clause 16, wherein the at least one processor is further programmed or configured to: digitally sign the access token based on the private key, thereby generating a digitally signed access token; and send the digitally signed access token to the authorization system.

[0033] Clause 18: A system according to clause 16 or 17, wherein the at least one processor is further programmed or configured to: receive a request initiated by the user through a first website associated with the first system; and redirect the user's computing device from the first website associated with the first system to a second website associated with a second system, wherein the second website is configured to receive credentials associated with the user.

[0034] Clause 19: The system of any of clauses 16-18, wherein receiving the encrypted authorization code from the authorization system comprises receiving the encrypted authorization code from a second system, wherein the second system receives the encrypted authorization code from the authorization system.

[0035] Clause 20: A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions that, when executed by at least one processor, cause the at least one processor to: receive an encrypted authorization code from an authorization system; decrypt the encrypted authorization code based on a private key associated with the first system, thereby generating an authorization code; digitally sign the authorization code based on the private key, thereby generating a digitally signed authorization code; send the digitally signed authorization code to the authorization system; and receive an access token from the authorization system, the access token being configured to authorize a user to use the first system.

[0036] Clause 21: The computer-implemented method of any one of clauses 1-5, further comprising: verifying, with at least one processor, that authorization for the first system is active; and authorizing the user to use the second system in response to verifying the authorization for the first system and the digitally signed access token.

[0037] These and other features and characteristics of the present disclosure, as well as the methods of operation and function of the related structural elements and combinations of parts, and the economies of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification, wherein like reference numerals designate corresponding parts throughout the several views. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Additional advantages and details are explained in more detail below with reference to non-limiting, exemplary embodiments shown in the schematic drawings, in which:

[0039] Figure 1 is a schematic diagram of a system for third-party authorization according to a non-limiting embodiment;

[0040] Figure 2 is a sequence diagram of a system for third-party authorization according to a non-limiting embodiment;

[0041] Figure 3 is another sequence diagram of a system for third-party authorization according to a non-limiting embodiment; and

[0042] Figure 4 Example components of a device are shown for use with non-limiting embodiments. DETAILED DESCRIPTION

[0043] For purposes of the following description, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "transverse," "longitudinal," and their derivatives will be used relative to the orientation of the embodiments in the accompanying drawings. However, it will be understood that the embodiments may employ various alternative variations and step orders, except where expressly specified to the contrary. It will also be understood that the specific devices and processes shown in the accompanying drawings and described in the following specification are merely exemplary embodiments or aspects of the present invention. Accordingly, specific dimensions and other physical characteristics related to the embodiments or aspects disclosed herein should not be considered limiting.

[0044] As used herein, aspects, components, elements, structures, actions, steps, functions, instructions, etc. should not be understood as being critical or necessary unless explicitly described as such. Also, as used herein, the article "one" is intended to include one or more items and can be used interchangeably with "one or more" and "at least one". In addition, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, a combination of related items and unrelated items, etc.), and can be used interchangeably with "one or more" or "at least one". In the case of wishing only one item, the term "one" or similar language is used. Also, as used herein, the term "having" etc. is intended to be an open term. Additionally, unless explicitly stated otherwise, the phrase "based on" is intended to mean "at least partially based on".

[0045] As used herein, the term "communication" may refer to the reception, acceptance, transmission, transfer, provision, etc. of data (e.g., information, signals, messages, instructions, commands, etc.). A unit (e.g., a device, a system, a component of a device or system, a combination thereof, etc.) communicating with another unit means that the unit is able to directly or indirectly receive information from the other unit and / or send information to the other unit. This may refer to a direct or indirect connection (e.g., a direct communication connection, an indirect communication connection, etc.) that is wired and / or wireless in nature. In addition, although the information sent can be modified, processed, relayed, and / or routed between the first unit and the second unit, the two units may also communicate with each other. For example, even if the first unit passively receives information and does not actively send information to the second unit, the first unit may communicate with the second unit. As another example, if at least one intermediate unit processes the information received from the first unit and transmits the processed information to the second unit, the first unit may communicate with the second unit.

[0046] As used herein, the term "computing device" may refer to one or more electronic devices configured to process data. In some examples, a computing device may include the necessary components to receive, process, and output data, such as a processor, a display, a memory, an input device, a network interface, and the like. A computing device may be a mobile device. As examples, a mobile device may include a cellular phone (e.g., a smartphone or a standard cellular phone), a portable computer, a wearable device (e.g., a watch, glasses, lenses, clothing, etc.), a personal digital assistant (PDA), and / or other similar devices. A computing device may also be a desktop computer or other form of non-mobile computer.

[0047] As used herein, the term "server" may refer to or include one or more computing devices operated by or facilitating communications and processing for multiple parties in a network environment such as the Internet, but it should be understood that communications may be facilitated through one or more public or private network environments, and that various other arrangements may be possible. In addition, multiple computing devices (e.g., servers, point-of-sale (POS) devices, mobile devices, etc.) communicating directly or indirectly in a network environment may constitute a "system." As used herein, references to a "server" or "processor" may refer to a previously described server and / or processor stated as performing a previous step or function, a different server and / or processor, and / or a combination of servers and / or processors. For example, as used in the specification and claims, a first server and / or first processor stated as performing a first step or function may refer to the same or different server and / or processor stated as performing a second step or function.

[0048] As used herein, the term "application programming interface" (API) may refer to computer code that enables communication between different systems or (hardware and / or software) system components. For example, an API may include function calls, functions, subroutines, communication protocols, fields, etc. that can be used and / or accessed by other systems or other (hardware and / or software) system components.

[0049] As used herein, the term "user interface" or "graphical user interface" (GUI) refers to a generated display, such as one or more GUIs, with which a user can interact directly or indirectly (e.g., via keyboard, mouse, touch screen, etc.).

[0050] In non-limiting embodiments, systems and methods are provided for enabling a first system to provide user access based on authorization provided by another system. For example, some non-limiting embodiments may be implemented as enhancements to the Open Authorization (OAuth) protocol. However, it should be understood that non-limiting embodiments may also differ from OAuth and may be implemented with or separately from any existing standards and / or protocols.

[0051] The systems and methods described herein provide enhanced security for actions performed by a first system on behalf of a user through a second system (e.g., allowing the first system to make a payment on behalf of the user). The enhanced security can be achieved through the features described herein, including, but not limited to, arrangements that specifically allow a user to revoke authorization for the first system to take actions on behalf of the user and that allow access tokens, refresh tokens, and / or authorization codes to be digitally signed by the first system. Currently, the OAuth protocol does not allow for revocation of authorization. By allowing revocation, the user can have greater control over authorization to the first system. The user can be more proactive in responding to events that may require revocation of authorization prior to the normal expiration of the token, such as a known security breach. Additionally, the use of digitally signed tokens and authorization codes can increase security by ensuring that requests sent to the second system actually come from the first system and are not sent by an imposter. Digitally signed tokens allow for this increased security without requiring the user to take additional action for every action taken by the first system, thereby reducing network traffic.

[0052] Figure 1 A system 1000 for third-party authorization is depicted, according to a non-limiting embodiment. System 1000 includes an authorization system 102 in communication with an authorization database 110 and a second system 106. Second system 106 may also be in communication with a user device 104 operated by a user 100. User device 104 may include a computing device. Second system 106 may be a system with which user 100 and / or user device 104 are registered, such as one or more computing devices running one or more software programs. For example, second system 106 may be a social network, a forum (e.g., a message board, a media hosting service, etc.), a retailer, an email provider service, a media streaming service, etc. User 100 may have an account with second system 106, represented by account data in an account database 112 in communication with second system 106. The account data in account database 112 may include user credentials associated with each of a plurality of users registered with second system 106, such as a username, password, PIN, etc.

[0053] Still refer to Figure 1In a non-limiting embodiment, the second system 106 may register with the authorization system 102 to provide authorization services for the first system 108 and / or other systems related to the user 100 and / or user device 104, as well as other users and / or user devices. For example, the second system 106 may be registered with the authorization system 102 by being pre-approved by the authorization system 102, such that the authorization system 102 recognizes the second system 106 as valid. The authorization system 102 may include a server and may be operated (e.g., controlled) by the second system 106, the user 100, or a third party. The third party may be associated with the user 100. The user 100 may be an employee, authorized user, client, customer, contractor, etc. of the third party. The third party may be a client, contractor, etc. of the user 100. The authorization system 102 may include a server. The first system 108 may include a service provider, social network, merchant system, etc. with which the user 100 and / or user device 104 seeks to interact. Thus, in a non-limiting embodiment, the user 100 may authorize themselves to use the first system 108 based on user credentials and / or other account information used and / or provided to the second system 106 .

[0054] In a non-limiting example, and with continued reference to Figure 1 , user device 104 may seek access to a website and / or service operated by first system 108. After user 100 requests access via user device 104, first system 108 redirects user device 104 to second system 106 (e.g., by redirecting a web browser on user device 104 to a website provided or hosted by second system 106). Through the website or service of second system 106, user 100 may enter credentials (e.g., a username, password, PIN, account identifier, etc.) to authenticate themselves. Through the website or service of second system 106, after being authenticated, user 100 may select one or more selectable options on a GUI to grant access permissions to first system 108. The one or more selectable options available for selection may vary depending on user 100 and / or the entity associated with first system 108. For example, an identifier for first system 108 may be displayed. In some non-limiting embodiments, specific permissions may be displayed with selectable options on the GUI, allowing user 100 to select one or more selectable options to customize the permissions to be granted to first system 108. Such permissions may include the sharing of personal information or a subset thereof, for example, the duration of such permissions, and / or other limitations and / or parameter settings.

[0055] Still refer to Figure 1, second system 106 may communicate with authorization system 102 to cause authorization system 102 to provide an authorization code. For example, second system 106 may call one or more APIs to request an authorization code from authorization system 102. Second system 106 may send access permission data (e.g., a user identifier associated with a user and at least one access permission) to authorization system 102. The access permission data may be stored in account database 112. Authorization system 102 may then generate an authorization code based on the access permission data and in response to the authorized user. In some examples, the authorization code may already exist and / or may be obtained from another system. In some examples, authorization system 102 may encrypt the authorization code using a public key associated with a private key held by first system 108. The authorization code may be valid for a predetermined amount of time, such as 1 minute, 5 minutes, 10 minutes, 1 hour, 1 day, or until a specified expiration date and / or time. The generation / encryption of the authorization code may be responsive to receiving the access permission data and / or the authorized user. The encrypted authorization code is sent to second system 106, which in turn sends the encrypted authorization code to first system 108. In other examples, the encrypted authorization code may be sent directly to the first system 108 .

[0056] Continue to refer Figure 1 , the first system 108 receives the encrypted authorization code. The first system 108 is configured to decrypt the authorization code to obtain a decrypted authorization code (e.g., a plaintext authorization code), which can be exchanged for an access token (e.g., a JavaScript Object Notation (JSON) Web Token (JWT) payload) for granting the user device 104 access to the first system 108. The decryption can be based on a private key associated with the first system 108. To obtain the access token, the first system 108 can digitally sign the authorization code with the private key to generate a digitally signed authorization code. The digitally signed authorization code can then be sent to the authorization system 102 to request an access token. The authorization system 102 can use the public key to verify the digital signature generated by the first system 108 and, in response to verifying the digitally signed authorization code, can return an access token to the first system 108. As an example, the access token can be sent in plaintext or encrypted using the public key. The access token can then be used to grant access to the user 100 and / or the user device 104. The access token can be valid for a predetermined period of time, such as 15 minutes, 1 hour, 1 day, or until a specified expiration date or time. The predetermined validity period of the access token can be longer than the predetermined validity period of the authorization code.

[0057] In a non-limiting example, and with continued reference to Figure 1, the authorization system 102 can maintain a revocation list in the authorization database 110 or elsewhere so that issued access tokens can be revoked to prevent continued use. Before the authorization system 102 grants access to the first system 108, the authorization system 102 can check to ensure that the first system still has active authorization. The authorization system 102 can compare each access token to the revocation list to determine whether the token is still valid. If the access token is invalid, the first system 108 will not be granted access. The user 100 can withdraw (e.g., revoke) the authorization to the first system 108. This can be requested through the website and / or service of the second system 106. The website and / or service of the second system 106 can be accessed directly or through the website or service of the first system 108. The user 100 can then revoke the access (e.g., access rights) granted to the first system 108.

[0058] Still refer to Figure 1 , the first system 108 can be configured to refresh the access token. The first system 108 can transmit the refresh token to the authorization system 102. The refresh token can be digitally signed by the first system 108 using a private key associated with the first system 108. The authorization system 102 can use the public key to verify the digital signature generated by the first system 108, and in response to verifying the digitally signed response token, can return the access token to the first system 108. The authorization system 102 can compare the refresh token to a revocation list. If access to the first system 108 has been revoked, the access token may not be returned. The refresh token can be valid for a predetermined period of time, such as 1 hour, 1 week, or 1 year, and / or until a specified expiration date and / or time.

[0059] The predetermined validity period of the refresh token can be longer than the predetermined validity period of the access token. User 100 can renew the refresh token. In a non-limiting embodiment, if first system 108 attempts to complete a transaction with second system 106 after the validity period of the refresh token has expired, second system 106 can communicate with user 100 to determine whether the refresh token should be renewed. If user 100 requests a refresh token renewal, second system 106 will pass a new refresh token to first system 108.

[0060] refer to Figure 2 , showing a sequence diagram according to a non-limiting embodiment. Figure 2 The examples shown in can be based on an OAuth implementation for authentication. It should be understood that Figure 2The sequence shown in FIGURE 2 is for example purposes only and is subject to variation. In a non-limiting embodiment, steps 201-210 represent a registration process for registering (e.g., registering) the first system 108 with the second system 106 for authorization. Step 211 represents requesting a new access token. Step 212 represents sending the access token to the authorization system 102. Steps 213-215 represent revoking authorization for the first system. Step 216 represents allowing access to the first system 108.

[0061] In step 201, the user 100 navigates to a website or service 258 operated by a first system 108. The first system (e.g., Figure 1 The first system 108 shown in FIG. 1 may include both a website or service 258 for the first system and a server 268 for the first system. A user may use a user device 104, such as a computing device, to navigate to the website or service 258 for the first system. The user 100 may be an authorized user of the entity. In a non-limiting embodiment, any authorized user of the entity may complete the actions of the user 100.

[0062] In step 202, the website 258 of the first system redirects the user 100 to the website or service 256 operated by the second system for authentication. The user 100 can be redirected to the website 256 of the second system (e.g., Figure 1 For example, the button may state that it will grant access to the server 268 of the first system.

[0063] In step 203, the user 100 logs into the website 256 of the second system and authenticates using the user's credentials. The user 100 may manually enter their credentials, for example, by pressing keys on a keyboard. In non-limiting embodiments, the user's credentials may include a username, password, PIN, two-factor authentication, answers to security questions, personal identification information, etc.

[0064] In step 204, the user 100 is presented with an access permission page (e.g., a GUI) on the second system's website 256, where the user 100 selects one or more selectable options to select one or more permissions. Permissions may include rights or authorizations that allow access to specific information and / or access to services 270 of the second system 106. Permissions may allow the first system 108 to access services and / or information on behalf of the user 100. The selectable permissions may vary depending on the user 100 and / or entity associated with the first system 108. In a non-limiting embodiment, the first system 108 may submit a list of permissions, and the user 100 may grant the first system 108 all, some, or none of the permissions submitted by the first system 108. In a non-limiting embodiment, the user 100 may not be able to grant some of the permissions submitted by the first system 108, but may be required to grant all or none of the permissions submitted by the first system 108. After the user 100 makes a selection, an API of the authorization system 102 is called from the second system's website 256 (e.g., a "register" API function) to transmit the following data: a) a client identifier (e.g., an identifier of the computing device (client) being provided access, which identifier has been previously registered with the first system and received as a client identifier outside of this process); b) a first system identifier (e.g., an identifier of the first system 108, such as a merchant identifier); and c) one or more permissions.

[0065] In step 205, the authorization system 102 records the selected permission in a database 110, such as an authorization database, an account database, or a separate permission database. The database 110 may be operated by the second system 106 or a third party.

[0066] In step 206, the authorization system 102 returns the authorization code encrypted with the first system's public key to the second system's website 256.

[0067] In step 207, the second system's website 256 redirects the user 100 back to the first system's website 258. The encrypted authorization code may also be redirected to the first system's website 258.

[0068] In step 208 , the first system's website 258 sends the encrypted authorization code to the first system 108 (eg, a server of the first system 108 ).

[0069] In step 209, the first system's server 268 decrypts the encrypted authorization code using the first system's private key.

[0070] In step 210, the first system's server 268 transmits the authorization code, digitally signed with the first system's private key, to the authorization system 102. The first system 108 may transmit the code to the authorization system 102 directly or indirectly. The first system 108 may call an API function of the authorization system (e.g., a "getToken" function call) with the authorization code. The first system 108 then receives an access token. The access token may grant the first system 108 access to perform services (e.g., business transactions) for a limited period of time. The access token may be based on the permissions selected in step 204 and may only allow the first system 108 to perform actions and / or transactions authorized for the first system 108.

[0071] The access token may have a short validity period. If the access token expires, the first system 108 may request a new access token. In step 211, the first system 108 requests a new access token from the authorization system 102 via the first system's server 268. The first system's server 268 sends a digitally signed refresh token parameter to the authorization system 102. The first system's server 268 may invoke an API function call (e.g., a "refreshToken" function call) of the authorization system by passing the digitally signed refresh token parameter to the authorization system 102. The digitally signed refresh token parameter may be passed directly or indirectly to the authorization system 102. The authorization system 102 may validate the refresh token. The authorization system 102 may then transmit the access token to the first system 108. The refresh token may facilitate fully autonomous third-party authorization, for example, allowing authorization to be granted after registration without any additional action by the user 100. In a non-limiting embodiment, the refresh token does not expire and may only cease to be valid upon explicit revocation.

[0072] In step 212, the first system 108 sends the digitally signed access token to the authorization system 102. The first system 108 can make an API call to the authorization system 102 to pass the digitally signed access token. This differs from existing OAuth techniques, in which the second system 106 relies on a bearer token to allow API calls. Here, in a non-limiting example, the second system 106 verifies that the token originated from the second system 106 because the second system uses the first system's public key to verify the digital signature of the access token. In a non-limiting embodiment, the digitally signed access token can be verified by the authorization system 102.

[0073] In a non-limiting example involving OAuth or similar implementations, a client (e.g., an OAuth client) may include an Issued At Claim ("iat") field in the token in a format specified by the JWT standard. The iat field will monotonically increment for each call using any given refresh token. It will be appreciated that various forms of structured data may be used. Additionally, various mechanisms may be used to vary the payload of the refresh token. Maintaining a count of each call in the payload serves as a countermeasure against attacks in which an attacker somehow obtains a token that includes the refresh token and the client identifier as the payload. In such a scenario, the attacker could reuse the JWT token to obtain additional access tokens for the lifetime of the refresh token (which could be on the order of months or even years). However, if the tokens created by the client have a constantly changing payload, such as an increasing / changing value in the iat field, a single token cannot be reused twice. However, an attacker could steal two or more tokens and use them in a circular manner to achieve the result that the payload of each request is different from the previous payload. In this case, making the value of the iat field monotonically increasing renders all tokens previously created in this part of the protocol unusable. As a result, stolen and / or compromised tokens will have no value to a potential attacker.

[0074] In a non-limiting embodiment, the refresh token can be valid for a predetermined period of time. The predetermined period of time can be set by the user 100, the first system 108, or the second system 106. When the refresh token expires, the first system 108 cannot obtain an access token to initiate transactions. This forces the user 100 to re-authorize access to the first system 108 by re-enrolling (steps 201-210). In a non-limiting embodiment, in response to determining that the refresh token has expired, a web service call is issued to the user 100 to allow the user 100 to determine whether to extend their permission to the first system 108 by renewing the refresh token. In a non-limiting embodiment, another communication method, such as an email or an application notification, is sent to the user 100 to renew the refresh token. The authorization system 102 can respond to the API call by returning a new refresh token to the first system 108, thereby ensuring that the first system 108 can programmatically obtain a new refresh token without human intervention.

[0075] The existing OAuth protocol does not allow access tokens to be invalidated after creation and does not provide for in-flight token revocation. An OAuth token can be valid for a fixed period of time specified in the OAuth token and defined by the token creator. In a non-limiting embodiment, post-creation invalidation of an access token and in-flight token revocation are provided by the following steps.

[0076] In step 213, the user 100 may log into the website 256 of the second system and revoke access from the first system 108. In a non-limiting embodiment, the user 100 may log into the website 256 of the second system through the website 258 of the first system. In other non-limiting embodiments, the user 100 may directly log into the website 256 of the second system. The user 100 may revoke all permissions for the first system 108, or the user 100 may revoke only some permissions for the first system 108.

[0077] In step 214 , the second system 106 records (eg, logs) the revocation (eg, revocation) of access with the authorization system 102 .

[0078] In step 215, the authorization system 102 records (e.g., logs) the revocation of access in its permissions database 110. The revocation log may include a list of the first system's identification, such as a first system identifier, and the user's identification, such as a user identifier in the permissions database 110. The revocation may include a list of the permissions being revoked. The first system 108 may be revoked for some users, but still have permissions for other users.

[0079] For any in-flight business transactions conducted by the first system 108, the authorization system 102 of the second system's website 256 checks its permission database 110 and, in response to determining that access has not been revoked, executes step 216. The second system's website 256 may check the permission database 110 by searching the permission database 110 for the first system identifier and the user identifier.

[0080] In step 216, the authorization system 102 allows access by permitting the first system 108 to invoke services 270 (e.g., features, actions, transactions, and / or access) available on the second system 106 on behalf of the user 100. If access has been revoked, step 216 will not be performed, and the authorization system 102 will not allow the first system 108 to invoke services 270 of the second system 106.

[0081] Reference Figure 3 , shows a sequence diagram according to a non-limiting embodiment. It should be understood that Figure 3 The sequences shown in are for example purposes only and are subject to variation.

[0082] In step 301, entity server 358 sends a token to policy enforcement point (PEP) 362. PEP 362 can be, for example, a network device that applies rules to input data (e.g., token). The token can include entity identification, user identification, and the scope of permissions allowed by entity server 358.

[0083] At step 302, PEP 362 verifies the token with one of the two keys from the public / private key pair, such that the other key is held by entity server 358, which signed the token using this other key.

[0084] At step 303, PEP 362 checks the token to determine if it has been revoked by querying revocation list 380 (revocation process 375 may be independent of the runtime token and not part of the OAuth protocol). Revocation list 380 may include a list of entity identifiers. In a non-limiting embodiment, revocation process 375 may follow steps 213-215, such as Figure 2 In the revocation process 375, user 300 may access portal 388 to revoke authorization to entity server 358. Portal 388 may then log the revocation with authorization server 382. Authorization server 382 may record (e.g., log) the revocation with token database 390 and may add the entity identifier and user identifier to revocation list 380.

[0085] At step 304, once the token is verified, the PEP 362 allows the entity server 358 to access the service 370 (e.g., features, payments, actions, transactions, analytics, updates, profiles, etc.). In a non-limiting embodiment, the PEP 362 may inspect the requested service 370 to determine whether the service 370 is within the scope of the permissions allowed by the entity server 358 before allowing the entity server 358 to access the service 370.

[0086] Reference Figure 4 , a diagram showing example components of an apparatus 900 according to a non-limiting embodiment. As an example, the apparatus 900 may correspond to Figure 1 The user device 104, the first system 108, the second system 106 and / or the authorization system 102, Figure 2 The server 268 of the first system and / or Figure 3 Entity server 358, PEP 362 and / or authorization server 382 in. In some non-limiting embodiments, such a system or device may include at least one device 900 and / or at least one component of device 900. The number and arrangement of components shown are provided as examples. In some non-limiting embodiments, Figure 4 , device 900 may include additional components, fewer components, different components, or components arranged in a different manner than those shown in . Additionally or alternatively, one set of components (e.g., one or more components) of device 900 may perform one or more functions described as being performed by another set of components of device 900.

[0087] like Figure 4As shown in , the device 900 may include a bus 902, a processor 904, a memory 906, a storage component 908, an input component 910, an output component 912, and a communication interface 914. The bus 902 may include components that permit communication between the components of the device 900. In some non-limiting embodiments, the processor 904 may be implemented in hardware, firmware, or a combination of hardware and software. For example, the processor 904 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), etc.), a microprocessor, a digital signal processor (DSP), and / or any processing component that can be programmed to perform a function (e.g., a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc.). The memory 906 may include a random access memory (RAM), a read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions for use by the processor 904.

[0088] Continue to refer Figure 4 , storage component 908 may store information and / or software related to the operation and use of device 900. For example, storage component 908 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, a solid-state disk, etc.) and / or another type of computer-readable medium. Input component 910 may include components that allow device 900 to receive information, for example, via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, a microphone, etc.). Additionally or alternatively, input component 910 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, etc.). Output component 912 may include components that provide output information from device 900 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.). Communication interface 914 may include transceiver-type components (e.g., a transceiver, a separate receiver and transmitter, etc.) that enable device 900 to communicate with other devices, for example, via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communication interface 914 may allow device 900 to receive information from another device and / or provide information to another device. For example, the communication interface 914 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, interface, cellular network interface, etc.

[0089] Device 900 can perform one or more processes described herein. Device 900 can perform these processes based on processor 904 executing software instructions stored by computer-readable media such as memory 906 and / or storage component 908. Computer-readable media may include any non-transitory memory device. Memory devices include memory space located within a single physical storage device or memory space distributed across multiple physical storage devices. Software instructions can be read from another computer-readable medium or from another device into memory 906 and / or storage component 908 via communication interface 914. When executed, the software instructions stored in memory 906 and / or storage component 908 cause processor 904 to perform one or more processes described herein. Additionally or alternatively, hard-wired circuitry may be used in place of or in conjunction with software instructions to perform one or more processes described herein. Therefore, the embodiments described herein are not limited to any specific combination of hardware circuitry and software. As used herein, the term "programmed or configured" refers to the arrangement of software, hardware circuitry, or any combination thereof, on one or more devices.

[0090] Although the embodiments have been described in detail for purposes of illustration, it should be understood that such detail is solely for that purpose and that the present disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements within the spirit and scope of the appended claims. For example, it should be understood that the present disclosure contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

Claims

1. A computer-implemented method comprising: receiving a request via a first website associated with a first system, the request being initiated by a user via a computing device; redirecting a computing device of the user from a first website associated with the first system to a second website associated with a second system, the computing device being operated by the user to log into the second website and authenticated by the user's credentials; presenting an access permissions page from which the user can select one or more permissions; receiving, at an authorization system, access permissions data from the second system, the access permissions data comprising a user identifier associated with the user and at least one permission selected from the access permissions page; generating, with at least one processor of the authorization system, an authorization code in response to receiving the access permission data; encrypting, with the at least one processor, the authorization code using a public key associated with the first system to generate an encrypted authorization code; sending the encrypted authorization code from the authorization system to the website of the second system, the second website redirecting back to the first website with the encrypted authorization code, and the first website sending the encrypted authorization code to the first system; receiving, at the authorization system, from the first system, a digitally signed authorization code generated by the first system based on the authorization code and a private key corresponding to the public key associated with the first system; verifying, with at least one processor in the authorization system, the digitally signed authorization code based on the public key and the authorization code; sending an access token from the authorization system to the first system in response to verifying the digitally signed authorization code, wherein the access token is configured to authorize a user to use the first system; receiving, at the authorization system, from the first system, a digitally signed access token generated by the first system based on the access token and the private key; verifying, with the at least one processor, the digitally signed access token based on the public key and the access token; verifying, with at least one processor of the authorization system, that authorization by the first system is active by comparing the access token to a revocation list to determine that the token is still valid, wherein the revocation list indicates access tokens that have been revoked by the user through the second website; as well as In response to verifying the digitally signed access token and verifying authorization activity of the first system, the first system is authorized to invoke one or more services of the second system on behalf of the user.

2. The computer-implemented method of claim 1 , comprising: receiving, via the second website, a request from the user to revoke authorization of the first system; recording, by the second system, the revocation of the authorization system; recording, by the authorization system, the revocation in the revocation list, wherein the revocation list is stored in an authorization database; as well as In response to determining that authorization of the first system has been revoked, the first system is prevented from invoking one or more services of the second system on behalf of the user. 3 . The computer-implemented method of claim 2 , wherein the request to revoke authorization is received from the user via the first website.

4. The computer-implemented method according to any one of claims 1 to 3, comprising: receiving, with at least one processor of the first system, the encrypted authorization code from the authorization system; decrypting, with at least one processor of the first system, the encrypted authorization code based on a private key associated with the first system to generate an authorization code; digitally signing the authorization code based on the private key using at least one processor of the first system, thereby generating the digitally signed authorization code; sending the digitally signed authorization code to the authorization system; as well as An access token is received from the authorization system with at least one processor of the first system, the access token being configured to authorize a user to use the first system.

5. The computer-implemented method of claim 4 , further comprising: digitally signing the access token based on the private key using at least one processor of the first system, thereby generating the digitally signed access token; as well as The digitally signed access token is sent to the authorization system.

6. A system comprising at least one processor programmed or configured to perform the method of any one of claims 1 to 5.

7. A computer program product comprising at least one non-transitory computer-readable medium, the at least one non-transitory computer-readable medium comprising program instructions which, when executed by at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 5.

Images