Abstract: Presented herein are systems and methods for end-to-end encryption for session-less communications. A first server may receive, from a second server, a request to retrieve keys for a customer device to access a service. The request may include a device identifier and a first token encrypted using a first encryption key. The first server may determine, responsive to validating, that the customer device is to be issued a second token. The first server may identify least a portion of the first token decrypted using the first encryption key. The first server may generate a set of second encryption keys to be used by the customer device. The first server may package the second token to include (i) at least the portion of the first token and (ii) the set of second encryption keys. The first server may transmit, to the second server, a response including the second token.

Abstract: Presented herein are systems and methods for processing tokens in identity assertions for access control to resources. A server may receive, via an interface from a gateway, a request to permit a customer device to access a resource associated with the server. The request may include an identifier for the customer device and a first token used to authenticate the customer device at the gateway. The server may generate, responsive to validating the first token, a second token to be used to authorize the customer device at the server for access to the resource. The server may store, on a database, an association identifying the identifier, the first token, and the second token. The server may perform the server, an action to permit the customer device access to the resource associated with the server based on the association maintained on the database.

Abstract: Presented herein are systems and methods for end-to-end encryption for session-less communications. A first server may receive, from a second server, a request to retrieve keys for a customer device to access a service. The request may include a device identifier and a first token encrypted using a first encryption key. The first server may determine, responsive to validating, that the customer device is to be issued a second token. The first server may identify least a portion of the first token decrypted using the first encryption key. The first server may generate a set of second encryption keys to be used by the customer device. The first server may package the second token to include (i) at least the portion of the first token and (ii) the set of second encryption keys. The first server may transmit, to the second server, a response including the second token.

Abstract: A network system to provide mutable access tokens for access requests that eliminate a need for token replacement. The system allows an access token to be changed to update data in the token. When data stored with the token changes, such as when a user or partner has a change in status, a new token is not required to be requested, generated, dispersed, or stored. Conventional systems refuse the API call request and require the new token be provided. The described system instead completes the request while simultaneously notifying the user to subsequently retrieve an updated access token. Requesting, generating, communicating, and presenting a new token requires additional time, bandwidth, computing capacity, and system interactions. While performing new token acquisition in conventional systems, devices are forced to perform additional interactions, which may result in a time delay or in one or more devices exceeding capacity, becoming overloaded, and seizing.

Abstract: Presented herein are systems and methods for binding web components to protect accessing of resources. A first server may receive, from a second server, a request to provide access to content for a first web component on a web application of a customer device. The first server may determine whether to issue an identifier to the customer device responsive to validating the request. The first server may generate, responsive to the determination, the identifier to bind the first web component with a second web component to permit access to the content for the first web component on the web application. The first server may transmit, to the second server, a response including the identifier and the content. The first server may communicate, via the second server, data associated with a user interaction with the content on the first web component bound with the second web component using the identifier.

Abstract: Presented herein are systems and methods for end-to-end encryption for session-less communications. A first server may receive, from a second server, a request to retrieve keys for a customer device to access a service. The request may include a device identifier and a first token encrypted using a first encryption key. The first server may determine, responsive to validating, that the customer device is to be issued a second token. The first server may identify least a portion of the first token decrypted using the first encryption key. The first server may generate a set of second encryption keys to be used by the customer device. The first server may package the second token to include (i) at least the portion of the first token and (ii) the set of second encryption keys. The first server may transmit, to the second server, a response including the second token.

Abstract: Presented herein are systems and methods for end-to-end encryption for session-less communications. A first server may receive, from a second server, a request to retrieve keys for a customer device to access a service. The request may include a device identifier and a first token encrypted using a first encryption key. The first server may determine, responsive to validating, that the customer device is to be issued a second token. The first server may identify least a portion of the first token decrypted using the first encryption key. The first server may generate a set of second encryption keys to be used by the customer device. The first server may package the second token to include (i) at least the portion of the first token and (ii) the set of second encryption keys. The first server may transmit, to the second server, a response including the second token.

Abstract: A method for securing communication may include: (1) receiving, at the authorization platform and from a hybrid browser component of a computer application, an encrypted payload comprising an authentication code, a bundle identifier, and an application unique identifier; (2) registering, by the authorization platform, a username for a user; (3) receiving, at the authentication framework and from the computer application, the username and the encrypted payload; (4) receiving, at the authentication framework, user login credentials from the user; (5) validating, by the authentication framework, the user login credentials; (6) passing, by the authentication framework to the authorization platform, the encrypted payload; (6) comparing, by the authorization platform the encrypted payload received from the computer application to the encrypted payload received from the authentication framework; and (8) accepting, by the authentication framework, the encrypted payload and tying the process to the computer applicatio

Abstract: Systems and methods for using an OAUTH client-secret to encrypt data sent to browser are disclosed. In one embodiment, in an issuer authorization services processing apparatus comprising at least one computer processor, a method for using an OAUTH client-secret to encrypt data may include: (1) receiving, from a client, a registration request; (2) returning, to the client, a client identifier, a client secret, and a nonce; (3) generating an extended client secret using a combination of the client identifier, the client secret, and the nonce; (4) storing the extended client secret; (5) receiving, from the client, encrypted plaintext data; (6) decrypting the encrypted plaintext data using the extended client secret; and (7) providing an encrypted response to the plaintext data, the encrypted response encrypted using the extended client secret.

Abstract: An embodiment of the present invention is directed to a multi-certificate pinning. The innovative system configures servers with at least two certificates from multiple different vendors/sources with differing expiration dates. This provides lead time to replace voided/expired certificates. If a first certificate expires, the system uses another valid certificate for that server until the certificated is addressed, thereby avoiding service down times. Accordingly, providers are not required to expedite mobile app store submission.

Abstract: Systems and methods for token linking and unlinking in digital wallets are disclosed. In one embodiment, a method for token linking in digital wallets may include: an issuer wallet application executed by the information processing device requesting, from a token vault, an identification of a customer's accounts that are eligible for push-provisioning to a third party wallet application executed by the information processing device; receiving the identification of customer accounts from the token vault; identifying accounts provisioned in the third party wallet application; determining accounts from the customer accounts that have not been provisioned to the third party wallet application to provision to the third party wallet application; provisioning the determined accounts to the third party wallet application; and requesting the token vault link a token associated with the provisioned account to an issuer wallet associated with the issuer wallet application.

Abstract: In one embodiment, in an information processing apparatus comprising at least one computer processor, a method for binding a GET/AUTHORIZE URL to a proxy through a native application may include: (1) receiving, at a native application executed by an electronic device, an applink call or a universal link call from a third-party application executed by the electronic device, the redirect comprising at least one parameter; (2) providing a Get/Authorize call with the at least one parameter to an API gateway; (3) receiving a 302 redirect from the API gateway; (4) providing authentication information to an authorization platform; (5) receiving an authorization code from the authorization platform; and (6) redirecting the third-party application with the redirect URL and authorization code.

Abstract: A method for securing communication may include: (1) receiving, at the authorization platform and from a hybrid browser component of a computer application, an encrypted payload comprising an authentication code, a bundle identifier, and an application unique identifier; (2) registering, by the authorization platform, a username for a user; (3) receiving, at the authentication framework and from the computer application, the username and the encrypted payload; (4) receiving, at the authentication framework, user login credentials from the user; (5) validating, by the authentication framework, the user login credentials; (6) passing, by the authentication framework to the authorization platform, the encrypted payload; (6) comparing, by the authorization platform the encrypted payload received from the computer application to the encrypted payload received from the authentication framework; and (8) accepting, by the authentication framework, the encrypted payload and tying the process to the computer applicatio

Abstract: Systems and methods for providing encrypted storage within application sandbox are disclosed. Embodiments may secure data at rest on mobile device within application sandbox. The data may be stored in a manner that is resistant to attacks intended to reveal the data, and situations in which unintentional disclosures could occur. In embodiments, data may not be unintentionally lost, and it may be used with data that may be classified as Personally Identifiable Information.

Abstract: Systems and methods for providing encrypted storage within application sandbox are disclosed. Embodiments may secure data at rest on mobile device within application sandbox. The data may be stored in a manner that is resistant to attacks intended to reveal the data, and situations in which unintentional disclosures could occur. In embodiments, data may not be unintentionally lost, and it may be used with data that may be classified as Personally Identifiable Information.

Abstract: Systems and methods for token linking and unlinking in digital wallets are disclosed. In one embodiment, a method for token linking in digital wallets may include: an issuer wallet application executed by the information processing device requesting, from a token vault, an identification of a customer's accounts that are eligible for push-provisioning to a third party wallet application executed by the information processing device; receiving the identification of customer accounts from the token vault; identifying accounts provisioned in the third party wallet application; determining accounts from the customer accounts that have not been provisioned to the third party wallet application to provision to the third party wallet application; provisioning the determined accounts to the third party wallet application; and requesting the token vault link a token associated with the provisioned account to an issuer wallet associated with the issuer wallet application.

Abstract: In one embodiment, in an information processing apparatus comprising at least one computer processor, a method for binding a GET/AUTHORIZE URL to a proxy through a native application may include: (1) receiving, at a native application executed by an electronic device, an applink call or a universal link call from a third-party application executed by the electronic device, the redirect comprising at least one parameter; (2) providing a Get/Authorize call with the at least one parameter to an API gateway; (3) receiving a 302 redirect from the API gateway; (4) providing authentication information to an authorization platform; (5) receiving an authorization code from the authorization platform; and (6) redirecting the third-party application with the redirect URL and authorization code.

Abstract: Integrating systems using an enablement token are disclosed. According to one embodiment, in an information processing apparatus for a first provider comprising at least one computer processor, a method for linking a plurality of accounts using an enablement token, may include: (1) receiving, from a first provider user interface for the first provider and from a customer, a request for an enablement token to link a product provided by the first provider with a second provider; (2) generating the enablement token; (3) sending the enablement token to the first provider user interface; (4) receiving, from a second provider, the enablement token and a customer identifier for the customer with the second provider; (5) validating the enablement token; and (6) sending an authorization code and a product identifier for the product to the second provider.

Abstract: Systems and methods for using an OAUTH client-secret to encrypt data sent to browser are disclosed. In one embodiment, in an issuer authorization services processing apparatus comprising at least one computer processor, a method for using an OAUTH client-secret to encrypt data may include: (1) receiving, from a client, a registration request; (2) returning, to the client, a client identifier, a client secret, and a nonce; (3) generating an extended client secret using a combination of the client identifier, the client secret, and the nonce; (4) storing the extended client secret; (5) receiving, from the client, encrypted plaintext data; (6) decrypting the encrypted plaintext data using the extended client secret; and (7) providing an encrypted response to the plaintext data, the encrypted response encrypted using the extended client secret.

Abstract: An embodiment of the present invention is directed to a multi-certificate pinning. The innovative system configures servers with at least two certificates from multiple different vendors/sources with differing expiration dates. This provides lead time to replace voided/expired certificates. If a first certificate expires, the system uses another valid certificate for that server until the certificated is addressed, thereby avoiding service down times. Accordingly, providers are not required to expedite mobile app store submission.