System and method for account verification escalation

Abstract

This disclosure relates to systems and methods for account verification upgrades. The invention describes a method and apparatus for converting an account associated with an application into a device using a single sign-on service. In an exemplary embodiment, the device receives an indication of a weak password associated with the account. The device further sends a request to verify the account credentials of a user associated with the device. Additionally, the device receives verification of the account credentials. The device further requests and receives the single sign-on credentials for the account. Furthermore, the device sends a message to a server associated with a service for the application that registers for the single sign-on service.

Description

[0001] This application is a divisional application of the PCT application filed on May 27, 2021, with national application number 202180040314.2 and entitled "System and Method for Account Verification Upgrade", which has entered the Chinese national phase.

[0002] This application claims the benefits of U.S. Provisional Application No. 63 / 041,671, filed June 19, 2020, U.S. Provisional Application No. 63 / 033,070, filed June 1, 2020, and U.S. Non-Provisional Application No. 17 / 303,291, filed May 26, 2021, all of which are incorporated herein by reference. Technical Field

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

[0004] Single sign-on (SSO) is a service that allows users to log in to multiple services across one or more authorized domains using a single set of credentials. For example, a user can use a single username and password combination (or another set of user credentials) to log in to a media streaming service from one company and a social media account from another company, even if the two companies are located in different authorized domains. In this example, providing SSO for multiple services across multiple authorized domains allows users to remember only a single set of credentials for multiple services from multiple sources. 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 the service via a network interface, accessing the service via a digital media player, and / or presenting the user with an interface for authenticating against that service), a user interface is presented to the user displaying both the native login user interface for the application and the SSO user interface (e.g., "Connect with XYZ"). Summary of the Invention

[0005] A method and apparatus for converting an account associated with an application into a device using a single sign-on service are described. In an exemplary embodiment, the device receives an indication of a weak password associated with the account. The device further sends a request to verify the account credentials of the user associated with the device. Additionally, the device receives verification of the account credentials. The device further requests and receives the single sign-on credentials for the account. Furthermore, the device sends a message to a server associated with a service for the application to register for the single sign-on service.

[0006] In another embodiment, a non-transitory machine-readable medium is described having executable instructions for causing one or more processing units to perform a method for converting an account associated with an application to use a single sign-on service. In one embodiment, the machine-readable medium method receives an indication of a weak password associated with the account. The machine-readable medium method may further send a request for verifying account credentials of a user associated with a device and receive verification of the account credentials. Additionally, the machine-readable medium method may request and receive the single sign-on credentials of the account. Furthermore, the machine-readable medium method may send a message indicating that the application is registering for a single sign-on service to a server associated with a service for the application.

[0007] In another implementation, the machine-readable medium method can perform local authorization on the device using a set of user credentials, wherein the set of user credentials is selected from a group including biometric user credentials or a username and password. The machine-readable medium method can further negotiate an authorization token with an identification server. Additionally, the machine-readable medium method can forward the authorization token to a server associated with the service. Furthermore, the machine-readable medium method can convert the account to use a single sign-on service.

[0008] In another implementation, the machine-readable medium method can present a third-party authorization user interface and receive third-party credentials from the user. The machine-readable medium method can further send the third-party credentials, where the third-party credentials are verified. Additionally, the machine-readable medium method can detect indications of the use of a third-party authorization mechanism. Furthermore, a single sign-on service is a service that allows users to log in to multiple services across one or more authorization domains using a single set of credentials.

[0009] In another embodiment, a method for converting an account associated with an application to use a single sign-on service is described. In one embodiment, the method receives an indication of a weak password associated with the account. The method may further send a request for verifying the account credentials of a user associated with the device and receive verification of the account credentials. Additionally, the method may request and receive the single sign-on credentials for the account. Furthermore, the method may send a message to a server associated with a service for the application to register for the single sign-on service.

[0010] In another implementation, the method can perform local authorization on the device using a set of user credentials, selected from a group including biometric credentials or a username and password. The method can further negotiate an authorization token with an identification server. Additionally, the method can forward the authorization token to a server associated with the service. Furthermore, the method can convert the account to use a single sign-on service.

[0011] In another implementation, the method may present a third-party authorization user interface and receive third-party credentials from the user. The method may further send the third-party credentials, which are then verified. Additionally, the method may detect indications to use a third-party authorization mechanism. Furthermore, a single sign-on service is a service that allows users to log in to multiple services across one or more authorization domains using a single set of credentials.

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

[0013] 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.

[0014] Figure 1 This is a diagram illustrating one implementation of a system that converts application login into single sign-on.

[0015] Figure 2 This is a diagram illustrating one implementation of the process for upgrading application login.

[0016] Figure 3 This is an illustration of one implementation of a process that uses a local user interface to convert application login into single sign-on.

[0017] Figure 4 This is an illustration of one implementation of the process of converting application login to single sign-on using a local user interface.

[0018] Figure 5 This is an illustration of one implementation of a process that uses a third-party user interface to convert application login into single sign-on.

[0019] Figure 6 This is an illustration of one implementation of the process of converting application login to single sign-on using a third-party user interface.

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

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

[0022] A method and apparatus for converting an account associated with an application into a device using a single sign-on 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 can 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.

[0023] 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.

[0024] 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.

[0025] 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.

[0026] 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.

[0027] A method and apparatus for converting an account associated with an application into a device using a single sign-on 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 use a single username and password combination (or another set of user credentials) to log in to a media streaming service from one company and a social media account from another company, even if the two companies are located in different authorized domains. In this embodiment, providing single sign-on services for multiple services across multiple authorized domains allows the user to remember only a single set of credentials for multiple services from multiple sources. Typically, when a user wants to log in to a first service (e.g., launching the application for the first time, logging back into the application, accessing the service via a web interface, accessing the service via a digital media player, and / or presenting the user with an interface for authenticating against that service), a user interface is presented to the user displaying both the native login user interface and the single sign-on user interface for the application (e.g., "Connect with XYZ").

[0028] In one implementation, a single sign-on service allows a user to log in to different services across different authorization domains using a single set of credentials without sharing privacy information, unless the user explicitly authorizes such sharing. In this implementation, for the 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. Furthermore, 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 use to verify the user's identity.

[0029] In one implementation, an authorization domain is a collection of one or more services and / or authorization authorities that allow authorization authorities using that domain to authorize users for one or more services offered by the domain. Furthermore, these authorization authorities can be used to authorize one or more user devices associated with a user for 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, an authorization domain can be used by a user and / or a user's device to purchase applications, purchase and / or stream media, store content in cloud storage, access social media and / or other types of services.

[0030] In one implementation, the single sign-on service provides single sign-on for multiple services provided by native applications on a user's device or via 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 privacy information) to the developers or providers of the different applications and / or services.

[0031] Additionally, and in one implementation, the application can transform the login process from one using a customized set of credentials (e.g., a specific username and password) to one using single sign-on (SSO). In this implementation, the transformation to use a SSO process involves converting the application and the application backend supporting the application to use a SSO process. In one implementation, the application and application backend provide the service to users with accounts specific to the service. To use the service-specific account, the user provides a set of credentials (e.g., username and password, or some other set of credentials) that identifies the user against the service and identifies the level of service characteristics available to the user. By converting the service to use SSO, the application and application backend can leverage SSO to authorize the user to use the service.

[0032] Figure 1 This is a diagram illustrating one implementation scheme for a system that converts application login to single sign-on. Figure 1In this system, system 100 includes a device 102 coupled to an application backend 110 and an identity provider 112. In one embodiment, device 102 includes an application 104, an application extension 106, a password manager 108, and an authorization process 114. In this embodiment, device 102 can be any type of device capable of executing application 104 (e.g., smartphone, laptop, personal computer, server, tablet, wearable device, vehicle component, and / or any type of device capable of processing application instructions). Furthermore, and in one embodiment, application 104 can be a word processing application, spreadsheet, contact, email, telephone, web browser, media player, comment application, classifieds application, social media and / or web, productivity, utility, game, real estate, photo, video, e-commerce, storefront, coupon, operating system, and / or any other type of application that can run on the device. Additionally, application 104 can support the service via an account for the service, which may require some kind of credentials from the user for the application 104 to enable the service to the user. In one embodiment, the credentials may be a username and password combination used by the service provider to authorize the user to access the service, or some other type of credentials. In this implementation, application 104 is enabled to provide services to the user by using the user's credentials for the service.

[0033] In one embodiment, application extension 106 is a process of providing access to the functionality of application 104 via the operating system of device 102. For example, in one embodiment, application extension 106 may provide functionality to other applications or operating system features on device 102 (e.g., as a desktop applet, providing image or media manipulation capabilities, data sharing, audio processing, custom actions, and / or any other type of functionality that the application can provide). For example, in one embodiment, application extension 106 may be used to communicate with application backend 114 and convert application logins from account usernames and passwords customized for the services corresponding to the application into generic single sign-on. An example of such single sign-on service is shown in U.S. Patent Application No. 16 / 888,479, filed May 29, 2020, entitled “SYSTEMS AND METHODS OF APPLICATION SINGLE SIGN ON,” which is incorporated herein by reference.

[0034] In one implementation, application extension 106 can be used to transform the login process to a service from a custom username and password (or some other form of credentials specific to the account for that service) into a single sign-on mechanism shared by multiple applications across authorized domains.

[0035] In one implementation, the application is associated with a specific identity provider (such as identity provider 112). For example, in one implementation, if the application (and corresponding account) 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 one 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, application extension 106 may request password manager 108 to present an authorization user interface on device 102. In one implementation, the authorization user interface is handled by authorization process 106.

[0036] In one implementation, the authorization user interface requests the user to log in to convert the account to single sign-on. In response to presenting the authorization user interface, the user selects single sign-on and enters user credentials. Upon receiving the user credentials, the authorization process 114 can perform local authentication using authentication components and security hardware (not shown) that are part of the authorization process 114. For example, in one implementation, the authorization process 114 uses sensors to capture biometric data and uses the sensor data in the security hardware to perform 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, the authorization process 114 determines that the user interacting with the authorization process 114 is known to device 102 by performing local authentication. In one implementation, the authorization requesting device 102 does not require two-factor authentication because the authorization requesting device 102 is a trusted device with valid access continuation parameters.

[0037] If the authorization process 114 successfully performs local authentication, it sends a server authorization request to the identity provider 112. In one embodiment, server authorization is used to authenticate the user and authorize device 102 to convert the account to use single sign-on. In this embodiment, the authorization process 114 sends a Secure Remote Protocol (SRP) request to the identity provider 112 with access continuation parameters. In one embodiment, based on the device's two-factor authentication, the authorization requesting device 114 is trusted. Due to the two-factor authentication, device 102 receives access continuation parameters, which can be used in the server authorization request sent to the identity provider 112. In one embodiment, the access continuation parameters allow device 102 to access the account associated with the user without device 102 providing 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 112 authenticates the user using the received credentials and receives an authorization response including an authorization code and a token. In some implementations, identity provider 112 may provide evidence that device 102 is from a specific manufacturer, wherein specific security hardware exists on the device available to the application (e.g., security hardware, biometric authentication hardware / sensors).

[0038] In another implementation, the authorization process 114 returns an authorization response to the password manager 108. The password manager 108 sends a login with single sign-on credentials to the application extension 106, which forwards the single sign-on credentials to the application backend 110. In one implementation, the application backend 110 is a device (or a set of devices) that supports the application by providing remote services to the application 104. For example, in one implementation, the application backend 110 may provide authorization services (e.g., verifying account credentials) to enable services on device 102 (e.g., providing access to social media or the web, providing access to media, banking, healthcare, government services, and / or another type of service delivered via the web). In one implementation, utilizing single sign-on credentials, the application backend 110 can change the authorization process used by the application backend 110 from using a set of account credentials to using single sign-on credentials. Figure 3 and Figure 4The document further describes the conversion of an account from a set of custom credentials to single sign-on credentials. In another implementation, the device may present a third-party user interface for authorizing the conversion of the account to use single sign-on credentials. Figure 5 and Figure 6 The document further describes the transition of accounts using a third-party user interface from a set of custom credentials to single sign-on credentials.

[0039] In one implementation scheme, and in addition to the above Figure 1 Beyond the application login process described herein, the device can provide passwords for usernames of accounts associated with the application. In this implementation, the device can receive instructions from the user that they wish to update their password using a device-suggested password. In one implementation, the device can analyze stored passwords to determine whether the password is weak (e.g., including full words, passwords shared by other accounts, passwords with easily detectable patterns (e.g., incrementing numbers or letters, letters or numbers following keyboard patterns, etc.), passwords with the known names of the user or their relatives or friends, passwords derived from user characteristics (e.g., their own birthday, their spouse's or children's birthday, etc.), passwords adopted from or derived from known compromised services (e.g., the consequences of a hacking attack), and / or other types of weak passwords). In one implementation, the device can detect weak stored passwords for accounts in the device's password store and suggest that the user upgrade their password to a stronger device-generated password for that account, or it can switch the account to use a single sign-on mechanism.

[0040] Figure 2 This is a diagram illustrating one implementation of the application's single sign-on upgrade process 200. In Figure 2In this process, process 200 begins by detecting a weak password for the account or detecting that the user has already requested a password upgrade for the account at box 202. In one embodiment, the weak password may be as described above. Alternatively, the user may request a password upgrade for the account through a user interface. At box 204, process 200 receives a password upgrade request from the user. Process 200 determines whether the password upgrade request is a request for using the single sign-on service for the account. If the password upgrade request is a request for using the single sign-on service for the account, execution proceeds to box 210 below. If the request is not for using the single sign-on service for the account and is for password upgrade, process 200 generates and presents a new password to the user at box 212. In one embodiment, process 200 generates a strong password, wherein a strong password is designed to be difficult for a person or program to discover. Because the purpose of a password is to ensure that only authorized users can access resources, an easily guessed password is a security risk. The basic components of a strong password may include sufficient length and a mix of character types. If process 200 detects that the user has accepted the presented password at box 214, then process 200 stores the new password in the password store on the device. If process 200 detects that the user has not accepted the new password, then process 200 does not update the current password at box 216.

[0041] As described above, if a user instructs a password upgrade to convert the account to single sign-on, then at box 210, process 200 converts the account to single sign-on. (See below...) Figures 3-6 The text further describes the transition to single sign-on.

[0042] As described above, the device can transition accounts from using specific groups of user credentials bound to the account to a single sign-on process. Figure 3 This is a diagram of one implementation of process 300, which uses a local user interface to convert application login into single sign-on. Figure 3In this process, process 300 begins with password manager 308 detecting user interaction (314A). In one implementation, the user may have triggered password autofill, which may suggest generating a strong password for the account associated with the application, or may suggest upgrading the account to use a single sign-on mechanism. Alternatively, the user can access the user interface of password manager 308 and view the account's current credentials, where the password manager prompts the user to upgrade credentials. The password manager may further check to determine if the credentials include a weak password and whether the account has a domain with an application extension that can support the single sign-on process. If either of these checks is true (or in another implementation, both checks are true), password manager 308 presents a user interface proposing to upgrade the account to single sign-on (314B). User 306 can choose to upgrade the account (314C) to the single sign-on credentials used for that account. Password manager 308 receives an instruction for the single sign-on conversion.

[0043] In response to receiving an instruction for single sign-on conversion, password manager 308 sends a request to application extension 310 to upgrade existing account credentials (314D) to the single sign-on mechanism. Application extension 310 sends a request to application backend 312 to verify the account's existing credentials. In one embodiment, application extension 312 provides credentials to application backend 312. In another embodiment, application backend 312 retrieves the account's credentials stored in application backend 312. Application backend 312 verifies the account credentials and sends a response (314F) to application extension 310. If application backend 312 can verify the current account credentials, application extension 310 sends a request to password manager 308 to obtain single sign-on authorization from password manager 308 (314G). If application backend 312 cannot verify the current account credentials, process 300 ends.

[0044] If the application backend 312 verifies the current account credentials, process 300 continues by sending a set of identifiers (314H) to the authorization process 304 via password manager 308. In one embodiment, this set of identifiers includes an application identifier and a developer identifier. Developer 104 may have one or more developer identifiers for different bundles of one or more applications (e.g., an entity with a large number of software engineers). The authorization process requests authorization consent from user 306 (314I). In one embodiment, authorization process 304 requests authorization consent by presenting an authorization user interface on the device. In response, authorization process 306 receives user consent by having user 306 enter user credentials via the authorization user interface (314J), 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 1 The authorization process 306 presents an authorization user interface and receives user consent. In this embodiment, by requesting and receiving user consent, the authorization process 306 is performing local authentication to authenticate the user as part of the authorization process for the account credential upgrade. In one embodiment, the authorization user interface is a generic user interface or at least based on a generic user interface template that can be used for multiple different applications.

[0045] In another implementation, where local authentication is performed in authorization process 306, authorization process 306 sends a single sign-on request (314K) to identity provider 302. In one implementation, the server authorization request includes access continuation parameters and the name of the application. In this implementation, 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 third-party website is permitted for the operation (e.g., associated with a validly registered developer of the website). If authorization is successful, identity provider 302 returns an authorization response for authorized single sign-on upgrade (314L) to authorization process 304. In one implementation, the authorization response includes access continuation parameters and an identity token.

[0046] In one implementation, upon receiving an authorization response for the Single Sign-On (SSO) upgrade, authorization process 304 sends a login with SSO credentials (314M) to password manager 308. Password manager 308 then sends the login with SSO credentials to application extension 310 (314N). Application extension 310 sends the SSO credentials (314O) to application backend 312 to convert the account to use SSO credentials. If the conversion is successful, application backend 312 sends a response (314P) indicating successful conversion to application extension. Application extension 310 sends a message to password manager indicating that the SSO upgrade is complete (314Q). Password manager 308 deletes any saved credentials for the account, as these credentials are no longer needed.

[0047] Figure 4 This is an illustration of one implementation of a process 400 that converts application login to single sign-on using a local user interface. In one implementation, the device interacting with the user performs process 400, as shown above. Figure 1 Device 102. Figure 4 In this process, process 400 begins by verifying account credentials at box 402. In one embodiment, account credentials are credentials of an account that the application can use before transitioning to single sign-on. In this embodiment, process 400 sends a request to the application backend to verify the account credentials, and the application backend sends a response regarding whether the account credential verification was successful. If account verification fails, execution proceeds to box 406, where process 400 takes alternative actions. If account verification is successful, at box 408, process 400 obtains single sign-on authorization. In one embodiment, process 400 sends a request for single sign-on authorization to the password manager.

[0048] Process 400 performs local authentication at box 410. In one embodiment, process 400 performs local authentication by presenting an authorization user interface to the user. In one embodiment, process 400 uses the authorization user interface to present a single sign-on authorization request to the user and prompts the user for their credentials. Process 400 receives user credentials, which may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials. Upon receiving user credentials, process 400 performs local authentication. In one embodiment, as described above. Figure 1As described above, process 400 uses the authentication component and the secure hardware of the device as part of the authorization process to perform local authentication. If local authentication is successful, process 400 negotiates an authorization token with the identity provider at box 412. 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 400 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 1 The process sends a server authorization request. Additionally, process 400 receives an authorization token from the identity provider. At box 414, process 400 further forwards the authorization token to the requesting application extension. In one embodiment, the application uses the authorization token to authorize single sign-on for that account and / or application. 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.

[0049] At box 416, process 400 converts the account to use single sign-on. In one embodiment, process 400 converts the account to use single sign-on by sending a message to the application backend that performs the account conversion. The application backend sends a message back to process 400 indicating whether the account conversion was successful. If the account conversion is successful, process 400 completes the account conversion at box 418. In one embodiment, process 400 completes the account conversion by deleting any stored credentials for this account.

[0050] Figure 5 This is an illustration of one implementation of a process 500 that uses a third-party user interface to convert application login to single sign-on. Figure 5In this process, process 500 begins with password manager 508 detecting user interaction (514A). In one implementation, the user may have triggered password autofill, which may suggest generating a strong password for the account associated with the application, or may suggest upgrading the account to use a single sign-on mechanism. Alternatively, the user can access the user interface of password manager 508 and view the account's current credentials, and the password manager prompts the user to upgrade credentials. The password manager may further check to determine if the credentials include a weak password and whether the account has a domain with an application extension that can support the single sign-on process. If either of these checks is true (or in another implementation, both checks are true), password manager 508 presents a user interface proposing to upgrade the account to single sign-on (514B). User 506 can choose to upgrade the account to the single sign-on credentials used for that account (514C). Password manager 508 receives an instruction for the single sign-on transition.

[0051] In response to receiving an instruction for single sign-on conversion, password manager 508 sends a request to application extension 510 to upgrade (514D) existing account credentials to the single sign-on mechanism. Application extension 510 sends a request to application backend 512 to verify the account's existing credentials. In one embodiment, application extension 512 provides credentials to application backend 512. In another embodiment, application backend 512 retrieves the account's credentials stored in application backend 512. Application backend 512 verifies the account credentials and sends a response (514F) to application extension 510. In one embodiment, the response may include instructions to use a custom user interface for local authentication.

[0052] In one implementation scheme, and different from Figure 3 In processes 300 and 500, a customized user interface for local authentication can be presented. In one implementation, application extension 510 cancels a user interface error (514G) to password manager 508 to signal the need for further authorization. Upon seeing the error, password manager 508 requests a third-party user authorization interface from application extension 510 (514H). Application extension 510 presents the third-party user authorization interface to the user (514I). The user responds, instructing approval for single sign-on conversion (514J), where approval (and the user's credentials for the account) is returned to application extension 510. Application extension forwards the account credentials to application backend 512 (514K), where application backend 512 verifies the account credentials and returns a response (514L) to application extension 510.

[0053] If the application backend 512 can verify the current account credentials, the application extension 510 sends a request to the password manager 508 to obtain single sign-on authorization (514M) from the password manager 508. If the application backend 512 cannot verify the current account credentials, the process 500 ends.

[0054] If the application backend 512 verifies the current account credentials, process 500 continues by sending a set of identifiers (514N) to the authorization process 504 via password manager 508. In one embodiment, this set of identifiers includes an application identifier and a developer identifier. The authorization process requests authorization consent from user 506 (514O). In one embodiment, authorization process 504 requests authorization consent by presenting an authorization user interface on the device. In response, authorization process 506 receives user consent by having user 506 enter user credentials via the authorization user interface (514P), 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 1 The authorization process 506 presents an authorization user interface and receives user consent. In this embodiment, by requesting and receiving user consent, the authorization process 506 is performing local authentication to authenticate the user as part of the authorization process for account credential upgrade. In one embodiment, the authorization user interface is a generic user interface or at least based on a generic user interface template that can be used for multiple different applications.

[0055] In another implementation, where local authentication is performed in the authorization process 506, the authorization process 506 sends a single sign-on request (514Q) to the identity provider 502. In one implementation, the server authorization request includes access continuation parameters and the name of the application. In this implementation, 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 third-party website is permitted for the operation (e.g., associated with a validly registered developer of the website). If authorization is successful, the identity provider 502 returns an authorization response for an authorized single sign-on upgrade (514R) to the authorization process 504. In one implementation, the authorization response includes access continuation parameters and an identity token.

[0056] In one implementation, upon receiving an authorization response for the Single Sign-On (SSO) upgrade, the authorization process 504 sends a login with SSO credentials (514S) to the password manager 508. The password manager 508 then sends the login with SSO credentials to the application extension 510 (514T). The application extension 510 sends the SSO credentials (514U) to the application backend 512 to convert the account to use SSO credentials. If the conversion is successful, the application backend 512 sends a response (514V) indicating successful conversion to the application extension. The application extension 510 sends a message to the password manager indicating that the SSO upgrade is complete (514W). The password manager 508 deletes any saved credentials for the account, as these credentials are no longer needed.

[0057] Figure 6 This is an illustration of one implementation of the process of converting application login 600 to single sign-on using a third-party user interface. In one implementation, the device interacting with the user performs process 600, as shown above. Figure 1 Device 102. Figure 6 In this process, process 600 begins by verifying account credentials at box 602. In one embodiment, account credentials are credentials of an account that the application can use prior to transitioning to single sign-on. In this embodiment, process 600 sends a request to the application backend to verify the account credentials, and the application backend sends a response regarding whether the account credential verification was successful. If account verification fails, execution proceeds to box 606, where process 600 takes an alternative action. If account verification succeeds, execution proceeds to box 610 below. If account verification fails, execution proceeds to box 608 below.

[0058] At box 608, process 600 performs third-party authorization. In one embodiment, process 600 performs third-party authorization because account credentials are invalid, expired, or need to be refreshed. In one embodiment, process 600 requests a third-party user interface from an application extension and presents that user interface to the user. The user enters appropriate information, such as account credentials. In one embodiment, the third-party user interface may request existing user credentials or additional credentials (e.g., a two-factor authentication code or some other secret information to further authenticate the account). Process 600 sends these account credentials to the application backend, where the application backend verifies the account credentials. If the account credentials are verified by the application backend, the application backend sends a response to process 600. Using the verified account credentials, at box 608, process 600 obtains single sign-on authorization. In one embodiment, process 600 sends a request for single sign-on authorization to a password manager.

[0059] Process 600 performs local authentication at box 612. In one embodiment, process 600 performs local authentication by presenting an authorization user interface to the user. In one embodiment, process 600 uses the authorization user interface to present a single sign-on authorization request to the user and prompts the user for their credentials. Process 600 receives user credentials, which may be a facial identifier, touch identifier, user personal identification number, and / or another type of user credentials. Upon receiving user credentials, process 600 performs local authentication. In one embodiment, as described above. Figure 1 As described above, process 600 uses the authentication component and the secure hardware of the device as part of the authorization process to perform local authentication. If local authentication is successful, process 600 negotiates an authorization token with the identity provider at box 614. 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 this operation (e.g., associated with a validly registered developer of the application). In one embodiment, process 600 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 1 The process involves sending a server authorization request. Additionally, process 600 receives an authorization token from the identity provider.

[0060] Process 600 further forwards the authorization token to the requesting application extension at box 616. In one embodiment, the application uses the authorization token to authorize single sign-on for that account and / or application. 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.

[0061] At box 618, process 600 converts the account to use single sign-on. In one embodiment, process 600 converts the account to use single sign-on by sending a message to the application backend that performs the account conversion. The application backend sends a message back to process 600 indicating whether the account conversion was successful. If the account conversion is successful, process 600 completes the account conversion at box 620. In one embodiment, process 600 completes the account conversion by deleting any stored credentials for this account.

[0062] Figure 7An example of a data processing system 700 is shown, which can be used with one embodiment of the present invention. For example, system 700 may be implemented as described above. Figure 1 The system of device 102 shown. Note that, although... Figure 7 Various 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, as 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 may also be used in this invention.

[0063] like Figure 7 As shown, a computer system 700 in the form of a data processing system includes a bus 703 coupled to a microprocessor 705 and ROM (Read-Only Memory) 707, as well as volatile RAM 709 and non-volatile memory 711. The microprocessor 705 may include one or more CPUs, GPUs, dedicated processors, and / or combinations thereof. The microprocessor 705 may retrieve instructions from and execute the memories 707, 709, and 711 to perform the operations described above. The bus 703 interconnects these various components and also interconnects these components 705, 707, 709, and 711 to a display controller and display device 719, as well as 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, an input / output device 715 is coupled to the system via an input / output controller 713. The volatile RAM (random access memory) 709 is typically implemented as dynamic RAM (DRAM), which requires continuous power to refresh or retain the data in the memory.

[0064] Mass storage device 711 is typically a magnetic hard disk drive or magnetic optical drive or DVD, which retains data (e.g., large amounts of data) even after a system power outage, or a RAM or flash memory or other type of storage system. Typically, this mass storage device 711 will also be random access memory, although this is not required. Figure 7 The mass storage device 711 is shown as a local device directly coupled to the rest of the data processing system; however, it should be understood that the invention may utilize non-volatile memory located off-system, such as network storage devices coupled to the data processing system via a network interface (such as a modem, Ethernet interface, or wireless network). The bus 703 may include one or more buses interconnected via various bridges, controllers, and / or adapters well known in the art.

[0065] Figure 8An example of another data processing system 800 that can be used with one embodiment of the present invention is shown. For example, system 800 may be implemented as described above. Figure 1 The device 102 shown. Figure 8 The data processing system 800 shown includes a processing system 811, which may be one or more microprocessors or a system-on-a-chip integrated circuit, and the system also includes a memory 801 for storing data and programs for execution by the processing system. System 800 also includes an audio input / output subsystem 805, which may include a microphone and speaker for, for example, playing music through a speaker and microphone or providing telephone functionality.

[0066] The display controller and display device 809 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 800 also includes one or more wireless transceivers 803 for communicating with another data processing system. 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 system 800, and in some embodiments, the data processing system may also use... Figure 8 The components shown are fewer. System 800 also includes one or more communication ports 817 for communicating with another data processing system. The communication ports may be USB ports, FireWire ports, Bluetooth interfaces, etc.

[0067] The data processing system 800 also includes one or more input devices 813 provided to allow 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 800 also includes optional input / output devices 815, which may be connectors for interfaces. 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 8 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 800 may be a network computer or an embedded processing device in another device, or have more than Figure 8Other types of data processing systems, which may have fewer or more components, are shown in the diagram.

[0068] 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.

[0069] Portable media players may include media selection devices, such as the iPod from Apple Inc. (Cupertino, CA). ® or iPod Nano ® A click wheel input device, touchscreen input device, button device, movable indicator input device, or other input device can be used 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 titles or other indicators of media selected via an input device and presented through a speaker or headphones, or on the display device and on a 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.

[0070] 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.

[0071] 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.

[0072] 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.

[0073] The article of manufacture may be used to store program code. The article of manufacture storing program code may be implemented as, but is not limited to, one or more memories (e.g., one or more flash memories, random access memory (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 may 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)).

[0074] 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. These operations are those that require physical manipulation of physical quantities. Often, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, transmitted, combined, compared, and otherwise manipulated. It has proven convenient to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, etc., primarily for general reasons.

[0075] However, it should be remembered that all these and similar terms are associated with appropriate physical quantities and are merely convenient labels applied to these 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,” “request,” “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.

[0076] 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.

[0077] 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 non-transitory machine-readable medium having executable instructions for causing one or more processing units to perform a method for converting an account associated with an application to use a single sign-on service, the method comprising: Receive instructions on the device regarding a weak password associated with the account; Send a request to verify the account credentials of the user associated with the device; Receive the verification of the account credentials; Request the single sign-on credentials for the account; Receive the single sign-on credentials; as well as The message indicating that the application is registering the single sign-on service is sent to the server associated with the service for the application.

2. The non-transient machine-readable medium of claim 1, wherein the request for the single sign-on credential comprises: Perform local authorization on the device using a set of user credentials.

3. The non-transitory machine-readable medium according to claim 2, wherein the set of user credentials is selected from the group including biometric user credentials or username and password.

4. The non-transitory machine-readable medium according to claim 1, further comprising: Negotiate an authorization token with the identification server.

5. The non-transitory machine-readable medium according to claim 4, further comprising: The authorization token is forwarded to the server associated with the service.

6. The non-transitory machine-readable medium according to claim 1, further comprising: Convert the account to use the single sign-on service.

7. The non-transitory machine-readable medium of claim 1, wherein sending a request to verify the account credentials comprises: Presents a third-party authorized user interface; Receive third-party credentials from the user.

8. The non-transitory machine-readable medium according to claim 7, further comprising: Send the third-party credentials, wherein the third-party credentials are verified.

9. The non-transitory machine-readable medium according to claim 7, further comprising: Instructions for detecting the use of third-party authorization mechanisms.

10. The non-transitory machine-readable medium of claim 1, wherein the 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.

11. A method for converting an account associated with an application to use a single sign-on service, the method comprising: Receive instructions on the device regarding a weak password associated with the account; Send a request to verify the account credentials of the user associated with the device; Receive the verification of the account credentials; Request the single sign-on credentials for the account; Receive the single sign-on credentials; as well as The message indicating that the application is registering the single sign-on service is sent to the server associated with the service for the application.

12. The method of claim 11, wherein the request for the single sign-on credential comprises: Perform local authorization on the device using a set of user credentials.

13. The method of claim 12, wherein the set of user credentials is selected from a group including biometric user credentials or username and password.

14. The method of claim 11, further comprising: Negotiate an authorization token with the identification server.

15. The method of claim 14, further comprising: The authorization token is forwarded to the server associated with the service.

16. The method of claim 11, further comprising: Convert the account to use the single sign-on service.

17. The method of claim 11, wherein sending a request for verifying the account credentials comprises: Presents a third-party authorized user interface; Receive third-party credentials from the user.

18. The method of claim 17, further comprising: Send the third-party credentials, wherein the third-party credentials are verified.

19. The method of claim 17, further comprising: Instructions for detecting the use of third-party authorization mechanisms.

20. The method of claim 11, wherein the 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.

Images