Techniques for mixed-mode authentication are described. In one or more embodiments, an authentication service may be implemented to selectively configure and issue authentication tokens based upon an optional secure mode that enables enhanced security. Clients may be provided with an option to choose between an insecure mode and a secure mode for authentications. Based on this choice, tokens may be configured to include an indication of whether the secure mode is disabled or enabled. When secure mode is disabled, an insecure token valid for both secure sites and other sites is issued to a client when the client is authenticated. When the optional secure mode is enabled, both secure and insecure tokens are provided to the client. The authentication services and/or other services may be configured to reject an insecure token when secure mode is enabled to prevent unauthorized use of a stolen token to access secure resources.

BACKGROUND

The use of the Internet and World Wide Web (or simply the Web) is ever increasing. To prevent unauthorized access to resources on the Web, providers may require clients to authenticate to gain access to the resources.

In a traditional approach for authentication, a client may submit credentials (e.g., username and password) to an authentication service, which validates the credentials and if appropriate issues a token that can be used to gain access to resources. In this approach, authentication may occur over a secure channel, such as using Secure Sockets Layer (SSL)/Hypertext Transfer Protocol Secure (HTTPS) for secure communications or using another type of secure channel. For some providers, though, a token that is obtained over a secure channel in response to a “single sign-on” may be valid to access resources from various sites including some sites that are secure (e.g., sites using HTTPS) and some sites that may employ less security (e.g., sites using Hypertext Transfer Protocol (HTTP)).

Although the token may be encrypted, when the token is used during insecure communications with a site (e.g., HTTP communications in the clear), the potential exists for an attacker to steal the token. The attacker may then “replay” the token (e.g., present the token to a service) and thereby obtain unauthorized access, even to secure sites. Thus, tokens issued in accordance with traditional authentication approaches may be considered insecure because the tokens are susceptible to being stolen and replayed to gain unauthorized access to resources.

SUMMARY

Techniques for mixed-mode authentication are described. In one or more embodiments, an authentication service may be implemented to selectively configure and issue authentication tokens based upon an optional secure mode that enables enhanced security. In particular, clients may be provided with an option to choose between an insecure mode and a secure mode for authentications in various ways. Based on this choice, authentication tokens may be configured to include an indication of whether the secure mode is disabled or enabled.

When secure mode is disabled, an insecure token valid for both secure sites and other sites is issued to a client when the client is authenticated. When the optional secure mode is enabled, both secure and insecure tokens are provided to the client. The authentication services and/or other services may be configured to reject an insecure token when secure mode is enabled to prevent unauthorized use of a stolen token to access secure resources.

DETAILED DESCRIPTION

Overview

Traditional approaches for client authentication may provide a client with a token that is issued in response to a “single sign-on.” The token may be valid to access resources from various sites including some sites that are secure and some sites that employ less security. In this kind of mixed environment, an insecure token may be used over a secure channel with secure sites as well as over an insecure channel with other sites. Although the token may be encrypted, when the token is used during insecure communications with a site, the potential exists for an attacker to steal the insecure token. The attacker may then “replay” the token (e.g., present the token to a service) and thereby obtain unauthorized access, even to secure sites. Thus, the traditional approaches have security risks because the token is susceptible to being stolen and replayed to gain unauthorized access to resources.

Techniques for mixed-mode authentication are described. In one or more embodiments, an authentication service may be implemented to selectively configure and issue authentication tokens based upon an optional secure mode that enables enhanced security. Clients may be provided with an option to choose between an insecure mode and a secure mode for authentications. Based on this choice, authentication tokens may be configured with a mixed-mode flag or other data that indicates whether the secure mode is disabled or enabled. For example, a mixed-mode flag may be set to “0” or “1” to indicate that secure mode is disabled or enabled, respectively.

When secure mode is disabled, an insecure token valid for both secure sites and other sites is issued to a client when the client is authenticated. In other words, access to resources may occur in a way that is similar to traditional approaches when secure mode is disabled. However, even in the insecure mode, tokens may be configured to include the mixed-mode flag to differentiate tokens issued in the insecure mode from those issued in the secure mode.

When the optional secure mode is enabled, though, both secure and insecure tokens are provided to the client when the client is authenticated. The secure token is valid to access resources securely from a secure site, such as using SSL or other secure protocols. Generally, the secure token is configured for use over a secure channel and communication of the token over an insecure channel may be prevented or restricted. As the secure token is configured to be used over a secure channel it is unlikely to be stolen by an attacker. The insecure token is valid to access sites that may not support SSL to maintain compatibility with these sites. The insecure token may still be susceptible to being stolen during insecure communications with some sites. Various services from a service provider, though, can be configured to determine based on the mixed-mode settings whether secure mode is enabled and reject an insecure token when secure mode is enabled (e.g., mixed-mode=1). Accordingly, even if an insecure token is stolen under the secure mode, the token cannot be used to gain access to secure resources.

In the discussion that follows, a section entitled “Example Environment” describes an example environment and devices, which may be employed to provide mixed-mode authentication in various embodiments. Following this, a section entitled “Example Procedures” describes example techniques related to mixed-mode authentication in accordance with one or more embodiments. After that, a section entitled “Mixed-Mode Authentication Implementation Examples” describes example implementation details of mixed-mode authentication techniques that may be employed in one or more embodiments. Last, a section entitled “Example System” is provided and describes example systems and devices that can be used to implement one or more embodiments.

Example Environment

FIG. 1is an illustration of an example environment100that is operable to provide techniques for mixed-mode authentication. The illustrated environment includes one or more service providers102, one or more clients104, and one or more authentication services106that are communicatively coupled, one to another, over a network108. Although the network108is illustrated as the Internet, the network may assume a wide variety of configurations. For example, the network108may include a wide area network (WAN), a local area network (LAN), a wireless network, a public telephone network, an intranet, and so on. Further, although a single network108is shown, the network108may be configured to include multiple networks.

For the purposes of the following discussion, a referenced component, such as service provider102, may refer to one or more entities, and therefore by convention reference may be made to a single entity (e.g., the service provider102) or multiple entities (e.g., the service providers102, the plurality of service providers102, and so on) using the same reference number.

The service provider102may have one or more processors110and memory112. Service provider102is depicted as storing a resource manager114in the memory112that is executable via the one or more processors110. The resource manager114represents functionality operable by service provider102to manage various resources116that may be made available over the network108. For example, various resources116may be provided via web pages or other user interfaces that are communicated over the network for output by the one or more clients104. The resource manager114may manage access to the resources116, performance of the resources116, configuration of user interfaces or data to provide the resources116, and so on.

As illustrated, resources116made accessible by a service provider102may include one or more services118and/or content120. A service provider102may provide one or more sites, which a client104can navigate to in order to access the resources116. Sites accessible via a service provider102can include both secure sites and other sites that may employ lower security. The resources116can include any suitable combination of services118and/or content120typically made available over a network by one or more providers. Some examples of services118include, but are not limited to, a search service, an email service to send and receive email, an instant messaging service to provide instant messages between clients104, and a social networking service to facilitate connections and interactions between groups of users who share common interests and activities. Additional examples of services118include a shopping service, a weblog service, productivity service, an authentication service as described herein, a news service, and an advertisement service to name a few. Content may include various combinations of text, video, ads, audio, multi-media streams, animations, images, web pages, web applications, device applications, content for display by a browser or other device application, and the like.

The example authentication service106is depicted as including an authentication manager122that is representative of functionality to authenticate clients to access various resources116that may be provided by one or more of the service providers102. In at least some embodiments, the authentication manager122is configured to perform various techniques for mixed-mode authentication described above and below. The authentication service106may also include and/or manage an accounts database124that may be configured to store a variety of data related to user accounts with the one or more service providers102. By way of example and not limitation, accounts database124may store account identifiers that may be used for authentication and access control (e.g., unique account IDs, usernames, passwords, and so on) and profile data that may correspond to personal data and pages accessible through various resources116. Accounts database124may also include a configurable mixed-mode indicator or settings that controls whether a secure mode is enabled or disabled for a user account. A variety of other data is also contemplated, including service authorizations, user preferences, program files such as documents and spreadsheets maintained online, and other data typically associated with user accounts.

The authentication service106may be provided as a separate service as illustrated. For instance, authentication service106may be implemented by way of one or more standalone server devices having corresponding hardware (processors and memory) and software typically associated with server devices. Additionally or alternatively, an authentication service106may also be implemented by a service provider102. Accordingly, services118made available from a service provider102can include an authentication service106configured to perform techniques for mixed-mode authentication described herein.

In operation, a client104may provide a username and password that is authenticated by the authentication service. When the authentication is successful, the authentication service may issue a token to enable access to corresponding resources116. Tokens may be configured in a variety of ways. By way of example and not limitation, the term token as used herein may refer to encrypted cookies, encryption keys, digital certificates, binary large objects (BLOBs), a hash value, and/or other shared secrets or data that are suitable to make an authentication determination to determine whether a client104, or other entity, “is who they say they are.” In addition to being encrypted, tokens can be configured for use with particular protocols. For instance, insecure tokens may be configured for insecure communication protocols, such as HTTP. Likewise, secure tokens may be configured for corresponding secure communication protocols, such as SSL and/or HTTPS.

Authentication of the client104to an account may provide access to a single corresponding service provider102and/or to a single service118or other specific individual resources116. Additionally or alternatively, a single authentication or “single sign-on” may correspond to many resources116, such that authentication to a single account provides access to multiple resources116from one or more service providers102, such as providing access to an entire suite of services116(e.g., search, email, instant messaging, shopping, social networking, and so forth).

In at least some embodiments, the authentication manager122may configure tokens (e.g., cookies) associated with authentications in a manner that makes them suitable for mixed-mode authentication. Tokens may be selectively configured for a secure mode or an unsecure mode based upon the configurable mixed-mode setting mentioned above that may be associated with user accounts. In the secure mode, both secure and insecure tokens may be provided to the client. In insecure mode, an insecure token is provided. Tokens may also be configured to include an indication that secure mode is enabled. Further discussion of selectively configuring and issuing tokens in accordance with mixed-mode authentication techniques may be found in relation to the following figures.

The one or more clients104are depicted as having one or more processors126and memory128. To enable various communications over the network108, the one or more clients104may also include a communication module130. Communication module130may be configured to process user interface data from the service provider102to output a corresponding user interface132that enable interaction with various resources116.

The communication module130is depicted as being stored in memory128and is also executable via the processor126to provide various interactions with service providers102and/or resources116. Examples of such interaction include, but are not limited to, communicating one to another, navigating content120, navigating different sites from one or more providers service102, searching web pages, accessing services118, accessing web pages and other resources116, instant messaging, e-mail, and so forth. In at least some embodiments, the communication module130may be implemented as a browser or other suitable application to obtain and output web pages from the service provider102over the network108. The communication module130may also represent a component of another application used to obtain resources116from the service providers102. For example, a communication module130may be configured as a component of an email application, an instant messaging application, or other Web-enabled application of a client104.

Having considered devices and components of an example environment, consider now example mixed-mode authentication procedures that may be implemented in the environment using the example components, as well as in other environments.

Example Procedures

FIG. 2depicts a procedure200in an example implementation in which authentication is performed using mixed-modes. In at least some embodiments, procedure200may be performed by a suitably configured authentication service, such as by an authentication service106ofFIG. 1that includes or otherwise makes use of an authentication manager122.

A request for authentication and credentials are obtained (block202). For example a client104may seek authentication to obtain resources from a service provider102. One way this may occur is by way of an authentication service106. The client104may be redirected to the authentication service106when an attempt is made to access resources. At the authentication service106, authentication manager122may cause a login interface to be output requesting input of credentials that may be input via the login interface by the client104. The authentication manager122may then perform operations to authenticate the client104.

In particular, a determination is made regarding whether the credentials are valid (block204). For instance, the authentication manager122can check the validity of credentials provided by a client104(e.g., username and password) to authenticate the client104as discussed in relation toFIG. 1.

If the credentials are determined to be invalid, access is denied (block206). For instance, access to resources116can be prevented and/or a request to retry the authentication may be sent to the client104. In this case, the client is not “authenticated.”

If the credentials are determined to be valid, the client is “authenticated” and a determination is made regarding whether secure mode is enabled (block208). For example, authentication manager122may examine an account associated with the client104and/or the request to ascertain whether secure mode is enabled or disabled for the account. This may involve referring to data fields or other suitable account data associated with user accounts that indicate whether a secure mode is enabled or disabled for the account. Data suitable to determine whether secure mode is enabled may be referred to herein as mixed-mode indicators or settings. In at least some embodiments, users are provided an option to opt in or out of the secure mode. An option to enable secure mode can be provided at various times, such as when an account is created, when account preferences are updated, during authentication transactions, and/or when a site that is not secure is accessed. In one particular example, the mixed-mode indicator may be configured as Boolean mixed-mode field that is associated with accounts to indicate whether secure mode is enabled or disabled for the account. A value for the mixed-mode field is set accordingly when a user opts in or out of secure mode. The authentication manager122and/or a service provider102may then make use of the mixed-mode field to determine whether secure mode is enabled.

Based on this determination, the authentication manager122can selectively issue authentication tokens to the client. If secure mode is enabled, a secure token and an insecure token are issued to the client104(block210). If secure mode is disabled, an insecure token is issued to the client104(block212). For example, the secure token may be configured as an HTTPS cookie that is compatible with sites that use secure communications, such as secure sockets layer (SSL) or other secure protocols. The insecure token may be configured as an HTTP cookie that is compatible with sites that cannot or choose not to use secure communications. Providing both tokens in the secure mode enables enhanced security communications (e.g., HTTPS) using the secure token with secure sites and continued compatibility using the insecure token with sites that may not support secure communications and/or the security enhancements implemented by the secure mode.

Additionally, authentication manager122may configure both secure and insecure tokens to contain a mixed-mode flag that corresponds to the mixed-mode indicator for a corresponding account. The mixed-mode flag may be included with tokens in both the secure and insecure modes. In either case, the mixed-mode flag may be encrypted within the token to prevent tampering. This enables a service provider102to differentiate between tokens issued in secure mode from those issued in insecure mode. For example, the mixed-mode flag for both tokens issued in block210may have a value of “1” or “True” as secure mode is enabled. The mixed-mode flag for the insecure token issued in block212may have a value of “0” or “False” as secure mode is disabled.

Sites may be configured to make use of the mixed-mode flag included with tokens to understand whether the enhanced security of the secure mode is enabled for a corresponding account. In insecure mode, both secure sites and other sites may be configured to accept an insecure token. When an insecure token is used during insecure communications with a site (e.g., HTTP communications in the clear), the potential exists for an attacker to steal the insecure token. The attacker can then “replay” the insecure token (e.g., present the token to a service) and thereby obtain unauthorized access, even to secure sites. This type of attack is sometimes referred to as a man in the middle attack.

When secure mode is enabled, though, secure sites can be configured not to accept insecure tokens when the mixed-mode flag indicates that secure mode is enabled. In other words, a secure site may reject an insecure token when a corresponding mixed-mode flag has a value of “1” or “True.” This effectively forces the secure token to be used for secure sites when a user opts into the enhanced security of the secure mode. Even if the insecure token is stolen by an attacker during an insecure communication, the stolen token includes the mixed-mode flag indicating that secure mode is enabled. Accordingly, the token will not be accepted by secure sites or other sites configured to reject tokens based on mixed-mode settings. Thus, enabling secure mode may prevent unauthorized access to sites that may occur in traditional approaches through man in the middle attacks.

FIG. 3is a flowchart illustrating an example procedure300for authentication of a client to access resources. In particular,FIG. 3illustrates an example authentication sequence that may be employed when secure mode is enabled. Acts of procedure300illustrated on the left-hand side ofFIG. 3may be carried out by an authentication service, such as authentication service106ofFIG. 1. Acts of procedure300illustrated in the middle ofFIG. 3may be carried out by a client104. For example, the acts may be performed by a browser, or other suitably configured communication module130of a client104, that enables interaction with various webpages, or other UI's, that are provided at least in part over the network108. Acts of procedure300illustrated on the right-hand side ofFIG. 3may be carried out by a service provider, such as service provider102ofFIG. 1.

At the browser, secure mode is enabled (block302). For example, a user interface132output at the client104may provide functionality to enable a user to selectively choose between secure mode and insecure mode. This may occur during authentication or at another time such as when the user establishes an account, changes account settings, responds to a message, email, or other notification from the service provider102, and so forth. When the user selects secure mode, a mixed-mode indicator associated with the user's account may be set accordingly. The browser sends a request to the service provider for resources (block304). For instance, the browser may be navigated to a particular site, such as a home page or other resource page provided by the service provider102. The service provider receives the resource request (block306) and determines whether the client is authenticated (block308). For instance, the client104may have previously obtained a token that is valid to access resources from the service provider102. For a secure site in secure mode, this determination may involve determining if the client holds a valid secure token. An insecure token is not valid for a secure site when secure mode is enabled. Accordingly, if an insecure token is presented, the service provider may simply ignore the insecure token or otherwise reject the insecure token. If the client is authenticated, then the service provider responds to the resource request by providing the requested resources (block310).

If the client is not authenticated, though, the service provider redirects the client for authentication (block312). For instance, the client104may be redirected to authenticate with the authentication service106. The redirection may cause the client to send a request for authentication (block314) that is received by the authentication service (316). The authentication request may include credentials of the client104, such as a username and a password, or other suitable credentials. Typically, the authentication occurs using a secure communication channel, such as SSL or another suitable secure protocol. The authentication service authenticates the client using secure mode (318). For instance, authentication manager122may check the credentials in the request against credentials for the account in the accounts database126. The client104is authenticated when the credentials match. However, if the credentials do not match, the client may be prompted to re-input credentials and/or access may be denied.

Assuming authentication is successful, tokens are configured for the client (block320). For instance, secure and insecure tokens that each include a mixed-mode flag may be configured in the manner discussed in relation to example procedure200ofFIG. 2. In this example, the mixed-mode flag or other data for the secure and insecure tokens is set to indicate that secure mode is enabled (e.g., mixed-mode=“1” or “true”). If instead secure mode is disabled, an insecure token with a mixed-mode flag set to indicate that secure mode is disabled may be configured at this point.

The configured tokens are sent by the authentication service (block322) and received at the client (block324). Again, this typically occurs using a secure channel so that the tokens are not susceptible to being intercepted or stolen by a third-party.

The client may then present the tokens for access to resources (block326). As noted previously, the mixed-mode flag effectively forces the secure token to be used with secure sites. Less secure sites, though, may accept the insecure token. Thus, the client104can use the tokens that are obtained through the authentication sequence to access resources from both secure and other sites.

A site may obtain a token that is presented by a client (block328) and verify the token (block330). If the verification is not successful, the site may deny access and/or prompt the client104to re-authenticate. The verification of the token may include checking the mixed-mode flag to determine whether the secure mode is enabled. When secure mode is enabled, a secure site may be configured to deny a token based on the value of the mixed-mode flag. Thus, if an insecure token is presented using secure mode, verification of the token per block330will be unsuccessful. This prevents an attacker from using a stolen insecure token to access secured resources.

If the verification is successful, then the service provider102considers the client “authenticated” and therefore authorized to access corresponding resources116. Accordingly, the service provider provides the requested resources (block310) and the client obtains the resources (block332).

To further illustrate the described techniques for mixed-mode authentication, consider now a comparison of example depictions of interactions of a client104to obtain resources116from a service provider102using an insecure mode (FIG. 4) and a secure mode (FIG. 5). These depictions represent various example acts that can occur in the course of the interactions to obtain resources116and that are designated using different letters.

In particular,FIG. 4depicts an example diagram400in which secure mode is disabled and accordingly a mixed-mode flag has a corresponding value of “0.” A client104makes a resource request to a service provider102(Act A) and because the client104is not authenticated, the client104is redirected to an authentication service106(Act B). Credentials (e.g., username/password) are presented for authentication (Act C). In this example an insecure token, such as an HTTP token is returned having a mixed-mode flag with a value of “0” (Act D) in accordance with techniques described in relation toFIGS. 2 and 3. The insecure token can be presented by the client104(Act E) to obtain the requested resources. As represented, at402an attacker may steal or otherwise obtain the insecure token. This can occur at various times, such as when the token is returned to the client104over an insecure network, when the token is presented by the client using an insecure channel, or otherwise when the token is exposed to the attacker. The attacker can replay the token (Step F) and since the mixed-mode flag is set to “0,” the service provider102will accept the token even if the attacker is attempting to access secure resources from a secure site (e.g., HTTPS communications).

In contrast,FIG. 5depicts an example diagram500in which secure mode is enabled and accordingly a mixed-mode flag has a corresponding value of “1.” Here, a browser makes a resource request to a service provider102(Act A) and the client104is again redirected to an authentication service106(Act B) and credentials (e.g., username/password) are presented for authentication. In this example both a secure token (e.g., HTTPS Token) and an insecure token (e.g., HTTP token) having a mixed-mode flags with a value of “1” are returned (Act C) in accordance with techniques described in relation toFIGS. 2 and 3. The insecure token can be presented by the client104(Act D) to obtain the resources116over an insecure channel or network. As represented, at502an attacker may steal or otherwise obtain the insecure token when this occurs. The attacker can replay the token (Step E) to attempt access to secure resources from the service provider102. However, since the mixed-mode flag is set to “1,” the service provider102will not accept the token for access to secure resources from a secure site (e.g., HTTPS communications). Thus, even if the token is stolen, the attacker is effectively unable to use the token.

Having considered example procedures for mixed-mode authentication, consider now example scenarios that illustrate further implementation details of mixed-mode authentication in accordance with one or more embodiments.

Mixed-Mode Authentication Implementation Examples

The following discussion describes example implementation details of mixed-mode authentication techniques that may be employed in one or more embodiments. These implementation details are described in relation to example scenarios that are illustrated inFIGS. 6-10. These scenarios represent various example acts that can occur in the course of the interactions to obtain resources and that are designated using different letters. By way of example and not limitation, secure resources and service in the following scenarios are described in the context of using Secure Sockets Layer (SSL) for secure communication. Likewise, secure tokens for the purpose of the example scenarios correspond to HTTPS tokens and insecure tokens correspond to HTTP tokens. It is to be appreciated, though, that the mixed-mode authentication techniques described herein may be employed with various secure communication protocols and corresponding tokens typically used for client-server interactions, authentications, resource provision, and access management.

FIG. 6depicts an example scenario600in which an option to select secure mode is provided when a client104attempts to access a secure resource.FIG. 6includes a secure service602configured to use SSL and an insecure service604that is a non-SSL service. Various services are contemplated including, but not limited to, the example services118described in relation toFIG. 1. A request is made to access the secure service (Act A). The client104is redirected for authentication (Act B) and provides credentials such as a previously obtained token (Act C). Authentication service may now determine whether secure mode is enabled for the client104by checking the mixed-mode flag and/or mixed-mode indicator for the user account. If secure mode is enabled (mixed-mode=1), the client is authenticated to access the secure service602(Act D.1). If secure mode is not enabled (mixed-mode=0), the client104may be redirected to an interstitial sign-up page or site (Act D.2). Here, the client104may be provided with an option to opt into the secure mode. For instance, the client104may be provided with a webpage, sign-up screen, pop-up notification, or other suitable mechanism configured to facilitate the interstitial sign-up. The interstitial sign-up may include various selectable controls to enable a selection to switch from insecure mode to secure mode. If the client104does not choose to switch, control is returned to the secure service602(Act E1), and resources may be selectively provided based upon the token presented by the client104.

If a selection is made to switch to secure mode, an account refresh sequence is initiated to switch to secure mode (Act E.2). In this case, the mixed-mode indicator associated with a corresponding account may be set to indicate that secure mode has been enabled. Then, a redirection to the authentication service106is made to refresh the authentication token (Act F). Authentication service106may again request and verify credentials from the client104. Upon successful verification, authentication service106issues a new secure HTTPS token to the client104(Act G). Control is returned to the secure service602(Act H), which provides resources to the client104in response to the request.

FIG. 7depicts an example scenario700in which navigation between secure and insecure resources occurs in an insecure mode (mixed-mode=0).FIG. 7includes examples services including secure email702, insecure email704, a profile page706, and a calendar708.FIG. 7illustrates that a user who does not opt for secure mode may still navigate using HTTPS, but may cross the HTTP/HTTPS boundary as they interact with different services. For instance, client104may access secure email (Act A) and then navigate to access different services118. For instance, navigation may occur from secure email702to calendar708(Act B) and then back to email (Act C). In another example, navigation may occur from secure email702to profile706(Act D) and then back to email (Act E). Note that these navigations cross the SSL boundary between secure and insecure services. Accordingly, navigation back to email is illustrated as being directed to the insecure email704. However, a session based SSL bit can be included in the authentication token to cause redirection back to SSL when appropriate. In this example, a session based SSL bit for secure email702causes redirection back to secure email702following navigation to other unsecure services. Although, crossing the SSL boundary has some security risks, the session based SSL bit helps reduce the risks by redirecting to preserve the SSL experience as much as possible.

FIG. 8depicts an example scenario800in which navigation between secure and insecure resources occurs in a secure mode (mixed-mode=1).FIG. 8includes examples services including secure email802, a calendar804, and a profile page806. In this example, calendar804represents a secure site that supports SSL. Profile page806represents a site that does not support SSL.FIG. 8illustrates that when secure mode is selected, navigation to both secure sites and other sites is secure. For instance, client104may access secure email802(Act A) and then navigate to access different services118. For instance, navigation may occur from secure email802to calendar804(Act B) and then back to email (Act C). This navigation is secure because it occurs within the SSL boundary using secure communications. In another example, navigation may occur from secure email802to profile806(Act D) and then back to email (Act E). Navigation to sites in this manner does cross the HTTP/HTTPS boundary. However, with secure mode enabled, an insecure token used for navigation to a site is secure because the mixed-mode flag prevents the insecure token from being used to access secure resources, as discussed previously. Accordingly, navigation within and across the HTTP/HTTPS boundary when secure mode is enabled as represented inFIG. 8may be considered secure.

FIG. 9depicts an example scenario900in which an option to select secure mode is provided when a client104provides input to change from viewing a web page in HTTP to HTTPS. For instance, a client104may login to email using HTTP and then later select HTTPS. This may occur for example by a user typing HTTPS in the address bar of the browser, selection of a link or other control, a menu item selection, and so forth. This may cause a redirection from a non-secure service902to a secure service904.

When this happens, the client104may be provided with an option to opt into the secure mode. For instance, the client104may be provided with a webpage, sign-up screen, pop-up notification, or other suitable mechanism configured to facilitate the interstitial sign-up. This scenario is similar to the scenario previously described in relation toFIG. 6except the interstitial sign-up here is initiated responsive to input to change from viewing a web page in HTTP to HTTPS, rather than in response to a log-in sequence as inFIG. 6. Once the interstitial sign-up page or other mechanism is exposed the remaining acts depicted inFIGS. 6 and 9are substantially the same, and reference is made to the previous description of those acts.

FIG. 10depicts an example scenario1000in which an automatic switch to secure mode occurs when a client104logs in insecurely via HTTP to an account that has opted into to secure mode. In particular, the client104may use HTTP to access a service118, such as the example insecure service1002ofFIG. 10(Act A). Assuming the client104has previously opted into secure mode, insecure service1002, perhaps in conjunction with authentication service106, may reference a mixed-mode indicator associated with a corresponding account and determine that secure mode is enabled for the account and/or client104. Alternatively, the insecure service1002may be configured to determine that secure mode is enabled based on a mixed-mode flag included with an HTTP token/cookie presented by the client to access the insecure service1002.

Accordingly, the insecure service1002may redirect the client104to a corresponding secure service1004that may be configured to use SSL (Act B). If the token presented is valid, the client104may access secure resources from the secure service1004. If the token presented is invalid, the secure service1004may redirect the client for re-authentication (Act C). For example, the token may be an insecure HTTP token that the secure service will not accept because secure mode is enabled (mixed-mode=1). In this case, the client104may be redirected to obtain a secure HTTPS token that may be used to access secure resources from the secure service1004. For instance, the client104may resubmit credentials to the authentication service106(Act D). Upon verification of the credentials, authentication service106may issue a secure HTTPS token (Act E) that is valid for access to resources from the secure service1004. In this manner, a client104may be automatically upgraded to secure mode even if the client104logs in insecurely.

Having considered example implementation details related to mixed-mode authentication techniques, consider now a discussion of an example system and devices that may be employed to implement various aspects of the described techniques in accordance with one or more embodiments.

Example System

FIG. 11illustrates an example system generally at1100that includes an example computing device1102that is representative of one or more such computing devices that can implement the various embodiments described above. The computing device1102may be, for example, a server of a service provider102or authentication service106ofFIG. 1, a device associated with the client104, and/or any other suitable computing device or computing system.

The example computing device1102includes one or more processors1104or processing units, one or more memory and/or storage components1106, one or more input/output (I/O) interfaces1108for input/output (I/O) devices, and a bus1110that allows the various components and devices to communicate one to another. The bus1110represents one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. The bus1110can include wired and/or wireless buses.

The memory/storage component1106represents one or more computer storage media. The memory/storage component1106may include volatile media (such as random access memory (RAM)) and/or nonvolatile media (such as read only memory (ROM), Flash memory, optical disks, magnetic disks, and so forth). The memory/storage component1106may include fixed media (e.g., RAM, ROM, a fixed hard drive, etc.) as well as removable media (e.g., a Flash memory drive, a removable hard drive, an optical disk, and so forth).

The one or more input/output interfaces1108allow a user to enter commands and information to computing device1102, and also allow information to be presented to the user and/or other components or devices using various input/output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone, a scanner, and so forth. Examples of output devices include a display device (e.g., a monitor or projector), speakers, a printer, a network card, and so forth.

Various techniques may be described herein in the general context of software or program modules. Generally, software includes routines, programs, objects, components, data structures, and so forth that perform particular tasks or implement particular abstract data types. An implementation of these modules and techniques may be stored on or transmitted across some form of computer-readable media. The computer-readable media may include a variety of available medium or media that may be accessed by a computing device. By way of example, and not limitation, computer-readable media may comprise “computer-readable storage media.”

Software or program modules, including the communication module130, authentication manager122, resource manager114, and other program modules, may be embodied as one or more instructions stored on computer-readable storage media. The computing device1102may be configured to implement particular functions corresponding to the software or program modules stored on computer-readable storage media. Such instructions may be executable by one or more articles of manufacture (for example, one or more computing devices1102, and/or processors1104) to implement techniques for mixed-mode authentication, as well as other techniques. Such techniques include, but are not limited to, the example procedures described herein. Thus, computer-readable storage media may be configured to store instructions that, when executed by one or more devices described herein, cause various techniques for mixed-mode authentication.

The computer-readable storage media includes volatile and non-volatile, removable and non-removable media and/or storage devices implemented in a method or technology suitable for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer-readable storage media may refer to media and/or devices that enable persistent and/or non-transitory storage of information in contrast to mere signal transmission. The computer-readable storage media can include, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other storage device, tangible media, or article of manufacture suitable to store the desired information and which may be accessed by a computer.

Conclusion

Although the mixed-mode authentication techniques have been described in language specific to structural features and/or methodological acts, it is to be understood that the appended claims are not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as example forms of implementing the mixed-mode authentication techniques.