Application login method, device, system, storage medium, and program product

Abstract

Embodiments of the present disclosure provide an application login method, a device, a system, a storage medium, and a program product. In the embodiments of the present disclosure, a user inputs, on a login page of an application, a composite password comprising a static password and a one-time password. A terminal device of the user requests, from a first service device via the composite password, an access token for logging into a first application. The first service device can separate the static password and the one-time password from the composite password, and acquire a two-factor verification result of the static password and the one-time password. Two-factor authentication is introduced into a conventional password-based authentication process, thereby improving security of identity authentication and contributing to improving security of application login. In addition, a password-based authentication process of OIDC is also used, thereby reducing intrusion into the password-based authentication process and reducing development difficulty and costs of identity authentication.

Description

Application login methods, devices, systems, storage media, and program products

[0001] This disclosure claims priority to Chinese Patent Application No. 202411948386.9, filed with the China Patent Office on December 26, 2024, entitled “Application Login Method, Apparatus, System, Storage Medium and Program Product”, the entire contents of which are incorporated herein by reference. Technical Field

[0002] This disclosure relates to the field of Internet technology, and in particular to an application login method, device, system, storage medium, and program product. Background Technology

[0003] As businesses grow in size and demand, and technology advances, the number and variety of applications used within organizations increase dramatically. To improve productivity and ensure data security, simplifying employee access to multiple applications has become a critical requirement. Single Sign-On (SSO) systems have emerged to address this need, allowing users to access all authorized applications and services with a single authentication, eliminating the need to repeatedly enter credentials. However, with the development of cloud computing, mobile work, and digital transformation trends, traditional on-premises SSO solutions are increasingly showing their limitations, failing to meet the flexibility and scalability requirements of modern enterprises.

[0004] To address these challenges, an increasing number of enterprises are entrusting their applications' identity information to Identity as a Service (IDaaS). IDaaS provides managed identity management and access control services, granting users access to multiple applications and services through a single login process, simplifying the user login process and reducing password fatigue. Due to legacy or migration reasons, password-based login to IDaaS-hosted applications is often a transitional login method; however, existing password-based login processes have relatively low security. Summary of the Invention

[0005] This disclosure provides, in various aspects, an application login method, device, system, storage medium, and program product for application login security.

[0006] This disclosure provides an application login method applicable to a first service device, including:

[0007] Obtain an authorization request from the terminal device for a first application; the authorization request includes a composite password; the composite password includes: a static password and a one-time password;

[0008] From the composite cipher, the static cipher and the one-time cipher are separated;

[0009] Obtain the two-factor authentication results of the static password and the one-time password;

[0010] If the two-factor authentication result indicates that the static password and the one-time password have passed the authentication, a first access token is returned to the terminal device so that the terminal device can log in to the first application using the first access token.

[0011] This disclosure also provides a service system, including: a terminal device running a first application, a first service device, and a service device corresponding to the first application;

[0012] The terminal device is used to send an authorization request to the first service device; the authorization request includes a composite password; the composite password includes: a static password and a one-time password;

[0013] The first service device is configured to, in response to the authorization request, separate the static password and the one-time password from the composite password; obtain the two-factor verification result of the static password and the one-time password; and, if the two-factor verification result indicates that the static password and the one-time password have passed the verification, return a first access token to the terminal device.

[0014] The terminal device is configured to send a login request to the service device based on the first access token;

[0015] The service device is used to check the validity of the first access token based on the login request, and if the first access token is valid, to return the resources of the first application to the terminal device.

[0016] This disclosure also provides an electronic device, including: a memory, a processor, and a communication component; wherein the memory is used to store a computer program;

[0017] The processor is coupled to the memory and the communication component to execute the computer program for performing the steps in the aforementioned application login method.

[0018] This disclosure also provides a computer-readable storage medium storing computer instructions that, when executed by one or more processors, cause the one or more processors to perform the steps in the aforementioned application login method.

[0019] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the aforementioned application login method.

[0020] In this embodiment, the user enters a composite password consisting of a static password and a one-time password on the application's login page. The user's terminal device requests an access token for logging into the first application from the first service device using the composite password. The first service device can separate the static password and the one-time password from the composite password and obtain the two-factor authentication result of the static password and the one-time password. This introduces two-factor authentication into the traditional password pattern standard process, improving the security of identity authentication and contributing to enhanced application login security. Furthermore, it reuses the OIDC password pattern standard process, reducing intrusion into the password pattern standard process and decreasing the development difficulty and cost of identity authentication. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this disclosure and form part of this disclosure, illustrate exemplary embodiments of the present disclosure and are used to explain the disclosure, but do not constitute an undue limitation of the disclosure. In the drawings:

[0022] Figure 1 is a schematic diagram of the standard OIDC password mode login application process;

[0023] Figure 2 is a schematic diagram of the structure of the service system provided in this embodiment of the present disclosure, and a schematic diagram of the process of password mode login application;

[0024] Figure 3 is a schematic diagram of another password mode login application provided in an embodiment of this disclosure;

[0025] Figure 4 is a flowchart illustrating the application login method provided in this embodiment of the present disclosure;

[0026] Figure 5 is a schematic diagram of the structure of the electronic device provided in the embodiment of this disclosure. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this disclosure clearer, the technical solutions of this disclosure will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without creative effort are within the scope of protection of this disclosure.

[0028] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0029] The terms or concepts involved in the embodiments of this disclosure will be explained below.

[0030] Identity Source: An identity source is a system or service that stores user identity information. When a user attempts to access protected resources or services, the authentication system interacts with the identity source to verify the user's identity and grant or deny access based on the stored information.

[0031] OpenID Connect (OIDC) is an authentication protocol, an authentication extension built on top of OAuth 2.0 (an authorization framework) used to verify a user's identity and obtain basic information about the user. It provides a standardized method for secure login to World Wide Web (Web) applications, mobile applications, and other clients, and can be integrated with various authentication mechanisms.

[0032] Password pattern: Password pattern is an authorization type that allows applications to request access tokens using an account and password obtained directly from the resource owner (i.e., the user). Specifically, the application obtains the account and password from the user and then uses them to request an access token from an Identity Provider (IDP) or authorization server.

[0033] Two-Factor Authentication: Two-factor authentication is a robust authentication mechanism that forces users to provide two different types of credentials to ensure their identity during login. Even if a potential attacker illegally obtains a user's password, they will be unable to authenticate and log in to the account due to the lack of a second, independent, and real-time generated authentication credential. This additional layer of security significantly enhances an account's ability to resist unauthorized access.

[0034] The following explains the process of logging into applications using the traditional password method.

[0035] Currently, identity providers (such as Okta and Authing) offer comprehensive support for the OpenID Connect (OIDC) standard, including support for various authorization types such as password mode, authorization mode, and implicit mode. Password mode is suitable for highly trusted environments, such as applications within an organization. Using password mode in situations that do not meet this high level of trust may lead to security vulnerabilities and increase the likelihood of attacks. Therefore, integrating OIDC with an application using password mode naturally introduces security vulnerabilities. The following is an illustrative description of the application login process using password mode, with reference to Figure 1. As shown in Figure 1, the standard OIDC password mode login process mainly includes the following steps:

[0036] Step 1: The user enters their username and password on the application's login page. This password is a static password that the user has set beforehand.

[0037] Step 2: The application obtains the account and password, and then requests an access token from the authentication server using the account and password.

[0038] Step 3: The authentication server verifies the account and password. If the verification passes, it issues an access token to the application.

[0039] Step 4: The application sends a login request carrying an access token to the application server.

[0040] Step 5: The application server checks the validity of the access token and decides whether to grant access to the requested resource based on the validity check result.

[0041] Step 6: If the check result shows that the access token is valid, grant the application access to the requested resource and return the corresponding resource to the application, such as the application homepage or other pages, so that the user can log in to the corresponding application service.

[0042] In the traditional password login process described above, if a user's account and password are leaked, such as being intercepted by an attacker, it could lead to attacks on the application server and the theft of the user's assets, information, and other resources. Therefore, the security of traditional password login applications is relatively low.

[0043] To enhance the security of password-based application login, in some embodiments of this disclosure, the user enters a composite password containing a static password and a one-time password on the application's login page. The user's terminal device requests an access token for logging into the first application from a first service device using the composite password. The first service device can separate the static password and the one-time password from the composite password and obtain the two-factor authentication result of the static password and the one-time password. This introduction of two-factor authentication into the traditional password-based standard process improves the security of identity authentication and helps enhance the security of application login. Furthermore, it reuses the OIDC password-based standard process, reducing intrusion into the standard password-based process and decreasing the development difficulty and cost of identity authentication.

[0044] The technical solutions provided by the embodiments of this disclosure are described in detail below with reference to the accompanying drawings.

[0045] It should be noted that the same reference numerals in the following figures and embodiments denote the same object or the same step. Therefore, once an object or step is defined in one figure or embodiment, it does not need to be discussed further in subsequent figures and embodiments.

[0046] Figure 2 is a schematic diagram of the service system provided in this embodiment. In this embodiment, for ease of description and distinction, the application to which the user needs to log in is defined as the first application. In this embodiment, the application can be any application that requires user registration of account information and setting of related login passwords, such as instant messaging applications, navigation applications, online shopping applications, video applications, email applications, and lifestyle service applications. These applications require user registration of account information, manage user identity information, and can serve as an identity source.

[0047] As shown in Figure 2, the service system mainly includes: a terminal device 10 running a first application, a first service device 20 providing authentication services, and a service device 30 corresponding to the first application. The service device 30 provides the first application with corresponding resources, such as page resources.

[0048] In this embodiment, the first service device 20 and the service device 30 are computer devices that can respond to service requests from terminal devices and provide users with related services. They generally possess the capability to undertake and guarantee services. The first service device 20 and the service device 30 can be a single server device, a cloud-based server array, or a virtual machine (VM) running within a cloud-based server array. Alternatively, the first service device 20 and the service device 30 can also refer to other computing devices with corresponding service capabilities, such as computers or other terminal devices (running service programs). The first service device 20 and the service device 30 can be deployed on the same physical machine or on different physical machines. Generally, the first service device 20 and the service device 30 are deployed on different physical machines and belong to different developers.

[0049] Terminal device 10 can be a terminal device running the first application, such as a computer, mobile phone, or wearable device (such as a smartwatch). The first application can be an application (APP), a computer-side client, a mini-program, or a web application, etc.

[0050] In this embodiment, the first service device 20 is equipped with an authentication service system. This authentication service system can be the developer's own authentication service system or an IDaaS system. For an IDaaS system, users or enterprises can entrust identity information (such as accounts) from one or more identity sources to the IDaaS system. "Multiple" refers to two or more (including two). Identity sources may include: Active Directory (AD) service, Lightweight Directory Access Protocol (LADP), and one or more application services. AD is a directory service widely used for centralized management and configuration of users, devices, permissions, etc., providing enterprises with robust authentication and access control functions. LADP is an open, industry-standard application protocol used for accessing and maintaining distributed directory information services over a network. It allows applications to query, update, add, or delete information stored in a directory server.

[0051] In this embodiment, users log in to the application using a password, and the user's identity information is managed by the first service device 20. To improve the security of password-based login, a two-factor authentication mechanism is introduced. Specifically, as shown in Figure 2, when logging into the first application, the user can enter their account and password on the application's login page. To further enhance the security of password-based login, a one-time password can be obtained before logging into the first application. A one-time password (OTP), also known as a dynamic password or single-use password, is a password that can only be used once on a computer system or other digital device. Its validity period is short, ranging from seconds, such as 30 seconds or 60 seconds. A login session or transaction is performed within the validity period of the one-time password. The one-time password can be an SMS verification code, a digital token, or a password. A one-time password generally consists of multiple characters, which may include one or more data types such as numbers, letters, operators, and punctuation marks.

[0052] In some embodiments, a first application in a terminal device generates a one-time password. The first application and the first service device 20 share a key, and the terminal device 10 and the first service device 20 are time-synchronized. The first application or the terminal device 10 determines the time window corresponding to the current timestamp. The size of the time window is determined by the validity period of the one-time password. For example, the time window may be equal to the preset validity period of the one-time password. Further, the first application uses a data encryption algorithm to encrypt and encode the time window value and the shared key to obtain a fixed-length numeric string as the one-time password. The data encryption algorithm may be a hash-based message authentication code-secure hash algorithm (HMAC-SHA) or other hash algorithms. HMAC is a technique that generates a message authentication code by combining a key and a hash function. It is used to verify the integrity and authenticity of a message and ensure that the message has not been tampered with. SHA is a secure hash algorithm. HMAC-SHA refers to the HMAC algorithm implemented using the SHA series of hash functions.

[0053] In this one-time password generation method, the terminal device 10 sends the generated one-time password to the first service device 20 for verification. The first service device 20 can generate a one-time password in the same way. If the one-time password generated by the first service device 20 is the same as the one-time password sent by the terminal device 10, then the one-time password is determined to have passed the verification.

[0054] In other embodiments, the first application may employ an event-based one-time password generation method. Specifically, during initial setup, both the first application and the first service device 20 initialize a counter value and share a key. Whenever a new one-time password needs to be generated, the first application uses a data encryption algorithm to encrypt the current counter value and the key, obtaining a fixed-length numeric string as the one-time password.

[0055] In this one-time password generation method, both the first application and the first service device 20 increment their respective counters after each successful one-time password generation. The terminal device 10 sends the generated one-time password to the first service device 20 for verification. The first service device 20 can generate one-time passwords in the same way. If the one-time password generated by the first service device 20 is the same as the one-time password sent by the terminal device 10, then the one-time password is determined to have passed verification.

[0056] In some other embodiments, a challenge / response-based one-time password generation method can be used. Specifically, the first application and the first service device 20 share a key. The first service device 20 generates a random string as challenge information and sends it to the first application. The first application uses a data encryption algorithm to encrypt the challenge information and the shared key, obtaining a fixed-length numeric string as response information, i.e., the one-time password.

[0057] In this one-time password generation method, the terminal device 10 sends the generated one-time password to the first service device 20 for verification. The first service device 20 can use the same method to encrypt the challenge information and the shared key to generate a one-time password. If the one-time password generated by the first service device 20 is the same as the one-time password sent by the terminal device 10, then the one-time password is determined to have passed the verification.

[0058] The foregoing embodiments exemplify specific implementation methods for terminal device 10 to obtain a one-time password, but do not constitute a limitation. Terminal device 10 can output the one-time password for the user to view. For example, terminal device 10 can display the one-time password on the login page of the first application.

[0059] In other embodiments, the login page of the first application may set a password component corresponding to the one-time password. Users can trigger this password component to request a one-time password from the first service device 20. Specifically, the terminal device can send a password request to the first service device 20 in response to the triggering operation of the password component. The first service device 20 can return the one-time password to the terminal device 10 in response to the password request. In this embodiment, the first service device 20 can record a timestamp of the one-time password returned to the terminal device 10. When the terminal device 10 sends the one-time password to the first service device 20 for verification, the first service device 20 can determine whether the one-time password sent by the first service device 20 is within a set validity period. This validity period is generally short, such as 30 seconds or 60 seconds. Specifically, it determines the time difference between the time the one-time password sent by the first service device 20 is received and the aforementioned recorded timestamp; if the time difference is greater than the set validity period, it is determined that the one-time password sent by the first service device 20 has exceeded its validity period, and it can be determined that the one-time password sent by the terminal device 10 has failed verification. If the time difference is less than or equal to the set validity period, it is determined that the one-time password received from the first service device 20 is valid. For a valid one-time password, if the one-time password is the same as the one-time password sent by the first service device 20 to the terminal device 10, it is determined that the one-time password sent by the terminal device 10 has passed verification. If the one-time password is different from the one-time password sent by the first service device 20 to the terminal device 10, it is determined that the one-time password sent by the terminal device 10 has failed verification.

[0060] In this embodiment, the specific method by which the first service device 20 generates the one-time password is not limited. Optionally, the first service device 20 may generate the one-time password based on the current timestamp. Specifically, the first service device 20 may determine the time window corresponding to the current timestamp. Further, a data encryption algorithm may be used to encrypt and encode the time window value to obtain a fixed-length numeric string as the one-time password. Alternatively, the first service device 20 may use the current timestamp as a random seed to generate a fixed-length random number as the one-time password, etc. Further, the first service device 20 may send the one-time password to the terminal device 10.

[0061] In this disclosure, the specific implementation method by which the first service device 20 can send the one-time password to the terminal device 10 is not limited. In some embodiments, the first service device 20 can send the one-time password to the service device of a telecommunications operator and request the service device of the telecommunications operator to send the one-time password to the terminal device 10 in the form of an SMS (text message and / or voice message). In other embodiments, the first service device 20 can send the one-time password to the service device of an email address and request the service device of the email address to send the one-time password to the terminal device 10 in the form of an email. In still other embodiments, the first service device 20 can directly send the one-time password to the terminal device 10 via the network in the form of a network message, etc. The terminal device 10 can output the one-time password for the user to view.

[0062] After obtaining the one-time password, the user can combine the static password set in the first application with the one-time password to obtain a composite password, which they then enter into the login page of the first application. The composition of the composite password follows the agreed-upon method between the first application and the first service device 20. For example, the one-time password can be added to a specific position within the static password set; such as at the end of the static password, before the first character of the static password, or after the Nth character of the static password. Here, 1 ≤ N < M, where M is the total number of characters in the static password. The user can also enter account information, etc., in the login page of the first application.

[0063] Furthermore, the user can trigger the login control on the login page of the first application to request login to the first application. As shown in step 1 of Figure 2, the terminal device 10 can respond to the login operation for the first application by obtaining the user's entered account information and the entered composite password. Further, as shown in step 2 of Figure 2, it can send an authorization request carrying the aforementioned composite password to the first service device 20 to request an access token for logging into the first application. In some embodiments, the terminal device 10 can encapsulate the user's account information and the user's entered password in the authorization request and send the authorization request to the first service device 20 to request an access token for logging into the first application. For the terminal device 10, it only perceives the password entered by the user and cannot perceive whether the password entered by the user is the original static password or a composite password.

[0064] In this embodiment, the password entered by the user is a composite password set by the user, containing both a static password and a one-time password. Even if the authorization request is intercepted by an attacker, since the attacker does not know that the password in the authorization request is a composite password composed of a static password and a one-time password, nor does the attacker know the combination rules of the composite password, when the attacker uses the password in the authorization request to attack the service device of the first application, i.e., service device 30, the service device 30 will fail to verify the password and will block the attacker's access request. Therefore, by carrying the composite password entered by the user containing both a static password and a one-time password in the authorization request, this embodiment can improve the security of the first application.

[0065] On the other hand, the application uses password mode to integrate OIDC. The standard process of traditional password mode login application is shown in Figure 1 above. In this embodiment, the composite password is sent to the first service device 20 in the authorization request, which can reuse the standard process of password mode login application and reduce the intrusion of password mode login method.

[0066] For the first service device 20, in response to the authorization request, it can obtain the composite password from the authorization request. Of course, the first service device 20 can also obtain account information, etc., from the authorization request. Further, as shown in step 3 of Figure 2, the first service device 20 can separate the static password and the one-time password from the composite password.

[0067] Specifically, since the first service device 20 and the first application have pre-agreed on the composition of the password—that is, inserting a one-time password at a predetermined position in the static password—the first service device 20 can read characters of a predetermined length sequentially forward or backward from the predetermined position in the composite password. For example, the first service device 20 can start from the last character in the composite password and read characters of a predetermined length sequentially forward; or, it can start from the first character in the composite password and read characters of a predetermined length sequentially backward. Inserting a one-time password at the predetermined position in the static password facilitates the separation of the static password and the one-time password by the first service device, thus improving the efficiency of the first service device 20 in separating the composite password.

[0068] Furthermore, the first service device 20 can use the read characters of a set length as a one-time password; and use the characters in the compound password other than the one-time password as a static password.

[0069] After separating the static password and the one-time password, as shown in step 4 of Figure 2, the first service device 20 can obtain the two-factor authentication results of the static password and the one-time password.

[0070] In some embodiments, the first service device 20 is the authentication server of the developer of the first application. The first service device 20 can obtain the account information carried in the authorization request and obtain the static password corresponding to the account information carried in the authorization request from the pre-stored correspondence between account information and static password. Further, if the static password separated from the composite password is the static password corresponding to the account information carried in the authorization request, it is determined that the static password separated from the composite password passes the verification, that is, the verification result of the static password is obtained.

[0071] In other embodiments, the first service device 20 deploys an IDaaS system and performs identity verification through the IDaaS system. In some embodiments, the first application has its own authentication server, and the account information of the first application can be hosted in the IDaaS system. However, to improve the security of the first application and its user assets, the static password of the first application is not hosted in the IDaaS system. Therefore, the first service device 20 can request the authentication server of the first application to verify the static password. Specifically, the first service device 20 can send a password authentication request to the authentication server of the first application; the password authentication request carries the static password separated from the composite password. The authentication server of the first application can obtain the static password from the password authentication request, verify the static password, obtain the verification result of the static password, and send the verification result of the static password to the first service device 20. The first service device 20 can obtain the verification result of the static password sent by the authentication server of the first application. For the specific implementation of the first application's authentication server verifying the static password, please refer to the aforementioned content on the verification of the static password by the first service device 20, which will not be repeated here.

[0072] In other embodiments, if the first application does not have its own authentication server, static password verification can be achieved by specifying an identity source in the IDaaS system. In this embodiment, the IDaaS system can provide multiple identity sources, meaning two or more. In this embodiment, the user can independently set and specify an identity source; for ease of description, the user-specified identity source is defined as the target identity source. The user can log in to the first application using the account information and static password from the target identity source.

[0073] To enable users to independently specify a target identity source, in some embodiments, the first service device 20 provides an identity source configuration page to the terminal device 10, which can then display the page. The identity source configuration page may include an identity source configuration control. Users can configure the target identity source independently using this control. The terminal device 10 can obtain the identifier of the target identity source configured through the control and send it to the first service device 20. The first service device 20 can obtain the identifier of the identity source sent by the terminal device 10 and configure the identity source represented by that identifier as the target identity source.

[0074] In some embodiments, the target identity source specified by the user is the IDaaS system. The user's account information and static password in the IDaaS system can be either an IDaaS account created by the user and a static password set in the IDaaS system, or the user's account information and static password in the first application. In embodiments where the user's account information and static password in the IDaaS system are the account information and static password of the first application, the user needs to host both their account information and static password in the first application in the IDaaS system. The method by which the first service device 20 obtains the static password verification result differs depending on the target identity source specified by the user. Specifically, the first service device 20 can obtain the static password verification result according to the static password verification method adapted to the target identity source. By specifying the target identity source for authentication, the first application does not need its own authentication server, saving the authentication development costs for the first application developer.

[0075] Specifically, if the user-specified target identity source is the IDaaS system, the user can enter a static password set in the IDaaS system on the login page of the first application when logging in. Alternatively, the user can enter account information set in the IDaaS system on the login page of the first application. In this embodiment, the static password verification method for the target identity source is as follows: the first service device 20 uses the IDaaS system to verify the static password. Specifically, the first service device 20 can obtain a pre-configured target identity source; if the target identity source is the IDaaS system, it can use the IDaaS system to obtain the static password corresponding to the account information carried in the authorization request. If the static password separated from the composite password is the same as the static password corresponding to the account information carried in the authorization request, then the static password separated from the composite password passes the verification. If the static password separated from the composite password is different from the static password corresponding to the account information carried in the authorization request, then the static password separated from the composite password fails the verification.

[0076] In other embodiments, the target identity source specified by the user is an application other than the first application (defined as the second application). The IDaaS system provides multiple identity sources, including the second application. The second application has its own authentication server. The authentication server corresponding to the second application is defined as the second service device. In this embodiment, the user can enter their account information and static password set in the second application on the login page of the first application to request login to the first application. The static password verification method adapted to the target identity source is as follows: the first service device 20 requests the second service device 40 of the second application to verify the static password and obtains the verification result of the static password returned by the second service device 40. Specifically, as shown in step 4.1 of Figure 3, the first service device 20 can send the static password to the second service device 40 of the second application to request the second service device to verify the static password. Of course, the first service device 20 can also send the account information carried in the authorization request to the second service device 40. The second service device 40 can respond to the request of the first service device 20 and verify the static password to obtain the verification result of the static password (not shown in Figure 3).

[0077] Specifically, the second service device 40 can obtain the static password corresponding to the account information carried in the authorization request; if the static password sent by the first service device 20 is the same as the static password corresponding to the account information carried in the authorization request, then it is determined that the static password sent by the first service device 20 has passed the verification. If the static password sent by the first service device 20 is different from the static password corresponding to the account information carried in the authorization request, then it is determined that the static password sent by the first service device 20 has failed the verification.

[0078] Furthermore, the second service device 40 can return the verification result of the static password to the first service device 20. The first service device 20 then obtains the verification result of the static password.

[0079] The specific implementation method of the first service device 20 verifying the static password shown in the foregoing embodiments is merely illustrative and does not constitute a limitation. Of course, as shown in step 4 of Figure 2 and step 4.2 of Figure 3, the first service device 20 can also verify the one-time password separated from the composite password. The method by which the first service device 20 verifies the one-time password is related to the aforementioned method of generating the one-time password; for details, please refer to the relevant content regarding the verification of the one-time password by the first service device 20, which will not be repeated here. The first service device 20 can use the verification result of the static password and the verification result of the one-time password as the two-factor authentication result.

[0080] The first service device 20 obtains two-factor authentication of the static password and the one-time password in the composite password, which can improve the security of identity verification.

[0081] Furthermore, as shown in step 5 of Figures 2 and 3, when both the static password and the one-time password pass verification (i.e., two-factor authentication is successful), the first service device 20 can return an access token to the terminal device 10. Specifically, when both the static password and the one-time password pass verification, the first service device 20 sends an access token to the terminal device 10, introducing a one-time password verification mechanism on top of the traditional password mode. This provides dual protection for user account security and improves the account security of the first application.

[0082] Terminal device 10 can log in to the first application based on an access token. Specifically, as shown in step 6 of Figures 2 and 3, terminal device 10 can send a login request carrying an access token to the service device (i.e., service device 30) of the first application. Accordingly, as shown in step 7 of Figures 2 and 3, service device 30 can check the validity of the access token based on the login request and decide whether to grant access to the requested resource based on the result of the access token validity check.

[0083] Typically, an access token includes a header, payload, and signature. Therefore, when checking the validity of an access token, the service device 30 can verify the correctness of the access token's signature. Specifically, it re-encodes the header and payload using the encoding method recorded in the access token's header to obtain a new signature. If this new signature matches the signature carried on the access token, the access token's signature is considered correct. If the new signature differs from the signature carried on the access token, the access token's signature is considered incorrect.

[0084] The service device 30 can also check whether the access token has expired. The access token contains an expiration time (Exp) field, which records the expiration time of the access token; if the service device 30 receives the access token after the time recorded in the expiration time field, the access token is determined to be expired; if the service device 30 receives the access token before the time recorded in the expiration time field, the access token is determined to be valid.

[0085] Service device 30 can also check whether the access token has the permission to access the requested resource. Permission check: The resource server checks whether the Access Token has the permission to access the requested resource. The access token contains a Scope field, which records the scope of permissions for the access token. Service device 30 can obtain the scope of permissions for the access token from the access token; if the scope includes permission to access the first application, then it is determined that service device 30 has permission to access the first application. If the scope does not include permission to access the first application, then it is determined that service device 30 does not have permission to access the first application.

[0086] Service device 30 can also check whether the issuer of the access token (i.e., the first service device 20) is a trusted authentication server. Specifically, service device 30 can obtain the issuer's statement from the access token, which specifies the entity that issued the token, i.e., the identification information of the second service device 40. If the second service device 40 is a trusted authentication server pre-configured by service device 30, then the issuer of the access token is determined to be a trusted authentication server; if the second service device 40 is not a trusted authentication server pre-configured by service device 30, then the issuer of the access token is determined not to be a trusted authentication server.

[0087] Through the above implementation method, the service device 30 can check whether the access token is valid. Specifically, the service device 30 can determine that the access token is valid if the signature of the access token is correct, the access token is valid, the access token has the permission to access the first application, and the issuer of the access token is a trusted authentication server. Further, as shown in step 8 of Figures 2 and 3, if the access token is valid, the service device 30 grants the application access to the requested resource and returns the corresponding resource to the terminal device 10, such as the homepage or other pages of the first application, thereby enabling the terminal device to log in to the first application.

[0088] In this embodiment, the user enters a composite password containing a static password and a one-time password on the application's login page. The user's terminal device requests an access token for logging into the first application from the first service device using the composite password. The first service device can separate the static password and the one-time password from the composite password and obtain the two-factor authentication result of the static password and the one-time password. This introduces two-factor authentication into the traditional password pattern standard process, improving the security of identity authentication and contributing to the security of application login. Furthermore, it reuses the OIDC password pattern standard process, reducing intrusion into the password pattern standard process and reducing the development difficulty and cost of identity authentication.

[0089] In some embodiments of this disclosure, the IDaaS system provides multiple identity sources. Users can log in to the application corresponding to the identity source provided by the IDaaS system. Specifically, in response to a login operation of the terminal device on the IDaaS system, an identity source management page of the IDaaS system is provided to the terminal device; this identity source management page includes identifiers for multiple identity sources. Users can select the identity source corresponding to the application they wish to log in to by triggering the identity source identifier. Furthermore, the terminal device can display a login control for the triggered identity source. Users can log in to the relevant application by triggering the login control.

[0090] For the first service device 20, login operations by the terminal device targeting the first identity source among multiple identity sources can be monitored. The first identity source is the identity source triggered by the user. Furthermore, in response to the login operation targeting the first identity source, the first service device 20 can send a login request carrying another access token and the identifier of the terminal device to the third service device (not shown in the attached figure) corresponding to the first identity source. The third service device refers to the service device that provides relevant resources (such as page resources) to the application corresponding to the first identity source.

[0091] Specifically, the first service device 20 can issue an access token to the terminal device in response to a login operation targeting the first identity source. In this embodiment of the disclosure, for ease of description and distinction, the access token issued for the login request targeting the first application is defined as the first access token; and the access token issued for the login operation targeting the application corresponding to the first identity source in this embodiment is defined as the second access token.

[0092] Furthermore, the first service device 20 can generate a login request carrying a second access token and the identifier of the terminal device. Correspondingly, the third service device can obtain this login request and extract the second access token and the identifier of the terminal device from it. Furthermore, the third service device can check the validity of the second access token. For a detailed implementation of checking the validity of the second access token, please refer to the aforementioned content regarding the service device checking the validity of the first access token in the first application; it will not be repeated here.

[0093] If the second access token is valid, the third service device can return the target resources of the application corresponding to the first identity source, such as the target page, to the terminal device based on the terminal device's identifier. The target page can be the application's homepage or other pages, such as the page the user was on when exiting the application.

[0094] In this embodiment, the IDaaS system supports multiple identity sources. Users can log in to the application corresponding to the identity source through the IDaaS system. When switching to other applications, users only need to initiate a login operation for the identity source corresponding to the application they need to log in to on the identity source management page of the IDaaS application, without having to enter the application's account information and static password. This simplifies the application login process, improves the user experience, and also helps to speed up the switching speed between different applications.

[0095] In addition to the service system provided in the foregoing embodiments, this disclosure also provides an application login method, which will be described exemplarily from the perspective of the authentication server (i.e., the aforementioned first service device).

[0096] Figure 4 is a flowchart illustrating the application login method provided in this embodiment. As shown in Figure 4, the application login method mainly includes:

[0097] 401. Obtain the authorization request from the terminal device for the first application; the authorization request includes: a composite password consisting of a static password and a one-time password.

[0098] 402. Separate static ciphers and one-time ciphers from composite ciphers.

[0099] 403. Obtain the two-factor authentication results for both static password and one-time password.

[0100] 404. If the two-factor authentication result indicates that the static password and the one-time password have passed the authentication, return the first access token to the terminal device so that the terminal device can log in to the first application through the first access token.

[0101] In this embodiment of the disclosure, the first service device is equipped with an authentication service system. This authentication service system can be the developer's own authentication service system or an IDaaS system. For an IDaaS system, users or enterprises can entrust identity information (such as accounts) from one or more identity sources to the IDaaS system.

[0102] In this embodiment, users log in to the application using a password, and the user's identity information is managed by a first service device. To improve the security of password-based login, a two-factor authentication mechanism is introduced. Specifically, when logging into the first application, the user can enter their username and password on the application's login page. To further enhance the security of password-based login, a one-time password can be obtained before logging into the first application. For details on how the terminal device obtains the one-time password, please refer to the relevant content in the foregoing embodiments, which will not be repeated here.

[0103] After receiving the one-time password, the user can combine it with the static password set in the first application to obtain a composite password, which they then enter into the login page of the first application. The composition of the composite password is agreed upon by the first application and the first service device. For example, the one-time password can be added to the static password at specific positions, such as at the end, before the first character, or from the Nth position of the static password. Here, 1 < N < M, where M is the total number of characters in the static password. Users can also enter account information in the login page of the first application.

[0104] Furthermore, the user can trigger the login control on the login page of the first application to request login to the first application. In response to the login operation for the first application, the terminal device can obtain the account information and the complex password entered by the user, and further, can send an authorization request carrying the aforementioned complex password to the first service device to request an access token for logging into the first application.

[0105] In this embodiment, the password entered by the user is a composite password consisting of a static password and a one-time password. Even if the authorization request is intercepted by an attacker, since the attacker does not know that the password in the authorization request is a composite password composed of a static password and a one-time password, nor does the attacker know the combination rules of the composite password, when the attacker uses the password in the authorization request to attack the service device of the first application, the service device will fail to verify the password and will block the attacker's access request. Therefore, this embodiment carries the composite password containing a static password and a one-time password entered by the user in the authorization request, which can improve the security of the first application.

[0106] On the other hand, the application uses password mode to integrate OIDC. The standard process of traditional password mode login application is shown in Figure 1 above. In this embodiment, the composite password is sent to the first service device in the authorization request, which can reuse the standard process of password mode login application and reduce the intrusion of password mode login method.

[0107] For the first service device, in step 401, in response to the authorization request, the composite password can be obtained from the authorization request. Of course, account information, etc., can also be obtained from the authorization request. Further, in step 402, the static password and the one-time password can be separated from the composite password.

[0108] Specifically, since the first service device and the first application have pre-agreed on the composition of the password—namely, inserting a one-time password at a predetermined position in the static password—the first service device can read characters of a predetermined length sequentially forward or backward from the predetermined position in the composite password. For example, the first service device can start from the last character of the composite password and read characters of a predetermined length forward; or, it can start from the first character and read characters of a predetermined length backward. Inserting a one-time password at the predetermined position in the static password facilitates the separation of the static password and the one-time password by the first service device, thus improving the efficiency of the first service device in separating the composite password.

[0109] Furthermore, characters of a set length can be identified as a one-time password; and characters in a compound password other than the one-time password can be identified as a static password.

[0110] After separating the static password and the one-time password, in step 403, the two-factor authentication results of the static password and the one-time password can be obtained.

[0111] In some embodiments, if the first service device is the authentication server of the developer of the first application, then the first service device can obtain the account information carried in the authorization request and retrieve the static password corresponding to the account information carried in the authorization request from the pre-stored correspondence between account information and static passwords. Further, if the static password extracted from the composite password is the static password corresponding to the account information carried in the authorization request, then the static password extracted from the composite password is determined to have passed the verification, and the verification result of the static password is obtained and returned to the first service device. The first service device obtains the verification result of the static password returned by the authentication server of the first application.

[0112] In other embodiments, the first service device deploys an IDaaS system and performs identity verification through the IDaaS system. In some embodiments, the first application has its own authentication server, and the account information of the first application can be hosted in the IDaaS system. However, to improve the security of the first application and its user assets, the static password of the first application is not hosted in the IDaaS system. Therefore, the first service device can request the authentication server of the first application to verify the static password. Specifically, a password authentication request can be sent to the authentication server of the first application; this password authentication request carries the static password separated from the composite password. The authentication server of the first application can obtain the static password from the password authentication request, verify the static password, obtain the verification result of the static password, and return the verification result of the static password to the first service device. The first service device obtains the verification result of the static password returned by the authentication server of the first application. For the specific implementation of the first application's authentication server verifying the static password, please refer to the aforementioned content on the verification of the static password by the first service device, which will not be repeated here.

[0113] In other embodiments, if the first application does not have its own authentication server, static password verification can be achieved by specifying an identity source in the IDaaS system. In this embodiment, the IDaaS system can provide multiple identity sources, meaning two or more. In this embodiment, the user can independently set and specify an identity source; for ease of description, the user-specified identity source is defined as the target identity source. The user can log in to the first application using the account information and static password from the target identity source.

[0114] To enable users to independently specify a target identity source, in some embodiments, the first service device provides an identity source configuration page to the terminal device, which can then display this page. The identity source configuration page may include an identity source configuration control. Users can configure the target identity source independently through this control. The terminal device can obtain the identifier of the target identity source configured via the control and send it to the first service device. The first service device can obtain the identifier of the identity source sent by the terminal device and configure the identity source represented by that identifier as the target identity source.

[0115] In some embodiments, the target identity source specified by the user is the IDaaS system. The user's account information and static password in the IDaaS system can be either an IDaaS account created by the user and a static password set in the IDaaS system, or the user's account information and static password in the first application. In embodiments where the user's account information and static password in the IDaaS system are the account information and static password of the first application, the user needs to entrust both their account information and static password in the first application to the IDaaS system. The method by which the first service device 20 obtains the static password verification result differs depending on the target identity source specified by the user. Specifically, the first service device 20 can obtain the static password verification result according to the static password verification method adapted to the target identity source.

[0116] If the user-specified target identity source is the IDaaS system, the user can enter the static password set in the IDaaS system on the login page of the first application when logging in. Alternatively, the user can enter the account information set in the IDaaS system on the login page of the first application. In this embodiment, the static password verification method for the target identity source is as follows: the first service device can use the IDaaS system to verify the static password. Specifically, the first service device can obtain a pre-configured target identity source; if the target identity source is the IDaaS system, the IDaaS system can be used to obtain the static password corresponding to the account information carried in the authorization request. If the static password separated from the composite password is the same as the static password corresponding to the account information carried in the authorization request, then the static password separated from the composite password passes the verification. If the static password separated from the composite password is different from the static password corresponding to the account information carried in the authorization request, then the static password separated from the composite password fails the verification.

[0117] In other embodiments, the target identity source specified by the user is an application other than the first application (defined as the second application). The IDaaS system provides multiple identity sources, including the second application. The second application has its own authentication server. The authentication server corresponding to the second application is defined as the second service device. In this embodiment, the user can enter their account information and set static password in the second application on the login page of the first application to request login to the first application. The static password verification method adapted to the target identity source is as follows: the first service device requests the second service device of the second application to verify the static password. Specifically, the first service device can send the static password to the second service device of the second application to request the second service device to verify the static password. Of course, the first service device can also send the account information carried in the authorization request to the second service device. The second service device can respond to the request of the first service device and verify the static password to obtain the verification result. For the specific method of the second service device verifying the static password, please refer to the relevant content of the foregoing embodiments, which will not be repeated here.

[0118] Furthermore, the second service device can return the verification result of the static password to the first service device. The first service device then obtains the verification result of the static password.

[0119] The specific implementation method for verifying static passwords by the first service device shown in the foregoing embodiments is merely illustrative and does not constitute a limitation. Of course, the first service device can also verify the one-time password separated from the composite password to obtain the verification result of the one-time password. The method by which the first service device verifies the one-time password is related to the aforementioned method of generating the one-time password; please refer to the relevant content on the verification of one-time passwords by the first service device for details, which will not be repeated here. The first service device can use the verification result of the static password and the verification result of the one-time password as the two-factor authentication result, thus realizing two-factor authentication and improving the security of identity verification.

[0120] Furthermore, if both the static password and the one-time password pass verification, an access token can be returned to the terminal device in step 404. Specifically, when both the static password and the one-time password pass verification, the first service device sends an access token to the terminal device. This introduces a one-time password verification mechanism on top of the traditional password mode, providing dual protection for user account security and improving the account security of users of the first application.

[0121] Terminal devices can log in to the first application based on an access token. For details on how terminal devices can log in to the first application based on an access token, please refer to the relevant content in the aforementioned system embodiments; these details will not be repeated here.

[0122] In this embodiment, the user enters a composite password containing a static password and a one-time password on the application's login page. The user's terminal device requests an access token for logging into the first application from the first service device using the composite password. The first service device can separate the static password and the one-time password from the composite password and obtain the two-factor authentication verification result of the static password and the one-time password. The introduction of two-factor authentication into the traditional password pattern standard process improves the security of identity authentication and helps enhance the security of application login. On the other hand, it reuses the OIDC password pattern standard process, reducing intrusion into the password pattern standard process and reducing the development difficulty and cost of identity authentication.

[0123] In some embodiments of this disclosure, the IDaaS system provides multiple identity sources. Users can log in to the application corresponding to the identity source provided by the IDaaS system. Specifically, in response to a login operation of the terminal device on the IDaaS system, an identity source management page of the IDaaS system is provided to the terminal device; this identity source management page includes identifiers for multiple identity sources. Users can select the identity source corresponding to the application they wish to log in to by triggering the identity source identifier. Furthermore, the terminal device can display a login control for the triggered identity source. Users can log in to the relevant application by triggering the login control.

[0124] For the first service device, login operations by the terminal device targeting the first identity source among multiple identity sources can be monitored. The first identity source is the identity source triggered by the user. Furthermore, in response to the login operation targeting the first identity source, the first service device 20 can send a login request carrying another access token and the identifier of the terminal device to the third service device (not shown in the attached figure) corresponding to the first identity source. The third service device refers to the service device that provides relevant resources (such as page resources) to the application corresponding to the first identity source.

[0125] Specifically, the first service device can issue an access token to the terminal device in response to a login operation targeting the first identity source. In this embodiment of the disclosure, for ease of description and distinction, the access token issued for the login request targeting the first application is defined as the first access token; and the access token issued for the login operation targeting the application corresponding to the first identity source in this embodiment is defined as the second access token.

[0126] Furthermore, the first service device can generate a login request carrying a second access token and the identifier of the terminal device. Correspondingly, the third service device can obtain this login request and extract the second access token and the identifier of the terminal device from it. Furthermore, the third service device can check the validity of the second access token. For a detailed implementation of checking the validity of the second access token, please refer to the aforementioned content regarding the service device checking the validity of the first access token in the first application; it will not be repeated here.

[0127] If the second access token is valid, the third service device can return the target resources of the application corresponding to the first identity source, such as the target page, to the terminal device based on the terminal device's identifier. The target page can be the application's homepage or other pages, such as the page the user was on when exiting the application.

[0128] In this embodiment, the IDaaS system supports multiple identity sources. Users can log in to the application corresponding to the identity source through the IDaaS system. When switching to other applications, users only need to initiate a login operation for the identity source corresponding to the application they need to log in to on the identity source management page of the IDaaS application, without having to enter the application's account information and static password. This simplifies the application login process, improves the user experience, and also helps to speed up the switching speed between different applications.

[0129] It should be noted that the execution subject of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution subject of steps 401 and 402 can be device A; or the execution subject of step 401 can be device A, and the execution subject of step 402 can be device B; and so on.

[0130] Furthermore, some processes described in the above embodiments and accompanying drawings include multiple operations that appear in a specific order. However, it should be clearly understood that these operations may not be executed in the order they appear herein, or they may be executed in parallel. The operation numbers, such as 401, 402, etc., are merely used to distinguish different operations and do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel.

[0131] Accordingly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions, which, when executed by one or more processors, cause one or more processors to perform the steps in the application login method described above.

[0132] This disclosure also provides a computer program product, including a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps in the application login method described above. In this disclosure, the specific implementation of the computer program product is not limited. In some embodiments, the computer program product may be implemented as an application (APP), a mini-program, a PC-side client, a program module, a plug-in, an installation package, a software development kit (SDK), an optical disc image file (such as an ISO file), a plug-in, or software in the form of Software as a Service (SaaS), etc., but is not limited thereto.

[0133] Figure 5 is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. As shown in Figure 5, the electronic device includes: a memory 50a, a processor 50b, and a communication component 50c. The memory 50a is used to store computer programs.

[0134] The processor 50b is coupled to the memory 50a and the communication component 50c, and is used to execute a computer program to perform the steps in the application login method provided in the foregoing embodiments. Specific implementation details of each step can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here.

[0135] In some alternative embodiments, as shown in FIG5, the electronic device may further include optional components such as a power supply component 50d, a display component 50e, and an audio component 50f. FIG5 only schematically shows some components and does not mean that the electronic device must include all the components shown in FIG5, nor does it mean that the electronic device can only include the components shown in FIG5.

[0136] Furthermore, the components within the dashed boxes in Figure 5 are optional, not mandatory, and their specific requirements depend on the product form of the electronic device. The electronic device in this embodiment can be a desktop computer, laptop computer, mobile phone, or IoT device; it can also be a traditional server, cloud server, or server cluster, or other server equipment.

[0137] In embodiments of this disclosure, the memory is used to store computer programs and can be configured to store various other data to support operation on its host device. The processor can execute the computer programs stored in the memory to implement corresponding control logic. The memory can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random-Access Memory (SRAM), Electrically Erasable Programmable Read Only Memory (EEPROM), Electrically Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0138] In this embodiment of the disclosure, the processor can be any hardware processing device capable of executing the above-described method logic. Optionally, the processor can be a central processing unit (CPU), a graphics processing unit (GPU), or a microcontroller unit (MCU); it can also be a programmable device such as a field-programmable gate array (FPGA), a programmable array logic (PAL), a general array logic (GAL), or a complex programmable logic device (CPLD); or it can be an advanced RISC machine (ARM) or a system on chip (SoC), etc., but is not limited thereto.

[0139] In embodiments of this disclosure, the communication component is configured to facilitate wired or wireless communication between its host device and other devices. The device housing the communication component can access wireless networks based on communication standards, such as Wireless Fidelity (WiFi), 2G or 3G, 4G, 5G, or combinations thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In another exemplary embodiment, the communication component may also be implemented based on Near Field Communication (NFC), Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), or other technologies.

[0140] In embodiments of this disclosure, the display component may include a liquid crystal display (LCD) and a touch panel (TP). If the display component includes a touch panel, the display component may be implemented as a touchscreen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation.

[0141] In embodiments of this disclosure, a power supply component is configured to provide power to various components of the device in which it resides. The power supply component may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply component resides.

[0142] In embodiments of this disclosure, the audio component can be configured to output and / or input audio signals. For example, the audio component includes a microphone (MIC) configured to receive external audio signals when the device containing the audio component is in an operating mode, such as call mode, recording mode, or voice recognition mode. The received audio signals can be further stored in memory or transmitted via a communication component. In some embodiments, the audio component also includes a speaker for outputting audio signals. For example, in devices with voice interaction capabilities, voice interaction with a user can be achieved through the audio component.

[0143] It should be noted that the terms "first" and "second" in this article are used to distinguish different messages, devices, modules, etc., and do not represent a chronological order, nor do they limit "first" and "second" to different types.

[0144] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code.

[0145] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0146] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0147] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0148] In a typical configuration, a computing device includes one or more processors (CPU, etc.), input / output interfaces, network interfaces, and memory.

[0149] Memory may include non-persistent storage in computer-readable media, such as random-access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0150] Computer storage media are readable storage media, also known as removable media. Removable and non-removable media can be used to store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, Digital Video Disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0151] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the aforementioned element.

[0152] The above description is merely an embodiment of this disclosure and is not intended to limit the scope of this disclosure. Various modifications and variations can be made to this disclosure by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure should be included within the scope of the claims of this disclosure.

Claims

1. A method for application login, suitable for a first service device, wherein, include: Obtain the authorization request from the terminal device for the first application; The authorization request includes: a composite password; the composite password includes a static password and a one-time password; From the composite cipher, the static cipher and the one-time cipher are separated; Obtain the two-factor authentication results of the static password and the one-time password; If the two-factor authentication result indicates that the static password and the one-time password have passed the authentication, a first access token is returned to the terminal device so that the terminal device can log in to the first application using the first access token.

2. The method of claim 1, wherein, The first service device is equipped with an Identity as a Service system; obtaining the two-factor authentication result of the static password and the one-time password includes: The identity-as-a-service system is used to verify the one-time password to obtain the verification result of the one-time password; Obtain the target identity source pre-configured in the Identity-as-a-Service system; Based on the static password verification method adapted to the target identity source, obtain the verification result of the static password; The verification results of the one-time password and the static password are used as the two-factor authentication results.

3. The method of claim 2, wherein, The step of obtaining the verification result of the static password according to the static password verification method adapted to the target identity source includes: If the target identity source is the second application, the static password is sent to the second service device of the second application to request the second service device to verify the static password and obtain the verification result of the static password returned by the second service device; wherein, the static password is the static password set in the second application that is entered on the login page of the first application; or, If the target identity source is the Identity as a Service system, then the Identity as a Service system is used to verify the static password to obtain the verification result of the static password; the static password is the static password set in the Identity as a Service system and entered on the login page of the first application.

4. The method according to any one of claims 1 to 3, wherein, The step of separating the static password and the one-time password from the composite password includes: Starting from a predetermined position in the composite cipher, read characters of a predetermined length sequentially forward or backward; The characters of a set length read are determined as the one-time password; and the characters in the composite password other than the one-time password are determined as the static password.

5. The method of claim 4, wherein, The step of reading characters sequentially forward or backward from a predetermined position in the composite cipher includes: Starting from the last character in the composite cipher, read characters sequentially forward for a set number of positions; or, Starting from the first character of the composite cipher, read characters of a set length sequentially.

6. The method according to any one of claims 1 to 5, wherein, Also includes: In response to the password request from the terminal device, the one-time password is returned to the terminal device for input of the composite password on the login page of the first application.

7. The method of claim 3, wherein, The Identity as a Service system provides multiple identity sources; The multiple identity sources include: the second application; the method further includes: Obtain the identifier of the identity source sent by the terminal device; and configure the identity source represented by the identifier of the identity source as the target identity source.

8. The method of claim 2, wherein, The Identity-as-a-Service system provides multiple identity sources; the method further includes: In response to the login operation of the terminal device for the Identity as a Service system, the identity source management page of the Identity as a Service system is provided to the terminal device; the identity source management page includes identifiers of multiple identity sources; In response to a login operation targeting a first identity source among the multiple identity sources, a login request carrying a second access token and the identifier of the terminal device is sent to a third service device corresponding to the first identity source, so that the third service device can return the target resources of the application corresponding to the first identity source to the terminal device based on the second access token and the identifier of the terminal device.

9. The method of any one of claims 1-8, wherein, The one-time password is either a time-based one-time password or an event-based one-time password; obtaining the two-factor authentication result of the static password and the one-time password further includes: When verifying the one-time password, the validity period or event relevance of the one-time password is verified.

10. The method of claim 1, wherein, Before returning the first access token to the terminal device, the process also includes: Generate a refresh token corresponding to the first access token; The refresh token is associated with and stored with the first access token, and the refresh token is returned to the terminal device so that the terminal device can request a new access token using the refresh token when the first access token expires.

11. The method according to any one of claims 1-10, wherein, The composite cipher further includes a separator; separating the static cipher and the one-time cipher from the composite cipher includes: The composite password is split into two parts based on the delimiter, which are respectively identified as the static password and the one-time password.

12. The method according to claim 11, wherein, The delimiter is a preset character or a preset string; the method further includes: The rule information of the separator is sent to the terminal device in advance so that the terminal device can follow the rule information when generating the composite password.

13. The method according to claim 2, wherein, The Identity as a Service system verifies the one-time password by including: Obtain the seed key corresponding to the terminal device; A one-time password for verification is generated based on the seed key and the preset algorithm; The verification one-time password is compared with the one-time password separated from the compound password to obtain the verification result of the one-time password.

14. The method according to claim 7, wherein, The step of obtaining the identifier of the identity source sent by the terminal device includes: The terminal device receives an identity source selection instruction sent through the login page of the first application. The identity source selection instruction carries the identifier of the identity source and is generated by the terminal device in response to the user's selection operation of the identity source list displayed on the login page.

15. The method according to claim 1, wherein, After obtaining the authorization request from the terminal device for the first application, it also includes: The authorization request is validated for legality, including validating the identity information of the terminal device or the identification information of the first application. If the authorization request passes the validity verification, the step of separating the static password and the one-time password from the composite password is performed.

16. The method according to claim 8, wherein, The second access token is a global access token generated by the Identity as a Service system based on the login operation of the terminal device; The global access token is used by the terminal device to access applications corresponding to various identity sources provided by the Identity as a Service system.

17. A service system, wherein, include: The terminal device running the first application, the first service device, and the service device corresponding to the first application; The terminal device is used to send an authorization request to the first service device; The authorization request includes a complex password; The composite cryptography comprises a static cryptography and a one-time cryptography. The first service device is configured to, in response to the authorization request, separate the static password and the one-time password from the composite password; obtain the two-factor verification result of the static password and the one-time password; and, if the two-factor verification result indicates that the static password and the one-time password have passed the verification, return a first access token to the terminal device. The terminal device is configured to send a login request to the service device based on the first access token; The service device is used to check the validity of the first access token based on the login request, and if the first access token is valid, to return the resources of the first application to the terminal device.

18. An electronic device, wherein, include: A memory, a processor, and communication components; wherein the memory is used to store computer programs; The processor is coupled to the memory and the communication component for executing the computer program to perform the steps of the method according to any one of claims 1-16.

19. A computer-readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors are caused to perform the steps of the method according to any one of claims 1-16.

20. A computer program product, wherein, Includes a computer program that, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to any one of claims 1-16.

Images