Background authentication refresh

Techniques for refreshing an authentication token. Access is granted to a secure computing environment in response to receiving authentication information from a requesting computing device. The access is granted for a session and one or more client applications allow secure delegated access to server resources on behalf of a resource owner by utilizing an access token. The access token is refreshed without explicit user interaction utilizing the authentication information for the session while the session is valid. Access is granted to the secure computing environment in response to the refreshed access token.

TECHNICAL FIELD

Embodiments relate to techniques for refreshing authentication tokens. More particularly, embodiments relate to techniques for generating refresh operates in the background to maintain authentication tokens without user interaction to improve the user experience in a secure environment.

BACKGROUND

Secure environments require some sort of authentication in order for a party to be authorized to access the environment. For example, in secure computing environments a user name and password is commonly required to utilize the computing environment. However, some computing environments utilize more sophisticated authentication procedures, for example, two-factor authentication, biometric authentication, OAuth. These more sophisticated authentication procedures require more input from users, which results in a more cumbersome process.

OAuth is an open standard for authorization that provides client applications a secure delegated access to server resources on behalf of the resource owner. OAuth specifies a process for resource owners to authorize third-party access to their resources without sharing credentials utilizing an access token. Access tokens can have a life time after which they expire and some reauthorization/reauthentication is required. This can be inconvenient for a user.

DETAILED DESCRIPTION

In the following description, numerous specific details are set forth. However, embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description.

The techniques described herein are generally described in terms of an OAuth 2.0 framework; however, the concepts described herein are applicable to many types of authentication. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. The OAuth 2.0 specification can be found in Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749 (tools.ietf.org/html/rfc6749).

In one embodiment, access (e.g., via API) is provided using a token that is acquired by redirecting a user to a login page. According to the OAuth 2.0 specification, the token expires after one hour (however, the exact length of time is not important). Thus, a user would have to be redirected to the login page each hour. Redirecting the user for reauthentication every hour can lead to a frustrating user experience.

In one embodiment, a silent request is utilized to accomplish reauthentication without redirecting the user. In one embodiment, a background redirect (e.g., via an asynchronous JavaScript and XML, or AJAX, call) is performed to accomplish the reauthentication without redirecting the user. In one embodiment, the silent request utilizes session information from the user, so the user does not experience any redirections when acquiring a new token.

In one embodiment, the techniques described herein can be accomplished without modification to the OAuth 2.0 flow. In one embodiment, the techniques described herein can be provided as browser (e.g., Chrome®, Internet Explorer®, Safari®, Firefox®, Edge®) extensions and/or AJAX calls and/or a sandbox. Generally speaking, a browser extension is a computer program that extends the functionality of a browser in some way. Depending on the browser and the version, the term may be distinct from similar terms such as plug-in or add-on. Some extensions are authored using web technologies such as HTML, JavaScript, and CSS.

FIG. 1is a block diagram of one embodiment of a system in which an authentication token can be utilized. The example ofFIG. 1includes resource owner100, which can be any entity capable of granting access to a protected resource. Resource owner100can be, for example, an end user. Resource owner100accesses services/resources via client application120, which can be, for example, an app on a mobile device, a web page accessed via a browser application, a program on a desktop/laptop computer.

Client application120operates to make protected requests (to access data/resources) on behalf of resource owner100with the authorization of resource owner100. Resource server(s)140is/are the server(s) that host the protected resource and can be capable of accepting and responding to protected resource requests using access tokens. In an OAuth example, resource server140provides an application programming interface (API) to provide access to the protected resource.

Resource server140can delegate authorization to authorization server160, which issues access/authentication tokens to client application120after authentication of resource owner100. In one embodiment, the components ofFIG. 1can operate according to standard OAuth 2.0 specifications. In another embodiment, the components ofFIG. 1can operate to provide background authentication so that resource owner100(e.g., an end user) is not redirected to provide credentials (e.g., username and password, two-factor authentication) frequently.

In one embodiment, session information can be used as substitute credentials in refreshing access tokens during the period that the session is valid. Because sessions are typically valid for a longer period than access tokens (e.g., 3 weeks vs. 1 hour), the frequency with which a user is required to provide security information is reduced while still providing a secure environment. In one embodiment, one or more of the servers providing resources has identity/authentication information for the user from providing a session. The server(s) can use the session information to communicate with the authentication server to refresh the authentication token. This allows the user to access secure resources with an authentication token with a limited lifespan for the length of a valid session without repeatedly entering authentication/identification information to acquire/refresh the authentication token.

FIG. 2is a flow diagram of one embodiment of a technique for providing background token refreshes. In one embodiment, session information is utilized to provide a background authentication token refresh that is transparent to the user, which improves the user experience. In one embodiment, the session can be for an on-demand services environment, for example, a multitenant database environment. Various on-demand service environment embodiments are described in greater detail below.

Authentication information is received,210. In one embodiment, a user can be presented with a login interface (e.g., login screen, biometric interface, multifactor authentication mechanism) through which the user can provide the requested authentication information (e.g., username and password, fingerprint, secret key). In one embodiment, the authentication information is received by the secure environment through which the user wishes to access resources, for example, the on-demand services environment mentioned above.

In one embodiment, the authentication information is used to start a session and acquire an authentication token,220. In one embodiment, the authentication token is acquired utilizing OAuth 2.x protocols; however, other authentication protocols can also be supported in a similar manner. In one embodiment, the one or more servers within the on-demand services environment can receive the authentication information and use the authentication information to both start a session and acquire an authentication token.

With appropriate authentication information, access is allowed,230. Access can be allowed to any secure computing environment, for example, the on-demand services environment discussed above. Access can be allowed,230, while the authentication token is not expired,240. When using the OAuth 2.x protocols, the tokens are valid for one hour; however, other time periods can also be supported. When the token is expired,240, one or more computing devices within the secure environment can utilize session information (e.g., authentication information required to start a session) to acquire a refresh token,250.

In one embodiment, a silent (or background) request is utilized to accomplish reauthentication without redirecting the user. In one embodiment, a background redirect (e.g., via an asynchronous JavaScript and XML, or AJAX, call) is performed to accomplish the reauthentication without redirecting the user. In one embodiment, the silent request utilizes session information from the user that has been provided previously (e.g.,210) to start the session, so the user does not experience any redirections when acquiring while refreshing the authentication token.

In one embodiment, the silent request is provided via a browser (e.g., Chrome®, Safari®, Firefox®, Edge®, Internet Explorer®) extension within a sandbox in order to provide a secure silent refresh. In alternate embodiments, servers within the secure environment may manage the silent requests.

FIG. 3is a block diagram of one embodiment of a background authentication token refresh agent. In one embodiment, background authentication token refresh agent300includes control logic310, which implements logical functional control to direct operation of background authentication token refresh agent300, and/or hardware associated with directing operation of background authentication token refresh agent300. Logic may be hardware logic circuits and/or software routines.

In one embodiment, background authentication token refresh agent300includes one or more applications312, which represent code sequence and/or programs that provide instructions to control logic310. Applications can provide various functional components of background authentication token refresh agent300.

Background authentication token refresh agent300includes memory314, which represents a memory device and/or access to a memory resource for storing data and/or instructions. Memory314may include memory local to background authentication token refresh agent300, as well as, or alternatively, including memory of the host system on which background authentication token refresh agent300resides.

In one embodiment, background authentication token refresh agent300also includes one or more interfaces616, which represent access interfaces to/from (an input/output interface) background authentication token refresh agent300with regard to entities (electronic or human) external to background authentication token refresh agent300. Interface(s)316can include, for example, the various APIs utilized to perform the functionality described above and/or the user interface discussed above. Other and/or different and/or additional interfaces can also be provided.

Background authentication token refresh agent300also includes background authentication token refresh engine320, which includes one or more functions or modules that enable background authentication token refresh agent300to provide the records management services as described above. The example ofFIG. 3provides several modules that may be included in background authentication token refresh engine320; however, different and/or additional modules may also be included. Example modules that may be involved in providing the records management functionality include authentication module330, token manager335, session manager340and token refresh module345. The modules of background authentication token refresh engine320can be hardware, software or a combination thereof.

In one embodiment, background authentication token refresh engine320includes authentication module330. In one embodiment, authentication module330operates to receive and store authentication information from a user. In one embodiment, authentication module330controls/operates the interface (e.g., graphical user interface) utilized to receive the authentication information from the user. In one embodiment, authentication module includes, or has access to, secure storage for storing authentication information and/or related data.

In one embodiment, token manager335operates to manage the authentication token. In one embodiment, token manager335operates according to the OAuth 2.0 standard; however, other authentication tokens can also be supported. In one embodiment, token manager335includes, or has access to, secure storage for storing authentication tokens and/or related data. In one embodiment, token manager335operated through one or more interfaces to securely communicate with an authorization server or other device to acquire an authentication token. Token manager335may receive the authentication token and/or related information from the authorization server.

In one embodiment, session manager340operates to manage access to one or more secure resources during a session, which can have a limited life (e.g., one day, two weeks, one month, 18 hours). In one embodiment, session manager340includes, or has access to, secure storage for storing authentication information related to session management. In one embodiment, session manager340operates through one or more interfaces to securely communicate with devices within the secure environment to manage the user session.

In one embodiment, token refresh module345operates as described above to provide background authentication token refresh operations without user interaction. In one embodiment, all or part of token refresh module may be implemented as a browser extension to provide the functionality described herein. In one embodiment, token refresh module345operates according to OAuth 2 protocols and utilizing OAuth 2-compliant APIs to refresh authentication tokens without explicit user involvement. This provides the user with the security provided by authentication tokens without the overhead and inconvenience of periodic manual reauthentication procedures.

FIG. 4illustrates a block diagram of an environment410wherein an on-demand database service might be used. Environment410may include user systems412, network414, system416, processor system417, application platform418, network interface420, tenant data storage422, system data storage424, program code426, and process space428. In other embodiments, environment410may not have all of the components listed and/or may have other elements instead of, or in addition to, those listed above.

Environment410is an environment in which an on-demand database service exists. User system412may be any machine or system that is used by a user to access a database user system. For example, any of user systems412can be a handheld computing device, a mobile phone, a laptop computer, a work station, and/or a network of computing devices. As illustrated in hereinFIG. 4(and in more detail inFIG. 5) user systems412might interact via a network414with an on-demand database service, which is system416.

An on-demand database service, such as system416, is a database system that is made available to outside users that do not need to necessarily be concerned with building and/or maintaining the database system, but instead may be available for their use when the users need the database system (e.g., on the demand of the users). Some on-demand database services may store information from one or more tenants stored into tables of a common database image to form a multi-tenant database system (MTS). Accordingly, “on-demand database service416” and “system416” will be used interchangeably herein. A database image may include one or more database objects. A relational database management system (RDMS) or the equivalent may execute storage and retrieval of information against the database object(s). Application platform418may be a framework that allows the applications of system416to run, such as the hardware and/or software, e.g., the operating system. In an embodiment, on-demand database service416may include an application platform418that enables creation, managing and executing one or more applications developed by the provider of the on-demand database service, users accessing the on-demand database service via user systems412, or third party application developers accessing the on-demand database service via user systems412.

User systems412might communicate with system416using TCP/IP and, at a higher network level, use other common Internet protocols to communicate, such as HTTP, FTP, AFS, WAP, etc. In an example where HTTP is used, user system412might include an HTTP client commonly referred to as a “browser” for sending and receiving HTTP messages to and from an HTTP server at system416. Such an HTTP server might be implemented as the sole network interface between system416and network414, but other techniques might be used as well or instead. In some implementations, the interface between system416and network414includes load sharing functionality, such as round-robin HTTP request distributors to balance loads and distribute incoming HTTP requests evenly over a plurality of servers. At least as for the users that are accessing that server, each of the plurality of servers has access to the MTS' data; however, other alternative configurations may be used instead.

One arrangement for elements of system416is shown inFIG. 4, including a network interface420, application platform418, tenant data storage422for tenant data423, system data storage424for system data425accessible to system416and possibly multiple tenants, program code426for implementing various functions of system416, and a process space428for executing MTS system processes and tenant-specific processes, such as running applications as part of an application hosting service. Additional processes that may execute on system416include database indexing processes.

FIG. 5also illustrates environment410. However, inFIG. 5elements of system416and various interconnections in an embodiment are further illustrated.FIG. 5shows that user system412may include processor system412A, memory system412B, input system412C, and output system412D.FIG. 5shows network414and system416.FIG. 5also shows that system416may include tenant data storage422, tenant data423, system data storage424, system data425, User Interface (UI)530, Application Program Interface (API)532, PL/SOQL534, save routines536, application setup mechanism538, applications servers5001-400N, system process space502, tenant process spaces504, tenant management process space510, tenant storage space512, tenant data514, and application metadata516. In other embodiments, environment410may not have the same elements as those listed above and/or may have other elements instead of, or in addition to, those listed above.

User system412, network414, system416, tenant data storage422, and system data storage424were discussed above inFIG. 4. Regarding user system412, processor system412A may be any combination of one or more processors. Memory system412B may be any combination of one or more memory devices, short term, and/or long term memory. Input system412C may be any combination of input devices, such as one or more keyboards, mice, trackballs, scanners, cameras, and/or interfaces to networks. Output system412D may be any combination of output devices, such as one or more monitors, printers, and/or interfaces to networks. As shown byFIG. 5, system416may include a network interface420(ofFIG. 4) implemented as a set of HTTP application servers500, an application platform418, tenant data storage422, and system data storage424. Also shown is system process space502, including individual tenant process spaces504and a tenant management process space510. Each application server500may be configured to tenant data storage422and the tenant data423therein, and system data storage424and the system data425therein to serve requests of user systems412. The tenant data423might be divided into individual tenant storage spaces512, which can be either a physical arrangement and/or a logical arrangement of data. Within each tenant storage space512, tenant data514and application metadata516might be similarly allocated for each user. For example, a copy of a user's most recently used (MRU) items might be stored to tenant data514. Similarly, a copy of MRU items for an entire organization that is a tenant might be stored to tenant storage space512. A UI530provides a user interface and an API532provides an application programmer interface to system416resident processes to users and/or developers at user systems412. The tenant data and the system data may be stored in various databases, such as one or more Oracle™ databases.

Application platform418includes an application setup mechanism538that supports application developers' creation and management of applications, which may be saved as metadata into tenant data storage422by save routines536for execution by subscribers as one or more tenant process spaces504managed by tenant management process510for example. Invocations to such applications may be coded using PL/SOQL534that provides a programming language style interface extension to API532. A detailed description of some PL/SOQL language embodiments is discussed in commonly owned U.S. Pat. No. 7,730,478 entitled, “Method and System for Allowing Access to Developed Applicants via a Multi-Tenant Database On-Demand Database Service”, issued Jun. 1, 2010 to Craig Weissman, which is incorporated in its entirety herein for all purposes. Invocations to applications may be detected by one or more system processes, which manage retrieving application metadata516for the subscriber making the invocation and executing the metadata as an application in a virtual machine.

Each application server500may be communicably coupled to database systems, e.g., having access to system data425and tenant data423, via a different network connection. For example, one application server5001might be coupled via the network414(e.g., the Internet), another application server500N-1might be coupled via a direct network link, and another application server500Nmight be coupled by yet a different network connection. Transfer Control Protocol and Internet Protocol (TCP/IP) are typical protocols for communicating between application servers500and the database system. However, it will be apparent to one skilled in the art that other transport protocols may be used to optimize the system depending on the network interconnect used.

In certain embodiments, each application server500is configured to handle requests for any user associated with any organization that is a tenant. Because it is desirable to be able to add and remove application servers from the server pool at any time for any reason, there is preferably no server affinity for a user and/or organization to a specific application server500. In one embodiment, therefore, an interface system implementing a load balancing function (e.g., an F5 Big-IP load balancer) is communicably coupled between the application servers500and the user systems412to distribute requests to the application servers500. In one embodiment, the load balancer uses a least connections algorithm to route user requests to the application servers500. Other examples of load balancing algorithms, such as round robin and observed response time, also can be used. For example, in certain embodiments, three consecutive requests from the same user could hit three different application servers500, and three requests from different users could hit the same application server500. In this manner, system416is multi-tenant, wherein system416handles storage of, and access to, different objects, data and applications across disparate users and organizations.

In certain embodiments, user systems412(which may be client systems) communicate with application servers500to request and update system-level and tenant-level data from system416that may require sending one or more queries to tenant data storage422and/or system data storage424. System416(e.g., an application server500in system416) automatically generates one or more SQL statements (e.g., one or more SQL queries) that are designed to access the desired information. System data storage424may generate query plans to access the requested data from the database.