Account protection service based on edge network

Abstract

An account protection service for preventing abuse of user logins or other protected endpoint requests. In one embodiment, the service collects user identification data, preferably for each login attempt (e.g., data about the connection, session, and other relevant context), and it preferably uses the identification data from successful logins to construct a real user profile for each such user over time. The profile evolves as additional identification data is collected from successful logins. The profile is a model of what the user "looks like" in the system. For subsequent login attempts, the system then calculates a real user score. This score represents how well the current user identification data matches the model represented by the real user profile. The user identification service is used to drive policy decisions and enforcement capabilities. Preferably, in a combined solution, user identification works in conjunction with robot detection.

Description

background Technical Field

[0001] The present application relates generally to network security, and more particularly to techniques for preventing takeover and abuse of user accounts.

[0002] Brief description of related technology

[0003] Distributed computer systems are well known in the prior art. One such distributed computer system is a "content delivery network" (CDN) or "overlay network" operated and managed by a service provider. The service provider typically provides content distribution services on behalf of third parties (customers) who use the shared infrastructure of the service provider. This type of distributed system typically refers to a collection of autonomous computers linked by one or more networks, together with software, systems, protocols, and technologies designed to facilitate various services (such as content distribution, web application acceleration, or other support for outsourced source site infrastructure). CDN service providers typically provide service delivery through digital assets (such as websites), which are provided in a customer portal and then deployed to the network. Digital assets are typically bound to one or more edge configurations that allow the service provider to bill for traffic and charge its customers.

[0004] Account takeover on the Internet is a significant problem. There are known technologies and services that can solve this problem. For example, in the CDN field, Bot Managers help mitigate bot-driven credential abuse and account takeover attempts; while this type of solution offers significant advantages, they do not address human-driven account takeovers. Therefore, when there is a trust issue, for example, when the user's password itself is stolen in an account takeover attack, the bot detection system cannot necessarily determine that the authenticated user is who they claim to be. In this case, step-up authentication can be useful, but there is still a need for an enhanced solution to the problem.

[0005] Brief Overview

[0006] The content distribution network is enhanced to include a "user identification" (sometimes referred to herein as "account protection") service to prevent abuse of user login or other protected endpoint requests, which is preferably associated with a robot detection system. User identification as used herein refers to a term that identifies the characteristics of a user not necessarily (or only) based on the provided user identifier and credentials, but also based on one or more other features. In one embodiment, the service collects user identification data, preferably for each login attempt (e.g., data about connections, sessions, and other relevant contexts), and it preferably uses the identification data from successful logins to construct a true user profile for each such user over time. Preferably, the profile evolves as additional identification data is collected from successful logins. Therefore, the true user profile is a model of what the user "looks like" in the system. For subsequent login attempts, the system then calculates a true user score. This score represents the degree of match between the current user identification data and the model represented by the true user profile. Preferably, the user identification service is used to drive different policy decisions and enforcement capabilities. Thus, for example, for account protection services, user identification facilitates implementation of a policy-driven security model, e.g., as a policy decision point (PDP) that determines what action to take on an authentication attempt, and auxiliary control by a policy enforcement point (PEP) that implements the policy decision. Preferably, user identification such as described above works in conjunction with bot detection in a combined solution.

[0007] Some of the more relevant features of the subject matter have been outlined above. These features should be interpreted as being merely illustrative. Many other beneficial results can be obtained by applying the disclosed subject matter in a different manner or by modifying the subject matter to be described. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] For a more complete understanding of the subject matter and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0010] Figure 1 is a block diagram illustrating a known distributed computer system configured as a content delivery network (CDN);

[0011] Figure 2 This is a representative CDN edge machine configuration;

[0012] Figure 3 Depicts a representative client machine interacting with an origin server via a content delivery network;

[0013] Figure 4 is a high-level description of a user identification service that provides real-time fake user detection according to the techniques of this disclosure;

[0014] Figure 5 A logical diagram depicting the components and their connections in the first use case;

[0015] Figure 6A-6B Depicted Figure 5 A sequence diagram of the operations of the architectural components shown in ;

[0016] Figure 7 A logical diagram depicting the components and their connections in the second use case;

[0017] Figure 8A-8C Depicted Figure 7 A sequence diagram of the operations of the architectural components shown in ;

[0018] Fig. 9 A logic diagram depicting the components and their connections in a third use case;

[0019] Figures 10A-10D Depicted Fig. 9 A sequence diagram of the operations of the architectural components shown in ;

[0020] Fig.11 depicts an alternative embodiment of an architectural solution for providing a bot management detection service associated with an account protection service; and

[0021] Figure 12A-12B Depicts a period during a user login to a protected endpoint Fig.11 A sequence diagram of the interactions between components.

[0022] Detailed Description

[0023] In such Figure 1In the known system shown in , a distributed computer system 100 is configured as a content delivery network (CDN) and is assumed to have a group of machines 102 distributed on the Internet. Typically, most of the machines are servers located near the edge of the Internet (i.e., located at or adjacent to the end-user access network). A network operation command center (NOCC) 104 manages the operation of various machines in the system. Third-party sites such as websites 106 offload the distribution of content (e.g., HTML, embedded page objects, streaming media, software downloads, etc.) to the distributed computer system 100, and in particular to the "edge" servers. Typically, content providers offload their content distribution to a domain managed by the authoritative domain name service of the service provider by aliasing (e.g., by DNS CNAME) a ​​given content provider domain or subdomain. End users who expect content are directed to the distributed computer system to obtain the content more reliably and efficiently. Although not shown in detail, the distributed computer system may also include other infrastructure, such as a distributed data collection system 108 that collects usage and other data from edge servers, aggregates data across a region or a group of regions, and transmits the data to other backend systems 110, 112, 114, and 116 to facilitate monitoring, logging, alerting, billing, management, and other operational and management functions. A distributed network proxy 118 monitors the network and server loads and provides network, traffic, and load data to a DNS query processing mechanism 115 that is authorized for content domains managed by the CDN. A distributed data transmission mechanism 120 may be used to distribute control information (e.g., metadata for managing content, facilitating load balancing, etc.) to edge servers.

[0024] like Figure 2 As shown in FIG, a given machine 200 includes commodity hardware (e.g., Processor) 202, the operating system kernel 204 supports one or more applications 206. To facilitate content delivery services, for example, a given machine typically runs a set of applications such as an HTTP proxy 207 (sometimes called a "global host" (gHost) process), a name server 208, a local monitoring process 210, a distributed data collection process 212, and the like. HTTP proxy 207 serves web objects, streaming media, software downloads, and the like. CDN edge networks running this type of machine support HTTP Adaptive Streaming (HAS), which uses standard HTTP servers and TCP to deliver content, allowing the CDN to leverage the full capacity of its HTTP network to deliver streaming content, rather than relying on a smaller network of dedicated streaming servers. The two dominant HAS formats are HTTP Live Streaming (HLS) and MPEG DASH. HLS traditionally uses TS containers to store multiplexed audio and video data, while DASH is preferred to ISO-based media file formats that store demultiplexed audio tracks. Therefore, content owners who want to achieve device diversity must package and store two sets of files, each of which stores exactly the same audio and video data. To address this inefficiency, the Common Media Application Format (CMAF) was developed in 2017. CMAF is a restricted version of the mature fragmented mp4 container and is similar to the DASH-ISO file format. CMAF is a standardized container that can store video, audio, or text data. CMAF is efficient because CMAF-encapsulated media segments can be referenced by both HLS playlists and DASH manifests. This enables content owners to package and store a set of files.

[0025] The CDN edge servers are configured to preferably use a configuration file distributed to the edge servers using a configuration system, preferably on a domain-specific, customer-specific basis, to provide one or more extended content delivery features. A given configuration file is preferably XML-based and includes a set of content processing rules and instructions that facilitate one or more advanced content processing features. The configuration file can be delivered to the CDN edge server via a data transfer mechanism. U.S. Patent No. 7,111,057 shows a useful infrastructure for delivering and managing edge server content control information, and this and other edge server control information can be provided by the CDN service provider itself, or (via an extranet, etc.) by a content provider customer operating an origin server.

[0026] The CDN can provide secure content delivery between client browsers, edge servers, and customer origin servers in the manner described in U.S. Publication No. 20040093419. As described herein, secure content delivery implements SSL-based links between the client and edge server processes on the one hand and between the edge server processes and the origin server processes on the other hand. This enables SSL-protected web pages and / or components thereof to be delivered via the edge servers.

[0027] As an overlay, CDN resources can be used to facilitate wide area network (WAN) acceleration services between an enterprise data center (which may be privately managed) and a third-party software as a service (SaaS) provider.

[0028] In typical operation, a content provider identifies a content provider domain or subdomain that it expects to be served by a CDN. The CDN service provider (e.g., by a canonical name or CNAME) associates the content provider domain with an edge network (CDN) host name, and the CDN provider then provides the edge network host name to the content provider. When a DNS query for a content provider domain or subdomain is received at the content provider's domain name server, those servers respond by returning the edge network host name. The edge network host name points to the CDN, which is then resolved by the CDN name service. To this end, the CDN name service returns one or more IP addresses. The requesting client browser then makes a content request (e.g., via HTTP or HTTPS) to the edge server associated with the IP address. The request includes a host header containing the original content provider domain or subdomain. Upon receiving a request with a host header, the edge server checks its configuration file to determine whether the requested content domain or subdomain is actually being processed by the CDN. If so, the edge server applies its content processing rules and instructions for the domain or subdomain as specified in its configuration. These content handling rules and instructions may reside within XML-based "metadata" configuration files.

[0029] like Figure 3 As shown, in a typical interaction scenario, an end-user client browser or mobile application 300 is associated with a customer origin server (or "origin") 302 via the intermediary of an overlay network edge machine server instance 304 (sometimes referred to as an "edge server"). The terms "origin" or "edge" are not intended to be limiting.

[0030] Content distribution networks such as those described above can provide robot detection. A representative approach is described in U.S. Publication No. 2019 / 019950, assigned to the assignee of the present application, and the disclosure of which is hereby incorporated by reference. In related methods, (such as Figure 2) overlay network edge server interacts with a robot detection service to provide active robot detection when a requesting client interacts with the overlay network edge server. In a typical interaction, when a session between a requesting client and an overlay network edge server is initiated, the edge server sets a long-term cookie and a short-term cookie associated with returning a page (typically a basic HTML page) to the requesting client. In an asynchronous mode of operation, the edge server injects a reference to a data collection script into the page. The script is configured to record one or more interactions at the requesting client, collect sensor data about the interaction, and send the collected sensor data from the requesting client back to the edge server. After the client receives the page and instantiates the script locally, the sensor data is collected and forwarded back to the edge server via a series of automatic posts (e.g., POST requests in JSON format), where a particular post is typically associated with a behavioral action that occurs locally at the requesting client. The edge server then forwards these posts onward to the robot detection service (via a service API) to enable the service to assess whether the requesting client is a human or a robot. During this asynchronous mode of data collection, the edge server can then receive requests for protected endpoints. When this occurs, and in a synchronous mode of operation, the edge server issues a query to the bot detection service to obtain a threat score associated with the requesting client. The threat score is typically based at least in part on the collected sensor data received and forwarded by the edge server. The edge server receives the threat score from the bot detection service. Based at least in part on the threat score received in response to the query, the edge server then determines whether the request for the endpoint should be forwarded onward for processing, typically by an origin server hosting the protected endpoint.

[0031] This style of bot detection works well, although it takes time to collect telemetry and decide if the requesting entity is a bot. False positives are also resource inefficient.

[0032] It is also assumed that the CDN has some basic ability to identify account owners and provide access decisions based on this identification. In particular, this type of system has the ability to determine that it has seen a particular user before, typically based on data held by the system that allows such identification, and this is true regardless of whether the system also knows the user's actual identity (who he or she claims to be). A representative system of this type is Identity Cloud, which provides a secure, seamless, and scalable customer identity and access management (CIAM) service. The service provides a wide range of authentication methods, including social media login, directory services, and OpenID Connect (OIDC), role-based and attribute-based access control (RBAC and ABAC), and risk-based and multi-factor authentication options for secure access and single sign-on (SSO) across an ecosystem of clients. Preferably, the service is cloud-native, and it is provided as a service (i.e., SaaS) solution (in association with one or more other CDN services). Therefore, it is designed to be an intelligent extension to ensure that customer registration, authentication, and SSO functions are always available and executed with the lowest latency. Both customer API-based implementations and SDK-based implementations are supported to facilitate rapid deployment.

[0033] User identification and identification are different structures, and preferably both are necessary to prevent login (credential) abuse or fraud. In particular, the system can produce identification results with low confidence (in other words, the actual identity of the user is unknown), but the user can still provide valid credentials. Similarly, the system can produce recognition results with high confidence (in other words, the system has seen the user before), but does not necessarily know who the user is. The preferred method for allowing access to protected resources is that the system only does so when it has a high (or at least some sufficient) confidence, that is, it can both identify who the user is and recognize that it has seen the user before.

[0034] With the above content as the background, the technology of the present disclosure is now described.

[0035] User Identification / Account Protection

[0036] According to one embodiment of the present technology, the system extends the CIAM service to provide additional user identification functionality. The user identification service determines whether the entity attempting to log into the account is the real user who owns the account, or whether it is sufficiently "different" from the real user, so that the system should take some mitigation or verification action. Preferably, a real user profile is constructed for each user. This is a statistical profile of real users collected over time and updated regularly based on successful logins. Preferably, only data from successfully authenticated user sessions is compiled into the real user profile. For each login attempt, user identification data is collected. Preferably, this is a set of data that includes session, connection and context data for identifying the user. Preferably, the data is collected by the edge server, using a script injected into the login session (e.g., JavaScript (JS)) and CIAM service or other means. Preferably, the system calculates the real user score in real time. This is the match score between the user identification data (URD) ​​of the session and the real user profile (TUP) for a given user (UUID). Preferably, the real user score is normalized to a range of 0 to 10 (or 1 to 100). A score of 0 means that there is essentially no match between the URD and TUP for the current session. In this scoring embodiment, a score of 10 (or 100) means that there is a strong match between the URD and TUP for the current session. Based on the score, the system can then take appropriate actions, such as blocking (or challenging, or slowing down, etc.) the ability of any entity (when presented to the customer login page) that is not sufficiently "similar" to the real user.

[0037] Advantageously, the above-mentioned user identification method can be used in combination with robot detection. This enables the system to reduce the false negatives of robot detection. In particular, it is known that robot developers continue to improve their software to avoid being detected as robots. They achieve this by experimenting to make their software behave more like humans (matching real browser headers, human-like mouse / device movement and keystroke rhythm, trial and error, etc.). In doing so, they compare their software with real humans (any humans) for verification or training. In other words, one thing they can't do is train their software to act like a specific human, let alone the user whose credentials they are trying to destroy. As the user identification model improves, each real user will look more obvious, making it increasingly difficult for robot developers to stumble upon the right combination of user features when trying to destroy user credentials. Even if the robot can avoid standard robot detection and present the correct credentials, user identification (as provided herein) will still detect imposters, block access, and provide the robot detection system with a false negative feedback loop that can be used to improve its own algorithm.

[0038] Figure 4 Describes the combined techniques used in the operation of this embodiment. Systems / services identified by commercial name ( Identity Cloud, The robot manager) is merely exemplary and not intended to be limiting. In step (1), a user initiates a login request. In step (2), the identity cloud (CIAM service) provides services for the login and collects user data (as explained in more detail below). In step (3), the identity cloud performs user identification as provided herein. In step (4), the robot manager (robot detection service) identifies the robot. In step (5), the user reaches the login page (when no login fraud is detected) or is rejected (when potential login fraud is detected). According to the methods of this article, the real user score enables the CIAM (or other) service to measure end-user risk.

[0039] There are several possible implementation approaches (use cases), several of which are now described. Typically, the solution assumes a CDN implementation, where a CIAM service is used to provide managed login for CDN customers' applications (as an identity provider); preferably, the CDN also provides edge-based application security services such as Kona TM Site Defender, which further protects the customer's applications. Kona Site Defender provides a variety of technologies to protect applications, such as web application firewall (WAF), distributed denial of service (dDoS) attack mitigation, etc. As used herein, CIAM services distributed through CDN and protected by Site Defender are sometimes referred to as security edges. As described below, it is not required to implement the techniques herein (e.g., involving CIAM services) in this specific use context.

[0040] In the first use case, the system performs and uses initial (preliminary) data collection. A workflow is shown below, and Figure 5As shown. An entity 500 claiming to be a permitted user of the application attempts to log in to an application that uses the CDN's CIAM service (hosted login) as its identity provider. The user selects traditional login and submits his or her username and password to component 502. The security edge 504 receives the client request and extracts a set of connection attributes. The security edge sends the attributes to the user identification service 506, and it also forwards the login request to the login component 508 of the CIAM service to determine whether the login is recognized. The login component makes a judgment and sends the login result back to the client via the security edge. The security edge detects the login status and sends it (status) back to the user identification service 506, and it also returns the login result to the client 500. The client then either displays a login failure message or completes the authentication, for example, by sending an access token to the hosted login and following the rest of the usual authentication process.

[0041] Figure 5 A logical diagram of the components and their connections in a first use case is depicted; in this embodiment, the service is provided through a service architecture that includes (in this example) a load balancing component 510 and a gateway component 512. The user identification service includes an ingress component 514, a database 516, and an analysis component for scoring 518. In this example, all of these components can be accessed by edge servers in a cloud service (here designated as an identity cloud). Figure 6A-6B Depicted Figure 5 An operational sequence diagram of the architectural components shown in , where sites represent service client sources.

[0042] In the second use case, if the client user agent runs a script (e.g., JavaScript), additional data is also collected from the agent. A workflow is as follows. An entity claiming to be a permitted user of the application attempts to log in to an application that uses the CDN's CIAM service (hosted login) as its identity provider. The security edge detects the CDN client and causes the user identification service script to be downloaded along with the rest of the page component that hosts the login. The script asynchronously or synchronously collects device and user agent specific attributes for user identification and sends them to the user identification service via the security edge. The user selects traditional login and submits his or her username and password. The security edge receives the client request and extracts a set of connection attributes. The security edge sends the attributes to the user identification service, and it also forwards the login request to the CIAM's login component ("capture") to determine whether the login is recognized. The login component makes a judgment and sends the login result back to the client via the security edge. The security edge detects the login status and sends it (status) back to the user identification service, and it also returns the login result to the client. The client then either displays a login failure message or completes authentication, for example, by sending a captured access token to the hosted login and following the rest of the usual authentication process.

[0043] Figure 7 Describes the logic diagram of the components and their connections in the second use case above; the components here are similar to Figure 5 Corresponding to the components in . Figure 8A-8C Depicted Figure 7 A sequence diagram of the operations of the architectural components shown in .

[0044] In a third use case, a previous successful login is used to generate a True User Profile (TUP), and the user or imposter now logs in. In this embodiment, and as Fig. 9As shown, the user identification service 906 includes a scoring service 907 and a true user profile (TUP) generator 909 that generates a user profile 911. In this embodiment, the system collects attributes about the device, user agent, and session, and uses the scoring service 907 to calculate a true user score (TUS). The score will then enable a policy-based decision on whether to allow access to the login attempt. A workflow is as follows. An entity 900 claiming to be a user of the application attempts to log in to an application 903 that uses the CDN's CIAM service (hosted login 908) as its identity provider. The security edge 904 detects the CDN customer and causes the user identification service script to be downloaded along with the rest of the page components that host the login. The script asynchronously or synchronously collects device and user agent specific attributes for user identification and sends them to the user identification service 906 via the security edge 904. The user selects traditional login 902 and submits his or her username and password. The security edge 904 receives the client request and extracts a set of connection attributes. The security edge 904 sends the attributes to the user identification service, and it also forwards the login request to the login component 908 of CIAM to determine whether the login is recognized. The login component 908 makes a judgment and sends the login result back to the client via the security edge 904. The security edge detects the login status and sends it (status) back to the user identification service, and it also returns the login result to the client. Then, the client either displays a login failure message or continues the authentication by sending a captured access token to the hosted login. If the username and password are correct, the client is redirected to the OpenID Connect (OIDC) token endpoint 913 with the authorization code. The OIDC token endpoint 913 looks up the real user score (TUS) for this login session. If the score is better than the risk threshold, a token is issued and the client logs the user in to the website; if the score is worse than the risk threshold, a token is not issued and the client is redirected to the failure page. In both cases, the client preferably accesses the application programming interface (API) to find the reason for the real user score.

[0045] Fig. 9 A logical diagram depicting the components and their connections in the above use case; Figures 10A-10D Depicted Fig. 9 A sequence diagram of the operations of the architectural components shown in .

[0046] The following describes data collection that can be implemented in one or more of the above use cases.

[0047] Preferably, edge server (or "edge") data collection collects information specific to HTTP requests, which may differ between users, user agents, or devices. This may include, but is not limited to, the client's geolocation, user agent headers, and TLS fingerprints. Preferably, this information does not include data that is not client request specific, such as the current CPU load on the edge server. Preferably, edge data collection and forwarding to the user identification service does not increase request processing time by more than a predetermined (low) percentage value, and preferably, edge data collection does not change the response sent to the user. In addition, preferably only data from traditional logins is collected.

[0048] Client data collection refers to data collected directly at the client using JavaScript (JS) or other methods. Preferably, client data collects attributes such as screen orientation, browser plug-ins, local time zone, etc. Client data collection must be sensitive to and comply with privacy regulations, and it should not affect authentication or other request flows. As described above, client data collection is preferably performed through the edge, whether implemented in the existing HTTP request flow or in a separate asynchronous request.

[0049] When the data model ( Fig. 9 , 915) is implemented, the output of the data modeling process preferably includes a definition of how to store, accumulate and expire data, i.e., a True User Profile (TUP), which can be used with the model and kept up-to-date across successive user logins. The data modeling process also outputs a model (algorithm and weights) that can compare the user identification data of the current authentication request with the TUP in order to calculate the TUS.

[0050] Preferably, when implemented, a True User Profile (TUP) includes an indicator of whether sufficient data has been collected for the TUP to be considered useful for generating a True User Score (TUS). Preferably, the TUP includes only data from successful authentication events, including whether the TUS was sufficiently trustworthy at the time of authentication. Preferably, the TUP is interpretable, e.g., which user identification data attributes are consistent with the TUP and which are deviating. Furthermore, the TUP preferably supports both frequent and infrequent users.

[0051] In implementation, the TUS is preferably instantiated as a simple numeric value (for policy decisions). As described above, the TUS preferably has associated information that can be used to explain which parts of the user identification data are consistent with the TUP and which parts deviate and by how much. Example data points include, but are not limited to: current TUS relative to the last 5 TUS and their policy decisions, sample location data relative to previously seen locations, user agent data relative to previously seen user agents, time of day relative to previously seen time, etc. Preferably, the TUS is calculated in real time so as not to slow down the login process.

[0052] Preferably, the threshold between trusted and untrusted TUS is configurable.

[0053] Preferably, policy enforcement is configurable.

[0054] Preferably, when the TUS is not trustworthy (worse than a threshold), preferably no identification, access or refresh tokens are issued.

[0055] As previously described, the distribution configuration at the CDN edge can be used to coordinate the collected data to be stored and used in the initial data modeling and to facilitate TUS calculations based on the collected data. Fig. 9 ), policy decisions and enforcement are implemented in a wrapper for the OIDC token endpoint. Figure 5-6B ), data collection happens right at the edge of initial data modeling. Figure 7-8C ), deploying hosted login to a secure edge also delivers JavaScript (JS) to the browser to collect additional data from the client. In the second use case, a script tag is injected on the HTML page hosting the login, and telemetry information for that script is obtained from subsequent requests. The script is used to obtain user agent and device specific data. The client data adds useful diversity to the data to enable user identification services to better identify when authentication appears to be coming from someone other than the real user.

[0056] In the third use case above ( Figure 9-10D), a user identification model based on the data collected (from the edge and the client) is generated. A service is provided to generate a real user profile based on the collected attributes and the user identification model. A repository is provided to store the real user profile. A service is provided to generate a real user score based on the real user profile, the attributes of the current request, and the user identification model. Preferably, a token endpoint wrapper is provided, which checks the TUS and applies a policy-based decision to obtain an OIDC token only when the score is good enough. In one embodiment, the token endpoint wrapper provides a bridge or proxy between the OIDC token interface of the managed login and the user identification scoring service; outside the client, it exposes a token endpoint. It receives an authorization code from the client and exchanges the code for a set of tokens (identification, access, refresh) on behalf of the client using the real managed login token endpoint. Preferably, the wrapper does not exchange the code for a token without first requesting a score for the authentication session from the scoring service. It does this by calling an endpoint of the scoring service (e.g., on a secure edge) and looking up the score for a specific session ID. A "code challenge" can be used as the session ID. The token request comes from a client with a "code verifier", so the token endpoint wrapper must compute the code challenge from the verifier and use it as the session ID in the score lookup. Preferably, the token endpoint wrapper is the policy decision point (PDP), making the decision as to whether the score is high enough to proceed with the code for token exchange. As also noted, the mechanism also preferably retrieves the TUS reason when the login succeeded or failed, and presents the information visually if appropriate.

[0057] The scoring service exposes an endpoint on which it receives requests to retrieve scores, retrieves attributes of the current authentication event, retrieves the profile of the currently authenticating user (from the profile store), calculates the score according to the TUS algorithm, returns the score, and preferably returns data on how the scoring decision was made on the same endpoint.

[0058] The techniques described above provide significant advantages. One advantage is that the approach leverages CDN information for risk analysis. Most CIAM and authentication services rely on data collected from clients or information received directly from their offline authentication services for risk determination. However, clients increasingly use plugins like ublock and other JS restrictions to block data collection; furthermore, even in the cloud, performance and scalability are impacted if such services are not distributed via a CDN, which (by its nature as an application-level proxy) will also obscure key risk factors on the client side. The solution herein collects key risk factors about the client at the CDN edge and contributes them to the risk engine of the CIAM server for full fidelity risk determination. The approach enables the CIAM service and / or risk engine to actually run at the edge, providing the best of both worlds. Furthermore, user identification as described reduces false negatives for bot detection. The better the UR (user identification) model, the more each user will behave differently, making it increasingly difficult for bot developers to stumble upon the right combination of user characteristics when attempting to compromise user credentials. Leveraging the power of user identification, even if a bot can evade standard bot detection and present correct credentials, user identification can detect an imposter, block access, and provide a false negative feedback loop for the bot detection system that it can use to improve its algorithms. This approach is also advantageous because it enables risk-based authentication to be applied to social logins. In particular, user identification can add a layer of security on top of social logins. While traditional authentication services focus on their users and strengthen their identity authentication, the above-mentioned CIAM services can combine user identification with the determination of a true user score, independent of whether the user authenticates against the CDN directory. This further provides a unique way to strengthen the level of assurance on social identities. It also opens up new opportunities for leveraging social identifiers in financial services institutions and other higher security environments.

[0059] Although described and depicted in the example scenarios above, the techniques herein are not dependent on a CIAM system, or even on implementations within or associated with a CIAM system. The real user score is useful for any edge-driven policy decision, CIAM policy decision, or source policy decision. Furthermore, in addition to being associated with a login to an endpoint, the real user score can also be calculated for a request to a resource. Other implementations may utilize the score via the application's session ID, via an identifier in an OpenIDConnect or OAuth2 access token, or other means.

[0060] Furthermore, the concept of "identification" described above is not intended to be limiting per se. By inverting the score (eg, in a range of 0 to 100), it becomes a risk score (as opposed to an identification score), where the highest value (eg, 100) represents the most dangerous value.

[0061] Reference now Fig.11 , depicting another embodiment of the subject matter of this article. In this embodiment, the solution is implemented in an Infrastructure as a Service (IaaS)-based cluster 1100 with various components, and the method (together with robot detection) implements the concept of a "user risk" score. At a high level, the service calculates a user risk score and supporting evidence for a customer application endpoint, makes policy-driven decisions at the edge based on the score, and communicates the score and evidence to the customer in various forms for real-time and asynchronous fraud analysis and mitigation. This functionality is sometimes referred to herein as an account protection service to distinguish it from the robot detection service. Together, these services provide a fraud infrastructure.

[0062] For example, in one exemplary implementation, cluster 1100 supports a robot management system, e.g. BotManager Premiere(BMP). Fig.11 As shown, the robot management system generally includes an application server 1102 that provides real-time robot detection services and its associated asynchronous analysis 1104 functions. The robot management system also includes various data stores, including an attempt data store 1106 and a cache 1108. As also depicted, in this embodiment, the cluster 1100 supports a user risk engine 1110 and a user data service 1112, which together with a user profile and activity data store 1114 implement the account protection technology of the present disclosure. Typically, the user risk engine executes in its own application server stack, which is different from the application server stack used for robot detection and mitigation. The solution architecture also includes a load balancer component 1116 and a request distributor 1118 component. As also shown, the solution cluster interoperates with an edge server 1120, which is located between the end user machine 1122 and the source 1124 that serves the customer. The service may also interoperate with other services, such as threat intelligence service 1126 (e.g., Akamai Cloud Security Intelligence (CSI) platform) and one or more other (CDN) internal systems (not shown). As will be described, the solution provides a highly available, highly reliable, and highly scalable solution to enable service clients (operation sources 1124) to combat both automated and human fraud attacks related to account takeover (ATO) and new account fraud (NAF).

[0063] As used herein, ATO refers to an attack by which a malicious actor gains access to a victim's account on a website or application. ATO is typically implemented via a credential stuffing attack, whereby one or more websites are attempted to leak credentials from a previous user database in an iterative manner. A successful ATO can result in compromised accounts. As used herein, NAF is an attack by which a malicious actor creates an account on a website or application by claiming to be someone who is not a real person. These may be the result of identity theft, using a real person's identity to create a new account without the person's knowledge. This may also be a synthetic identity, for example, created using a collection of attributes including name, address, telephone number, and email address, where the combination is not relevant to a real person. The purpose of NAF is typically to obtain benefits for new accounts, such as free trial periods, coupons, discounts, loyalty points, miles, and rewards. These benefits are then combined and resold to other people, who cash out by converting these points, miles, or rewards into valuable items.

[0064] Return to reference Fig.11 In this example implementation, the load balancer component 1116 provides balancing of requests to the infrastructure, and the component can be implemented using available components (e.g., software load balancer HAProxy and service networking solution Consul). The request distributor 1118 is preferably implemented as a multi-node, multi-threaded, in-memory data cache (e.g., Redis), and also incorporates firewall and TLS support. The user risk engine 1110 is a component for calculating a user risk score for each protected endpoint request, for example based on per-request data, a real user profile, and zero or more other risk factors. The user data service 1112 is a component for managing user profiles and user activity history. The user data service is used to separate the user risk engine from how and where the service maintains user profiles and user activity history. The end-user machine 1122 wants to access a protected endpoint, which is sometimes referred to as a protected API resource. The source exposes one or more such endpoints. The end-user machine requests access to an endpoint at the source proxied by the edge. The endpoint identified by the URL and parameter pattern is a resource defined in the security policy to obtain BMP and the protection provided by the technology of the present disclosure. Also as Fig.11As described in , the edge server typically makes requests to the infrastructure in the form of autoposts, where an autopost is an asynchronous POST sent by a script (e.g., BMP JavaScript) that contains client attributes and other data used by the service, such as for robot detection. As further shown, according to this embodiment, the edge server also makes a request to the infrastructure for a GTS, which refers to "Get Threat Score". This is a request issued at the edge and used to obtain robot and user risk scores when required by the security policy.

[0065] In runtime operation, the service backend components in cluster 1100 use automatic collection (usually enhanced by edge data). The request distributor layer makes automatic collection and get_threat_score (GTS) requests available to the application server stack (bot manager application server 1102 and user risk engine 1110) and synthesizes responses. In operation, the edge server requests a user risk score, usually together with a robot score from the robot manager service. Typically, the user risk engine 1110 generates a score and responds to the edge server using automatic collection data, reputation data from threat intelligence services, and a true user profile (TUP). The edge application policy takes any necessary mitigation measures and forwards the login request to the source if allowed. The edge can optionally inject the user risk score, true user factor, and risk factor into the header forwarded to the source. Finally, the login status is reported to the service backend, where the login status is preferably combined with the automatic collection data to update the user profile and activity history.

[0066] The load balancer 1116 exposes the new endpoint and routes traffic to the new application server cluster, using health monitoring auto-scaling support to manage traffic. In addition, the auto-scaling request distributor 1118 streaming publish / subscribe deployment (pub / subdeployment) enables the application servers of both the robot manager and user risk protection to receive requests from the load balancer. The user risk engine and user data service are shown as separate services to reflect their independent functions and their potentially different computing needs, but this is not a requirement. As depicted, the user profile and activity data store provides storage services for several categories of data: automatic collection, scores associated with protected endpoint requests and their associated automatic collection, user activity history, and user profiles.

[0067] In this embodiment, the User Risk Service preferably leverages and extends the Robot Manager Service's methods of collecting data from the client and edge and sending requests to the Fraud Detection Infrastructure. To this end, preferably, the services (User Risk Engine and User Data Service) leverage the Robot Manager collection methods so that the client-side data being checked comes from the same automated collection used for robot detection. That is, it is not required that the protected endpoint utilize both the robot detection and the User Risk Detection Services. In addition, there may be situations where the User Risk Service still needs to score the client request even when the Robot Manager has determined whether the client is a robot.

[0068] Preferably, the automatic collection of the robot manager system contains client-side data and is enhanced by data at the edge before being forwarded to the user risk engine / user data service that constitutes the account protection infrastructure. As described, the account protection service preferably uses the data in the automatic collection to represent user identification data, and the information related to the current request is used to compare with the TUP when calculating the user risk score. In addition, preferably, the data from the automatic collection is also merged into the real user profile based on the generated risk score, the detected login state, and other inputs determined by the threat intelligence service, for example. Preferably, the edge contains and calculates data to enhance the request sent to the account protection infrastructure. This data can include data such as country, state, and ASN, TLS and TCP fingerprint data. In this embodiment, the robot manager service also uses several cookies, for example, short-term cookies and long-term cookies. Each of these cookies preferably has its own unique identifier, which the robot detection service uses to associate the automatic collection with the protected endpoint request and aggregate data for determining whether the client is a robot. In addition, the stop protocol is preferably encoded into the long-term cookie, indicating when the JavaScript stops sending more automatic collections. Typically, the Bot Manager Application Server tells the client to stop sending telemetry after determining that the client is human, and restarts telemetry (resets the flag) for humans after a certain number of protected endpoint requests to re-verify human status. The Account Protection Service uses these unique identifiers to associate automated acquisitions with protected endpoint requests so that it does not unnecessarily recalculate scores for multiple automated acquisitions in rapid succession on a single page, and to find the true user profile against which the scores were calculated using automated acquisitions.

[0069] The account protection service calculates a user risk score (preferably in real time) based on data collected at the client and edge, reputation data, and historical data specific to that user (real user profile). Figure 12A-12BA representative sequence diagram is included that details the interactions between the main components during a user login to a protected endpoint. In this example, a client 1200 operates a browser 1202 and interacts with an edge server 1204. The backend components of the account protection service include a user risk engine 1206 and a user data service 1208. A service client source 1210 is also depicted. In operation, after the browser requests a page from the source and the source returns HTTP 200, the edge server injects a script reference and returns the page (with the reference) to the browser. The browser requests the script and the edge server obtains the script from the local CDN data storage. The script is served and executed in the client. The script running inside the browser uses the collected data / telemetry data to enable automatic collection back to the edge server. The edge server then enhances the automatic collection with the edge data and forwards the information to the user risk engine. The user risk engine uses this information to obtain a user profile from the user data service. The profile data is returned to the user risk engine, which then calculates the user risk score. The score is cached. On subsequent login requests (in this example scenario, after the end user submits his / her credentials), the edge server makes a request to the user risk engine to obtain the score. The score is returned from the user risk engine to the edge server, which then applies the policy based on the score. If the score passes, the login request is forwarded from the edge server to the origin, and the success / failure response is then received at the edge server and passed to the browser for action. The result is also returned to the user risk engine, which updates the user data service with the result. This concludes the process. As also described, when the policy requirements are not met (based on the score), the edge server rejects the login request, returns an appropriate response to the client (e.g., HTTP 403 Unauthorized), and reports the failure to the user risk engine. The user risk engine updates the user data service appropriately.

[0070] Although not intended to be limiting, typically the User Risk Engine and User Data Service operate on streams of data or events. An event is a message sent by the edge as a result of a protected request. As described above, preferably, automatic collection reception (at the edge server) drives the generation of the risk score. Login state events (or elapsed time) or some other configurable activity drives the update of the user profile. The User Data Service may pre-process existing profile data before making it available to the Risk Engine. As described, preferably, the User Risk Engine performs several main operations, namely, generating a user risk score based on telemetry information received asynchronously via automatic collection or synchronously with inline telemetry information in the protected endpoint request, and returning the user risk score to the edge for the protected endpoint request. The process of generating a user risk score may be based on an algorithm that may involve one or more stages. For example, in one example, the risk engine can retrieve unprocessed automated collections from a cache, enhance and transform automated collections to meet any algorithmic requirements, retrieve the client's IP and network reputation data, calculate reputation risk, retrieve real user profiles, identify changing elements, calculate weights of profile elements, calculate profile risk, retrieve available robot scores, and compose a user risk score from a set of one or more temporary values, potentially with real users and risk factors. As described, the user risk engine preferably receives a request from a protected endpoint for a current user risk score via a GTS API request, which can also be published to a request distributor stream. In an example implementation, the request distributor layer is an automatically scalable publish / subscribe deployment that uses Redis streams to support multiple clients (i.e., robot manager services and account protection services) for requests, and a key / value pair to read responses from these clients and send them back to the edge. In this approach, the robot manager application and the user risk engine represent independent groups of clients that subscribe to automated collections and GTS topics. Other request / response processing mechanisms can be used to implement the request distributor.

[0071] As described above, the User Risk Engine receives requests from protected endpoints for the current user risk score via GTS API requests that are also posted to the Request Dispatcher flow. Any previously calculated scores are retrieved from the cache, or scores can be calculated on demand. For mobile application requests that rely on inline (synchronous) telemetry information, or where scores are still being calculated when the GTS API call arrives, the score retrieval process must wait a configurable amount of time before returning, whether or not a score is available. Therefore, preferably, the algorithm supports the concept of partial scores, so that if a certain configurable time budget is exhausted, the Risk Engine can still return a score, which may have a lower precision or confidence.

[0072] The User Data Service preferably exposes an API to get user profiles, and delete user profiles. It also handles updating user profiles. Without limitation, updating user profiles and generating user risk scores preferably rely on client reputation data provided by the Threat Intelligence Service. The User Data Service is responsible for asynchronously retrieving reputation data via the API, parsing the data and loading it into memory, and making the data available for use by the profile update process and external lookups to the User Risk Engine.

[0073] A representative user profile includes: profile version, internal identifier, external UUID, account ID, date first seen by user, most relevant events in the profile, allowlist status, last allowlist status change data, and allowlist status changed by (userid). Typically, requests for profiles come from the User Risk Engine.

[0074] The user risk score in this embodiment is calculated when the automatic collection is received. These scores are stored along with the trust and risk factors, awaiting a request for the user risk score. In some cases, the calculation is completed before the request for the user risk score is received; however, in other cases, the score is obtained from a storage location. The stored data typically includes a number of data items in addition to the score (between 0-100) itself: external UUIDs, account IDs, event IDs or timestamps, short-term and long-term cookie identifiers, trust factors and their scores, risk factors and their scores, and additional status messages or codes indicating that the profile was not found, insufficient profiles were used for scoring, etc.

[0075] The user activity history contains the following types of data: external UUID, timestamp, edge server request ID, account ID, security configuration ID, resource purpose type, resource purpose ID, automatically collected attributes used in score calculation, risk score, score status, trust and risk factors, URL, login status and status code, device ID, device OS and version, and device browser type and version.

[0076] A True User Profile is a representation of the attributes of a user that are expected to be seen when the user makes a protected endpoint request. As described above, TUP is typically used by a User Data Service. The data in a profile typically includes: an internal UUID, an external UUID, an account ID, a set of long-term and short-term cookie identifiers for that user and a timestamp of when they most recently appeared on login, a profile creation date, a last update date, other metadata determined by algorithmic requirements (e.g., number of events), and the events and their attributes, preferably stored and organized according to any algorithmic requirements. As described above, TUP retrieval typically occurs on a protected endpoint request for the current user score.

[0077] In summary, a preferred method herein provides an account protection service that relies on previous user activity to construct a real user profile, including based on location, network, device, and time of activity. In one embodiment, a statistical model based on the real user profile and other risk factors collected over time and updated regularly is used to assess the risk of the user during the authentication process (or other process). Service customers use risk to eliminate unnecessary friction and reduce the incidence of automated and manual account takeover attacks. Using SIEM integration or header injection, service customers can even enhance their own internal systems with information about user risk scores, as well as risk and real factors, to make the final decision on-premise.

[0078] Other enabling technologies

[0079] More generally, the techniques described herein are provided using a set of one or more computing-related entities (systems, machines, processes, programs, libraries, functions, etc.) that together facilitate or provide the functionality described above. In a typical implementation, a representative machine on which the software is executed includes commodity hardware, an operating system, an application runtime environment, and a set of applications or processes and associated data that provide the functionality of a given system or subsystem. As described, the functionality can be implemented in a standalone machine or across a distributed set of machines. The functionality can be provided as a service, such as a SaaS solution.

[0080] The techniques herein can be implemented in a computing platform such as Figure 1-Figure 2 The platforms described in various embodiments may be used, although other implementations may also be used. One or more functions of the computing platform may be conveniently implemented in a cloud-based architecture. As is well known, cloud computing is a service delivery model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage devices, applications, virtual machines, and services) that can be quickly provisioned and released with minimal management effort or interaction with the service provider. Available service models that may be utilized in whole or in part include: Software as a Service (SaaS) (the provider's applications run on a cloud infrastructure); Platform as a Service (PaaS) (customers deploy applications that may have been created using provider tools onto a cloud infrastructure); Infrastructure as a Service (IaaS) (customers provide their own processing, storage, network, and other computing resources, and can deploy and run operating systems and applications).

[0081] The platform may include co-located hardware and software resources, or physically, logically, virtually, and / or geographically distinct resources. The communication network used to communicate with and from the platform services may be packet-based, non-packet-based, secure or non-secure, or some combination thereof.

[0082] More generally, the techniques described herein are provided using a set of one or more computing-related entities (systems, machines, processes, programs, libraries, functions, etc.) that together facilitate or provide the functionality described above. In a typical implementation, a representative machine on which the software is executed includes commodity hardware, an operating system, an application runtime environment, and a set of applications or processes and associated data that provide the functionality of a given system or subsystem. As described, the functionality may be implemented in a standalone machine or across a distributed set of machines.

[0083] Each of the above-described processes, modules or sub-modules is preferably implemented in computer software as a set of program instructions executable in one or more processors such as a special-purpose machine.

[0084] A representative machine for providing the subject matter herein may be an Intel Pentium-based computer running a Linux or Linux variant operating system and one or more applications for performing the functions described. One or more of the above processes may be implemented as a computer program for performing the functions, i.e., as a computer instruction set.

[0085] Although a particular order of operations performed by certain embodiments of the disclosed subject matter is described above, it should be understood that such order is exemplary and alternative embodiments may perform operations in a different order, combine certain operations, overlap certain operations, etc. References in this specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include that particular feature, structure, or characteristic.

[0086] Although the disclosed subject matter has been described in the context of a method or process, the subject matter also relates to an apparatus for performing the operations herein. The apparatus may be a specific machine specifically constructed for the desired purpose, or it may include a computer selectively activated or reconfigured in other ways by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk including an optical disk, a CD-ROM, and a magneto-optical disk, a read-only memory (ROM), a random access memory (RAM), a magnetic or optical card, or any type of medium suitable for storing electronic instructions and coupled to a computer system bus.

[0087] A given implementation of a computing platform is software executed on a hardware platform running an operating system such as Linux. A machine implementing the techniques herein includes a hardware processor, and non-transitory computer memory storing computer program instructions executed by the processor to perform the above-described methods.

[0088] There is no restriction on the types of computing entities that can implement the client side or server side of the connection. Any computing entity (system, machine, device, program, process, utility, etc.) can act as a client or server.

[0089] Although given components of the system have been described separately, one of ordinary skill will recognize that some functionality may be combined or shared in a given instruction, program sequence, code portion, etc. Any application or functionality described herein may be implemented as native code by providing hooks into another application, by facilitating the use of a mechanism as a plug-in, by linking to a mechanism, etc.

[0090] The platform functionality may be co-located, or the various parts / components may be separated and run as distinct functions, possibly in one or more locations (over a distributed network).

[0091] Machine learning may be used to enhance or facilitate the construction of user identification / user risk models as described herein.

[0092] What the applicant claims for is set forth in the appended claims.

Claims

1. A method for account protection, comprising: At the first server: In response to receiving a request associated with a client to access a resource, injecting a reference to the script and returning the resource with the reference to the client; In response to receiving an automatic collection from the client, forwarding the automatic collection to an account protection service, the automatic collection including data collected as a result of executing the script; At a second server different from the first server and executing the account protection service: In response to receiving the automatic collection, issuing a request for a user profile, the user profile being calculated based on information originating from one or more previous successful logins of the client; responsive to receiving the user profile, calculating a user score; Returning the user score to the first server; At the first server: In response to receiving the user score, applying a policy to the user score, wherein the policy is an account protection policy, and An action is taken based on whether the user score satisfies the account protection policy.

2. The method according to claim 1, wherein: The user score represents how well the current login matches a model of successful logins, wherein the model is derived from information from the one or more previous successful logins.

3. The method of claim 2, further comprising updating the model when additional successful logins occur.

4. The method according to claim 1, wherein: The data collected as a result of executing the script includes one of a device-specific attribute and a user-agent-specific attribute for user identification.

5. The method according to claim 1, wherein: The first server also enhances the automatic collection with edge data before forwarding the automatic collection to the second server.

6. The method according to claim 5, wherein: The edge data includes information specific to the request associated with the client accessing the resource, and the information varies between or among at least one of a user, a user agent, and a device.

7. The method according to claim 6, wherein: The information specific to the request associated with the client accessing the resource is one of a geolocation of an endpoint, a user-agent header, and a TLS fingerprint.

8. The method according to claim 1, wherein: The user score is enhanced to include information indicating which portions of a set of user identification data are consistent with the user profile.

9. The method according to claim 1, wherein: When a login request to a protected endpoint is received at the first server, the user score is returned to the first server.

10. The method according to claim 9, wherein: The login request is associated with a hosted login to the protected endpoint, the hosted login being provided by an identity and access authority.

11. The method according to claim 1, wherein: The automatic acquisition is associated with the collection of data for detecting whether the client is a robot.

12. The method according to claim 1, wherein: The user score is also calculated based on additional risk data.

13. The method according to claim 12, wherein: The additional risk data is client reputation data.

14. The method according to claim 1, wherein: The account protection service prevents account takeover (ATO) attacks by which a malicious actor associated with the client gains access to an account at a website or application.

15. The method according to claim 1, wherein: The account protection service prevents new account fraud (NAF) by which a malicious actor associated with the client creates an account at a website or application by claiming to be someone other than who they are.

16. The method according to claim 1, wherein: When the user score satisfies the account protection policy, the action includes providing an access token to an endpoint.

17. The method according to claim 1, wherein: When the user score satisfies the account protection policy, the action includes forwarding a login request to a client source.

18. An apparatus comprising: A set of hardware processors; A computer memory associated with the set of hardware processors and storing computer program code configured as a first server and a second server, the computer program code being configured to: At the first server: In response to receiving a request associated with a client to access a resource, injecting a reference to the script and returning the resource with the reference to the client; In response to receiving an automatic collection from the client, forwarding the automatic collection to an account protection service, the automatic collection including data collected as a result of executing the script; at the second server executing the account protection service: In response to receiving the automatic collection, issuing a request for a user profile, the user profile being calculated based on information originating from one or more previous successful logins of the client; responsive to receiving the user profile, calculating a user score; Returning the user score to the first server; At the first server: In response to receiving the user score, applying a policy to the user score, wherein the policy is an account protection policy, and An action is taken based on whether the user score satisfies the account protection policy.

19. The device according to claim 18, wherein: The account protection service prevents one of: an account takeover (ATO) attack and a new account fraud (NAF) by which a malicious actor associated with the client gains access to an account at a website or application; Through the new account fraud (NAF), a malicious actor associated with the client creates an account at a website or application by claiming to be someone other than who they are.

Images