Application Single Sign-On Systems and Methods

Abstract

A method and apparatus for authorizing a device to use a service are described. In one exemplary embodiment, the device intercepts a request for a webpage from a web browser running on the device, wherein the request includes an indication associated with an authorization request for a service, and the webpage provides the service. Additionally, the device presents an authorization user interface on the device. The device also performs local authorization using a set of user credentials entered via the authorization user interface. The device also performs server authorization with a server. Furthermore, the device redirects the web browser to the requested webpage, wherein the web browser is authorized to use the service provided by the webpage.

Description

[0001] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 856,059, filed June 1, 2019, the entire contents of which are incorporated herein by reference for the purpose of providing continuity of disclosure. Technical Field

[0002] This invention relates generally to application login, and more specifically to application single sign-on. Background Technology

[0003] A single sign-on service (SSO) is a service that allows a user to log in to multiple services across one or more authorized domains using a single set of credentials. For example, a user can log in to a company's media streaming service and another company's social media account using a single username and password combination (or another set of user credentials), even if the two companies are in different authorized domains. In this implementation, a SSO service is provided for multiple services across multiple authorized domains, and for various services from various sources, allowing the user to remember only a single set of credentials. Typically, when a user wants to log in to a first service (e.g., launching an application for the first time, logging back into the application, accessing a service via a web interface, accessing a service via a digital media player, and / or another scenario where the user is presented with an interface for service authentication), a user interface is presented to the user displaying both the application's native login user interface and the SSO user interface (e.g., "Connect with XYZ").

[0004] The problem with single sign-on (SSO) services is that the entity providing SSO services shares users' private information with various service providers. Often, this sharing of private information occurs without the user's knowledge of how it works. For example, a user may inadvertently share with a service provider, such as how often they use one or more applications, their real name, their real email address, and / or other private information, through the SSO service that allows them to authorize the service. Summary of the Invention

[0005] A method and apparatus for authorizing a device to use a service are described. In one exemplary embodiment, the device intercepts a request for a webpage from a web browser running on the device, wherein the request includes an indication associated with an authorization request for a service, and the webpage provides the service. Additionally, the device presents an authorization user interface on the device. The device also performs local authorization using a set of user credentials entered via the authorization user interface. The device also performs server authorization with a server. Furthermore, the device redirects the web browser to the requested webpage, wherein the web browser is authorized to use the service provided by the webpage.

[0006] A machine-readable medium having executable instructions that cause one or more processing units to perform a method for authorizing a device to use a service is described. In an exemplary embodiment, the machine-readable medium method intercepts a request for a web page from a web browser executing on the machine-readable medium method, wherein the request includes an indication associated with an authorization request for a service, and the web page provides the service. Additionally, the machine-readable medium method presents an authorization user interface on the machine-readable medium method. The machine-readable medium method also performs local authorization using a set of user credentials entered via the authorization user interface. The machine-readable medium method also performs server authorization on the server. Furthermore, the machine-readable medium method redirects the web browser to the requested web page, wherein the web browser is authorized to use the service provided by that web page.

[0007] In another implementation, the web request is a Hypertext Transfer Protocol request. Alternatively, the machine-readable medium method performs server authorization by sending a server authorization request to the server and receiving an authorization response from the server. Furthermore, the server authorization request is a Secure Remote Protocol request and uses a different process than that used to execute a web browser to present the authorization user interface.

[0008] In another embodiment, the machine-readable medium method intercepts a webpage request by: receiving the location of the webpage, determining the authorization that can be granted for the webpage, and loading an authorization extension to process the authorization for the webpage. Additionally, the authorization user interface includes components for receiving user credentials from the user, wherein the user credentials are selected from either biometric user credentials or a combination of a username and password.

[0009] A method for authorizing a device to use a service is described. In one exemplary embodiment, the method intercepts a request for a webpage from a web browser executed on the method, wherein the request includes an indication associated with an authorization request for the service, and the webpage provides the service. Additionally, the method presents an authorization user interface on a machine-readable medium. The method also performs local authorization using a set of user credentials entered via the authorization user interface. Server authorization is also performed on the server. Furthermore, the method redirects the web browser to the requested webpage, wherein the web browser is authorized to use the service provided by that webpage.

[0010] In another embodiment, a method and apparatus for authorizing a device to use a service provided by an application are described. In one exemplary embodiment, the device detects an authorization request for a service by means of an application running on the device, the service being provided by the application. Additionally, the device determines an identity provider associated with the application. The device also loads an authorization extension associated with the determined identity provider. The device further presents an authorization user interface corresponding to the authorization extension and receives local authorization for the device based at least on data received from the authorization user interface. Furthermore, the device negotiates an authorization token with a server and returns the authorization token to the application, whereby the application uses the authorization token to authorize the service provided by the application.

[0011] In another embodiment, a machine-readable medium is described having executable instructions for causing one or more processing units to perform a method for authorizing a device to use a service provided by an application. In one exemplary embodiment, the machine-readable medium method detects an authorization request for a service provided by the application through an application executed on the machine-readable medium method. Additionally, the machine-readable medium method determines an identity provider associated with the application. The machine-readable medium method also loads an authorization extension associated with the determined identity provider. The machine-readable medium method further presents an authorization user interface corresponding to the authorization extension and receives local authorization for the machine-readable medium method based at least on data received by the authorization user interface. Furthermore, the machine-readable medium method negotiates an authorization token with a server and returns the authorization token to the application, whereby the application uses the authorization token to authorize the services provided by the application.

[0012] In another embodiment, the machine-readable medium method detects an authorization request by receiving a web page request, wherein the web page request includes an indication associated with an authorization request for a service, and determines, at least based on the indication, that an application can be authorized to use the service. Additionally, an authorization user interface is presented using a process different from that used to execute the application. Furthermore, the machine-readable medium method detects the authorization request by receiving a request from the application to authorize the service.

[0013] In another implementation, the machine-readable medium method determines the identity provider by requesting a list of identity providers from a server, receiving the list of identity providers from the server, and selecting an identity provider from the list. Additionally, the server is a mobile device management server, the identity provider is a service capable of verifying identity, and the authorization extension is a user interface component for local authorization by entering a set of user credentials. Furthermore, the authorization user interface includes a component for receiving user credentials from the user, wherein the user credentials are selected from either biometric user credentials or a combination of username and password.

[0014] In another embodiment, a method for authorizing a device to use a service provided by an application is described. In one exemplary embodiment, the method detects an authorization request for a service provided by the application through an application executed on the method. Additionally, an identity provider associated with the application is determined. The method also loads an authorization extension associated with the determined identity provider. The method further presents an authorization user interface corresponding to the authorization extension and receives local authorization for the method based at least on data received from the authorization user interface. Furthermore, the method negotiates an authorization token with a server and returns the authorization token to the application, whereby the application uses the authorization token to authorize the services provided by the application.

[0015] Other methods and apparatus are also described. Attached Figure Description

[0016] The invention is illustrated by way of example and is not limited to the figures in the accompanying drawings, in which similar reference numerals indicate similar elements.

[0017] Figure 1 This is an illustration of an implementation of a system that handles application single sign-on via a browser.

[0018] Figure 2 This is a diagram illustrating one implementation of the application single sign-on process via a browser.

[0019] Figure 3 This is a diagram illustrating one implementation of the application single sign-on process via a browser.

[0020] Figures 4A to 4D This is a diagram illustrating an implementation scheme for a user interface used for application single sign-on via a browser.

[0021] Figure 5 This is a diagram illustrating an implementation scheme for a system that handles application single sign-on by intercepting authorization requests.

[0022] Figure 6 This is a diagram illustrating one implementation of the application single sign-on process that handles applications by intercepting authorization requests.

[0023] Figure 7 This is a flowchart of an implementation scheme for handling application single sign-on by intercepting authorization requests.

[0024] Figures 8A to 8D This is a diagram illustrating an implementation scheme for the application's single sign-on user interface.

[0025] Figure 9 This is a diagram illustrating an implementation of a system that uses an authorization process to handle application single sign-on.

[0026] Figure 10 This is a diagram illustrating one implementation of an application single sign-on process that uses an authorization procedure to handle the application's application.

[0027] Figure 11 This is a flowchart of an implementation of the process of using an authorization procedure to handle application single sign-on for an application.

[0028] Figure 12 This is a diagram of one implementation of a system for caching application information.

[0029] Figure 13 This is a flowchart of an implementation plan for the process of registering a developer.

[0030] Figure 14 This is a flowchart of an implementation plan for handling user login.

[0031] Figure 15 An example of a typical computer system that can be used with the implementation scheme described herein is shown.

[0032] Figure 16 An example of a data processing system that can be used with one embodiment of the present invention is shown. Detailed Implementation

[0033] A method and apparatus for authorizing a device to use a service are described. Numerous specific details are set forth in the following description to provide a thorough explanation of embodiments of the invention. However, it will be apparent to those skilled in the art that embodiments of the invention may be practiced without these specific details. In other instances, well-known components, structures, and techniques have not been shown in detail so as not to obscure the understanding of this description.

[0034] In this specification, the reference to "an embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with that embodiment may be included in at least one embodiment of the invention. The phrase "in an embodiment" appearing in various places throughout this specification does not necessarily refer to the same embodiment.

[0035] In the following description and claims, the terms “coupled” and “connected” and their derivatives may be used. It should be understood that these terms are not intended to be synonymous with each other. “Coupled” is used to mean that two or more elements may or may not be in direct physical or electrical contact with each other, and cooperate or interact with each other. “Connected” is used to mean the establishment of communication between two or more elements that are coupled to each other.

[0036] The processes illustrated in the following figures are executed by processing logic, which includes hardware (e.g., circuitry, special-purpose logic, etc.), software (such as software running on a general-purpose computer system or a special-purpose machine), or a combination of both. While these processes are described below in a certain order, it should be understood that some of the operations may be performed in a different order. Furthermore, some operations may be performed in parallel rather than sequentially.

[0037] The terms “server,” “client,” and “device” are intended to refer generally to a data processing system, rather than to specific form elements of a server, client, and / or device.

[0038] A method and apparatus for authorizing a device to use a service are described. In one embodiment, a single sign-on service is a service that allows a user to log in to multiple services across one or more authorized domains using a single set of credentials. For example, a user can log in to a company's media streaming service and another company's social media account using a single username and password combination (or another set of user credentials), even if the two companies are in different authorized domains. In this embodiment, the single sign-on service has multiple services on multiple authorized domains, and for various services from various sources, the single sign-on service allows the user to remember only a single set of credentials. Typically, when a user wants to log in to a first service (e.g., first launch of an application, re-login to the application, access to a service via a web interface, access to a service via a digital media player, and / or another scenario where an interface for service authentication is presented to the user), a user interface is presented to the user, which displays the application's native login user interface and the single sign-on user interface (e.g., "Connect with XYZ").

[0039] The problem with single sign-on (SSO) services is that the entity providing SSO services shares users' private information with various service providers. Often, this sharing of private information occurs without the user's knowledge of how it works. For example, a user may inadvertently share with a service provider, such as how often they use one or more applications, their real name, their real email address, and / or other private information, through the SSO service that allows them to authorize the service.

[0040] In one implementation, the new single sign-on service allows users to log in to different services across different authorization domains using a single set of credentials without sharing private information, unless the user explicitly authorizes the sharing of private information. In this implementation, for the new single sign-on service, a user is associated with a user identifier that can be used to authenticate the user and authorize the user and / or the user's devices to use one or more services across multiple authorization domains. Additionally, the user can control what information is shared with these service providers. In one implementation, each device in the user's device group (e.g., smartphone, tablet, laptop, digital media player, and / or another device) is a trusted device. In another implementation, the user's devices are trusted because each device has logged in using a high-trust mechanism such as two-factor authentication. For example, in one implementation, a trusted device is a device that the authorization domain knows is the user's device and can be used to verify the user's identity.

[0041] In one implementation, an authorization domain is a collection of one or more services and / or one or more authorization mechanisms that allow a user to be authorized to use one or more services provided by that authorization domain by using the authorization mechanisms of that authorization domain. Additionally, these authorization mechanisms can be used to authorize one or more user devices associated with a user to use one or more authorized services. In one implementation, each user is associated with a unique identifier (e.g., a user identifier) ​​that can be used across authorization domains. For example, in one implementation, a user and / or a user's device can use an authorization domain to purchase applications, and / or purchase streaming media, store content in cloud storage, access social media and / or other types of services.

[0042] In one implementation, the new single sign-on service provides single sign-on for multiple services, either provided by native applications on a user's device or through a web browser across multiple authorized domains. This allows users to log in to different applications and / or services using their user identifier without exposing their user identifier (and / or other private information) to the developers or providers of the different applications and / or services.

[0043] Additionally, the new single sign-on service provides proximity single sign-on on a first device, where a second user device allows the user to enter a set of credentials identifying the user in order to authorize services on that first device. An example of this single sign-on service is shown in U.S. Patent Application No. 16 / 888,482, filed May 29, 2020, entitled “Systems and Methods for Proximity Single Sign-On,” which is incorporated herein by reference.

[0044] Furthermore, the new single sign-on service can protect users' real email addresses by providing an anonymous email relay. This anonymous email relay is used to hide the user's real email address between the user and one of the service providers (e.g., the developer of the application the user logs into using the new single sign-on service). In one implementation, the single sign-on service allows users to remember only their user identifier across many different applications, and users can obtain emails from third-party developers without exposing their identifier information through email accounts set up for both the user and the developer.

[0045] Furthermore, the new single sign-on service uses a privacy-preserving machine learning risk assessment system to provide service providers with authentic user indicators. This system allows the service provider to forgo other mechanisms used to indicate that a genuine user is using its service (e.g., allowing the service provider to forgo additional user authentication steps, such as the fully automated Turing Test (CAPTCHA) mechanism that distinguishes between computers and humans). An example of anonymous email relay is shown in U.S. Patent Application No. 16 / 888,461, filed May 29, 2020, entitled "Systems and Methods of an Anonymous Email Relay," which is incorporated herein by reference.

[0046] Additionally, the new single sign-on service allows users to use a user identifier associated with an authorized domain to log in to applications and / or services in other authorized domains, where the user identifier and / or user device is not part of the other authorized domain. In one implementation, a user can use a user identifier that is part of authorized domain B to log in to one or more applications, which are authorized domains A1, ..., A n This is part of the login service. It enables the use of applications on one or more user devices without revealing user identifiers or other private information to the developers or providers of those applications. Additionally, the user identifier can be used to log in to one or more applications that are part of an authorization domain B.

[0047] Figure 1 This is an illustration of an implementation scheme of a system 100 that handles application single sign-on via a browser. Figure 1In this system, system 100 includes an authorization request device 102 coupled to a web server 112, an identity provider 116, and a mobile device management (MDM) server 118. In one embodiment, the authorization request device 102 is any type of device capable of executing an application (e.g., a smartphone, laptop, personal computer, server, tablet, wearable device, vehicle component, and / or any type of device capable of processing instructions for an application). Furthermore, in one embodiment, the web server 112 is a device that can receive requests for data (web pages, documents, videos, images, audio, objects, and / or any other type of data) and return that data to the requesting device. Additionally, the identity provider is a provider capable of verifying the identity of a user.

[0048] In one embodiment, the authorization request device 102 includes a browser 104 coupled to an authorization request process 106 and an authorization process 110. In one embodiment, the authorization request process 106 processes login requests to the browser 104. Additionally, the authorization process 110 processes authorization requests to the browser 104, detects authorization requests, and forwards them to the authorization request process 106. Furthermore, the browser 104 includes a web process 108 that sends web requests and receives responses to those requests. The web process 108 also processes received data and renders the data for display.

[0049] In one implementation, the MDM server is a server that performs MDM services, which are security services used by the IT department to monitor, manage, and protect employees' mobile devices deployed across multiple mobile service providers and multiple mobile operating systems used within the organization. In one implementation, the MDM server 118 includes a list of identity providers, where a device can select an identity provider to use with the authorization process.

[0050] In another embodiment, web process 108 sends a web request to web server 112. Web process 108 checks authorization cache 114 on device 102 to determine whether the web request should be authorized on that device or another device, or whether authorization is required for the web request. In one embodiment, authorization cache 114 includes information that allows authorization process 110 to check whether a web request requires authorization. In this embodiment, authorization cache 114 may include a list of domains requiring authorization. Furthermore, authorization cache 114 may include one or more authorization tokens for previously authorized domains, Uniform Resource Identifiers (URIs), and / or Uniform Resource Locators (URLs). Therefore, authorization process 110 can check whether a URL requires authorization or has been previously authorized. Additionally, because authorization cache 114 is on the device, these checks can be performed on the device, so the checks are not performed using a server. In one embodiment, because remote authorization checks are not required, this allows these authorization checks to remain private. In another embodiment, authorization cache 114 is updated periodically (e.g., every 24 hours). In this embodiment, authorization cache 114 is updated using authorization domain information and / or authorization tokens associated with the user. In one implementation, a user can authorize on different devices, and the authorization (e.g., by issuing an authorization token) is propagated to the user's other devices. In another implementation, websites and / or applications visited by the user are stored locally on the device by using an authorization cache 114 on the authorization request device 102, because the checks are performed locally and not on a remote server.

[0051] If authorization is required for the URL of a web request, web process 108 sends a request to authorization process 110 to perform an authorization request for the URL. Authorization process 110 then sends a request to authorization request process 106 to load an authorization extension 120 for the URL. In one embodiment, the authorization extension is an extension that includes authorization user interface components and / or resources to communicate with the identity provider associated with the authorization extension. In one embodiment, the URL is associated with a specific identity provider (such as identity provider 116). For example, in one embodiment, if the URL is used for a streaming service, the corresponding identity provider could be an identity provider that supports that streaming service. This identity provider could be a provider that authenticates various services and / or URLs (e.g., large media companies, technology providers, etc.), or a specialized identity provider that authenticates a small subset of URLs and / or services (e.g., companies, governments, educational organizations, etc.). In response, authorization process 110 receives the authorization extension and uses these extensions to load the authorization user interface on device 102. In one embodiment, the authorization user interface is handled by authorization process 110 and is not part of the process of browser 104. In one embodiment, the authorization user interface is located above the browser user interface. (The following...) Figures 4A to 4D An implementation scheme for an authorized user interface is discussed in the paper.

[0052] In one implementation, the authorization user interface requests the user to log in to the requested URL. In response to presenting the authorization user interface on authorization process 110, the user selects single sign-on and enters user credentials. Upon receiving the user credentials, authorization process 110 can perform local authentication using authentication components and security hardware 116, which are part of authorization process 110. For example, in one implementation, authorization process 110 sensors capture biometric data and use the sensor data in security hardware 116 for local authentication. For example, in one implementation, a biometric sensor is used for facial recognition to collect data for comparison with a template in the security hardware. In one implementation, authorization process 110 determines that the user interacting with authorization process 110 is known to authorization requesting device 102 by performing local authentication. In one implementation, authorization requesting device 102 does not require two-factor authentication because authorization requesting device 102 is a trusted device with valid access continuation parameters.

[0053] If the authorization process 110 successfully performs local authentication, it sends a server authorization request to the identity provider 116. In one embodiment, server authorization is used to authenticate the user and authorize device 102 to use the requested URL. In this embodiment, the authorization process 110 sends a Secure Remote Protocol (SRP) request to the identity provider 116 with access continuation parameters. In one embodiment, the authorization requesting device 102 is trusted based on two-factor authentication. Due to the two-factor authentication, the authorization process 110 receives access continuation parameters, which can be used in the server authorization request sent to the identity provider 116. In one embodiment, the access continuation parameters allow the authorization requesting device 102 to access the account associated with the user without requiring the authorization requesting device 102 to provide a set of user credentials. In one embodiment, the access continuation parameters are described in U.S. Patent Publication No. 2016 / 0359863, filed September 30, 2015, entitled "Account Access Recovery System, Method and Apparatus," which is incorporated herein by reference. In response to receiving an SRP request, identity provider 116 authenticates the user using the received credentials and receives an authorization response including an authorization code and a token. In some implementations, identity provider 116 may provide evidence that authorization request device 102 is an authorization request device from a specific manufacturer, wherein specific security hardware exists on the device available to the application (e.g., security hardware, biometric authentication hardware / sensors).

[0054] In another implementation, authorization process 110 returns an authorization response to authorization request process 106. Authorization request process 106 redirects web process 108 to load a third-party website on web server 112. Web process 108 uses a token for URI authorization to load the redirected Uniform Resource Identifier (URI).

[0055] Figure 2 This is a diagram illustrating one implementation of a single sign-on process 200 for an application via a browser. Figure 2 In this process, process 200 begins with web process 204 attempting to load a third-party URL 202 (214A). In one implementation, the user selects the URL via a browser. Additionally, authorization process 206 examines the URL to determine if authorization is required to load the third-party URL (214B). In one implementation, authorization process 206 uses the above-described... Figure 1The cache on the device determines whether a third-party website requires authorization. If the authorization process 206 detects that the third-party URL is part of a domain requiring authorization, the web process 204 sends a request to the authorization request process 210 to load the corresponding authorization extension (214C). In one implementation, as described above... Figure 1 The web process returned a 204 error and loaded the authorization extension.

[0056] After loading the authorization extension, process 200 begins exiting process flow 216. In one embodiment, authorization consent occurs outside the process flow, where these actions (214D-214I) are performed by a process different from web process 204 or a subprocess of web process 204. In response to the loading of the authorization extension, the authorization process 206 requests authorization consent from the user of the device (214D). In one embodiment, the authorization process 206 requests authorization consent by presenting an authorization user interface on the device. In response, the authorization process 206 receives user consent by having user 202 enter user credentials via the authorization user interface (214E), where user credentials may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials. In one embodiment, as described above... Figure 1 The authorization process 206 presents an authorization user interface and receives user consent. In this embodiment, by requesting and receiving user consent, the authorization process 206 performs local authentication to authorize the user's authentication as part of the authorization granted to the third-party webpage 202.

[0057] In another implementation, when authorization process 206 performs local authentication, authorization process 206 sends a server authorization request (214F) to identity provider 208. In one implementation, the server authorization request includes access continuation parameters and a URL. In this implementation, the server authorization request is used to check that the access continuation parameters are still valid to generate a token for authorization by the website, and to check that a third-party website is permitted for this operation (e.g., associated with a valid registered developer of the website). If authorization is successful, identity provider 208 returns an authorization response to authorization process 206 (214G). In one implementation, the authorization response includes access continuation parameters and an identity token. In one implementation, as described above... Figure 1 As described, identity provider 208 returns an authorization response to authorization request process 210 (214H). Authorization process 210 redirects web process 204 to a third-party site (214J). Then, as... Figure 1 As stated, web process 204 uses a token to load a redirect URI, where the login process has already been completed.

[0058] In one implementation, the authorization response includes an authorization code and a token. In one implementation, as described in U.S. Patent Application No. 16 / 888,461, entitled “Systems and Methods of Anonymous Email Relay,” filed May 29, 2020, the authorization code and token may be associated with an anonymous user identifier, which is incorporated herein by reference.

[0059] Figure 3 This is an illustration of one implementation of the application single sign-on process 300 via a browser. In one implementation, as described above... Figure 1 The device is accessed via a browser (such as the one described above). Figure 1 The authorization request device 102) performs application login. Figure 3 In this process, process 300 begins by receiving a request to load a webpage (at box 302). In one embodiment, the webpage request is received via a browser. Process 300 determines whether it can intercept an authorized webpage request (at box 304). In one embodiment, as described above... Figure 1 The process 300 determines whether it can intercept the webpage request by comparing the URL of the requested webpage with a cached version of a known domain, URI, and / or URL that requires authorization. If the webpage request does not require authorization, execution proceeds to box 306, where the process 300 processes the webpage normally.

[0060] If the requested webpage does indeed require authorization, process 300 loads the authorization extension (at box 308). In one implementation, process 300 sends a request to load the authorization extension for that URL, receives the authorization extension, and uses these extensions to load the authorization user interface on the device. With the authorization extension loaded, process 300 presents the authorization user interface to the user (at box 310). In one implementation, as described above... Figure 1 As described above, process 300 presents an authorization user interface. Process 300 receives user credentials, which may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials (at box 312). Upon receiving user credentials, process 300 performs local authentication (at box 314). In one embodiment, as described above... Figure 1As described above, process 300 uses the authentication component and the security hardware 116 of the authorization request device 102, which are part of the authorization process 110, to perform local authentication. If local authentication is successful, process 300 sends a server authorization request to the identity provider (at box 316). In one embodiment, the server authorization request includes access continuation parameters. In this embodiment, the server authorization request is used to check that the access continuation parameters are still valid to generate a token for authorization by the website, and to check that a third-party website is permitted for this operation (e.g., associated with a validly registered developer of the website). In one embodiment, process 300 sends an SRP request, which is used to identify the user and send the server request to the identity provider's device, and to authorize the application for the user. For example, in one embodiment, as described above... Figure 1 The process involves sending a server authorization request.

[0061] Process 300 receives an authorization response from the identity provider (at box 318). In one implementation, the authorization response indicates whether authorization of the application was successful. For example, in one implementation, as described above... Figure 1 As described above, process 300 receives an authorization response. Process 300 then returns a redirection to the web process at the URI (in box 320). In one implementation, as described above... Figure 1 The process described above redirects the web process to step 300. In one implementation, this sequence may establish an anonymous user identifier used with the website or a domain associated with the website. For subsequent requests, the anonymous identity token and authorization code are stored in the application authorization cache on the authorization requesting device, and single sign-on (or another type of login to the application) is not required until the user logs out of the application.

[0062] Figures 4A to 4D This is a diagram illustrating an implementation scheme for a user interface used for application single sign-on via a browser. Figure 4A In the browser, at 400, a web service login is displayed (402), which includes a hyperlink instructing the user to click here to log in. If the user clicks the link (404), the device intercepts the request and displays the intercepted user interface (420), such as... Figure 4B As shown. In Figure 4B In the browser 420, there is an overlay authorization user interface 422 overlaid on the browser 420. The overlay authorization user interface 422 includes text indicating "Provider Authorization Login" and includes user interface components that allow the user to enter their user credentials 424. If the user-entered credentials are successfully authorized, a success message can be displayed, such as... Figure 4C As shown. In Figure 4CIn the process, a "success" message 442 is displayed on the user interface 440. Upon successful authorization, the browser 460 is redirected to a third-party webpage 462.

[0063] exist Figures 1 to 4D In one implementation, authorization is being processed for the browser, where web requests are intercepted and authorization is provided using a process outside the browser's procedures. In another implementation, the device may intercept web requests from a local application and perform an authorization process outside the browser's procedures. Figure 5 This is an illustration of an implementation scheme for System 500 that handles application single sign-on by intercepting authorization requests. Figure 5 In this embodiment, device 502 includes application 504 coupled to identity provider 514 and mobile device management (MDM) server 516. In one implementation, device 502 is a device that executes an application, such as... Figure 1 The device 102 is described above. Furthermore, the identity provider 514 is as described above. Figure 1 The identity provider 116 is described above. In one embodiment, the MDM server is a server that performs MDM services, which are security services used by the IT department to monitor, manage, and protect employees' mobile devices deployed across multiple mobile service providers and multiple mobile operating systems used within the organization. In one embodiment, the MDM server 516 includes a list of identity providers, where a device can select an identity provider to use with the authorization process.

[0064] In one embodiment, device 502 includes an application 504 coupled to a Hypertext Transfer Protocol (HTTP) request process 508, which in turn connects to an authorization process 510 and a Single Sign-On (SSO) process 506. In one embodiment, application 504 is software that provides functionality when executed by device 502. Furthermore, the HTTP request process 508 is a process for sending and receiving HTTP requests to application 504, particularly for sending authorization requests via the HTTP protocol. The HTTP request process 508 uses the authorization process 510 for authorization checks. Additionally, the authorization process 510 is coupled to the SSO process 506. In one embodiment, the authorization process 510 executes the authorization request to the HTTP request process 508. In one embodiment, application 504 sends the authorization request via HTTP request.

[0065] In another implementation, application 504 sends an authorization request to HTTP request process 508. HTTP request process 508 checks authorization cache 518 on device 502 to determine whether the authorization request needs to be processed or whether authorization has been granted. In this implementation, authorization cache 518 includes information about which domain requires authorization and / or whether the application has been previously authorized. Furthermore, authorization cache 518 may include one or more authorization tokens of previously authorized domains, Uniform Resource Identifiers (URIs), and / or Uniform Resource Locators (URLs). In one implementation, by using authorization cache 518 local to device 502, applications launched or used by the user are kept locally on the device because these checks are performed locally rather than on a remote server.

[0066] If the HTTP request process 508 determines that the authorization request requires authorization, it sends a request to the authorization process 510 to execute the authorization request. The authorization process 510 then sends a request to the SSO process 506 to load the authorization extension 520 for the application 504. In one implementation, the application 504 is associated with a specific identity provider (such as identity provider 514). For example, in one implementation, if the application is used for a streaming service, the corresponding identity provider could be the identity provider that supports that streaming service. The identity provider could be an identity provider that verifies the identity of a wide variety of services and / or applications (e.g., large media companies, technology providers, etc.), or a specialized identity provider that verifies the identity of a small subset of applications and / or services (e.g., companies, governments, educational organizations, etc.). In response, the authorization process 510 receives the authorization extension and uses these extensions to load the authorization user interface on the device 502. In one implementation, the authorization user interface is handled by the authorization process 510 and is not part of the application 504 process. In one implementation, the authorization user interface is located above the application user interface. (See below...) Figures 8A to 8D An implementation scheme for an authorized user interface is discussed in the paper.

[0067] In one implementation, the authorization user interface requests the user to log in to the application. In response to presenting the authorization user interface on authorization process 510, the user enters credentials. Upon receiving the user credentials, authorization process 510 performs local authentication using authentication components and security hardware 522, which are part of authorization process 510. In one implementation, authorization process 510 determines that the user interacting with authorization process 510 is known to device 502 by performing local authentication. In one implementation, device 502 does not require two-factor authentication because device 502 is a trusted device with valid access continuation parameters.

[0068] If the authorization process 510 successfully passes local authentication, it sends a server authorization request to the identity provider 514. In one embodiment, server authorization is used to authenticate the user and authorize device 502 to use the requested URL. In this embodiment, the authorization process 510 sends a Secure Remote Protocol (SRP) request to the identity provider 514, which has the user's credentials. In response to receiving the SRP request, the identity provider 514 authenticates the user using the received credentials and receives an authorization response including an authorization code and a token. In one embodiment, device 502 is trusted based on two-factor authentication. Due to two-factor authentication, device 502 receives access continuation parameters, which can be used in the SRP request sent to the identity provider 514. In one embodiment, the access continuation parameters allow authorization to device 502 to access an account associated with the user without device 502 providing a set of the user's credentials. The access continuation parameters can be used when a user changes their credentials to generate a new token (e.g., changes the password of an account associated with one or more user devices). In one implementation, the access continuation parameters and token are described in U.S. Patent Publication No. 2016 / 0359863, entitled “Account Access Recovery System, Method and Apparatus,” filed September 30, 2015, which is incorporated herein by reference.

[0069] In another implementation, the authorization process 510 negotiates an authorization token and returns the authorization token to the HTTP request process 508. The HTTP request process 508 returns the authorization token to the application 504, which uses the authorization token to authorize the application 504 for the user.

[0070] Figure 6 This is a diagram illustrating an implementation scheme for handling application single sign-on by intercepting authorization requests. Figure 6 In this process, 600 begins with HTTP request procedure 604 detecting an authorization request from application 602 (614A). Furthermore, HTTP request procedure 604 examines the authorization request to determine whether application 602 requires authorization (614B). In one embodiment, HTTP request procedure 604 determines whether the application requires authorization by using a cache on the device, wherein the cache includes a list of domains requiring authorization, as described above. Figure 5As described above. If the HTTP request process 604 detects that the application is part of a domain that requires authorization, the HTTP request process 604 sends a request to the authorization request process 606 to load the corresponding authorization extension (614C), wherein the authorization process 606 relays the request to the SSO process 610. In one implementation, as described above... Figure 5 As mentioned above, the HTTP request process returns a 604 error indicating that the authorization extension has been loaded.

[0071] After loading the authorization extension, process 600 begins exiting process process 616. In one embodiment, authorization consent occurs outside the process flow, where these actions (614E-614I) are performed by a process different from HTTP request process 604 or a subprocess of HTTP request process 604. In response to the loading of the authorization extension, authorization process 606 requests authorization consent from the user of the device (614E). In one embodiment, authorization consent occurs outside the process flow, where these actions (614E-614I) are performed by a process different from the process of application 602. In one embodiment, authorization process 606 requests authorization consent by presenting an authorization user interface on the device. In response, authorization process 606 receives user consent by having user 612 enter user credentials via the authorization user interface (614F), where these user credentials may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials. In one embodiment, as described above... Figure 5 The authorization process 606 presents an authorization user interface and receives user consent. In this embodiment, by requesting and receiving user consent, the authorization process 606 performs local authentication to authenticate the user as part of the authorization of application 602.

[0072] In another implementation, where local authentication is performed in the authorization process 606, the SSO process 610 negotiates an authorization token (614G) with the identity provider 608. In one implementation, the server authorization request includes access extension parameters and a URL. In this implementation, the server authorization request is used to check that the access extension parameters are still valid to generate a token for authorization by the website, and to check that the application is permitted for the operation (e.g., associated with a validly registered developer of the application). If authorization is successful, the identity provider 608 returns the authorization token to the SSO process 610 (614H). In one implementation, the authorization token includes access extension parameters and a token. In one implementation, as described above... Figure 5 The SSO process 610 returns an authorization response to the HTTP request process 604 (614H). The HTTP process 604 returns an authorization token to the application 602, so the application 602 can use the authorization token to authorize.

[0073] Figure 7 This is a flowchart of one implementation of the application single sign-on process 700, which handles application single sign-on by intercepting authorization requests. In one implementation, the device (as described above) Figure 5 The device 502) performs application login via interception. Figure 7 In this process, process 700 begins by intercepting an authorization request from an application. In one embodiment, process 700 receives an HTTP request that includes an authorization request. In this embodiment, process 700 checks a cache on the device, which includes a list of domains requiring authorization. If the authorization request includes a domain requiring authorization and the user is not already logged in, process 700 determines an identity provider (at box 704). In one embodiment, process 700 requests a list of identity providers from a server and receives that list. Process 700 then selects an identity provider for the authorization request. In one embodiment, the server is as described above. Figure 5 The MDM server is described above. In one implementation, process 700 selects an identity provider based on the domain associated with the authorization request.

[0074] Process 700 loads the authorization extension associated with the determined identity provider (at box 706). In one embodiment, the authorization process sends a request to the SSO process to load the authorization extension for that HTTP request, and the authorization process receives the authorization extension and uses it to load the authorization user interface on the device. With the authorization extension loaded, process 700 presents the authorization user interface to the user (at box 708). In one embodiment, as described above... Figure 5 As described above, process 700 presents a user authorization request to the user using an authorization user interface. Process 700 receives user credentials, which may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials (at box 710). Upon receiving user credentials, process 700 performs local authentication (at box 712). In one embodiment, as described above... Figure 5As described above, process 700 uses the authentication component and the security hardware 522 of device 502, which are part of the authorization process 510, to perform local authentication. If local authentication is successful, process 700 negotiates an authorization token with the identity provider (step 714). In one embodiment, the server authorization request includes access continuation parameters and an application identifier. In this embodiment, the server authorization request is used to check that the access continuation parameters are still valid to generate a token for the application to use for authorization, and to check that the application is allowed to be used for the operation (e.g., associated with a validly registered developer of the application). In one embodiment, process 700 sends an SRP request to the identity provider, whereby the request is used to identify the user and send the server request to the identity provider's device, and to authorize the application for the user. For example, in one embodiment, as described above... Figure 5 The process 700 sends a server authorization request. Additionally, process 700 receives an authorization token from an identity provider. Process 700 also forwards the authorization token to the requesting application. In one embodiment, the application uses the authorization token to authorize its use. In one embodiment, this sequence may establish an anonymous user identifier used with a website or a domain associated with the application. For subsequent requests, the anonymous identity token and authorization code are stored in the application authorization cache on the authorization requesting device, and single sign-on (or another type of login to the application) is not required until the user logs out of the application.

[0075] Figures 8A to 8D This is a diagram illustrating an implementation scheme for the application's single sign-on user interface. Figure 8A In the middle, application 800 presents application service login 802, which includes a hyperlink instructing the user to click here to log in. If the user clicks the link 804, the device intercepts the request and presents the intercepted user interface on application 820, such as... Figure 8B As shown. In Figure 8B In the application 820, there is an overlay authorization user interface 822 overlaid on the application 820. The overlay authorization user interface 822 includes text indicating "Provider Authorization Login" and includes a user interface component allowing the user to enter user credentials 824. If the user-entered credentials are successfully authorized, a success message can be displayed, such as... Figure 8C As shown. In Figure 8C In the process, a "success" message 842 is displayed on application 840. Upon successful authorization, application 860 displays the application service user interface 862.

[0076] And as mentioned above Figures 5 to 8DIn one implementation, the HTTP process intercepts application authorization. This can be used to perform single sign-on to the application without making any changes to the application. In another implementation, the application itself can make the authorization request. Figure 9 This is a diagram illustrating an implementation of a system 900 that uses an authorization process to handle application single sign-on. Figure 9 In this system 900, application 904 is coupled to identity provider 910 and MDM server 912. In one embodiment, device 902 is a device that executes the application, such as... Figure 1 The device 102 is described above. Additionally, the identity provider 910 is as described above. Figure 1 The identity provider 116 is mentioned above. Additionally, the MDM server 912 provides MDM services as described above. Figure 5 The server mentioned above.

[0077] In one embodiment, device 902 includes application 904 and SSO process 906. Additionally, application 904 includes authorization process 908. In one embodiment, application 904 is software that provides functionality when executed by device 902. Authorization process 908 is a process invoked by application 902 when application 904 needs authorization of its functionality. Furthermore, authorization process 908 is coupled to SSO process 906.

[0078] In another implementation, application 904 invokes authorization process 908 to authorize the use of the application. In one implementation, authorization process 908 checks authorization cache 914 to determine whether application 904 has been authorized. In this implementation, authorization cache 914 includes information about which applications require authorization and / or whether the applications have been previously authorized. Furthermore, authorization cache 914 may include one or more authorization tokens for previously authorized applications. In one implementation, by using authorization cache 914 local to device 902, those applications launched or used by the user are stored locally on the device because these checks are performed locally and not on a remote server.

[0079] If application 904 is not yet authorized, the authorization process 908 sends a request to the SSO process to load the authorization extension 916 for application 904. In one embodiment, application 904 is associated with a specific identity provider (such as identity provider 910). For example, in one embodiment, if the application is used for a streaming service, the corresponding identity provider could be the identity provider that supports that streaming service. The identity provider could be an identity provider that verifies the identity of a wide variety of services and / or applications (e.g., large media companies, technology providers, etc.), or a specialized identity provider that verifies the identity of a small subset of applications and / or services (e.g., companies, governments, educational organizations, etc.). In response, the authorization process 908 receives the authorization extension and uses these extensions to load the authorization user interface on device 902. In one embodiment, the authorization user interface is handled by the authorization process 908 and is part of the process for application 904. In one embodiment, the authorization user interface is located above the application user interface. (See below...) Figures 8A to 8D An implementation scheme for an authorized user interface is discussed in the paper.

[0080] In one implementation, the authorization user interface requests a user to log in to the application. In response to presenting the authorization user interface on authorization process 908, the user enters credentials. Upon receiving the user credentials, authorization process 908 performs local authentication using authentication components and security hardware 918, which are part of authorization process 908. In one implementation, authorization process 908 determines that the user interacting with authorization process 908 is known to device 902 by performing local authentication. In one implementation, authorization requesting device 902 does not require two-factor authentication because the authorization requesting device 902 is a trusted device with valid access continuation parameters.

[0081] If the authorization process 908 successfully passes local authentication, it sends a server authorization request to the identity provider 910. In one embodiment, server authorization is used to authenticate the user and authorize device 902 to use the application. In this embodiment, the authorization process 908 sends a Secure Remote Protocol (SRP) request to the identity provider 910, which has the user's credentials. In response to receiving the SRP request, the identity provider 910 authenticates the user using the received credentials and receives an authorization response including an authorization code and a token. In one embodiment, device 902 is trusted based on two-factor authentication. Due to two-factor authentication, device 902 receives access continuation parameters, which can be used in the SRP request sent to the identity provider 910. In one embodiment, the access continuation parameters allow device 902 to access an account associated with the user without device 902 providing a set of the user's credentials. The access continuation parameters can be used when a user changes their credentials to generate a new token (e.g., changes the password of an account associated with one or more user devices). In one implementation, the access continuation parameters and token are described in U.S. Patent Publication No. 2016 / 0359863, entitled “Account Access Recovery System, Method and Apparatus,” filed September 30, 2015, which is incorporated herein by reference.

[0082] In another implementation, SSO process 906 negotiates an authorization token and returns the authorization token to authorization process 908. Authorization process 908 returns the authorization token to application 904, where application 904 uses the authorization token to authorize application 904 for the user.

[0083] Figure 10 This is a diagram illustrating one implementation of an application single sign-on process that uses an authorization procedure to handle the application's authorization. Figure 10 In this process, process 1000 begins with authorization process 1004 receiving an authorization request (1012A) from application 1002. Furthermore, authorization process 1004 examines authorization request 1012A to determine whether application 1002 requires authorization. In one embodiment, authorization process 1004 determines whether an application requires authorization by using a cache on the device, wherein the cache includes a list of domains requiring authorization. If authorization process 1004 detects that the application is part of a domain requiring authorization, authorization process 1004 sends a request to SSO process 1006 to load the corresponding authorization extension (1012B), wherein authorization process 1004 relays this request to SSO process 1010. In one embodiment, as described above... Figure 9The authorization process 1004 loads the authorization extension.

[0084] In response to the loading of the authorization extension, the authorization process 1004 requests authorization consent from the user of the device (1012C). In one embodiment, the authorization process 1004 requests authorization consent by presenting an authorization user interface on the device. In response, the authorization process 1004 receives user consent by having the user 1010 enter user credentials via the authorization user interface (1012D), where the user credentials may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials. In one embodiment, as described above... Figure 9 The authorization process 1004 presents an authorization user interface and receives user consent. In this embodiment, by requesting and receiving user consent, the authorization process 1004 performs local authentication to authenticate the user as part of the authorization of application 1002.

[0085] In another implementation, where authorization process 1004 performs local authentication, authorization process 1004 negotiates an authorization token with identity provider 1006. In one implementation, the server authorization request includes access extension parameters and a URL. In this implementation, the server authorization request is used to check that the access extension parameters are still valid to generate a token for authorization by the website, and to check that the application is permitted for the operation (e.g., associated with a validly registered developer of the application). If authorization is successful, identity provider 1006 returns the authorization token to authorization process 1004 (1012F). In one implementation, the authorization token includes access extension parameters and a token. In one implementation, as described above... Figure 9 The authorization process 1004 returns the authorization token to the authorization process 1004 (1012G). The authorization process 1004 returns the authorization token to the application 1002, so the application 1002 can use the authorization token to perform authorization.

[0086] Figure 11 This is a flowchart of an implementation scheme that uses an authorization process to handle application single sign-on for an application. In one implementation scheme, the device (as described above) Figure 9 The device 902) performs application login. Figure 11 In this process, 1100 begins by requesting a list of identity providers (at box 1102). In one implementation, as described above... Figure 9 The process 1100 requests a list of identity providers from the MDM server. Process 1100 receives the list of identity providers (at box 1104). Process 1100 determines the identity provider (at box 1106). In one implementation, the process 1100 for determining which identity provider to use depends on the application requesting authorization.

[0087] Process 1100 loads the authorization extension associated with the identified identity provider (at box 1108). In one embodiment, the authorization process sends a request to the SSO process to load the authorization extension for the application, receives the authorization extension, and uses it to load the authorization user interface on the device. With the authorization extension loaded, process 1100 presents the authorization user interface to the user (step 1110). In one embodiment, as described above... Figure 9 As described above, process 1100 presents a user authorization request to the user using an authorization user interface. Process 1100 receives user credentials, which may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials (at box 1112). Upon receiving user credentials, process 1100 performs local authentication (at box 1114). In one embodiment, as described above... Figure 9 As described, process 1100 uses the authentication component and the security hardware 918 of device 902, which are part of the authorization process 908, to perform local authentication. If local authentication is successful, process 1100 negotiates an authorization token with the identity provider (at box 1116). In one embodiment, the server authorization request includes access continuation parameters and an application identifier. In this embodiment, the server authorization request is used to check that the access continuation parameters are still valid to generate a token for the application to use for authorization, and to check that the application is permitted for the operation (e.g., associated with a validly registered developer of the application). In one embodiment, process 1100 sends an SRP request to the identity provider, whereby the request is used to identify the user and the device that sent the server request to the identity provider, and to authorize the user to use the application. For example, in one embodiment, as described above... Figure 9 The process sends a server authorization request. Additionally, process 1100 receives an authorization token from an identity provider. Process 1100 also forwards the authorization token to the requesting application. In one embodiment, the application uses the authorization token to authorize its use. In one embodiment, this sequence may establish an anonymous user identifier used with a website or a domain associated with the application. For subsequent requests, the anonymous identity token and authorization code are stored in the application authorization cache on the authorization requesting device, and single sign-on (or another type of login to the application) is not required until the user logs out of the application.

[0088] Figure 12 This is a diagram of one implementation of a system 1200 used for caching application information. Figure 12 In this embodiment, device 1206 is coupled to identity provider 1202. In one implementation, identity provider 1202 is as described above. Figure 1The identity provider 102 is described above. Furthermore, device 1206 can be as described above. Figure 1 The authorization request device 102 is mentioned above. Additionally, device 1206 is trusted by identity provider 1202 because the trust relationship established between device 1206 and identity provider 1202 is established through two-factor authentication. In this embodiment, device 1206 can be any type of device that can execute applications (e.g., smartphones, laptops, personal computers, digital media devices, televisions, servers, tablets, wearable devices, vehicle components, and / or any type of device capable of processing application instructions). Device 1206 also includes one or more applications 1212, a browser 1214, an authorization process 1208, an application authorization cache 1210, and security hardware 628. In one embodiment, each application in the one or more applications 1212 is an implementation of software that runs on device 1206 and performs various functions. Furthermore, in this embodiment, browser 1214 can be a web browser that can request data via a network coupled to device 1206 and receive requests for data. In this embodiment, authorization process 1208 is not a process or subprocess of application 1212 or browser 1214.

[0089] Device 1206 further includes an authorization process 1208 that communicates with an identity provider 1202 that interacts with one or more applications 1212 or browsers 1214. Specifically, the authorization process 1208 uses an application authorization cache 1210 and / or the identity provider 1202 to determine whether a user 1216 is authorized to use one or more applications 1212 or browsers 1214. In one embodiment, the user launches application 1212 (1218). The authorization process 1208 detects the launch of application 1212 and checks the application authorization cache 1210 to determine whether the user 1216 has previously been logged into application 1212 by the identity provider 1202 (620). If application 1212 is in the application authorization cache 1210, application 1212 continues to launch, wherein application 1212 is configured to be used with a private relay and an anonymous user email address.

[0090] If application 1212 is not in the application authorization cache 1210, the authorization process 1208 sends an authorization request (622) for application 1212. In one embodiment, the authorization request (622) includes data for the request, such as a global user identifier, a developer identifier for application 1212, one or more tokens generated on device 1206, and / or other information for the authorization request. Identity provider 1202 includes a user table that associates the global user identifier, developer identifier, anonymous user identifier, and / or other information used by identity provider 1202 for this combination of user and developer. In this embodiment, the developer identifier of the application is generated when a developer associated with one of the applications in application 1212 registers application 1212 using identity provider 1202. Additionally, an anonymous user identifier is generated when a user logs into the application, wherein the anonymous user identifier is bound to the global user identifier and the developer identifier.

[0091] In response to receiving an authorization request, identity provider 1202 returns local data (e.g., anonymous user identifier, application token, and / or other information used by the authorization process on the device) to authorization process 1208 (626) of device 1206. In one embodiment, some or all of the local data may be stored in application authorization cache 1210. Authorization process 1208 then returns the data to application 1212. In one embodiment, identity provider 1202 refreshes application authorization cache 1210 for each time period (e.g., every 24 hours) based on demand from the application, requests from the user, push notifications based on user activity on other devices (e.g., user logging in or out of different devices), dynamic scheduling, and / or another type of scheduling. In another embodiment, if user 1216 explicitly logs out of application 1212 on one device, identity provider 1202 detects the logout and pushes the logout notification to other devices of user 1216. For example, in one implementation, if user 1216 logs out of application 1212 on a smartphone, identity provider 1202 pushes the logout to application 1212 on other devices of user 1216 (e.g., the user's tablet or laptop). Alternatively, if user 1216 logs in to an application on one device, the login information is pushed to the user's other devices.

[0092] As mentioned above, in Figure 12If the authorization information for application 1212 is not stored in the application authorization cache 1210, device 1206 sends an authorization request for the application to identity provider 1202. In one embodiment, by using the application authorization cache 1210, device 1206 can shield users' private information from developers by using a local cache (e.g., application authorization cache 1210). This is because the identity management server does not track user logins to application 1212 or application launches. In one embodiment, device 1206 also includes security hardware 1228. In this embodiment, the security hardware 1228 is used for local authentication of user 1216 of device 1206 (e.g., via user ID, biometric credentials, and / or other types of authentication data).

[0093] Figure 13 This is a flowchart of an implementation plan for the developer registration process (1300). Figure 13 In this process, 1300 begins by receiving a registration from the developer, which includes information about the developer's source email address and / or permitted email patterns (at box 1302). In one embodiment, the developer registration information includes an application URL, i.e., the URL of the developer's base application, which proves ownership of the domain. Additionally, the registration information may include a URL for redirecting the web process after authorization is complete. This redirect URL can be returned to the authorization-requesting device after successful authorization. In one embodiment, each developer has an associated identifier used in login processes (such as the single sign-on process described above). Process 1300 generates a developer identifier that can be used with user login to create a long-term usage period for one of the developer's applications (at box 1304).

[0094] Figure 14 This is a flowchart of an implementation scheme for handling the user login application process. Figure 14In this process, process 1400 begins by receiving an instruction to log in via the application (at box 1402). In one embodiment, user login may include the user's global user identifier or another identifier bound to the global user identifier (e.g., the user's secondary email address). Alternatively, the user may be granted access to a password management system to allow the use of a user password against the global user identifier without requiring the user to enter a password. Process 1400 generates an anonymous user identifier and associates this identifier with the application's developer identifier (at box 1404). In one embodiment, the anonymous user identifier is associated with the developer identifier and is unique within the identity provider's authorized domain. In another embodiment, the anonymous user identifier and the developer identifier are stored in a table along with other information used for this association (e.g., the anonymous user email address, the user's real email address, private information to be shared, and other information used to maintain the association). Process 1400 further forwards the user's anonymous identifier, the anonymous user email address, and any non-private user information to the developer (at box 1406).

[0095] In one implementation, developers may use anonymous user identifiers to track user actions within their application, where the user is logged into the application. In this implementation, when a user is logged into the application, the developer can track the actions the user performs using the application (e.g., ordering goods, streaming media, browsing the application, and / or other types of actions using the developer's application). Therefore, the developer can use the anonymous user's email address and the tracked information about the user to send targeted emails to the user. However, in one implementation, because the application authorization cache is stored on the device rather than on a remote server, the developer cannot retrieve information about how the user uses applications not associated with the developer. In this implementation, the user's use of applications outside the developer's application is shielded from the developer.

[0096] Figure 15 An example of a data processing system 1500 that can be used with one embodiment of the present invention is shown. For example, system 1500 may be implemented as described above. Figure 1 The authorization request device 102 shown is as follows: Figure 5 The device 502 shown and / or such as Figure 9 The device shown is 902. Note that, although... Figure 15Various components of a computer system are illustrated, but they are not intended to represent any particular architecture or manner in which these components are interconnected, and therefore such details are not closely related to the present invention. It should also be understood that network computers and other data processing systems or other consumer electronic devices with fewer or potentially more components can also be used with the present invention.

[0097] like Figure 15 As shown, a computer system 1500 in the form of a data processing system includes a bus 1503 coupled to one or more microprocessors 1505, ROM (Read-Only Memory) 1507, volatile RAM 1509, and non-volatile memory 1511. The microprocessor 1505 includes one or more CPUs, dedicated processors, and / or combinations thereof. The microprocessor 1505 can retrieve instructions from and execute the memories 1507, 1509, and 1511 to perform the operations described above. The bus 1503 interconnects these various components and interconnects these components 1505, 1507, 1509, and 1511 to a display controller and display device 1519, and to peripheral devices such as input / output (I / O) devices, which may be a mouse, keyboard, modem, network interface, printer, and other devices well known in the art. Typically, the display controller and display device 1515 are coupled to the system via an input / output controller 1513. Volatile RAM (Random Access Memory) 1509 is typically implemented as dynamic RAM (DRAM) that requires continuous power to refresh or retain data in the memory.

[0098] Non-volatile memory 1511 is typically a magnetic hard disk drive or magnetic optical drive or DVD, which retains data (e.g., large amounts of data) even after the system is powered off; RAM or flash memory or other types of memory systems are also typically used. Non-volatile memory 1511 can also be random access memory, although this is not required. Figure 15 The non-volatile memory 1511 is shown as a local device directly coupled to the rest of the data processing system; however, it should be understood that the present invention may utilize non-volatile memory located off-system, such as network storage devices coupled to the data processing system via network interfaces such as modems, Ethernet interfaces, or wireless networks. The bus 1503 may include one or more buses interconnected via various bridges, controllers, and / or adapters well known in the art.

[0099] Figure 16 An example of another data processing system 1600 that can be used with one embodiment of the present invention is shown. For example, system 1600 may be implemented as follows: Figure 1 The authorization request device 102 is shown. Figure 16The data processing system 1600 shown includes a processing system 1611, which may be one or more microprocessors or a system-on-a-chip integrated circuit, and also includes a memory 1601 for storing data and programs to be executed by the processing system. System 1600 also includes an audio input / output subsystem 1605, which may include a microphone and / or speaker for, for example, playing music through a speaker and microphone or providing telephone functionality.

[0100] The display controller and display device 1609 provide a visual user interface for the user; this digital interface may include a graphical user interface, which, when running OS X operating system software, is similar to the user interface displayed on a Macintosh computer, and when running iOS operating system software, is similar to the user interface displayed on an Apple iPhone. System 1600 also includes interfaces for communication with another data processing system (such as...). Figure 16 One or more wireless transceivers 1603 communicate with the system 1600. The wireless transceivers may be WLAN transceivers, infrared transceivers, Bluetooth transceivers, and / or wireless cellular transceivers. It should be understood that in some embodiments, additional components (not shown) may also be part of the system 1600, and in some embodiments, the data processing system may also use... Figure 16 The components shown are fewer. System 1600 also includes components for use with another data processing system (such as...). Figure 15 One or more communication ports 1617 for communicating with the system (1500). The communication port can be a USB port, FireWire port, Bluetooth interface, etc.

[0101] The data processing system 1600 also includes one or more input devices 1613, providing an input device that allows a user to provide input to the system. These input devices may be a keypad, keyboard, touch panel, or multi-touch panel. The data processing system 1600 also includes optional input / output devices 1615, which may be connectors for interface purposes. It should be understood that, as is well known in the art, various components can be interconnected using one or more buses (not shown). Figure 16 The data processing system shown may be a handheld computer or personal digital assistant (PDA), or a cellular phone with PDA-like functionality, or a handheld computer including a cellular phone, or a media player (such as an iPod), or a device combining aspects or functions of these devices, such as a media player or embedded device or other consumer electronic device that combines a PDA and a cellular phone in one device. In other embodiments, the data processing system 1600 may be a network computer or an embedded processing device in another device, or have more than Figure 16 Other types of data processing systems, which may have fewer or more components, are shown in the diagram.

[0102] At least some embodiments of the present invention may be part of a digital media player, such as a portable music and / or video media player. The digital media player may include a media processing system for presenting media, a storage device for storing media, and may further include a radio frequency (RF) transceiver (e.g., an RF transceiver for a cellular phone) coupled to an antenna system and the media processing system. In some embodiments, media stored on a remote storage device may be transmitted to the media player via the RF transceiver. For example, the media may be one or more of music or other audio, still images, or moving images.

[0103] Portable media players may include media selection devices, such as those from Apple Inc. (Cupertino, CA). or iPod A click wheel input device, touchscreen input device, button device, movable indicator input device, or other input device on a media player. A media selection device can be used to select media stored on a storage device and / or remote storage device. In at least some embodiments, a portable media player may include a display device coupled to a media processing system to display the title or other indicators of media selected by the input device and presented via a speaker or headphones, or on the display device and on the speaker or headphones. Examples of portable media players are described in U.S. Patent Publication No. 7,345,671 and U.S. Patent Publication No. 2004 / 0224638, both of which are incorporated herein by reference.

[0104] Parts of the content described above can be implemented using logic circuits such as dedicated logic circuits or using microcontrollers or other forms of processing cores that execute program code instructions. Thus, the processes taught in the above discussion can be executed using program code such as machine-executable instructions, which cause the machine to execute these instructions to perform certain functions. In this context, "machine" can be a machine that translates intermediate (or "abstract") instructions into processor-specific instructions (e.g., abstract execution environments such as "virtual machines" (e.g., Java Virtual Machines), interpreters, Common Language Runtimes, high-level language virtual machines, etc.), and / or electronic circuits disposed on semiconductor chips (e.g., "logic circuits" implemented using transistors) designed to execute instructions, such as general-purpose processors and / or dedicated processors. The processes taught in the above discussion can also be executed (as an alternative to or in conjunction with a machine) by electronic circuits designed to execute processes (or parts thereof) without executing program code.

[0105] The present invention also relates to an apparatus for performing the operations described herein. This apparatus may be specifically configured for a desired purpose, or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in a computer. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including floppy disks, optical disks, CD-ROMs and magneto-optical disks, read-only memory (ROM), RAM, EPROM, EEPROM, magnetic cards or optical cards, or any type of medium suitable for storing electronic instructions, and each of which is coupled to a computer system bus.

[0106] Machine-readable media include any mechanism that stores or transmits information in a machine-readable (e.g., computer) form. For example, machine-readable media include read-only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; and so on.

[0107] The article of manufacture can be used to store program code. The article of manufacture storing program code can be implemented as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memories (static, dynamic, or other)), optical discs, CD-ROMs, DVD-ROMs, EPROMs, EEPROMs, magnetic cards or optical cards, or other types of machine-readable media suitable for storing electronic instructions. Program code can also be downloaded from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by means of data signals contained in a transmission medium (e.g., via a communication link (e.g., a network connection)).

[0108] The foregoing detailed description has been presented according to the algorithms and symbolic representations used to manipulate data bits within computer memory. These algorithmic descriptions and representations are tools used by those skilled in the art of data processing, and these tools are also the most effective means of communicating the essence of their work to others skilled in the art. An algorithm here and generally refers to a self-consistent sequence of operations that leads to a desired result. An operation is one that requires physical manipulation of physical quantities. Typically, though not always necessary, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and in other words, manipulated. This has proven convenient when these signals are referred to primarily for general reasons as bits, values, elements, symbols, characters, terms, numbers, etc.

[0109] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to those quantities. Unless otherwise specified, it is evident from the foregoing discussion that, throughout this specification, the use of terms such as “detect,” “determine,” “present,” “redirect,” “communicate,” “intercept,” “send,” “receive,” “load,” “negotiate,” “return,” “select,” etc., refers to the actions and processing of computer systems or similar electronic computing devices that can manipulate data represented as physical (electronic) quantities in the registers and memories of the computer system and convert them into other data similarly represented as physical quantities in the computer system’s memory or registers or other such information storage, transmission, or display devices.

[0110] The processes and displays presented herein are not inherently related to any particular computer or other device. Various general-purpose systems can be used with programs based on the teachings herein, or can prove convenient for constructing more specialized devices to perform the operations described herein. The necessary structures for various such systems will be apparent from the description below. Furthermore, the invention is not described with reference to any particular programming language. It should be understood that various programming languages ​​can be used to implement the teachings of the invention as described herein.

[0111] The foregoing discussion has only described some exemplary embodiments of the invention. Those skilled in the art will readily recognize from these discussions, drawings, and claims that various modifications can be made without departing from the spirit and scope of the invention.

Claims

1. A method for authorizing a device to use a service, the method comprising: Intercepting requests for web pages from a web browser running on the device, the requests being destined for a web server, wherein the requests include indications associated with authorization requests for the service, and the web page provides the service, the web server providing one of several services, each with a different local login mechanism, wherein intercepting the requests for the web page includes: Receive the location of the webpage; Determine whether authorization can be granted for the webpage; and Load the authorization extension to handle authorization for the webpage; In response to the interception of a request for a webpage, an authorized user interface is presented on the device; Local authorization is performed using a set of user credentials entered via the authorization user interface; In response to the execution of local authorization, server authorization is performed on the authorization server of the service, wherein, as a result of the local authorization, the server authorization is capable of authorizing each of the plurality of services, and the server authorization uses security parameters stored on the device to authorize each of the plurality of services, the security parameters allowing the device to access the service without the device having to provide the set of user credentials; and After local and server authorization, the web browser is redirected to the requested webpage, whereby the web browser is authorized to use the services provided by the webpage.

2. The method of claim 1, wherein the request for the webpage is a Hypertext Transfer Protocol request.

3. The method according to claim 1, wherein the server authorization further includes the following operations: Send a server authorization request to the authorization server; and Receive an authorization response from the authorization server.

4. The method of claim 3, wherein the server authorization request is a secure remote protocol request.

5. The method of claim 1, wherein the authorized user interface is presented using a process different from that used to execute the web browser.

6. The method of claim 1, wherein the authorization user interface includes a component for receiving the user credentials from the user.

7. The method according to claim 6, wherein the user credentials are selected from biometric user credentials or a combination of username and password.

8. A method for authorizing a device to use services provided by an application, the method comprising: The authorization request for a service provided by an application running on the device is detected on the device, the destination of which is a service provider server, wherein the service is one of a plurality of services, each of which has a different local login mechanism, and wherein the detection includes: Receive a webpage request, wherein the webpage request includes an indication associated with an authorization request for the service; and At least based on the instructions, it can be determined whether the application can be authorized to use the service; In response to detecting the authorization request, determine the identity provider associated with the application; Load the authorization extension associated with the identified identity provider; An authorized user interface corresponding to the authorized extension is displayed on the device; Local authorization for the device is received based at least on a set of user credentials data received through the authorization user interface; In response to local authorization, an authorization token is negotiated with the authorization server of the service, wherein, as a result of the local authorization, the authorization token is authorized for each of the multiple services, the authorization token is used by the authorization server to authorize each of the multiple services, and the authorization token allows the device to access the service without the device having to provide the set of user credentials; and The authorization token is returned to the application, which uses the authorization token to authorize the services provided by the application.

9. The method of claim 8, wherein the authorized user interface is presented using a process different from that used to execute the application.

10. The method of claim 8, wherein the detection comprises: Receive a request from the application to authorize the service.

11. The method of claim 8, wherein determining the identity provider comprises: Request a list of identity providers from the server; Receive the list of identity providers from the server; as well as Select an identity provider from the list of identity providers.

12. The method of claim 11, wherein the server is a mobile device management server.

13. The method of claim 8, wherein the identity provider is a service capable of verifying identity.

14. The method of claim 8, wherein the authorization extension is a user interface component for entering a set of user credentials to perform the local authorization.

15. The method of claim 8, wherein the authorization user interface includes a component for receiving the user credentials from the user.

16. The method of claim 15, wherein the user credentials are selected from biometric user credentials or a combination of username and password.

17. A machine-readable medium having executable instructions that cause one or more processing units to perform the method as described in any one of claims 1-16.

18. A system comprising one or more processing units configured to perform the method as claimed in any one of claims 1-16.

19. A computer program product having executable instructions that cause one or more processing units to perform the method as described in any one of claims 1-16.

Images