Secure content management through authentication

Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch of data, for restricted webpages based on the restricted webpages being associated with an authentication tier in an AASD registry. Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of the following for the webpage: an identifier, an authentication level, allowed fields, eager fetch fields, one or more sources for one or more fields, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements indicated in the AASD registry information, or whose authentication requirements are already fulfilled by the requesting client.

BACKGROUND

Many applications, including applications for banking, shopping, government, etc., utilize sensitive information that is personally-identifying for users, i.e., “Personally-Identifying Information” (PII). Examples of PII include full name, social security number, place of birth, birth date, mother's maiden name, email, phone number, physical address, etc. To protect such information, applications generally require user authentication via a username and password prior to allowing a user to navigate application content. Many times, additional authentication steps (AAS), such as knowledge-based authentication (KBA) or multi-factor authentication (MFA) in addition to username/password login, are also required in order to perform restricted actions, such as viewing or editing PII. Requirement of AAS before allowing a user to access an application works to prevent cyber-attacks, such as credential stuffing attacks that use known combinations of usernames and passwords to get unauthorized access to authentication-based applications.

KBA requires correct responses to one or more questions that require knowledge that would normally be held by the user, such as questions involving PII, credit bureau data, addresses that have been associated with the user, etc. MFA adds one or more additional factors, or evidence of identity, to user authentication. For example, an additional factor used for MFA may be a onetime password (OTP) that is sent to an email or telephone number associated with the user, use of a magic link (i.e., passwordless authentication), requests for biometric authentication (such as fingerprint, face ID, retina scan), etc.

Generally, a request for AAS, also referred to as an AAS challenge, is issued after the user has logged into an application by providing a username and password, or in conjunction with the user logging into the application. As such, an AAS challenge creates an extra hurdle for users to enter and navigate the application. This additional hurdle generally decreases click-through and conversion rates, which reduces the likelihood of the application enlisting the user for the application. The decrease in user interest in an application because of extra hurdles to application navigation can have significant financial impact on entities that offer services or products via the application, or on entities that make revenue based on click-throughs and conversions via the application.

To increase the attractiveness of authentication-based applications, it would be desirable to remove or delay AAS challenges as much as possible. One way to reduce the required AAS for an application is to allow a user to waive AAS requirements, either in general or when requests originate from a trusted device. However, waiving AAS requirements produces a vulnerability in application security, which may leave the user's PII open for attack.

Delayed, rather than waived, AAS avoids introduction of vulnerability to application security, but it can be expensive to retrofit an established application to delay AAS. For example, delayed AAS may be based on tracking the AAS requirements of different restricted pages in an application using intermediate status flags for login requests. However, retrofitting a system to handle the new status flags can be very costly.

Furthermore, additional authentication can be performed on a per-task basis, i.e., when the user requests an action that requires additional authentication. However, per-task authentication also creates friction for the user as it requires more user actions before being permitted to perform a desired task, and may discourage the user from proceeding with the application because of frustration with the required piece-meal security. Thus, per-task-based security can affect user experience, which can cause lost business opportunities because of users that are discouraged from interacting with the authentication-based application.

Accordingly, it would be beneficial to allow existing applications to delay AAS challenges as much as possible without requiring costly modifications to the application system.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the described techniques. It will be apparent, however, that the described techniques may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the described techniques.

General Overview

Techniques are described herein for performing authentication, and also “eager” or “lazy” fetch for restricted actions/webpages of an authentication-based application based, at least in part, on information stored for restricted actions/webpages in a registry. More specifically, according to an embodiment, restricted actions/webpages are associated with an authentication tier in an AAS Designation (AASD) registry. In this embodiment, information for restricted actions/webpages is recorded in the AASD registry. Herein, descriptions of functionality associated with webpages included in the AASD registry are also applicable to restricted actions included in the registry. Accordingly, where applicable, references to webpages included in the AASD registry may be interpreted as references to actions/webpages included in the AASD registry.

Inclusion of a restricted webpage in the AASD registry enables AASD-based authentication for the webpage. According to embodiments, information for a restricted webpage included in the AASD registry includes one or more of: an identifier of the webpage, an authentication level for the webpage, allowed fields for the webpage, eager fetch fields for the webpage, one or more sources for one or more fields of the webpage, etc. When information for a webpage is included in the AASD registry, that information is used to perform eager fetch for one or more fields of the webpage that are not associated with authentication requirements (as indicated in the AASD registry information) or whose authentication requirements are already fulfilled by the requesting client. Furthermore, sensitive information is provided once the user has accomplished the associated authentication level indicated in the AASD registry information, and, according to an embodiment, is retrieved from the source indicated in the AASD registry information.

Using the AASD registry to implement authentication for restricted webpages makes the process of allowing deferred AAS for a webpage very efficient for developers. For example, providing, in the AASD registry, identifiers of sources for retrieving sensitive data allows webpages to be drafted without knowledge of where the sensitive data resides. This increases the security of the webpages and the simplicity of webpage drafting. Also, the sources of truth for the various data fields may be changed in the mapping data, and webpages that are in the registry need not be updated with the change in the source of truth (since the webpages rely on the system to provide the sensitive data fields). Thus, if a webpage that is in the AASD registry requires the highest authentication tier, for at least one data field, the webpage may still benefit from eager and/or lazy fetch, and also benefit from ease of webpage development indicated above.

Further, techniques described herein are backward-compatible with existing webpages in an application whose behavior and authentication process will not change even after techniques described herein are implemented for a portion of the application. If a webpage (or action associated with a webpage) is not identified in the AASD registry, then it is not known what authentication tier is required by the page, and the page is processed without AASD and without eager or lazy fetch. Accordingly, lack of entry in this data access control (i.e., the AASD registry) for a particular webpage means default security is required to access that page. Thus, introduction of the AASD registry in an established application allows for backwards compatibility with webpages that are not included in the AASD registry and with web servers that are not AASD-enabled, which reduces the up-front cost of implementing AASD-based authentication for desired portions of the application.

For simplicity, an authentication service is depicted herein as responsible for both registering restricted actions/webpages and managing data access. However, any portion of these actions may be performed by another entity.

System Implementing an Application with Authentication Tiers

FIG.1depicts an example application100with an example configuration of services that perform functions for the application. Specifically, inFIG.1, application100includes an account service110, an authentication service (“auth service”)120that has access to an authentication dataset122, and one or more web servers including an AASD-enabled authentication user interface web server (“auth UI server”)130that serves a login page132and one or more authentication challenge pages134A-N. For purposes of illustration, application100includes one or more other web servers (not depicted inFIG.1), serving one or more respective pages. The one or more other web servers may or may not be AASD-enabled, and may or may not be in the same web domain as application100.

According to one or more embodiments, AASD functionality is implemented using middleware, which is logic, for a web server, that allows the web server to perform one or more middleware-library functions. In this embodiment, one or more particular middleware-library functions facilitate AASD functionality, such as functionality to include context information in a request to validate a client session. A first web server that uses the same version of middleware as a second web server has access to the same middleware-library functions as the first web server. A web server that uses a different version of middleware has access to different middleware-library functions, or different versions of the same middleware-library functions, than the first and second web server. A web server that does not implement middleware does not have access to any middleware-library functions. In this embodiment, if a web server implements a version of middleware with AASD middleware-library functions, the web server may implement AASD techniques described herein, and otherwise the web server reverts to non-AASD authentication for a given webpage. Nevertheless, AASD techniques may be implemented in any way, including embedding AASD functions in web servers without use of middleware, etc.

FIG.2is a block diagram that depicts an example network arrangement200for implementing application100, according to one or more embodiments. Specifically, network arrangement200includes a client device210and server devices220,240, and250, communicatively coupled via a network230. Client device210runs a client212, which is configured to communicate with one or more server devices over network230. Client212may be implemented in any way, including as a desktop browser-based client, a mobile browser-based client, a native mobile application, a script running on client device210that is not human-facing, etc. Herein, a “user” is one or more humans interfacing with client device210or one or more processes running on client device210. Server device220runs account service110, auth service120, auth UI server130, and a listener service222. Furthermore, server devices240and250run respective web servers242and252, each of which serves one or more pages for application100. For purposes of illustration, unless otherwise indicated, web server242is AASD-enabled and web server252is not AASD-enabled.

Authentication Tiers

According to an embodiment, application100implements a plurality of hierarchical authentication tiers, where each authentication tier is associated with one or more authentication steps, such as username/password authentication, non-bot verification (such as Captcha), knowledge-based authentication (KBA), multi-factor authentication (MFA), etc. For example, application100includes actions that are associated with the following example authentication tiers:

Public Authentication Tier: Requires no authentication steps. According to an embodiment, a client session that is not associated with an authentication tier is, by default, associated with the public authentication tier. According to an embodiment, the public tier is considered to be the lowest-security tier in the hierarchy, lower than the first authentication tier, and is associated with a null set of authentication steps. When associated with the public authentication tier, a client has access to public data only, which does not include any PII. However, the client may receive targeted experience based on cookie tracking. For example, while a user of client212is not logged in and based on one or more cookies in a cookie store214maintained at client device210, application100serves, to client212, a public webpage with one or more relevant news articles.

First Authentication Tier: Requires authentication by validation of username and password. A client session associated with the first authentication tier is considered a weak session, and the client has access to data with no critical user/account information, such as blog, articles, news, public materials, and basic account information without PII.

Second Authentication Tier: In addition to first authentication tier authentication mechanisms, KBA is also required. A session associated with the second authentication tier has stronger security than a session associated with the first authentication tier, but still is not considered as strong as higher tiers because KBA data can be obtained via social engineering. A client session associated with the second authentication tier allows the client access to basic user/account data, including some PII, but is not able to edit any PII.

Third Authentication Tier: In addition to first authentication tier authentication mechanisms, MFA is also required. According to an embodiment, KBA is also required. The third authentication tier provides the strongest security, and, as such, a client session associated with the third authentication tier has access to the most critical user/account information, including all PII, as well as the ability to edit PII.

According to an embodiment, each higher tier in the hierarchy provides access to one or more restricted actions in addition to any actions associated with all lower tiers. As such, restricted actions (including viewing a restricted page, viewing restricted information on a lower-security page, editing PII, etc.) are associated (either explicitly or implicitly) with an authentication tier. Restricted pages are associated with a non-public authentication tier, and access to that page is dependent on the client authenticating to at least the associated authentication tier. Furthermore, information included in a page, or actions available from a page, may be associated with an authentication tier that is different than the authentication tier associated with the page (if any). For example, a given page is associated with the first authentication tier and a restricted action accessible from the given page (such as editing PII) is associated with a higher authentication tier. A client that is authenticated to at least the first authentication tier may view the given page, but must be authenticated to at least the higher authentication tier in order to perform the restricted action accessible from the page.

To illustrate, login page132is a public page and, as such, is not associated with any authentication tier and may be accessed by clients that have not yet performed any authentication steps. Example pages244and256are associated with the first authentication tier, and are referred to herein as first-tier pages (“1TP”). Example page246is associated with the second authentication tier, and is referred to herein as a second-tier page (“2TP”). Further, example page254is associated with the third authentication tier, and is referred to herein as a third-tier page (“3 TP”).

According to an embodiment, a client that requests an action that is associated with an authentication tier that is at least two tiers higher than the authentication tier associated with the current client session is able to perform the action after solving the authentication challenge(s) associated with the requested action without solving the authentication challenges for intervening authentication tiers. According to another embodiment, as described in detail below, such a request is granted after the client has solved all authentication challenges associated with the tier of the requested action and the authentication challenges for any intervening authentication tiers between the tier of the requested action and the current client session tier.

AASD Eligibility of Action Requests

According to an embodiment, in order for a restricted action (which may include viewing at least a portion of a particular restricted webpage) to be eligible for AASD, each restricted action for application100, and the associated authentication tier, is registered with auth service120. Auth service120maintains an AASD registry, in authentication dataset122, that maps each registered restricted action to the associated authentication tier. The restricted action may be identified by a target URL that may contain an action other than viewing the target URL therein, e.g., as a parameter in the URL. To illustrate, web server242, which is AASD-enabled, is configured to serve a new page244. Web server242sends a registration message, to auth service120, with an identifier of page244and an identifier of the first authentication tier. Based on the registration message, auth service120records, in the AASD registry, that page244(or the action of viewing page244) is associated with the first authentication tier. According to an embodiment, web server242proves, to auth service120, that the registration of page244is not fraudulent, such as by using an encryption protocol to encrypt one or more portions of the registration message, by providing authentication information to authenticate web server242in connection with the registration message, etc.

The AASD registry is used by auth service120to determine what authentication tier is needed to perform a given restricted action, and allows auth service120to defer one or more authentication requirements for restricted actions that do not require the highest authentication tier. Thus, an action is not AASD-eligible when the action is not registered with auth service120, or when the request to validate the session in connection with a client request for the action is not accompanied by information identifying the context of the request required for AASD-based authentication, according to an embodiment. According to an embodiment, any request for a restricted action from a web server that does not implement functions required for AASD is treated as a highest-tier request and no AAS is deferred for that request.

AASD Webpage Registration

New webpage requesting pre-approved and pre-defined data access control may be registered with auth service120, e.g., to the AASD registry, via manual or automated way. According to an embodiment, the registration information in an AASD registry includes restricted data fields that are, themselves, associated with authentication tiers. Upon successful registration, data about the new webpage is persisted and maintained as necessary, e.g., in dataset122.

According to an embodiment, a manual process for registering a webpage with the AASD registry comprises internal processes to obtain approval and causing an identifier of a restricted webpage/action to be included in mapping data or an AASD registry for auth service120, where a set of metadata for each restricted webpage/action is collected and recorded in the AASD registry. The metadata for a given restricted webpage/action uniquely identifies the restricted webpage/action and the web server that hosts that restricted webpage/action (e.g., including one or more of universal resource locator (URL) of the restricted webpage/action, relative path for the restricted webpage/action, a name of the web server, information for the web server, IP address, identifier of the web server, etc.), and also includes a list of protected data to which the webpage has access.

According to an embodiment, an automated process for registering a webpage with the AASD registry involves using an asymmetric encryption key to securely send, to auth service120, registration data from a web server that hosts a restricted webpage or restricted action. Auth service120decrypts the data and, upon determining that the encrypted data decrypted properly, auth service120automatically registers the restricted webpage or action indicated in the registration data.

Normal Webpage Rendering Flow for Existing Webpage for AAS Enabled User Account

According to an embodiment, a webpage in application100that relies on auth server120for authentication, but is not included in the AASD registry, may still be accommodated by auth server120using established authentication processes. For example, a user uses client212at client device210to request, from a web server such as web server252, a restricted webpage that is part of application100and that is not registered in the AASD registry maintained by auth service120.

In response to this request, according to established authentication processes, the user is first asked to log in using username and password. Upon providing correct username and password, the user is asked to solve one or more AAS challenges, such as KBA, and/or and MFA challenge with an OTP sent to the user's email account. According to an embodiment, the set of AAS challenges that the user is required to perform for a restricted webpage that is not AASD-enabled is the set of AAS challenges that are associated with the highest authentication tier, e.g., the third authentication tier described above. Based on successful completion of the one or more AAS challenges by the user, a client session is created for client212of the user, the user is authenticated, and client212at client device210is successfully redirected to the requested webpage.

Flow for New Webpage Included in AASD Registry

The following is an illustration of an embodiment for serving a new webpage that includes one or more fields for information that is not PII (called “pre-approved” fields) and that is included in the AASD registry described above. A client212is not yet logged in to application100. Client212requests a webpage of application100, called Page-A, which is designed for AASD as it includes pre-approved fields that are not PII and thus do not require AAS. Page-A is registered with the AASD registry, and, according to an embodiment, the web server that serves Page-A is AASD-enabled.

In response to the request, client212is redirected to a login page by the web server. Client212submits a correct identifier and password (e.g., as described below in connection with step1of flowchart800). Upon receiving credential validation request, auth service120creates a special session identifier and returns that special session identifier with a status identifier indicating what AAS is needed to view Page-A (e.g., as described below in connection with at least some of steps2-21of flowchart800). The web server for Page-A, just as any other web server would, requests session validation against auth service120but with additional context because the web server is AASD-enabled (e.g., as described below in connection with step10of flowchart800). Although this additional context can be a contractual protocol (e.g., if Page-A is in the same domain as auth service120), it could involve asymmetric encryption (or some other encryption) for added security, as described in further detail below.

Auth service120processes the session validation request with added context (e.g., as described below in connection with step11of flowchart800). By checking against access control service (e.g., the AASD registry or a service that maintains the AASD registry), auth service120determines that the requester (Page-A) is eligible for deferred AAS (i.e., additional AAS will not be requested until necessary).

According to an embodiment, an AASD registry entry for a given webpage further indicates one or more restricted data fields that the webpage is pre-approved to retrieve. In this embodiment, auth service120facilitates retrieval of restricted data, for Page-A, as indicated in the AASD registry by either: (a) querying a master data service (or interface) to retrieve the restricted data; or (b) returning resource links to the restricted data to allow the web server to retrieve the data via the links (e.g., HATEOAS driven REST API-based resource links to the data, assuming Page-A has access to those APIs).

If the client navigates to non-special pages (i.e., existing pages, the web servers for which are not AASD-enabled) without being authenticated to the highest-security authentication tier, auth service120redirects the client to any needed AAS challenges, as described herein. In this case, session validation fails, even though there is a valid session, because the highest authentication tier is not associated with the current client session and valid additional context was not included in the request.

It is noted that these techniques work well on READ-ONLY pages and on pages with one directional update (e.g., document submission, form/request submission). Pages with update operations may trigger additional challenge (such as MFA) or redirect to a page that requires MFA. Further, these techniques work well on light-weight pages, given that authentication and data retrieval are bundled (from a client perspective). Furthermore, these techniques make it easier and quicker to add new pages, with known sets of required fields, to application100.

Auth Service Fetches Restricted Fields for Webpages

According to an embodiment, auth service120performs an “eager fetch” or a “lazy fetch” for one or more of the restricted data fields indicated in the AASD registry entry for PP1. Specifically, auth service120maintains a database, in dataset122, with AASD registry302and one or more other tables that facilitate fetching restricted data for pages registered with auth service120.FIG.3depicts an example database300maintained by auth service120in dataset122. Example database300, includes AASD registry302, as well as an auth level table310, a source per field table320, and a data source table330. Example auth level table310maps auth level identifiers, from AASD registry302, to authentication tier data. In example auth level table310, the first authentication tier (id=1) has an auth type of “credential”, and a level of ‘1’. According to an embodiment, the auth type of an authentication tier is the status indicator described in further detail herein. According to a further embodiment, auth level table310also associates each authentication tier with a status indicator. For example, for the first authentication tier, auth level table310includes a status indicator of “KBA_PENDING”.

Example database300further includes a source per field table320, which includes entries for restricted fields that may be associated with webpages in AASD registry302. Each entry indicates a field name, and a source identifier. The source identifier of source per field table320is a foreign key to the identifiers of data source table330, which identifies data sources for the restricted fields. For example, data source table330indicates that source Id ‘1’ corresponds to a user management service340, e.g., run by server device220, and source Id ‘2’ corresponds to auth service120. Thus, the allowed fields column of the example AASD registry302maps webpages to associated restricted fields, and the source Id column of source per field table320maps restricted fields to data sources.

Auth service120eager-fetches restricted data fields by retrieving the data for one or more restricted data fields, indicated for a webpage in AASD registry301, from one or more data sources indicated in data source table330. Auth service120provides the data for these eager-fetched data fields to the web server rendering the webpage that requires these data fields. Auth service120lazy-fetches restricted data fields by retrieving reference links for one or more restricted data fields (where the restricted data fields are indicated for a webpage in AASD registry302), where the reference links refer to one or more data sources indicated in data source table330. Auth service120provides the reference links for these lazy-fetched data fields to the web server rendering the webpage that requires these data fields, and the web server retrieves the data for the restricted fields using the reference links. According to an embodiment, the reference link is the link that auth service120would use to retrieve the data field for eager fetch.

According to an embodiment, web server242indicates, in the request to validate the client session for PP1, the one or more restricted fields that should be eager-fetched and/or lazy-fetched. According to another embodiment, as depicted in example AASD registry302of database300, the AASD registry entry for PP1 indicates the one or more restricted fields that should be eager-fetched and/or lazy-fetched. For example, in the eager fetch column, the AASD registry302entry for PP1 includes the fields user_ID and first_name. As such, AASD registry302indicates that both the first_name and user_ID fields for PP1 should be eager-fetched. As another example, in the eager fetch column, the AADS registry302entry for PP2 includes the fields user_ID and first_name. As such, AASD registry302indicates that both the first_name and user_ID fields for PP2 should be eager-fetched, and the email field for PP2 should be lazy-fetched.

According to an embodiment, auth service120determines which data to eager-fetch and which to lazy-fetch based on authentication tier mapping data. Specifically, auth service120eager-fetches all data fields, for a given page, that are at or below the authentication tier of the client session requesting the page, and auth service120lazy-fetches the data fields that are associated with authentication tiers that are higher-security than the authentication tier of the client session. In this way, when the web server attempts to retrieve the higher-security data values based on the reference links, auth service120causes the client to authenticate to the level of the higher-security fields before providing the higher-security data values to the web server.

First-Tier Authentication Page Access with Eager Fetch

Flowchart400ofFIG.4illustrates authentication of a first-tier authentication webpage of application100with eager fetch of a webpage field, where the illustration uses the example authentication tiers described above. At step1of flowchart400, a user at client212enters credentials comprising a username and password (i.e., for first-tier authentication) via login page132served by auth UI server130. For example, login page132is served at client212because of a request for the login page, or a request for a webpage of application100that is associated with first-tier authentication, which causes the system to redirection client212to login page132, according to techniques described herein.

At step2of flowchart400, auth UI server130calls auth service120for user login with credentials, i.e., the entered username/password. At step3, auth service120verifies that the user has provided authentic credentials, and, in response, returns a special session identifier (ES1) to auth UI server130. More information about special session identifiers is provided below.

At step4, auth UI server130redirects client212to a 1TP referred to as “PP1” (which may be the requested webpage or may be a landing page that is automatically displayed after the user provides authentic credentials at login page132) served by a web server242. In this example, web server242is AASD-enabled. At step5, web server242calls auth service120for session validation based on the special session identifier, ES1. Because web server242is AASD-enabled, web server242also sends, during validation, caller context comprising a target URL for PP1.

At step6, auth service120determines, based on AASD registry302, that PP1 is associated with the first authentication tier (the “CREDENTIALS” tier). More specifically, the user_ID and first_name fields of PP1 are associated with the first authentication tier, which are the only restricted fields in PP1. Because the client is also associated with at least the first authentication tier (by virtue of having provided correct user credentials and receiving the special session identifier ES1 that is associated with the first authentication tier), the client is eligible to view the restricted data fields in PP1, user_ID and first_name.

At step7, based on the AASD registry entry for PP1 indicating that the first_name field and the user_ID field for PP1 should be eager-fetched:Auth service120makes a call to user management service340, mapped to the first_name field in mapping data (e.g., source per field table320and data source table330) maintained by auth service120, to fetch the restricted data (first_name) for PP1.Auth service120also retrieves, from dataset122, the user_ID value, based on the mapping data that maps auth service120to the user_ID field for PP1.
At step8, User management service340returns the first_name value to auth service120. According to an embodiment, both a link and the value could be returned as part of an eager fetch of the value.

At step9of flowchart400, auth service120returns the first_name value, user_ID value, and optionally a flag to indicate pending_KBA (or other second authentication tier verification method). This flag indicates what AAS would be required for the client to attain the next authentication tier above the current authentication tier of the client session. In this case, because the client session is associated with the first (“CREDENTIALS”) authentication tier, the next authentication tier would be the second (“KBA”) authentication tier. A valid session flag may also be returned instead of or in addition to the pending_KBA flag. At step10, PP1 is displayed at client212with first_name value and user_ID value that were fetched by auth service120.

According to an embodiment, PP1 is associated with additional data fields (not shown inFIG.4) that are, in turn, associated with the second authentication tier. In this embodiment, upon attaining the second authentication tier, the client is able to view the data fields, for PP1, that are associated with the second authentication tier. For example, while the client session is associated with the first authentication tier, auth service120lazy-fetches the second-tier data fields before the client is associated with the second authentication tier (or higher), e.g., at the time that auth service120eager-fetches the first-tier fields. In this way, when web server242attempts to retrieve the higher-security data values based on the reference links (e.g., automatically or in response to a user request), auth service120causes client212to authenticate to the level of the higher-security fields before providing the higher-security data values to web server242.

First-Tier Authentication Page Access with Lazy Fetch

Flowchart500ofFIG.5illustrates authentication of a first-tier authentication webpage of application100with lazy fetch of a webpage field, where the illustration uses the example authentication tiers described above. In this example, the first_name field and the user_ID field for PP1 are to be lazy-fetched, e.g., because of information in the AASD registry, because of information in the request for PP1, etc. Steps1-6of flowchart500are similar to the corresponding steps1-6of flowchart400described above.

At step7of flowchart500, based on the AASD registry entry for PP1 indicating that the first_name field and the user_ID field for PP1 should be lazy-fetched, auth service120responds to the request of web server242(at step5) with a reference link to fetch the first_name field value for PP1. In this example, because auth service120is the owner of user_ID, auth service120returns that value to the caller even when the user_ID is indicated to be lazy-fetched. It is noted that, if auth service120were not the owner of user_ID, auth service120would send a second reference link to fetch a value for the user_ID field of PP1.

At step8, web server242calls the reference link, which directs the web server to user management service340, where the call includes the special session identifier (ES1). At step9, user management service340calls auth service120with ES1 to determine if the session identified by the special session identifier is valid, which requires that the identified session be authenticated to at least the authentication level associated with the first_name field for PP1. Accordingly, at step10of flowchart500, auth service120checks AASD registry302to determine that the first_name field is associated with the first authentication tier. Based on the session identified by ES1 being associated with the first authentication tier and the first_name field being associated with the same authentication tier, auth service120determines that the client is authorized to access the first_name value. Accordingly, auth service120returns a valid flag to user management service340.

At step11of flowchart500, the valid session identifier serves as authorization to return the first_name value to web service242. Thus, in response to receiving an indication that the session associated with ES1 is valid, user management service340returns the first_name value to web server242. At step12, PP1 is displayed at client212with the first_name value fetched from user management service340and the user_ID value that was fetched by auth service120.

Third-Tier Authentication Page Access with Eager Fetch

Flowchart600ofFIG.6illustrates authentication of a third-tier authentication webpage of application100with eager fetch of a first webpage field and also a (potentially delayed) lazy fetch of a second webpage field, where the illustration uses the example authentication tiers described above. At step1of flowchart600, a user at client212enters credentials comprising a username and password (i.e., for first-tier authentication) via login page132served by auth UI server130. For example, login page132is served at client212because of a request for the login page, or a request for a restricted webpage of application100, which causes the system to redirection client212to login page132, according to techniques described herein.

At step2of flowchart600, auth UI server130calls auth service120for user login with credentials, i.e., the entered username/password. At step3, auth service120verifies that the user has provided authentic credentials, and, in response, returns a special session identifier (ES1) to auth UI server130. More information about special session identifiers is provided below.

At step4of flowchart600, auth UI server130redirects client212to a web server242that serves a 3TP, “RP1”, which, for example, is the requested webpage. At step5, web server242calls auth service120for session validation based on the special session identifier ES1. During validation, web server242(which is AASD-enabled) also sends caller context comprising a target URL for RP1. At step6, auth service120determines, based on AASD registry302, that RP1 is mapped to the user_ID field and the first_name field, which are associated with the first authentication tier (“CREDENTIALS”), and also is mapped to an SSN field, which is associated with the third authentication tier (“MFA”).

At step7, based on the AASD registry entry for RP1 indicating that the first_name field and the user_ID field for RP1 should be eager-fetched:Auth service120makes a call to user management service340, mapped to the first_name field in mapping data (e.g., source per field table320and data source table330) maintained by auth service120, to fetch the restricted data (first_name) for RP1.Auth service120also retrieves, from dataset122, the user_ID value, based on the mapping data that maps auth service120to the user_ID field for RP1.

At step8, User management service340returns the first_name value to auth service120.

At step9, auth service120responds with the value for the user_ID field (from dataset122), the value for the first_name field, and PENDING_MFA flag. For example, auth service120also lists out all fields that the user has access to if the MFA challenge is satisfied, e.g., in response to a request from web server242for this additional information. Then web server242may use that information to allow the user to request session upgrade and display those higher-security fields.

At step10, web server242redirects to an MFA challenge page at auth UI server130because the response from auth service120had PENDING_MFA flag. According to an embodiment, web server242redirects to an MFA challenge page automatically, because RP1 requires a value for the SSN field, which is associated with the third authentication tier. According to an embodiment, web server242redirects to an MFA challenge page based on a request from the client to view the SSN field.

At step11, auth UI server130displays MFA challenge page134K to the user at client212. At step12, the user enters the required MFA code into the MFA challenge page. At step13, the MFA code entered by the user is passed to auth UI server130. At step14, auth UI server130sends the MFA code, with the special session identifier ES1, to auth service120for validation.

At step15, auth service120validates the MFA code and, given that the user has authenticated to the highest authentication tier, returns a normal session identifier S1 (if there were multiple levels of verification, auth service120would utilize another type of special session). According to another embodiment, the session identifier may be tied to the authentication tier in another way, such as by encoding the authentication level for the session. As another embodiment, there is no special or normal session identifiers—the session identifier is mapped to authentication tier in mapping data.

At step16, auth UI server130sends the normal session identifier S1 to web server242. At step17, web server242calls auth service120to validate the session using the normal session identifier S1. At step18, auth service120checks AASD registry302to determine that the client can access the first_name, user_ID, and SSN field values in RP1 when the client session is associated with the third authentication tier.

At step19, auth service120calls user management service340to fetch at least the SSN based on the client session being associated with the third authentication tier. At step20, user management service340then returns at least the retrieved SSN value. According to an embodiment, because user management service340is also the source of the first_name value, user management service340also returns the first_name value at step20. At step21, auth service120returns one or more of the values for the user_ID, first_name, and SSN fields. At step22, RP1 is displayed with the user_ID, first_name, and SSN values.

According to an embodiment, multiple services may be sources of data fields. Specifically, example database300includes only user management service340and authentication service120as sources of data fields. However, other sources, both internal and external to the domain of application100, may be included.

According to an embodiment, database300is organized such that data fields are associated with authentication tiers, and restricted pages/actions are associated with the data fields. According to an embodiment, the authentication tier associated with a given restricted action is the highest authentication tier associated with a data field for the action. According to another embodiment, when a webpage is associated with data fields from multiple authentication tiers, application100displays, at a given client, a version of the webpage that includes only information that is at or below the authentication tier of the given client based on the mapping data that maps the data fields to authentication tiers.

According to an embodiment, user management service340is implemented using a GraphQL interface. GraphQL works similar to RESTFul APIs, but a system can be built that can have multiple sources such as RDBM, restful APIs, direct SQL, flat file, events, etc., and expose those data via GraphQL APIs. One benefit to using GraphQL is that the client can ask just the data it needs (which is fitting to this use case) and GraphQL service will fetch the data from appropriate data sources. Additional information regarding GraphQL and RESTFul APIs is found in “GraphQL or BUST: to use it or not to use it? That is the question” by Nordic APIS, published Jul. 11, 2018, the entire contents of which are incorporated by reference as if fully set forth herein.

Caller Context

An AASD-enabled web server sends, to auth service120with a session validation request, additional caller context information that identifies a restricted action that initiated the session validation request. Auth service120uses the context information to identify the authentication tier that is required for the current client request. According to an embodiment, caller context is an optional field, called “map”, in the validate session message to auth service120. Specifically, the map data field is configured to provide extra context about the caller that requested the restricted action. For example, auth UI server130is a special case server, and is configured to include, in validate session requests to auth service120, caller context information in the map field that identifies auth UI, e.g., {“caller_context”:{“target_page”: “auth UI” }}. As another example, web server242is a typical (non-special case) AASD-enabled server, and is configured to include, in validate session requests to auth service120, caller context information in the map field that identifies the requested restricted action, e.g., {“caller_context”:{“target_page”: “page_244”}}.

According to an embodiment, if a particular request is from a trusted source, such as a source that is known to be controlled by the same entity as the destination, then the context information may contain an unencrypted identifier of the target restricted action. Otherwise, auth service120requires that the caller context information contain encrypted text. According to an embodiment, the encrypted text includes both the identifier of the target restricted action and the session identifier. Because the session identifier in the request is part of the encrypted text, the encrypted text is unique for each session, and the encrypted text cannot be easily faked by copying the encrypted text from a request associated with another session. Furthermore, the encrypted text for the caller context may also include a timestamp for further added security.

Encryption for caller context information can be achieved in any way, including encryption using a private key of the calling server. Auth service120decrypts the context information using the corresponding public key. In such an embodiment, auth service120manages and stores the encryption keys for all web servers from which requests to auth service120are expected, or obtains the needed encryption keys from one or more other secure services. Encryption can also be achieved using a symmetric key. Specifically, auth service120generates one or more symmetric keys and assigns each key to a service or group of services.

Deferring Additional Authentication Steps for an AASD-Eligible Action

FIGS.7A-7Bdepict a flowchart700for deferring additional authentication steps that are not required for a given requested restricted action, according to one or more embodiments. Specifically, at step702of flowchart700, a client is authenticated to a first authentication tier of a plurality of authentication tiers for an application. For example, before performing any authentication steps for application100, client212requests page244of application100, which is a 1TP. The request for page244goes to web server242, which attempts to retrieve a session identifier for the current client session.

Session identifiers may be persisted in various ways. For example, client212is a browser-based client, and auth service120causes the session identifier to be sent to client212, which stores the session identifier in a cookie store214. Techniques are described herein as using cookie store214to store session identifiers, as a non-limiting illustration. As a further example, client212is a native mobile application, and auth service120uses an application programming interface (API) gateway to exchange tokens with client212, which may be implemented using OAuth, etc. In the case of a token-based authentication system, client212receives a token that represents the user session rather than the session identifier to be stored as a cookie.

In this example, web server242attempts to retrieve a session identifier for the current client session from cookie store214. In this case, there is no session identifier for a current client session because a session has not yet been established with application100. Accordingly, web server242automatically reroutes client212to login page132at auth UI server130. According to an embodiment, auth UI server130attempts to retrieve a session identifier from client212, but does not find any cookie for the session. Accordingly, Auth UI server130serves login page132to client212.

FIGS.8A-8Bdepict a flowchart800of interactions between entities depicted inFIG.2to enact AASD-based authentication for requested restricted actions of application100. As depicted at step1of flowchart800, through client212, a user enters user credentials (e.g., a username and password) into login page132. At step2of flowchart800, auth UI server130sends the username and password to auth service120for validation. At step3of flowchart800, based on information stored in authentication dataset122, auth service120determines whether the user credentials are valid. In this example, the user credentials are valid.

At step4of flowchart800, auth service120determines whether AAS are required for page244, e.g., based on caller context information sent with the login validation message. According to an embodiment, to determine whether AAS are required for the requested action, auth service120first determines whether the user associated with the username and password has opted out of AAS requirements. If the user has opted out of AAS, no AAS is required for requests associated with the current client session, and the first authentication tier is sufficient to perform all restricted actions of application100.

However, if the user has not opted out of AAS, then the requested action potentially requires AAS based on which authentication tier (if any) is associated with the action in the AASD registry in authentication dataset122. According to an embodiment, auth service120checks the registration information stored in the AASD registry to determine the authentication tier associated with page244, which is the first authentication tier. Because the first authentication tier requires only username and password, auth service120determines that no AAS are required (beyond the username and password verification, which was already performed).

In the embodiment depicted in flowchart800, at step5, auth service120determines whether client212is eligible for AASD, e.g., based on information maintained by account service110or based on information maintained by auth service120in authentication dataset122, etc. This step allows application100to deny AASD for particular clients or users (based on username and password), depending on an implementation. For purposes of the present example, either auth service120does not perform step5, or auth service120performs step5and determines that the user or client212is eligible for AASD.

Special Session Identifiers

At step704of flowchart700, a particular session identifier is generated and data that associates the particular session identifier with the first authentication tier is maintained, where each authentication tier, of the plurality of authentication tiers, is associated with one or more respective authentication steps of a plurality of authentication steps, and where the application comprises a first page that is associated with the first authentication tier, and a second page that is associated with a second authentication tier of the plurality of authentication tiers. For example, auth service120generates a normal session identifier (NS1) for client212and saves NS1 in authentication dataset122, as depicted in step6of flowchart800.

For client sessions that request restricted actions that are eligible for AASD, auth service120generates and tracks a special session identifier. Thus, in connection with the user credential validation request, auth service120also generates a special session identifier (SS1) for client212. According to an embodiment, auth service120generates SS1 for client212by generating a random session identifier to be SS1 and mapping the random special session identifier to NS1 in mapping data maintained in authentication dataset122. In this embodiment, auth service120stores SS1 in dataset122(e.g., in a separate table in dataset122from the normal session identifiers, or with a flag to indicate that SS1 is a special session identifier, etc.). According to another embodiment, auth service120generates SS1 for client212by encrypting NS1. For example, auth service120uses a secret key to encrypt NS1 to generate SS1. The same key can be used to decrypt SS1 to identify the associated normal session identifier for the client session, i.e., NS1; in this embodiment, SS1 does not need to be saved to authentication dataset122because SS1 can be derived from NS1, which is saved in dataset122.

Based on the validation of the user credentials (which is the only authentication step that has been completed by client212for the current client session), auth service120associates SS1 with the first authentication tier, either explicitly or implicitly via NS1. A session that is identified, by a client, via a special session identifier is eligible for AASD while a session that is identified, by the client, using a normal session identifier is not eligible for AASD. Thus, according to embodiments, using special session identifiers, authentication steps other than login with username and password are deferred until restricted actions associated with higher-security authentication tiers are requested.

At step7of flowchart800, auth service120sends a session valid message with SS1 to auth UI server130as a response to the request to for user credential validation (from step2). At step8of flowchart800, in response to receiving the session valid message, auth UI server130sends SS1 to client212to store in cookie store214. According to embodiments, client212uses SS1 as it would a normal session identifier, i.e., to identify the current client session in future communications with application100.

Deferral of Additional Authentication Steps Based on Special Session Identifier

At step706of flowchart700, a first request for the first page is received, where the first request is associated with the particular session identifier. For example, after receiving SS1 from auth service120, auth UI server130automatically reroutes client212to page244(the originally-requested page) with SS1 as the session identifier, as shown in step9of flowchart800. Accordingly, web server242receives the reroute request.

While this example shows the first request as a reroute request, the first request may be a direct request for a page from client212, e.g., a request for a 1TP while the current client session is associated with the first authentication tier. Furthermore, it is noted that, in an example where the client request was initially for login page132and page244is the default landing page after login, then the process would be very similar to that described above for the client212request for page244before being logged in. One difference would be that the initial request would be directly routed to auth UI server130, and then, once client212had been issued a special session identifier as described above, auth UI server130automatically reroutes client212to page244based on that page being the default landing page after client login.

At step708of flowchart700, as a response to the first request, information for the first page is provided to the client, based, at least in part, on the particular session identifier being associated with the first authentication tier and the first page being associated with the first authentication tier. For example, in response to receiving the request to route client212to page244, web server242sends a message to auth service120to validate the client session based on SS1 and context information identifying page244, as shown in step10of flowchart800. Upon receiving this request to validate the client session identified by SS1, at step11of flowchart800, auth service120checks authentication dataset122to determine whether the authentication tier associated with SS1 is the same as the authentication tier associated with page244(identified based on the caller context information sent from web server242).

While web servers request validation of client sessions based on both normal session identifiers and special session identifiers in the same way, which allows for backwards compatibility, auth service120validates special session identifiers differently than normal session identifiers. According to an embodiment, auth service120uses the presence of context information in a validate session request as an indicator that the session identifier in the request is a special session identifier. Accordingly, in order to validate SS1, auth service120attempts to derive a normal session identifier from SS1, where the process of deriving the normal session identifier depends on how special session identifiers are generated. In this case, auth service120derives NS1 from SS1, e.g., based on SS1 being mapped to NS1 in mapping data in dataset122, or based on decrypting SS1 to generate NS1, etc.

According to an embodiment, if the received session identifier (which was assumed to be a special session identifier based on being accompanied by context information) does not map to a valid normal session identifier, then auth service120attempts to validate the received session identifier as a normal session identifier. If the received session identifier is a normal session identifier, then the request is processed without AASD. According to another embodiment, if the received session identifier (which was assumed to be a special session identifier based on being accompanied by context information) does not map to a valid normal session identifier, then auth service120determines that the client session is invalid.

In this example, auth service120derives NS1 from SS1. After deriving NS1, auth service120attempts to validate the client session based on NS1, i.e., using normal session identifier information stored at dataset122. If, based on the normal session identifier, the client session is determined to be invalid, auth service120sends a message to the requesting entity indicating that the session is invalid. However, if, based on the normal session identifier, the client session is determined to be valid, then auth service120identifies an authentication tier associated with the special identifier within dataset122. In this case, auth service120determines that NS1 is valid. As such, auth service120identifies an authentication tier associated with SS1 in dataset122, which is the first authentication tier. Auth service120further identifies an authentication tier associated with page244is the AASD registry in dataset122, which is also the first authentication tier.

Because both SS1 and page244are associated with the first authentication tier, auth service120determines that no AAS is required for client212to access page244. In other words, authentication steps associated with authentication tiers that are higher-security than the first authentication tier are deferred until client212requests an action that requires a higher-security authentication tier. Thus, at step12of flowchart800, auth service120sends a message to server242indicating that the session identified by SS1 is valid, which works as authorization for web server242to serve page244to client212. In response to receiving the message that the session is valid, at step13of flowchart800, server242serves page244to client212(e.g., for client212to render on a display device).

Requiring Additional Authentication Steps for a Restricted Action

Returning to the previous example, if, while SS1 is associated with the first authentication tier, client212issues a request (associated with SS1) for a restricted action that is associated with an authentication tier that is higher-security than the first authentication tier, auth service120requires AAS before allowing the restricted action to be performed.

To illustrate, at step710of flowchart700, a second request for the second page is received, where the second request is associated with the particular session identifier. For example, as depicted at step14of flowchart800, client212navigates to page254, which is a 3TP, where the request is associated with SS1. Web server252receives the request for page254. This example is described with web server252being either AASD-enabled or non-AASD-enabled, in the alternative. According to an embodiment, steps712-718of flowchart700are performed in response to receiving the second request.

At step712of flowchart700, based, at least in part, on (a) the particular session identifier being associated with the first authentication tier and (b) the second page being associated with the second authentication tier, an authentication challenge associated with the second authentication tier is provided to the client. For example, in response to receiving the request from client212to navigate to page254, where the request includes SS1, web server252sends a request to auth service120to validate the session identified by SS1, as depicted in step15of flowchart800.

In the embodiment that web server252is not AASD-enabled, the validation request of step15is not accompanied by caller context information identifying page254. In this case, based on the lack of caller context in the validate session request, auth service120validates SS1 as if it were a normal session identifier, which fails because SS1 is not listed as a normal session identifier in dataset122. According to an embodiment, in response to SS1 failing to validate as a normal session identifier, auth service120attempts to validate SS1 as a special session identifier, which, in this case, does not fail, and proceeds as described below. (If the received session identifier also fails to validate as a special session identifier, then the client session is invalid.) This embodiment allows application100to leverage any authentication steps that have been performed in connection with the current session.

At step16of flowchart800, auth service120determines whether AAS is required to perform the requested action. When no context information accompanies a session validation request, auth service120determines that the requested action is implicitly associated with the highest-security authentication tier, and all authentication steps required to perform a restricted action associated with the highest-security authentication tier are required to perform the action. As discussed above, in the case that web server252is AASD-enabled, page254is associated with the third (i.e., highest-security) authentication tier of application100in the AASD registry, and all authentication steps required to perform a restricted action associated with the third authentication tier are required to view page254. Thus, according to an embodiment, web server252not being AASD-enabled has the same end result as if web server252were AASD-enabled, i.e., requiring client212to perform the AAS needed to access a third-tier restricted action.

More specifically, at step16of flowchart800, auth service120determines that SS1 is associated with the first authentication tier and page254is associated with the third authentication tier. Based on the authentication tier associated with SS1 being lower than the authentication tier associated with page254, auth service120determines that AAS is required for client212to navigate to page254. Based on this determination, and even though the session has not timed out and the user has not logged out of application100, auth service120sends a message to web server252indicating that the session associated with SS1 is invalid, as depicted in step17of flowchart800.

Generally, a message of session invalidity is sent when the client session is invalid, e.g., because there has not been a session established, the session has timed out, the client previously logged out of the session, etc. However, according to one or more embodiments, the message of invalidity sent at step17of flowchart800is used as a tool to force web server252(which may or may not be AASD-enabled) to redirect the request for the restricted action to auth UI server130, which implements AASD functionality. Auth UI server130then works with auth service120(as described in detail below) to ensure that all AAS required for the requested restricted action is performed before the client is allowed to perform the restricted action. The redirection of requests to auth UI server130, using the invalid session message, allows for backwards compatibility such that not all web servers implementing application100are required to be AASD-enabled.

Accordingly, in response to receiving the message that the session is invalid, web server252redirects client212to auth UI server130, as depicted by step18of flowchart800. According to an embodiment, the redirection request includes information identifying the target action of the original request, e.g., in this case, a URL identifying page254or caller context. At step19of flowchart800, auth UI server130retrieves the session identifier (SS1) from client212(e.g., stored in cookie store214), and, at step20, auth UI server130validates the session with auth service120based on SS1 and context information that identifies auth UI server130, as well as the target URL (or caller context) of the original request.

Because the context information of the session validation request identifies auth UI server130, which is the special-case web server implementing AASD functionality, auth service120does not respond to this validation request with an invalid session indicator, but instead responds to the request with an indication that the session is valid (at step21of flowchart800).

The valid session message sent to auth UI server130is accompanied by an indicator of one or more authentication steps needed for the client to satisfy requirements for the authentication tier associated with the requested action. According to an embodiment, the indicator comprises a status identifier that is associated with SS1 in dataset122. According to an embodiment, the status identifier is an identifier of the authentication tier associated with SS1. In the example session valid message of step21in flowchart800, the status identifier is “PENDING_KBA”, which is a non-limiting example of a status identifier for the first authentication tier. Because requests for restricted actions are rerouted to auth UI server130using an invalid session message, and auth UI server130then receives, from auth service120, a valid session message with information about AAS required for the requested action, the authentication steps are tied together such that continuity is maintained between what the user has previously done for authentication and what is still left to do in order to gain access to all possible actions within application100.

Based on the status identifier, such as PENDING_KBA depicted in step21of flowchart800, auth UI server130prompts the user to perform one or more AAS associated with the status identifier. For example, at step22of flowchart800, auth UI server130serves an authentication challenge page134A, which includes a KBA challenge, to client212.

At step714of flowchart700, based on user input to the authentication challenge via the client, the client is authenticated to the second authentication tier. For example, at step23of flowchart800, a user enters KBA information into authentication challenge page134A via client212, and, at step24, auth UI server130sends the received KBA information to auth service120for validation. At step25of flowchart800, auth service120validates the KBA information based on authentication dataset122. Upon determining that correct KBA information was entered, where KBA is the authentication step associated with the second authentication tier, auth service120associates SS1 with the second authentication tier in dataset122.

For purposes of illustration, the following explains what would happen if the requested page were associated with the second authentication tier (a 2TP). In this case, auth service120sends a session valid message with the special session identifier and without a status indicator, which works as authorization to route client212the 2TP. In response to the valid session message, auth UI server130sends a request to redirect client212to the AASD-enabled web server that serves the 2TP. In this case, when the web server sends a request to validate SS1 with context information identifying the 2TP, auth service120determines that the authentication tier associated with SS1 matches the authentication tier associated with the 2TP (i.e., the second authentication tier), and sends a session valid message to the AASD-enabled web server, resulting in the 2TP being served to client212, in a manner similar to steps10-13of flowchart800.

Returning to the illustration in which the requested page254is a 3TP, in response to validating the entered KBA information, at step26of flowchart800, auth service120sends another session valid message, to auth UI server130, with a second status indicator based on SS1 being associated with the second authentication tier, such as “PENDING_MFA”. At step27of flowchart800, based on receiving the valid session message with the “PENDING_MFA” status, which is associated with an MFA challenge page134B, auth UI server130serves MFA challenge page134B to client212. As depicted in step28of flowchart800, a user enters information into authentication challenge page134B, and, at step29, auth UI server130sends the MFA information to auth service120for validation. At step30of flowchart800, auth service120validates the MFA information based on authentication dataset122.

At step716of flowchart700, second data that associates the particular session identifier with the second authentication tier is maintained. For example, upon determining that MFA information from client212is validated, auth service120associates SS1 with the third authentication tier of application100in dataset122.

At step718of flowchart700, as a response to the second request, information for the second page is provided to the client based, at least in part, on the particular session identifier being associated with the second authentication tier. For example, as depicted in step31of flowchart800, after associating SS1 with the third authentication tier, auth service120sends a session valid message to auth UI server130with the normal session identifier (NS1) that is associated with SS1, according to an embodiment. This valid session message (without a status identifier) works to authorize routing client212to the target page254. At step32of flowchart800, auth UI server130causes client212to store NS1 in cookie store214as the new identifier of the current client session.

Furthermore, based on the valid session message of step31, auth UI server130routes client212to page254at web server252, as shown in step33of flowchart800. At step34, web server252sends a message (with or without caller context information identifying page254, as described in detail above) to auth service120to validate the client session based on NS1. At step35of flowchart800, auth service120validates the current client session based on NS1, which, the session identifier being a normal session identifier, no longer depends on AASD functionality. At step36, in response to determining that the client session identified by NS1 is valid, auth service120sends a session valid message to web server252with NS1. At step37, based on the valid session message, web server252provides the information for page254to client212, e.g., to render at a display device.

Functioning of Web Servers that are not AASD-Enabled

The following illustrates functioning of a non-AASD-enabled web server, such as web server252. In this example, web server252serves one or more webpages that may or may not be restricted webpages, i.e., where requests to view the webpages are restricted actions. Client212, which has not yet established a session with application100, requests page254, which is served by non-AASD enabled web server252. The request is routed, via network230, to web server252on server device250. According to an embodiment, when a web server implementing application100receives a request for a webpage, the web server sends a request to auth service120(on server device220) to validate the session (if any) associated with the page request. In this case, web server252does not have a session identifier to send to auth service120, nor does it send any context information identifying the page that was requested by client212(because the web server does not implement AASD functionality). Based on the lack of session identifier with the request, auth service120sends a message to web server252indicating that the session is invalid.

As a response to receiving the message that the session is invalid, web server252automatically reroutes client212to login page132, which reroute request goes to auth UI server130. In response to the reroute request, auth UI server130serves login page132to client212. Once a user enters credentials into login page132, and auth service120validates the entered credentials, auth service120generates a normal session identifier for the client session, as described above in connection with steps1-6of flowchart800.

Because web server252is not AASD-enabled, and does not include AASD-enabling caller context in the session validation request, auth service120does not produce a special session identifier for the session, but instead sends the normal session identifier to auth UI server130to be stored at client212. As such, auth service120sends the generated normal session identifier and an indicator stating that one or more AAS is required to auth UI server130. In response to this message, auth UI server130automatically provides one or more authentication challenge pages134A-N to client212. Auth UI server130sends any entered information to auth service120, and auth service120determines whether the one or more AAS have been satisfied, as described above.

In response to determining that the required AAS has been satisfied, auth service120sends a message to auth UI server130that client212has an active session identified by the normal session identifier. Auth UI server130sends the normal session identifier to client212to store in cookie store214. Auth UI server130then routes client212to page254at web server252. According to an embodiment, web server252again sends a message to auth service120to determine if the session is valid. Auth service120confirms that the session is valid and, accordingly, web server252serves page254to client212(e.g., for client212to render on a display device).

Alternatives and Extensions

Users may come to the login page organically or may try to access any page directly by providing the URL of another page instead of the URL of login page132. Before a user is routed to any new page from any page of application100, auth service120is called to validate the session.

The following use cases illustrate embodiments of AASD:1. User is an admin user that manages and accesses user info, where the username and password of the user is associated with an indication that the user is an admin user. For admin users, at step5of flowchart800, the user is determined to be not eligible for AASD. Thus, admin users must go through all authentication challenges up-front.2. User uses biometrics for login. If biometrics is used, then biometrics already provides another factor for the user. There is no need for challenging such users with MFA.3. A user comes for login organically to access a 3TP of application100. The following sequence of events happen:a. Events listed in steps1through8of flowchart800are followed (i.e., login through auth UI server130, and storing SS1 as a session identifier in a cookie).b. Events listed in steps14through37of flowchart800are followed (potentially omitting authentication steps for intervening authentication tiers).4. A user tries to access a 3TP of application100without coming to auth UI server130. The following sequence of events happen:a. The web server for 3TP tries to get a cookie stored in the session, but it does not find any. The web server redirects the client to auth UI server130for login.b. Auth UI server130does not find any cookie in the session and, accordingly, prompts the client for credentials.c. It now follows the events as in use case3.5. A user comes for login organically to access a 1TP, such as page256ofFIG.2, where web server252does not implement AASD functionality.a. Steps1through8of flowchart800are followed.b. Before being redirected to page256, web server252sends SS1 to auth service120for validation. This request does not contain a caller context.c. Auth service120does not find caller context in the validation request, so auth service120attempts to validate SS1 as if it were a normal session identifier. It fails.d. Steps17through32of flowchart800are followed.e. The user gets redirected to page256.6. A user comes directly to a 1TP, such as page256ofFIG.2, where web server252does not implement AASD functionality.a. Web server252tries to get a cookie stored for the session, but does not find any. Web server252redirects the client to Auth UI server130for login.b. Auth UI server130does not find any cookie for the session, and, as such, prompts the client for credentials.c. The steps in use case5are then followed.
Dynamically-Tiered Authentication

Dynamically-tiered authentication allows the authentication tier associated with a given client session to be automatically downgraded based on the client session satisfying one or more downgrade criteria. According to an embodiment, a client session satisfies downgrade criteria based on an explicit request for session downgrading, or based on passage of a pre-defined amount of time during which no activity (such as client interaction with the application, or activity on the client device) involving the higher-security authentication tier occurs. Unless the client session is downgraded to the public tier (i.e., the client is logged out of the application), automatically downgrading a client session restricts access to some authentication-based privileges for the client session without restricting access to all authentication-based privileges for the client session. Thus, session downgrading protects sensitive user information without the inconvenience that can be associated with logging a user out of the application.

Furthermore, according to an embodiment, the client session is upgraded based on an explicit request for session upgrade, or based on requesting a restricted action that requires a higher-security authentication tier than the tier associated with the current client session (as described in detail above).

FIG.9depicts a flowchart900for automatically downgrading the authentication tier of a client session, according to one or more embodiments. At step902, a particular session identifier is generated for a session of a client of an application, where the application supports a plurality of authentication tiers, where each authentication tier, of the plurality of authentication tiers, is associated with one or more respective authentication steps of a plurality of authentication steps, and where the plurality of authentication tiers includes (a) a higher-security authentication tier that allows first one or more restricted actions, and (b) a lower-security authentication tier that allows second one or more restricted actions. Tiered authentication may be implemented in one or more ways for dynamically-tiered authentication, according to one or more embodiments. The system described above in connection with flowchart800is one way to implement tiered authentication. Flowchart800is used in many examples of dynamically-tiered authentication herein for purposes of illustration. However, this example implementation of tiered authentication is non-limiting regarding techniques for dynamically-tiered authentication.

As another example, tiered authentication is implemented such that a current authenticated tier is stored along with session data to indicate a tier associated with the current client session (e.g., requests from the client include a session ID, and authentication tier, and, at times, one or more AAS associated with the authentication tier). This technique is desirable because session can be stateful, but auth service120does not maintain the needed state. Instead, auth service120maintains focus on validating user input to authentication steps. However, according to another embodiment, auth service120is stateful and maintains authentication tiers related to currently valid (or invalid) client sessions. In both cases, auth service120either maintains authentication tier and/or one or more AAS associated with the authentication tier (KBA, MFA, etc.) for client sessions, or is able to retrieve that information from one or more other sources.

To illustrate step902of flowchart900in the context of flowchart800, client212logs into application100, as described above, e.g., in connection with steps1-6of flowchart800. Based on the validated login information, auth service120generates a special session identifier for client212, which is sent to client212, as described above in connection with steps7and8of flowchart800.

At step904of flowchart900, the client is authenticated to the higher-security authentication tier. For example, after the client session for client212is established and the special session identifier (SS1) is associated with the first authentication tier, as described above, client212requests to navigate to page254, which is a 3TP. Based on the request to navigate to page254, application100authenticates client212to the third authentication tier, as described above in connection with steps14-30of flowchart800. In this example, web server252is AASD-enabled.

At step906of flowchart900, based on said authenticating the client to the higher-security authentication tier, authentication-tier data that associates the particular session identifier with the higher-security authentication tier is maintained. For example, auth service120stores, in mapping data of authentication dataset122, a mapping between the identifier of the current client session, SS1, and the third authentication tier. It is noted that, at steps31-32of flowchart800, client212receives a normal session identifier, NS1. However, according to an embodiment, client212continues to identify the current client session using SS1 (which is associated with NS1 is dataset122). Identifying the client session using the special session identifier allows for efficient automatic session upgrades and downgrades, as described herein.

According to another embodiment, tier information is embedded in the encrypted session identifier. In this way, when auth service120(the service that decrypts encrypted session identifiers) decrypts the session identifier for a given client session, auth service120derives, from the session identifier, the authentication tier that is associated with the client session. This is one way to retrofit this solution to an existing system that would require heavy lifting to store additional (tier level) information in session management.

Downgrade Criteria

At step908, it is detected that the session satisfies one or more downgrade criteria, where the one or more downgrade criteria comprise at least one of: an explicit request to downgrade the authentication tier associated with the particular session identifier, or passage of a pre-defined amount of time during which no activity involving the higher-security authentication tier occurs. One or more pre-determined amounts of time used to determine whether a session satisfies downgrade criteria may be configured in any way, depending on the needs of the particular application.

For example, the current client session for client212satisfies a downgrade criterion based on an explicit request to downgrade the session's authentication tier. To illustrate,FIGS.10A-10Cdepict example graphical user interface (GUI) versions1000-1020for page246, which is a 2TP. In this example, some third-tier restricted actions are accessible from page246. More specifically, in the example ofFIGS.10A-10C, page246is an account settings page that includes some PII that is accessible by clients that are authenticated to the second authentication tier. This second-tier PII includes the account nickname, the last three digits of the account number (the rest of which is redacted because the full account number is associated with the third authentication tier), the account email address, and a physical address associated with the account.

Furthermore, GUI1000ofFIG.10Aincludes a set of controls that requests restricted actions associated with the third authentication tier. Activation of one of these controls constitutes a request for a restricted action associated with the third authentication tier. This set of controls includes a display control1008for displaying the full account number1006, an edit control1010for editing the email address, and an edit control1012for editing the physical address.

While client212is authenticated to the third authentication tier, the version of page246that is displayed at client212is GUI1020ofFIG.10C. In GUI1020, account number1006is fully displayed and display control1008is deactivated. If, while client212is associated with the third authentication tier, either of edit controls1010or1012are activated, because client212is authenticated to the third authentication tier, the client is permitted to perform the associated restricted action without further authentication steps being required.

According to an embodiment, auth service120validates whether a tier-specific operation is permissible according to tier and data fields mapping (as described in further detail below). This embodiment prevents client session that are associated with lower-security authentication tiers from accessing the higher-security operation without permission. However, in micro services-oriented architecture, this may cause performance degradation because every operation requires validation. Thus, according to an embodiment, validation of whether tier-specific operations are permissible is handled by adding reactive measures such as alerts, monitoring, audit trails, etc., rather than relying on validating allowed operations.

Furthermore, in GUI1020, a current authentication tier indication1014shows that client212is authenticated to the third authentication tier. Indication1014is a non-limiting example of an authentication tier display. A downgrade control1004is available for activation (such as a mouse click on a GUI button), whereby downgrading of the authentication tier associated with the current client session may be requested. Further, an upgrade control1002is also included in example GUI1020, whereby upgrading of the authentication tier associated with the current client session may be requested. However, upgrade control1002is deactivated in GUI1020given that there is no higher authentication level to which client212may authenticate while the current client session is associated with the third authentication tier. According to an embodiment, a user interface allows requests to upgrade or downgrade by multiple authentication tiers.

Returning to the example given above in connection with step908of flowchart900, client212currently displays, at a display device, GUI1020. Downgrade control1004is activated via client212, which constitutes an explicit request to downgrade the authentication tier associated with the current client session.

As another example, client212satisfies a downgrade criterion based on passage of a pre-defined amount of time during which client212is active in application100, but the activity is associated with authentication tiers that are lower-security than the authentication tier associated with the current client session. For example, according to an embodiment, auth service120maintains, in dataset122, historical request data that records information for requests made by particular clients. In the historical request data, each record includes, at least, a timestamp indicating when the request was received, a session identifier associated with the request, and an authentication tier associated with the request. While the current client session for client212is associated with the third authentication tier and based on the historical request data, auth service120determines that, over a pre-determined past amount of time (e.g., five minutes), all activity associated with the current client session for client212is associated with the second authentication tier or lower. Based on this determination, auth service120determines that the current client session satisfies a downgrade criterion.

As another example, client212satisfies a downgrade criterion based on passage of a pre-defined amount of time during which client212does not request restricted actions for application100. For example, while the current client session for client212is associated with the third authentication tier and based on the historical request data, auth service120determines that, over a pre-determined past amount of time (e.g., two minutes), no requests are received at auth service120from client212. Based on this determination, auth service120determines that the current client session satisfies a downgrade criterion.

As yet another example, client212satisfies a downgrade criterion based on passage of a pre-defined amount of time during which client212is not active in application100. To illustrate, server device220runs a listener service222, which tracks user interactions with application100. More specifically, listener service222records, in historical interaction data, user interface interactions with application100, including clicks, taps, scrolls, mouse-overs, and keystrokes, etc., registered for application100user interfaces. To illustrate, while the current client session for client212is associated with the third authentication tier, auth service120determines that, based on historical interaction data, no interactions with interfaces of application100have been performed at client212over a pre-determined past amount of time (e.g., one minute). Based on this determination, auth service120determines that the current client session satisfies a downgrade criterion.

As yet another example, client212satisfies a downgrade criterion based on passage of a pre-defined amount of time during which no activity is detected at client device210. To illustrate, client device210runs a client-based listener service (not depicted inFIG.2), which tracks activity at client device210. According to an embodiment, the client-based listener service sends a warning message, to application100, if the client-based listener service does not detect activity at client device210(e.g., including mouse movements, mouse clicks, keystrokes, etc.) for a predefined amount of time (e.g., two minutes). Based on receiving a warning message from the client-based listener service at client device210, auth service120determines that the current client session for client212satisfies a downgrade criterion. Downgrading the client session based on device inactivity protects user information, available via application100, while the device is idle and potentially unattended.

According to an embodiment, data field-specific actions are associated with authentication tiers, e.g., in the AASD registry or other mapping data, by associating the data fields themselves, in the registry, with authentication tiers. For example, auth service, or other related system, maintains mapping data that maps authentication tiers to PII data fields. Types of data fields include, for example, FULL_SSN, FULL_FNAME, FULL_LNAME, EMAIL, LAST4_SSN, LAST3_ACCT_NUM, LAST4_PHONE_NUM, FIRST3_EMAIL, etc.

To illustrate, the second authentication tier is associated, in the mapping data, with the data field LAST4_SSN, and the third authentication tier is associated, in the mapping data, with the data field FULL_SSN. When the current client session is associated with the second authentication tier, a GUI displayed at the client includes a masked version of the SSN that displays only the last four digits of the number, based on the mapping of the second authentication tier to LAST4_SSN. When a request to unmask the SSN is received, such action triggers a request to upgrade to the third authentication tier, as described herein.

In connection with upgrading the client session to the third authentication tier, auth service120validates the current session and current tier, and returns a response to caller (web server) with information indicating one or more AAS required for the client session to authenticate to the third authentication tier, e.g., the status indicator described in detail herein.

Upon receiving response (with the information indicating the required one or more AAS) from auth service120, the web server redirects the client to auth UI server130with data that was received from auth service120. In response to the redirection, auth UI server130validates the current client session and associated authentication tier. Based on the received information, including the MFA_PENDING status, auth UI server130serves an MFA challenge page to the client. When the correct OTP code is submitted via the MFA challenge page, auth UI server130sends the OTP code validation request to auth service120. In response, auth service120validates the received OTP code and, based on the satisfied AAS, updates the current client session to be associated with the third authentication tier. Auth service120returns an authentication successful response to auth UI server130.

Auth UI server130redirects the client to the original destination, which is the page that the user was on from beginning of this operation by which the request to display the full SSN was requested. At this point, the page displays the full SSN based on the client session being associated with at least the authentication tier associated with FULL_SSN in the mapping data.

Determining the Target Downgrade Authentication Tier

Returning to flowchart900, at step910, in response to detecting that the session satisfies the one or more downgrade criteria, the authentication-tier data is updated to associate the particular session identifier with the lower-security authentication tier. For example, in the context of tiered authentication implemented by embedding an authentication tier for a current client session in the session identifier, the session identifier for a current client session indicates that the session is associated with the third authentication tier. While the client session is at the third authentication tier, there is an explicit request to downgrade the client session to the first authentication tier. This explicit request indicates that the target authentication tier is the first authentication tier.

In this embodiment, auth service120determines that the client session is valid at the third authentication tier and generates a new session identifier for the client session that embeds the first authentication tier. Auth service120returns the new session identifier to the caller web server in a successful downgrade response message, and the web server causes the new session identifier to be stored for the client. According to an embodiment, upon receiving the successful downgrade response message, the web server causes the client to display an indication, on the user interface, that the session downgrade was successful.

As another example, in the context of an implementation illustrated by flowchart800, in response to determining that the client session associated with SS1 satisfies one or more downgrade criteria, auth service120automatically associates SS1, in dataset122, with a target authentication tier. This target authentication tier for the session downgrade is one or more steps below the authentication tier associated with the client session at the time of session downgrade (referred to herein as the “pre-change” authentication tier).

According to an embodiment, auth service120identifies the target authentication tier, for a given session downgrade, to be a pre-defined number of authentication tiers (e.g., one authentication tier) below the pre-change authentication tier. In this way, if a client session continues to satisfy downgrade criteria over time (such as because the client device is left idle for a significant amount of time while the client is logged into the application, or because, after performing a high-tier restricted action, the user becomes interested in first-tier content for a significant amount of time) authentication tiers are stepped-down the hierarchy by the set amount. According to an embodiment, the pre-defined amount of time used to determine whether a session satisfies downgrade criteria is shortened at each sequential stepping down of session tier. For example, while the client device is idle, the first amount of time that triggers session downgrade is three minutes, the second amount of time that triggers session downgrade is two minutes, etc.

Stepping down the authentication tier hierarchy, rather than the client session being downgraded to the lowest authentication tier or a relatively low authentication tier all at once, extends the authentication-based rights of the client while protecting sensitive information and actions available at higher authentication tiers. This gradual downgrading can reduce the frustration a user might feel at being downgraded unintentionally, i.e., while the user planned to continue acting at a higher authentication tier.

According to an embodiment, auth service120identifies the target authentication tier, for a given session downgrade, based on information for the downgraded session at the time that the client session satisfies the downgrade criteria. For example, at the time of session downgrade, historical request data for client212indicates that over a threshold percentage of requests (which could be up to all requests) from client212, during a pre-defined amount of past time, were associated with a “focus” authentication tier, or were associated with an authentication tier that is at or below a focus authentication tier. If the focus authentication tier is lower than the pre-change authentication tier, then auth service120automatically identifies the focus authentication tier to be the target authentication tier for the session downgrade. In this embodiment, if the focus authentication tier is the pre-change authentication tier, then auth service120automatically identifies the next lower-security authentication tier, from the pre-change authentication tier, to be the target authentication tier for the downgrade.

According to an embodiment, auth service120identifies the target authentication tier, for a given session downgrade, based on the type of downgrade criteria that is satisfied by the client session. For example, when the downgrade criteria that is satisfied by the client session is based on client device inactivity, auth service120identifies the target authentication tier, for the session downgrade, to be the first authentication tier or a public tier. As another example, when the downgrade criteria that is satisfied by the client session is based on a lack of requests for the client recorded in historical request data, auth service120identifies the target authentication tier, for the session downgrade, to be the first authentication tier.

According to an embodiment, an explicit request to downgrade the client session targets a user-identified authentication tier, which is one or more tiers below the current authentication tier of the client session. For example, in response to detecting activation of downgrade control1004, application100automatically displays a pop-up window that requests input regarding the target authentication tier for the downgrade request. When a target authentication tier is selected through the pop up window, application100automatically downgrades the current client session to the indicated target authentication tier.

Tier Transitions

According to one or more embodiments, the effect of downgrading the authentication tier on the client depends on the state of client212at the time of session downgrade. For example, at the time of session downgrade, client212displays GUI1020ofFIG.10C. According to an embodiment, when the client session is downgraded to the second authentication tier from the third authentication tier, application100automatically routes client212to a default page associated with the second authentication tier.

According to another embodiment, when the client session is downgraded to the second authentication tier from the third authentication tier, the GUI of the currently-displayed page (e.g., page254) is adjusted based on the post-downgrade authentication tier. In the example of GUI1020, when the client session is downgraded to the second authentication tier, authentication tier indication1014displayed in GUI1020, which shows the current session authentication as the third authentication tier before the session is downgraded, is updated to reflect the downgraded authentication tier, as shown in GUI1000ofFIG.10A. Also, upgrade control1002is activated in GUI1000to allow explicit upgrading of the current authentication tier for the client session. Furthermore, as shown in GUI1000, application100redacts, from the currently-viewed page, information associated with the third authentication tier such that only information associated with the second authentication tier (or lower) is displayed in GUI1000.

As a further example, client212displays a user interface with information that is associated with the first authentication tier when the client session is downgraded to the first authentication tier. In this example, there is no change to the displayed user interface, other than to any indication of the current session authentication tier, as described above.

Timing

According to one or more embodiments, application100associates each authentication tier, of the plurality of authentication tiers, with a respective timeout period, e.g., in dataset122. A timeout period is a tier-specific amount of time on which used to determine whether a session, associated with a given authentication tier, satisfies downgrade criteria. To illustrate, for client212, the first authentication tier is associated with a 30 minute timeout period, the second authentication tier is associated with a 15 minute timeout period, and the third authentication tier is associated with a 5 minute timeout period.

According to an embodiment, at the time that a client session is associated with a particular authentication tier by auth service120, auth service120also sets a downgrade timer with the timeout period for the particular authentication tier. The downgrade timer measures the pre-determined amount of time that is used to determine whether a client session satisfies downgrade criteria, as described above.

According to an embodiment, when a client session changes authentication tier (via either downgrade or upgrade), the downgrade timer is reset with the timeout period of the new authentication tier. Such timer reset is performed whether the authentication tier is changed based on the timer tolling (i.e., the full timeout period has passed since the client session was associated with the pre-change authentication tier), or based on an explicit request, etc.

In this embodiment, there is effectively a single downgrade timer by which downgrades are determined, as illustrated by timeline1100ofFIG.11. In the example of timeline1100, client212is authenticated to the first authentication tier at authentication event1102, at which point a downgrade timer is initialized with 30 minutes according to the timeout period of the first authentication tier. After 20 minutes (time period1104A), client212is authenticated to the second authentication tier, at which point the downgrade timer is re-initialized with 15 minutes according to the timeout period of the second authentication tier. After five more minutes (time period1104B), the client session associated with client212is downgraded to the first authentication tier based on an explicit downgrade request. Upon the client session being associated with the first authentication tier, the downgrade timer is re-initialized with 30 minutes according to the timeout period of the first authentication tier. After 30 minutes at the first authentication tier without a session downgrade for client212(time period1104C), the client session is automatically downgraded to a public tier, as depicted by timeout event1108.

According to an embodiment, an extending event extends the amount of time left on the downgrade timer. Example extending events include requests that are associated with the current authentication tier for the client session, or an explicit request to extend the amount of time left on the downgrade timer. According to an embodiment, events that qualify as extending events are authentication tier-specific, and/or the amount of time by which the downgrade timer is extended is authentication tier-specific. For example, an extending event for the first authentication tier extends the time left on the downgrade timer by 5 minutes, an extending event for the second authentication tier extends the time left on the downgrade timer by 2 minutes, and an extending event for the third authentication tier extends the time left on the downgrade timer by 1 minute.

According to another embodiment, multiple tier-specific downgrade timers independently track the pre-determined amounts of time that are used to determine whether a given client session satisfies downgrade criteria. For example,FIG.11depicts a set of tier-specific timers1110A-1110C through times T1-T6. Specifically, at time T1, client212authenticates to the first authentication tier and, accordingly, a first authentication tier-specific timer1110A is initialized to 30 minutes based on the timeout period associated with the first authentication tier. After five minutes, at time T2, client212authenticates to the second authentication tier and, accordingly, a second authentication tier-specific timer1110B is initialized to 15 minutes based on the timeout period associated with the second authentication tier. At T2, there are 25 minutes left on timer1110A. While client212is authenticated to the second authentication tier, both timer1110A and timer1110B continue running.

At time T3, after five minutes of being authenticated to the second authentication tier, client212is authenticated to the third authentication tier and, accordingly, a third authentication tier-specific timer1110C is initialized to 5 minutes based on the timeout period associated with the third authentication tier. While client212is authenticated to the third authentication tier, all of timers1101A-1110C continue running. After five minutes at the third authentication tier, at time T4, the client session for client212satisfies a downgrade criterion based on timer1110C tolling. Furthermore, at time T4, timer1110B has not yet tolled, which means that the second-tier authentication has not yet expired. Because the second-tier authentication for client212has not yet expired, the client session for client212is downgraded to the second authentication tier.

In the absence of any extending events, at time T5(which is 15 minutes from time T2), the client session for client212is downgraded to the first authentication tier based on timer1110B tolling. Further, at time T6(which is 30 minutes from time T1), the client session for client212is downgraded to the public tier based on timer1110A tolling.

As depicted by a second set of tier-specific timers1120A-1120C, client212authenticates to the first authentication tier at time T7, and then to the second authentication tier at time T8that is five minutes after time T7, with respective timers1120A and1120B being initialized in a manner similar to timers1110A and1110B described above. At time T9, which is 13 minutes after time T8, client212is authenticated to the third authentication tier. In the absence of any extending events, at time T9, timer1120A has 12 minutes until tolling, and timer1120B has 2 minutes until tolling.

After two minutes at the third authentication tier, at time T10, timer1120B tolls, which does not qualify the client session for downgrade because it is not associated with the current authentication tier of the client session. At time T10, timer1120C has three minutes before tolling, and timer1120A has 10 minutes before tolling. At time T11, which is five minutes after time T9, the client session satisfies a downgrade criterion based on timer1120C tolling given that timer1120C is the timer that is associated with the pre-change authentication tier of the client session. In this case, because the second-tier authentication timer tolled before the third-tier authentication timer, the client session is downgraded to the first authentication tier, which still has remaining time before the associated timer tolls.

According to an embodiment, when a user explicitly downgrades before the time for the higher-security authentication tier expires, the timer for the higher-security authentication tier continues without being cleared. In this way, if the client requests re-authentication with the higher-security tier before the associated timer tolls, the client session is re-associated with the higher-security authentication tier without performing the AAS associated with the higher authentication tier based on the previous authentication (a “non-AAS upgrade”).

To illustrate in the context of the series of timers1110A-1110C, after a minute of being at the third authentication tier, at time T3A, the client session is explicitly downgraded to the first authentication tier. At the time of downgrading, there are four minutes remaining on timer1110C, nine minutes remaining on timer1110B, and 19 minutes remaining on timer1110C. Any time in the next four minutes (before time T4), the session may be re-associated with the third authentication tier without performing the AAS associated with the third authentication tier. Furthermore, any time in the next nine minutes (before time T5), the session may be re-associated with the second authentication tier without performing the AAS associated with the second authentication tier. For example, an event that instigates re-association of a session with a higher-security authentication tier is any event that would trigger authentication to the tier had the session not been eligible for a non-AAS upgrade.

According to an embodiment, when application100automatically downgrades a client session based on client device inactivity, any timers associated with higher-level authentication tiers are cleared such that the AAS associated with the higher tiers must be satisfied in order to return the session to the higher authentication tiers.

Upgrading the Session after Downgrading

According to an embodiment, a client session that is downgraded based on inactivity at the higher-security authentication tier is required to perform any AAS associated with higher-security tiers when the client requests a restricted action associated with the higher-security tiers. Such a restricted action may be a request to view a page that is associated with the higher-security authentication tier, a request to view redacted information (a higher-security request) in a page that is associated with the lower-security authentication tier, or a request to edit information (a higher-security request) in a page that is associated with the lower-security authentication tier, etc.

According to an embodiment, a request to upgrade the session authentication tier is performed without changing the currently-viewed page or the content thereon. For example, page244(a 1TP) includes a control, activation of which constitutes a request to upgrade the authentication tier associated with the current client session, such as upgrade control1002of GUI1000(FIG.10). A user at client212activates the upgrade control, thereby sending a request to upgrade the current client session from a first-tier authentication to a third-tier authentication. In this example, the AAS associated with the requested authentication tier (but not the AAS associated with intervening tiers) is completed in order to authenticate to the third authentication tier. Upon receiving this request, auth service120causes auth challenge page134B with an MFA challenge (associated with the third authentication tier) to be displayed, e.g., as a pop-up over page244. Once the MFA challenge is successfully completed, auth service120associates the client session with the third authentication tier and clears the pop-up, revealing page244. According to an embodiment in which the authentication tier of the current client session is displayed on page244, the only change to page244is to the current authentication indication, which is changed to show that the client session is now authenticated to the third authentication tier.

According to another embodiment, in response to upgrading the session authentication tier, previously-redacted information is displayed in the currently-viewed page. For example, while a current client session is at a second authentication tier, client212displays page246, which is a 2TP as shown in GUI1000ofFIG.10A. As indicated above, GUI1000includes some PII that is accessible at the second authentication tier, i.e., the account nickname, the last three digits of the account number (the rest of which is redacted as the full account number is associated with the third authentication tier), the account email address, and physical address. Furthermore, GUI1000includes the following controls, activation of which requests restricted actions associated with the third authentication tier: display control1008for displaying the full account number1006, an edit control1010for editing the email address, and an edit control1012for editing the physical address.

Through GUI1000, there are multiple paths to the third authentication tier, including activation of upgrade control1002, as discussed above, or activation of any of controls1008,1010, and1012. In this example, upon detecting activation of any of controls1008,1010, or1012, auth service120causes MFA challenge page134B to be displayed in a pop-up window, such as is depicted inFIG.10B. Once client212is authenticated to the third authentication tier, as described in detail above, the pop-up window is cleared and page246is displayed with third-tier information shown, as in GUI1020ofFIG.10C. Current authentication tier indication1014shows that the client is authenticated to the third authentication tier. Furthermore, account number1006is fully displayed. If, while the client is associated with the third authentication tier, either of edit controls1010or1012are activated, the client is permitted to perform the associated restricted action without further authentication steps being required.

Lower Authentication Level Emulation

According to an embodiment, application100is configured to emulate a lower-security authentication tier while the client session is associated with a higher-security authentication tier. Such lower-tier emulation is useful when a user wishes to show a user interface of application100to another person, but does not wish the other person to see or have access to the user's PII. For example, a client session being used by a businessperson is authenticated to an authentication tier that allows viewing of sensitive information, including multiple options for sales packages that the businessperson is authorized to offer a customer. The businessperson wishes to show the display to the customer, but does not wish the customer to see all of the sensitive information, including offers that would provide a lower commission to the businessperson. In this case, the businessperson causes application100to emulate a lower authentication tier, which hides the sensitive information, which emulation does not require re-execution of the authentication steps associated with the higher authentication tier upon the businessperson returning their screen to their exclusive view.

For example, emulation of the lower-security authentication tier causes the client to be redirected to a similar page that is associated with the lower-security authentication tier. As another example, emulation of the lower-security authentication tier causes higher-tier information to be redacted (or removed completely) from the GUI. Thus, authentication tier emulation saves time and frustration for the user. According to an embodiment, web servers implementing application100use a common module or common library that handles authentication tier-specific look and feel versions for webpages, which makes for efficient page development. For example, a common library provides a convenient and organized look and feel for each webpage of application100, which are authentication tier-specific. This library provides the information needed to mask information that is associated with a higher-security authentication tier when emulating a lower-security authentication tier.

Horizontal Tiers

According to an embodiment, authentication tiers are not strictly hierarchical in that information that is accessible across the tiers may be mutually exclusive. For example, on a client device that may be used by multiple different people within a company, each authentication tier represents a role in the company. In the case of horizontal tiers, a particular tier is configured to be the default authentication tier, which is treated as the lowest authentication tier. All other horizontal authentication tiers are treated as second-level authentication tiers. In accordance with techniques described above, a session that is at a second-level (horizontal) authentication tier is downgraded to the default authentication tier when the session satisfies the one or more downgrade criteria.

According to another embodiment, horizontal roles may be entered into for one or more authentication tiers of the plurality of hierarchical authentication tiers. These horizontal roles may also be organized in a separate hierarchy. To illustrate, a cashier is logged into a given machine as “cashier” role with a second-tier authentication. The cashier needs to perform an operation that is available only when in a “manager” role that is hierarchically higher than the “cashier” role. A manager comes and requests upgrading the role of the current client session to “manager”. As a condition of the upgrade operation, the manager solves one or more required authentication challenges, which includes providing a manager's username and password and/or scanning a managerial badge. After solving the one or more required authentication challenges, the current client session on the given machine is upgraded to a “manager” role with a second-tier authentication (based on the previous second-tier authentication while in the “cashier” role). While the client session is authenticated to the “manager” role, the manager performs one or more operations that are not allowed in “cashier” role at the second authentication tier. After performing the one or more operations, the manager explicitly downgrades the current client session back to the “cashier” role at the second authentication tier, and hands control of the machine back to the cashier.

Defining role-based horizontal tiers aids in tracking actions that were performed on a given client. For example, all actions performed while a session is at a particular horizontal authentication tier are logged to a log record that is specific to the particular horizontal tier. As such, log records are stored in association with the “roles” represented by the horizontal tiers rather than in a single composite log. Such logs are less expensive to audit than composite logs.

Network Architecture Overview

FIG.2is a block diagram that depicts an example network arrangement200implementing application100, according to embodiments. Network arrangement200includes a client device210and a server devices220,240, and250communicatively coupled via a network230. Example network arrangement200may include other devices, including client devices, server devices, and display devices, according to embodiments.

Client device210may be implemented by any type of computing device that is communicatively connected to network230. Example implementations of client device210include, without limitation, workstations, personal computers, laptop computers, personal digital assistants (PDAs), tablet computers, cellular telephony devices such as smart phones, and any other type of computing device.

In network arrangement200, client device210is configured with a client212. Client212may be implemented in any number of ways, including as a stand-alone application running on client device210, as a plugin to a browser running at client device210, etc. Client212may be implemented by one or more logical modules. Client device210may be configured with other mechanisms, processes and functionalities, depending upon a particular implementation.

Network230may be implemented with any type of medium and/or mechanism that facilitates the exchange of information between client device210and server device220. Furthermore, network230may facilitate use of any type of communications protocol, and may be secured or unsecured, depending upon the requirements of a particular embodiment.

Server devices220,240, and250may be implemented by any type of computing device that is capable of communicating with other devices over network230. In network arrangement200, server device220is configured with a plurality of services, including account service110, authentication service120, auth UI server130, and listener service222.FIG.2depicts these services running independently, but any of them may be implemented jointly, according to implementation. Server device220may run one or more other services/processes, including a web server serving pages stored at server device220or stored at memory that is accessible by server device220. Any of the functionality attributed to particular services/processes herein may be performed by another entity running on any of client device210, server devices220,240, or250, or on other devices that are communicatively coupled to network230, according to embodiments. Server devices220,240, and250may be configured with other mechanisms, hardware, processes, and functionalities, depending upon a particular implementation.

Any of authentication dataset122, login page132, and/or authentication challenge page(s)134A-N may be stored in persistent memory that is internal or external to server device220. For example, server device220is communicatively coupled to a database that maintains the indicated information. The database may reside in any type of storage, including volatile and non-volatile storage (e.g., random access memory (RAM), a removable or disk drive, main memory, etc.), and may be implemented by one or more logical databases. The storage on which the database resides may be external or internal to server device220.

Furthermore, in the example network arrangement200ofFIG.2, server devices240and250run respective web servers242and252, each of which serves one or more pages for application100. Pages being served by web servers242and252are depicted as being stored at the respective server devices (or in storage that is controlled by the respective server devices), but one or more of the pages may be stored by a different server device and served by the respective web server, depending on implementation. The webpages served by server devices240and250may or may not be within the same domain private/virtual private network as pages served by server device220, according to implementation. When a web server serves pages that are outside of the private network of pages served by server device220, the web server shares security credentials with auth service120in any way, including implementing single sign-on (SSO), using security markup language (SAML), signing part of a message, or in any other way. According to an embodiment, CSRF (cross-site reference forgery) is prevented using best security mechanism when dealing with cross-domain services.

One or more of the functions attributed to any service/process described herein, may be performed any other logical entity that may or may not be depicted inFIG.2, according to one or more embodiments. In an embodiment, each of the techniques and/or functionality described herein is performed automatically and may be implemented using one or more computer programs, other software elements, and/or digital logic in any of a general-purpose computer or a special-purpose computer, while performing data retrieval, transformation, and storage operations that involve interacting with and transforming the physical state of memory of the computer.

An application or service is a combination of integrated software components and an allocation of computational resources, such as memory, a machine node (i.e., a computing device and/or memory accessible to the computing device), and/or sub-processes on the machine node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients.

Hardware Overview

For example,FIG.12is a block diagram that illustrates a computer system1200upon which an embodiment may be implemented. Computer system1200includes a bus1202or other communication mechanism for communicating information, and a hardware processor1204coupled with bus1202for processing information. Hardware processor1204may be, for example, a general-purpose microprocessor.

Computer system1200also includes a main memory1206, such as a random access memory (RAM) or other dynamic storage device, coupled to bus1202for storing information and instructions to be executed by processor1204. Main memory1206also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor1204. Such instructions, when stored in non-transitory storage media accessible to processor1204, render computer system1200into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system1200further includes a read only memory (ROM)1208or other static storage device coupled to bus1202for storing static information and instructions for processor1204. A storage device1210, such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to bus1202for storing information and instructions.

Computer system1200may be coupled via bus1202to a display1212, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device1214, including alphanumeric and other keys, is coupled to bus1202for communicating information and command selections to processor1204. Another type of user input device is cursor control1216, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor1204and for controlling cursor movement on display1212. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.

The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage device1210. Volatile media includes dynamic memory, such as main memory1206. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.

Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor1204for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system1200can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus1202. Bus1202carries the data to main memory1206, from which processor1204retrieves and executes the instructions. The instructions received by main memory1206may optionally be stored on storage device1210either before or after execution by processor1204.

Computer system1200also includes a communication interface1218coupled to bus1202. Communication interface1218provides a two-way data communication coupling to a network link1220that is connected to a local network1222. For example, communication interface1218may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface1218may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface1218sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

Network link1220typically provides data communication through one or more networks to other data devices. For example, network link1220may provide a connection through local network1222to a host computer1224or to data equipment operated by an Internet Service Provider (ISP)1226. ISP1226in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the “Internet”1228. Local network1222and Internet1228both use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on network link1220and through communication interface1218, which carry the digital data to and from computer system1200, are example forms of transmission media.

Computer system1200can send messages and receive data, including program code, through the network(s), network link1220and communication interface1218. In the Internet example, a server1230might transmit a requested code for an application program through Internet1228, ISP1226, local network1222and communication interface1218.

The received code may be executed by processor1204as it is received, and/or stored in storage device1210, or other non-volatile storage for later execution.

Cloud Computing