System and Method for Providing Controlled Application Programming Interface Security

This application is a continuation application of, and claims priority under 35 U.S.C. § 120 to, U.S. patent application Ser. No. 17/555,589, filed Dec. 20, 2021, which is a continuation of U.S. patent application Ser. No. 16/589,165, now U.S. Pat. No. 11,206,247, filed Oct. 1, 2019, which is a continuation of U.S. patent application Ser. No. 14/580,809, now U.S. Pat. No. 10,432,598, filed Dec. 23, 2014, which is a continuation of U.S. patent application Ser. No. 13/611,993, now U.S. Pat. No. 8,955,067, filed Sep. 12, 2012, the entire contents of which are fully incorporated herein by reference.

Application Programming Interfaces (APIs) are generally employed to provide connectivity between applications and underlying data in a system or services provided by an entity or institution. Conventional authentication systems and processes for an API typically consider a single factor, trust between applications. Authentication is generally termed as the act of confirming the identity of a client or caller.

In a conventional authentication model, a client may request access to a restricted resource (protected resource) on a site (e.g., a server) by authenticating with the server via a portal or website using the resource owner's credentials. To provide third party applications (via an API) access to these restricted resources, the resource owner must share its credentials with the third party which may result in several problems. For example, in such conventional authentication models the applications and/or APIs may be required to store the resource owner's credentials (e.g., password) for future use and servers must support password authentication, despite the security weaknesses inherent in passwords. Additionally, in such conventional models applications and/or APIs may gain broad access to a resource owner's protected resources, leaving resource owners without an ability to restrict duration or access to a limited subset of resources. Thus, resource owners may not be able to revoke access to an individual third party without revoking access to all third parties, and any compromise of an API may result in the compromise of a user's password and all data protected thereby.

Additional methods or forms of authentication also exist in the industry. For example, OpenID is an open standard that describes how a user may be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. More specifically, in such a method a user may interact with a relying party (via a website) that provides an option to specify an OpenID for the purposes of authentication. An identity provider, or OpenID provider (OP), is a service that specializes in registering OpenID uniform resource locators (URLs) or extensible resource identifiers (XRIs). OpenID may then enable a user to communicate with a relying party through the exchange of an identifier or OpenID corresponding to the URL or XRI chosen to name the user's identity. An OP may provide the OpenID authentication (and possibly other identity services) which is enabled by a user-agent (e.g., a program such as a browser) employed by the end-user to communicate with the relying party and OP. By way of further example, OAuth 2.0 is another open standard for authorization which allows a resource owner or user to share private resources between two sites without having to provide a user's credentials to the relying party. More specifically, OAuth 2.0 provides an authorization framework enabling a third party application or API to obtain access to a service, on behalf of a user by orchestrating an approval interaction between the user and the service or by allowing the third party application or API to obtain access on its own behalf. OAuth 2.0 typically introduces an authorization layer and separates the role of a client (i.e., online service, etc.) from that of the user or resource owner. In OAuth 2.0, a client generally requests access to resources controlled by the user and hosted by a resource server and is issued a different set of credentials than those of the user. Instead of employing the user's credentials to access protected resources, a client may obtain an access token (i.e., a string denoting a specific scope, lifetime, or other access attribute). Access tokens are issued to clients by an authorization server with the approval of the user whereby the client uses the access token to access the protected resources hosted by the resource server. For example, a user or resource owner may grant a banking service (i.e., client) access to the user's account or other information stored at resource server without sharing the user's username and password with the banking service. Rather, the user may authenticate directly with a server trusted by the banking service (i.e., an authorization server) which issues an appropriate access token.

These forms of authentication, however, are still susceptible to certain attacks on supporting systems including phishing attacks, malicious applications, and the like. Thus, there remains a need to overcome conventional limitations and provide an API to securely support both internally and externally created applications which provide access to, for example, a user's financial data or services provided by an entity or institution.

The present disclosure is directed generally to systems and methods for providing an authentication methodology independent of user authentication to a front end application. As some of these applications are built by third parties there may be limited trust, however, there must be security around user data that these front end applications may not be capable of enforcing. One exemplary methodology may secure API calls to allow a user (or API provider) to control access to data or services in a form which may be run on multiple platforms such as a website plugin, mobile phone, etc. Such a methodology may be resistant to hacking even if some of the resident platforms are hostile (e.g., a rooted phone). The party controlling the API may thus be able to disable a rouge application with a single control or disable a single customer across one or all applications should an account be compromised. Furthermore, such an exemplary methodology may allow for optimal security controls over multiple applications and users, and the methodology may be implemented in a manner that is resistant to fraudulent attempts to capture a user's credentials (e.g. phishing).

One embodiment of the present invention provides a method for allowing an application acting on behalf of a user access to data pertinent to that user. The method may include issuing a unique key specific to the application, to the user of the application, and to the device or server upon which the application resides. The user may then be required to conduct a separate transaction to authorize access to the data whereby, in this separate transaction, the unique key may be activated which grants access to the data to callers using the activated key.

Another embodiment of the present invention provides a method for allowing an application acting on behalf of a user access to a service provided by an entity specific to that user (e.g. a service to move money in a bank account belonging to the user). The method may include the steps of a server issuing a unique key specific to the application, to the user of the application, and to the device or server upon which the application resides. The user may then be required to conduct a separate transaction to authorize access to the provided service whereby, in this separate transaction, the unique key may be activated which grants access to the service to callers using the activated key.

An additional embodiment of the present disclosure provides a system for controlling access by an application acting on behalf of a user to data belonging to that user or to services specific to that user and offered by an institution. The system may include one or more servers each server having a computer readable storage medium, the computer readable storage medium having instructions stored thereon. These instructions may cause the one or more servers to issue a unique key specific to the application, to the user of the application, and to the device upon which the application resides. The instructions may also cause the one or more servers to activate the unique key and which authorizes access to the data or service to callers using the activated key. The instructions to create the unique key and the instructions to activate the key are performed in separate transactions with the server.

These embodiments and many other objects and advantages thereof will be readily apparent to one skilled in the art to which the invention pertains from a perusal of the claims, the appended drawings, and the following detailed description of the embodiments.

To facilitate an understanding of the present subject matter, the various embodiments of a system and method for providing secure, controlled access to an application programming interface security are provided with reference to the figures where like elements have been given like numerical designations.

Embodiments of the present subject matter may be utilized to provide security and/or access to data of a user stored with a data custodian or to services provided by an entity, custodian or institution. An exemplary custodian may be, for example, a financial institution such as a bank, brokerage firm or other similar entity. Of course, a custodian may also be any agent or any agent's computer or computers acting as an intermediary between two other parties or computers of two other parties where access, such as via the Internet, to certain information or data is designed to be limited, regardless of whether or not the information or data is confidential. A custodian may also include a secure operating system executing on a microprocessor-based computer terminal or device capable of interactive network communications, or wireless device that connects to, and communicates through, the Internet using, for example, a wireless access protocol (WAP) or other protocol, and utilizing operating-system controls to limit access to data.

is an illustration of an exemplary data access systemconnected to a plurality of interconnected computer system networksand devices,,. The data access systemmay be employed by a custodian described above or any agent or intermediary thereof, for example. Each computer system networkmay include a corresponding local computer processor unit, which is coupled to a corresponding local data storage unitand to local network terminals. A computer system networkmay be a local area network (LAN) or part of a wide area network (WAN), for example. An exemplary data access systemand local computer processor unitsmay be selectively coupled to a plurality of devicesthrough the Internetor another known means. Exemplary devices may be desktop computers, tablets, mobile devicessuch as cell phones, smart phones, and the like. Each of the devices,,and local terminalsmay have various devices connected to their local computer systems, such as scanners, barcode readers, printers, finger print scanners, mouse devices, keyboards, and other interface devices. The data access systemmay be protected from network attacks by a piece of software or specialized hardware, commonly known as a firewall. It is understood that a firewall may be used to block network connections from the outside world to the data access systeminside the firewall. It is also understood that firewalls are often governed by a set of rules that specify what IP addresses, ports, and even types of traffic are allowed to connect to machines inside the firewall. It is also understood that other network security defense tools may be employed as part of a defense-in-depth strategy to secure the data access systemincluding, but not limited to, intranet subnet partitioning, intrusion detection or host-based intrusion prevention systems. Communications between any or all of the devices to an exemplary data access systemmay be via a transport layer security (TLS) tunnel or secure sockets layer (SSL) tunnel to prevent snooping and/or alternation of such communications and respective information. These tunnels are exemplary only as other cryptographic protocols may be employed to provide communications security over the Internet and encrypt segments of network connects at the application layer.

An exemplary data access systemmay include a processing unitcoupled to one or more data storage units,. The processing unitmay provide front-end graphical user interfaces (GUI), e.g., customer GUIand a data access service provider GUI, as well as back-end GUIsto a terminal, device,,or to a local computer. The GUIs may take the form of, for example, a webpage that is displayed using a browser program local to the terminal, device,,or to the local computer. It is understood that the data access systemmay be implemented on one or more computers, servers, or like devices. For example, a data access system may include servers programmed or partitioned based on permitted access to the data of a custodian or customer. It should be noted that the terms “customer” and “user” are used interchangeably herein and such use should not limit the scope of the claims appended herewith. Front- and back-end GUIs,,may be portal pages that include various content retrieved from the one or more data storage devices,. As used herein, “portal” may be general-purpose Internet portals and/or may include GUIs that are of interest to specific, limited audiences and that provide a user access to a plurality of different kinds of related or unrelated information, links and tools as described below. It should also be noted that the terms “webpage” and “website” may be used interchangeably herein and such use should not limit the scope of the claims appended herewith.

A user or customer may gain access to source data access systemby using a device,,,,, programmed with a Web browser or other software, to locate and select (such as by clicking with a mouse) a particular webpage. Application Programming Interfaces (APIs) may be employed to provide connectivity between applications resident on the devices,,,,and underlying data in the systemor services provided by an entity, custodian or institution. The content of the webpage may be located on the one or more data storage devices,. The device,,,,may be a microprocessor-based computer terminal, a pager adaptable to communicate through the Internet, Kiosks with Internet access, personal digital assistants (PDAs) (e.g., a PALM device manufactured by Palm, Inc., IPAQ device available from Compaq, iPHONE from Apple or BLACKBERRY from RIM), cellular phone, tablet, or other devices capable of interactive network communications, such as an electronic personal planner. Of course, such devices,,,,may be wireless or wire-line that connect to and communicate through the Internet.

As mentioned above, an exemplary data access systemmay provide separate features and functionality for users thereof, including customers and data access service providers, as well as back-end users that manage the data access system. A customer or user may be an individual or business or organization that signs up for or otherwise takes advantage of a data custodian service, and a “data access service provider” may be an individual or business or organization, such as a financial or banking institution, that provides one or more data access services to customers and/or third parties.

Embodiments of the present subject matter may provide security around an API for a wide variety of services to obtain information from an entity or custodian such as a financial or banking institution and/or may perform operations within the entity or custodian. This API may be available for code running anywhere outside the entity, including code written by independent users, or the API may be restricted only to code that has been reviewed and approved. An exemplary API may grant a user control over what applications may access their respective data stored on a central or custodial server, may run a respective application on a potentially untrustworthy platform without any increased risk to data of any other user, and may be resistant to aggressive third party attacks. The API may provide a method to build an application capable of running anywhere with network access that is capable of accessing data from an exemplary system. For example, an exemplary API may be utilized to build a smartphone application to track a user's progress toward a savings goal or may be utilized to build an application for transferring funds from one user to another. Exemplary services may employ, for example, a representational state transfer (REST)-based call with JavaScript Object Notation (JSON) data; such a service may be used from practically any language or development environment. Of course, other protocols and/or data-interchange formats may be employed in embodiments of the present subject matter such as a Simple Object Access Protocol (SOAP)-based call, extensible Markup Language (XML) format, or other protocols and/or formats; thus, such an example should not limit the scope of the claims appended herewith. Generally, such applications should be reviewed and approved by the respective institution prior to deployment to ensure that users or customers thereof remain in control of their respective data.

In one non-limiting embodiment, a call or request to an exemplary system may be made using HTTP. As is known, HTTP defines several “verbs” including, GET, POST, PUT, HEAD, TRACE, OPTIONS, CONNECT, and DELETE, to name a few. An institution's service may use any one or several of these verbs and may define a pattern of URLs to correspond to certain institutional entities such as an “account” or “transaction”. For example, performing a GET on a given URL may be used to read information about the entity, and performing a POST on a given URL may be used to create a new entity. Performing a PUT may be used for modifying fields, and performing a DELETE may be used for removing an entity. Thus, a user may perform a GET on an account to ascertain the balance in that account or perform a PUT for a certain transaction to modify the amount of the transaction. Of course, this functionality may recreate any number of processes including some that might otherwise be performed using Open Financial Exchange (OFX) (which is a specification for electronic exchange of financial data between financial institutions, businesses and users via the Internet).

In one embodiment, an exemplary API call may return a single JSON object (which may have inner objects) or a list of JSON objects. The documentation for a specific API call may determine the type of returned object returned by the respective field (e.g., an account has an “accountNumber” field, a “balance” field, an “availableBalance” field, etc.). Any number of fields may be specified, depending upon the service provided. Furthermore, a default set of fields may be provided. Generally, security policies resident on a browser may prevent an HTML application from one domain from using data returned by a call to a different domain (known as the “same origin policy”), thereby preventing browser-based applications from using a specific API. A response using JSONP (JSON with padding) may be employed in this case to request data from a server in a different domain whereby the calling application supplies the name of a function in the global namespace. The respective API call, instead of returning the data, may return JavaScript to call this function and pass the appropriate data. Thus to support JSONP, exemplary API calls may specify a query parameter “callback” setting it to the name of the function. The returned JSON may then be wrapped with “<function-name>(“and”);”, for example.

Exemplary APIs may include a variety of levels of security. For example, initial security may be implemented through the use of a TLS or SSL tunnel in communications with an exemplary system. Thus, calls made to the system from a remote device may use https rather than http and any call not so encrypted may be rejected. A first layer of security may include an application key or “ApplicationKey”. An application key is generally a unique key issued for each application from a respective API provider. In such an embodiment, any API call may be rejected if it lacks this application key. Further, monitoring, rate limiting, access to sensitive API calls, and an overall ability to disable the application may be controlled on the server-side of an exemplary system using such an application key. As an additional option, the issuing institution may review code before issuing an application key to enforce reasonable standards. In another embodiment, an existing API security package may be utilized to provide features such as rate limiting, denial-of-service resistance, and transaction logging and reporting. Thus, a per-application (rather than a per-customer or per-installation) key may also be utilized for this layer.

Independent of an application key or in addition to the key as a second layer of security, an embodiment may issue a customer data key or “CustDataKey”. Generally, this exemplary layer of security is directed to securing customer data; thus, in some embodiments not all institutional services or data may require this security layer. For example, services accessing a financial institution's current rates or services that set up a customer data key may not require this level of security. It follows, however, that services that read and/or modify customer-confidential or customer-sensitive data must provide a customer data key. In one embodiment, the customer data key may be provided in an HTTP header. It should be noted, however, that the customer data key is specific to a single customer or user, to a particular API-using application, and to a particular installation thereof and is not issued until that customer begins using a specific application. That is, a new, unique CustDataKey is issued the first time that a given user utilizes a given installation of a specific application, and the key is specific to that user, that application, and that installation. Thus, it follows that a new CustDataKey is issued in the instances when a user installs and launches an application on a device, when another user (e.g., spouse, friend, etc.) accesses his own account on the same device, and in instances when a user installs and launches a second application on the same device, and in instances when a user installs the same application to a second device, etc. If any one of these three variables change, then a new CustDataKey will need to be issued (and authorized). In one embodiment, the CustDataKey may be stored in a storage medium on the device. This storage medium may be a default medium or otherwise.

The customer data key is not valid for accessing a customer's data or performing operations related to that customer until the respective user successfully accesses an institution's services (e.g., logs onto a financial institution's website) using the independent authorization procedures such as, but not limited to, a two factor identification procedure. In one embodiment, when a customer accesses the institution's website, if any keys have been issued for his or her respective data an alert may be provided to the user which describes the application and access requested. The customer may then approve the request, deny it, or do neither. Of course, the customer or the institution may revoke previously approved keys. Thus, all calls that access sensitive or confidential customer data must provide a CustDataKey, and in the event that the CustDataKey is invalid, the respective call will be provided with an error and denied.

To obtain a new customer data key the respective application should, through a respective API call, request a customer to enter their “username” or other identifying means and a POST will be performed with an appropriate string of data, e.g., JSON data. A message may then be returned that contains the customer data key for the respective application for access or modification, etc. of the customer's data. At this stage, the customer data key is not authorized, that is, the application has requested access to customer data but access has yet to be granted. In one embodiment, an exemplary application may display a message to the user of a device instructing the user to log onto their respective account at the institution and approve the request from the application. This approval must be provided before access to customer data will be granted, thus ensuring the customer maintains control of his or her data. In one embodiment, the application may make a call to a specific URL to determine whether the customer data key has been approved. A return value of “revoked”, in this case may indicate that the customer or institution has prohibited the application (or at least that installation of the application) from access to that customer's data. A return value of “pending” may indicate that the customer has not yet approved or rejected the access request. A return value of “approved” may indicate that the application has been granted the requested access. The application may use this to begin a new transaction (in the case of “revoked”), continue prompting the customer to approve the request (in the case of “pending”), or proceed with invoking API calls and performing application functionality (in the case of an “approved”).

An optional third layer of security may exist within the specific application. The implementation details of such security may be dependent upon the application and the services accessed thereby. For example, if the application's function is obtaining information regarding the current financial balance of a customer, then the application may not require specific access controls. In contrast, an application whose function was managing or modifying account balances (creating money transfers and the like) may include additional measures of security such as a login processes or multi-factor authentication. Exemplary and non-limiting security for this third layer may include requiring users to enter a PIN, to enter an alternative password, to confirm answers to predetermined and/or specific questions, etc. Of course, the respective institution may enforce standards on this layer of security by reviewing code of applications prior to allowing that application's keys to be presented for approval by customers. It should be noted that the protection of the API provided by the CustDataKey of the second layer may be combined with any sort of additional security within the end application (this third layer). For example, a banking application that displays a customer's current checking-account balance on a display device may require no additional security. Thus, once the application has been authorized to use the API, the application may, for example, call a GET_BALANCE service every 15 minutes to obtain (and/or display) the latest balance. In this instance, the application would not need or have any credentials for the customer and would not need to store the customer's username after the initial call to obtain the CustomerKey.

In another example of in-application security, a banking application may request a customer's username and then show a unique-to-the-customer image prior to accepting the password, PIN or other authentication to prevent phishing. In a further example, a banking application may utilize a single CustDataKey and use different levels of security for different actions, e.g., showing a balance with no login, requiring a quick connect-the-dots pattern to unlock basic functionality but only allowing transfers to accounts not owned by the customer after a more stringent password challenge. In an additional example, a banking application may allow a customer to specify the level of security desired, recognizing that some customers are more concerned with convenience and others more concerned with security (of course, access may still be controlled with a CustDataKey regardless of the security level chosen).

As another example, a financial institution offering an API may institute a review policy requiring all applications using the API to be reviewed to ensure that the application's security was sufficient to satisfy regulations. In this case, if an application did not meet such standards, no CustDataKeys would be issued for the application and/or existing keys may be revoked. In a further example, a lost-phone service may automatically make API calls to disable CustDataKeys issued to a customer's lost phone (in addition to normal functions of remote locking of the phone and retrieving GPS location) thus being an equivalent to the cancellation of one's lost or stolen credit cards.

It is thus an aspect of embodiments of the present subject matter to provide a benefit that even if an individual planted a virus (i.e., hacked) onto a device capable of key-logging to capture a customer's PIN, that individual would not be able to use the device to access the APIs from another phone as the individual would not have a correct CustDataKey.

In a system which, by way of example, incorporated all three of the layers described above, calls or requests may include a variety of service-specific calls. For example, a ping service may use a GET call (e.g., “/v1/ping”) to test a connectivity to the API by calling a service that returned a fixed string (e.g., {“value”:“pong”}). Such a call might require a valid issued application key (layer 1), but not a valid CustDataKey (layer 2) as there is no customer-specific data being accessed. Another service requiring only an application key may be one to create a new CustDataKey. Such a service may use a POST call (e.g., “/v1/customerDataKeys”) to obtain a (not yet authorized) CustDataKey which is required for any of the service calls that access, modify, etc. customer data or access customer-specific services offered by an institution. In one non-limiting embodiment, the CustomerDataKey structure may include basic information about a particular customer data key and may include fields such as keyValue and keyStatus as shown in. A keyStatus field may include the statuses of “pending”, “approved”, or “revoked”.

Another service may use a GET call (e.g., “v1/customerDataKeys/{customer-data-key}”) to check the status of a customer data key. As discussed above, exemplary customer data keys may have a “pending”, “approved”, or “revoked” status. Thus, if a “pending” status is returned for this GET call, this indicates that the customer data key has been issued but the customer still needs to approve the key before use. If an “approved” status is returned this indicates that the customer data key is valid for use. If a “revoked” status is returned this indicates that the customer or institution has revoked permissions for a key. Such a service may also return an appropriate CustomerDataKey structure.

Another non-limiting service may get customer data. Such a service, as it accesses customer-specific data, would require an active CustDataKey to be provided. An exemplary service may use a GET call (e.g., “/v1/me”) to obtain customer personal data specific to the CustDataKey passed on the call. This may include a variety of fields such as, but not limited to, name, email, contact information, phone numbers (work, cell, home, etc.), addresses, and so forth, contained in a person structure as shown in. In one embodiment, the address fields may include sub-structures having additional fields such as, but not limited to line1, line2, line3, line4 (each a line of the address), city, state, and zip as illustrated in. Of course, these fields, structures and sub-structures are exemplary only and should not limit the scope of the claims appended herewith.

Another exemplary service may get an account list. Again, as this information is specific to a customer the service would require an activated CustDataKey. Such a service may use a GET call (e.g., “/v1/accounts”) to obtain a list of accounts owned by the customer whose customer data key is passed on the call. The service may return a JSON array of account structures, where an account structure may include fields such as, but not limited to, accountNumber (a string containing the account number for the account), nickName (a string containing the nickname that the customer has assigned to the account, if any), type (account type), balance (official ledger balance of the account), availableBalance (official available balance on the account), accountDescription (a string containing a description of the account type), and url (the URL for accessing specific details about the respective account) as shown in. Again, these fields and structures are exemplary only and should not limit the scope of the claims appended herewith.

An exemplary get account details service may use a GET call (e.g., “/v1/accounts/{accountNo}”) to obtain details about a particular account specified in the URL and owned by the customer whose customer data key is passed on the call. This example illustrates that in some cases it may be desirable to verify that requested data (the account number in this case) is appropriate to the customer whose CustDataKey is being used, e.g., if an account number is passed which was not owned by the customer to whom the CustDataKey was issued, the service may issue an error instead of valid data. The service may return an account object which may include exemplary fields such as account number, nickname, account balance, available balance and the like as depicted inand described previously.

An exemplary get transactions service may use a GET call (e.g., “/v1/accounts/{accountNo}/transactions”) to obtain a list of recent transactions for a particular account, specified by account number in the URL and owned by the customer whose customer data key is passed on the call. This service may return a JSON list of transaction structures which may, for example, include a transaction structure with fields such as, but not limited to, transactionId (a unique string to identify transactions), date (date on which the transaction occurred), description (text that describes the transaction, e.g., “Electronic Payment to Capital One”, “Debit Card Purchase-AMAZON MKTPLACE PMTS AMZN COM BIL WA”, etc.), amount (amount of the transaction in dollars), type (a string describing the type of transaction, e.g., “ATM”, or “Bill Payment”, etc.) as shown in. Furthermore, these get transactions services may utilize query parameters or other ways to allow the caller to control what transactions are returned. For example, a count parameter may be used to control the number of transactions to return, a startAfter parameter may specify which page of results should be returned, and a direction parameter may be used to specify whether earlier transactions or later transactions are returned. Of course, these query parameters are exemplary only and should not limit the scope of the claims appended herewith as any number or combination of parameters may be used to control what information or data is returned for a customer for any of the services described herein.

is a flow diagram describing, in general terms, one embodiment of the present subject matter. With reference to, a method is provided for controlled application access to a system. A customermay install at stepan application on a device depicted inor sign up via a website for a specific service offered by an institution. Upon first use of the application by the customer, the application or servicemay provide a setup screenwhich prompts the customer to enter his or her user identification or “UserID” at step. Upon entry of the UserID from the customer, the application or servicemay invoke a service offered by an institution at stepto issue a customer key. The providerof the API, generally the respective institution, may then create a new customer key at stepand send the same to the application or serviceusing a processor, server or the like. The application or servicewould store the customer key at stepin a storage medium resident on the device, on the servers providing the service, in a customer-specific data file, or otherwise. In one embodiment, the application or servicemay provide a prompt to the customerto log into an appropriate websiteto activate the customer key. The customermust now perform an out-of-band authentication, that is, must log onto the provider's system (likely a website) in a separate and distinct transaction, at step, and perform the standard login procedure which may include additional security measures such as multi-factor authentication, tokens, customer identifications, and the like (e.g., know-your-customer (KYC) queries). A web sessionmay then be initiated whereby the institution informs the customerthat a specific application is requesting access and what services, data, and records may be accessed. The web session then queries the customerwhether such access should be granted or rejected. In the event the customergrants access, at step, the institution may activate the customer key by communicating with the providerof the API and setting the status thereof to “active” at step. At this point the web sessionhas been completed and the customermay subsequently utilize the application or service.

Subsequently, the customermay use the application or service at step. The application or serviceuses the customer key stored on the device at stepand invokes a specific service to perform a respective function. The provider of the APIwill verify that the customer key exists and is active at stepand will perform the requested function at stepif it does exist and is active, performing the requested action or providing the results of the requested function to the application for display or otherwise to the customer.

is a flow diagram of another embodiment of the present subject matter. With reference to, a method is provided for controlled application access to a system. A customermay install at stepan application on a device depicted in. Upon first use of the application by the customer, the application, may provide a setup screenwhich prompts the customer to enter his or her user identification or “UserID” at step. Upon entry of the UserID from the customer, the applicationmay, in this embodiment, send a POST call to “/v1/customerKeys” at step, to an API Management Platform comprised, in this example, of Apigee (a commercially available API management tool) and PublicAPI (a custom-built API platform component). The API Management Platformmay then invoke a service offered by an institution at stepto issue a customer key by invoking a service—in this example calling a SOAP service provided by a DGW middleware server. In one embodiment, the API Management Platformand middle-ware servermay be the same system or on separate systems and may be resident on a processor, server, etc. of the respective institution or hosted elsewhere. The provider of the API, may then create a new CustomerKey at stepand send the same to the application. The applicationmay store the customer key at stepin a storage medium resident on the device or otherwise. In this embodiment, the application or servicemay provide a prompt to the customerto log into an appropriate websiteto activate the customer key. The customermust now go out-of-band, that is, must log onto the websitein a separate and distinct transaction, at step, and perform a standard login procedure using additional security measures such as multi-factor authentication, phishing-resistant customer identifications, and similar techniques (e.g., “out-of-wallet” questions). A web sessionmay then be initiated during which the institution informs the customerthat a specific application is requesting access, identifies what services or data the application will be permitted to access if activated, and queries the customerwhether such access should be approved or rejected. In the event the customergrants access, at step, the institution may activate the customer key by communicating with the serverand setting the status of that particular customer key to “active” at step. Upon setting such status, the websitemay provide an appropriate indication of the status to the customer. At this point the web sessionhas been completed and the customermay subsequently utilize the application to perform actions that require the APIs.

The customermay then subsequently use the application at stepwhereby the applicationuses the customer key stored on the device at stepand sends, for example, a GET call (“/v1/accounts”) to the API Management Platform. The API Management Platformmay request a customer key status from the middleware serverwhich then verifies whether the customer key exists and is active at step. If the customer key does not exist or is not active, then the Platformmay return an error to the application; if the customer key does exist and is active then the platformmay then request the specific function (getting accounts in this example) from appropriate services in step. Any results may then be provided to the applicationfor display to the customeror otherwise. As noted above, the API Management Platformand middle-ware servermay be the same and thus several described intermediate steps above may be simplified. Additionally, several separate calls may be required to fulfill a particular request so an actual implementation may be more complex than described here.

is a simplified block diagram of one embodiment of the present subject matter. With reference to, a methodis provided for accessing data of a user. At step, the method may include issuing an application key specific to an application resident on a device and then creating a customer data key at stepby a server, the customer data key specific to the application, to a single user of the application, and to the particular installation of the application. The term device may include devices described above in reference tobut may also include servers and the like. Of course, other embodiments of the present subject matter may not include stepas noted by the dashed line connecting stepsand, and the claims appended herewith should not be so limited. Exemplary information may be data of a user or services provided by an entity. For example, data may be, but is not limited to, financial data, confidential data, account data, personal data, sensitive data, and combinations thereof. Further, an exemplary device may be, but is not limited to, a microprocessor-based computer terminal, a mobile device, a pager, a kiosk, a personal digital assistant, a cellular phone, a tablet, an electronic personal planner, and a smart phone. Services may be, but are not limited to, transferring data, transferring funds, getting account information, displaying account information, modifying account balances and other account information, displaying personal information, modifying personal information, obtaining a financial analysis, payment of debt, depositing funds, opening accounts, and combinations thereof. In one embodiment, the methodmay further include monitoring or limiting access to the data as a function of the number of API calls made using the issued application key (“rate limiting”). In the event that a predetermined number of API calls have been made for the application, subsequent calls from that application would not be executed. In another embodiment, either the end user or the owner of the application may be charged an appropriate fee for each API call made, and the customer data key may be used to track this and produce appropriate billing records.

At step, the customer data key may be returned to the application via an API call. At step, the user may be required to conduct a separate transaction to access the data. In this separate transaction, the customer data key may be activated at stepand at step, access to the data using the activated customer data key may be authorized. In one embodiment, stepmay be performed by a website server and/or may include associating the customer data key with a status indicator such as, but not limited to, pending, active, or revoked. In another embodiment stepmay include authenticating the user and verifying that the customer data key is valid with respect to the application, the user of the application, and the device upon which the application resides. Such an authentication may require the user to enter a personal identification number, to enter a password, to confirm answers to one or more predetermined questions, and combinations thereof.

is a simplified block diagram of another embodiment of the present subject matter. With reference to, a methodis provided for allowing a user access to a service provided by an entity. An exemplary entity may be, but is not limited to, a financial institution and the like. At step, the method may include issuing an application key specific to an application resident on a device and then creating a customer data key at stepby a server, the customer data key being specific to the application, to the user of the application, and to the specific installation of the application. The term device may include devices described above in reference tobut may also include servers and the like. Of course, other embodiments of the present subject matter may not include stepas noted by the dashed line connecting stepsand, and the claims appended herewith should not be so limited. Exemplary information may include data of a user or services which include, but are not limited to, transferring data, transferring funds, getting account information, displaying account information, modifying account balances, displaying personal information, modifying personal information, obtaining a financial analysis, payment of debt, depositing funds, opening account, and combinations thereof Further, an exemplary device may be, but is not limited to, a microprocessor-based computer terminal, a mobile device, a pager, a kiosk, a personal digital assistant, a cellular phone, a tablet, an electronic personal planner, and a smart phone. In one embodiment, the methodmay further include monitoring or limiting access to the service as a function of the number of API calls made using the issued application key (“rate limiting”). In the event that a predetermined number of API calls have been made for the application, subsequent calls from that application would not be executed. In another embodiment, either the end user or the owner of the application may be charged an appropriate fee for each API call made, and the customer data key may be used to track this and produce appropriate billing records.

At step, the customer data key may be returned to the application via an API call. At step, the user may be required to conduct a separate transaction to access the service offered by the institution. In this separate transaction, the customer data key may be activated at stepand at step, access to the service using the activated customer data key may be authorized. In one embodiment, stepmay be performed by a website server and/or may include associating the customer data key with a status indicator such as, but not limited to, pending, active, or revoked. In another embodiment stepmay include authenticating the user and verifying that the customer data key is valid with respect to the application, the user of the application, and the device upon which the application resides. Such an authentication may require the user to enter a personal identification number, to enter a password, to confirm answers to one or more predetermined questions, and combinations thereof.

While portions of this disclosure have been described with reference to a financial institution, this should not limit the scope of the claims appended herewith, as the present subject matter may find utility in many different instances where it is necessary to secure an API protecting individual customer data independently of other customers and/or where it is desirable to leverage the enhanced security of a separate, pre-existing authentication mechanism for initial setup. For example, a mobile device application may employ a banking API whereby an initial setup would occur when the application was installed and run for the first time on the device. The customer would then log onto his or her bank's website to activate the customer key (using the enhanced security of the bank's login). Thereafter, the application may use the API normally. Another example would be a web application offering financial analysis which employs a brokerage API whereby an initial setup would occur when the user first specified to the web application that he or she wanted to analyze funds invested through that brokerage. The customer may then contact the broker to activate the customer key (using some form of enhanced security). Thereafter, the web application may poll the APIs nightly and perform its respective analysis. A further example may be a data backup program which employs a secure data storage API offered by a data storage company (a service where the customer controlled the data) whereby an initial setup would occur when the data backup program was installed. The customer may then log onto the data storage company's website to activate the customer key (using the enhanced security of that site's login). Thereafter, data backups may occur on demand or via schedule.

illustrates an example of an architecture of a computer processing unitconfigured to implement the algorithms and software programming associated with the present disclosure. This unit may be a standalone unit, may be a server or portion thereof. As illustrated in, the computer processor unitmay include one or more processors. The processormay be connected to a communication infrastructure(e.g., a communications bus, cross-over bar, or network). As discussed above, the computer processing unitmay include a display interface that forwards graphics, text, and other data from the communication infrastructure (or from a frame buffer not shown) for display on the front- and back-end GUIs,,and as retrieved from the one or more data storage devices,.

The computer processing unitmay also include a main memory, such as a random access memory (RAM), and a secondary memory. The secondary memorymay include, for example, a hard disk drive (HDD)and/or removable storage drive, which may represent a floppy disk drive, a magnetic tape drive, an optical disk drive, or the like. The removable storage drivemay read from and/or write to a removable storage unit. The removable storage unitmay be a floppy disk, magnetic tape, optical disk, or the like. As will be understood, the removable storage unitmay include a computer readable storage medium having stored therein computer software and/or data.

In alternative embodiments, the secondary memorymay include other similar devices for allowing computer programs or other instructions to be loaded into the computer processing unit. The secondary memorymay include a removable storage unitand a corresponding interface. Examples of such removable storage units include, but are not limited to, USB or flash drives, which allow software and data to be transferred from the removable storage unitto the computer processing unit.

The computer processing unitmay also include a communications interfaceallowing software and data to be transferred between computer processing unitand external devices. Examples of a communications interfacemay include a modem, Ethernet card, wireless network card, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. Software and data transferred via the communications interfacemay be in the form of signals, which may be electronic, electromagnetic, optical, or the like that are capable of being received by the communications interface. These signals may be provided to the communications interfacevia a communications path (e.g., channel), which may be implemented using wire, cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link and other communication channels.

The terms “computer program medium” and “computer readable storage medium” may generally refer to media such as a removable storage drive, a hard disk installed in a hard disk drive, etc. These computer program products may provide software to computer processing unit. Computer programs (also referred to as computer control logic) may also be stored in the main memory, secondary memoryand/or data storage devices,. Computer programs may also be received via the communications interface. Such computer programs, when executed by a processor, specifically enable the computer processing unitto perform features of the methods discussed herein. In an embodiment implemented using software, the software may be stored in a computer program product and loaded into computer processing unitusing a removable storage drive, hard drive, or communications interface. The software, when executed by a processor, causes the processorto specifically perform the functions described herein.

The present disclosure may be implemented by a general purpose computer or server programmed in accordance with the principals discussed herein. It may be emphasized that the above-described embodiments, particularly any “preferred” embodiments, are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiments of the disclosure without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present disclosure and protected by the following claims.

Embodiments of the subject matter and the functional operations described in this specification may be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Embodiments of the subject matter described in this specification may be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a tangible program carrier for execution by, or to control the operation of, data processing apparatus. The tangible program carrier may be a computer readable medium. As discussed above, the computer readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, or a combination of one or more of them.

The term “processor” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, server, or multiple processors, computers or servers. These apparatus, devices and machines may include (in addition to hardware) code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.