WO2021143280A1 - 登录认证方法、装置与系统 - Google Patents

登录认证方法、装置与系统 Download PDF

Info

Publication number
WO2021143280A1
WO2021143280A1 PCT/CN2020/125209 CN2020125209W WO2021143280A1 WO 2021143280 A1 WO2021143280 A1 WO 2021143280A1 CN 2020125209 W CN2020125209 W CN 2020125209W WO 2021143280 A1 WO2021143280 A1 WO 2021143280A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
token
verification
server
sent
Prior art date
Application number
PCT/CN2020/125209
Other languages
English (en)
French (fr)
Inventor
林龙
程慧涛
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP20914463.3A priority Critical patent/EP4092955A4/en
Priority to US17/793,322 priority patent/US20230353363A1/en
Publication of WO2021143280A1 publication Critical patent/WO2021143280A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G06F21/335—User authentication using certificates for accessing specific resources, e.g. using Kerberos tickets
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/63—Location-dependent; Proximity-dependent
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/48—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for in-vehicle communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication

Definitions

  • This application relates to the field of communication technology, and in particular to a login authentication method, device and system.
  • the second terminal Acquire the NFC identifier of the second terminal; if it is determined that the second terminal is a trusted device according to the NFC identifier, acquire the second token of the second terminal, and verify the validity of the second token through the server ; In the case of passing the second token verification, automatically log in to the target account.
  • the second token is applied by the second terminal to the server by logging in to the target account in advance.
  • the trusted list establishment method and the trusted device verification method are both simple and convenient.
  • acquiring the short-range communication identifier of the second terminal includes: in a case where the first terminal stores the first token and is in a logout state, acquiring the proximity of the second terminal Distance communication identification; wherein, the first token is applied by the first terminal to the server by logging in to the target account in advance.
  • the target account is automatically logged in through the first token, so that there is no need to store account information such as the user's account password in the first terminal, thereby improving the user's data security.
  • the method when the first terminal stores the first token and is in the logout state, before acquiring the short-range communication identifier of the second terminal, the method further includes: If the first token is not stored in the first terminal, in the process of logging in to the target account, a token acquisition request is sent to the server, where the token acquisition request is used to request the server to log in to the target account of the first terminal If the request is verified, the first token is returned; the first token returned by the server is received and stored.
  • a check code request is sent to the server, where the check code request carries the first token, and the check code request is used to indicate that the server is in the If a token is verified, a check code is returned; after receiving the check code returned by the server, the check code is sent to the second terminal to instruct the second terminal to send the check code to the server for verification ; Make sure that the check code is verified.
  • the check code verification is performed before the token verification is performed, so that the trust of the second terminal to the first terminal can be established, and the data security of the second terminal can be improved.
  • the method further includes: determining that the received unique identifier of the account is consistent with the unique identifier of the target account.
  • the account consistency verification is performed before the token verification is performed, so that the trust of the first terminal to the second terminal can be further established, thereby further improving the security of the automatic login of the first terminal.
  • the key is an asymmetric key. This can further improve the security of data interaction between the first terminal and the second terminal.
  • the method further includes: periodically sending the second token to the server for verification at a preset time interval; if the verification fails, reacquire the second token from the second terminal The second token is sent to the server for verification; if the re-acquired second token fails the verification, the logout operation is performed. In this way, the security of the automatic login of the first terminal can be further improved.
  • the embodiments of the present application provide a login authentication method, which is applied to a second terminal, and includes: in response to a request of the first terminal to obtain a short-range communication identifier, sending a short-range communication identifier to the first terminal; In the case of the target account, the first token sent by the first terminal is received, and the first token is sent to the server for validity verification, where the first token is when the first terminal determines the first token according to the short-range communication identifier.
  • the method further includes: if the second terminal is not stored If there is a second token, in the process of logging in to the target account, a token acquisition request is sent to the server, where the token acquisition request is used to request the server to verify the target account login request of the second terminal. Return the second token; receive and store the second token returned by the server.
  • the method further includes: if it is detected that the user inputs an operation to log out of the target account on the first terminal, performing a logout operation and clearing the second token.
  • the method before receiving the first token sent by the first terminal, the method further includes: establishing a short-range communication connection with the first terminal.
  • the method further includes: sending a unique identifier of the logged-in account to the first terminal, so that the first terminal determines that the received account unique identifier is consistent with the account unique identifier of the target account .
  • the embodiment of the present application provides a login authentication method, which is applied to the server, and includes:
  • the method before receiving the first token sent by the second terminal, the method further includes: receiving a check code request sent by the first terminal, where the check code request carries the first token. Token; if the verification of the first token is passed, return a verification code to the first terminal; receive a verification request carrying the verification code sent by the second terminal; in the case of verification of the verification code To return the verification result of the check code to the second terminal.
  • an embodiment of the present application provides a login authentication device, which is applied to a first terminal, and includes:
  • the near field communication unit is used to obtain the near field communication identifier of the second terminal when the first terminal has the first token stored in it and is in the logout state, and determine whether the second terminal is trustworthy according to the near field communication identifier
  • the device wherein the first token is applied by the first terminal to the server by logging in to the target account in advance.
  • the token exchange unit is configured to obtain the second token of the second terminal when the short-range communication unit determines that the second terminal belongs to a trusted device according to the short-range communication identifier;
  • the login request unit is configured to automatically log in to the target account when the second token is verified.
  • the device further includes: a trusted list establishing unit, configured to, before the Bluetooth matching unit obtains the short-range communication identifier of the second terminal, in the case where the target account is successfully logged in, The short-range communication identifier of the second terminal is added to the trusted list based on the configuration operation of the user, where the second terminal establishes a short-range communication connection with the first terminal.
  • a trusted list establishing unit configured to, before the Bluetooth matching unit obtains the short-range communication identifier of the second terminal, in the case where the target account is successfully logged in.
  • the short-range communication identifier of the second terminal is added to the trusted list based on the configuration operation of the user, where the second terminal establishes a short-range communication connection with the first terminal.
  • the login request unit is specifically configured to automatically log in to the target account when the first token is verified.
  • the device further includes:
  • the verification unit is configured to: before the token verification unit verifies the validity of the first token and the second token through the server, and after the near-field communication unit establishes a near-field communication connection with the second terminal, the near-field communication unit is When the short-range communication identifier determines that the second terminal is a trusted device, a check code request is sent to the server, where the check code request carries the first token, and the check code request is used to indicate that the server is in the If a token is verified, a check code is returned; after receiving the check code returned by the server, the check code is sent to the second terminal to instruct the second terminal to send the check code to the server for verification ; Make sure that the check code is verified.
  • the verification unit is further configured to: before the token exchange unit obtains the second token of the second terminal, determine that the received account unique identifier is consistent with the account unique identifier of the target account.
  • the token exchange unit is specifically configured to: send the first token to the second terminal to instruct the second terminal to send the first token to the server for validity verification , And return the second token after the first token is verified; if the second token sent by the second terminal is received, the token verification unit is instructed to send the second token to the server for validity verification.
  • the key is an asymmetric key.
  • an embodiment of the present application provides a login authentication device, which is applied to a second terminal, and includes:
  • the short-range communication unit is configured to send the short-range communication identifier to the first terminal in response to the request of the first terminal to obtain the short-range communication identifier.
  • the token exchange unit is configured to receive the first token sent by the first terminal when the target account has been successfully logged in.
  • the token verification unit is configured to send the first token to the server for validity verification, where the first token is sent by the first terminal when it is determined that the second terminal is a trusted device according to the short-range communication identifier ; Receive the first token verification result returned by the server.
  • the token exchange unit is also used to: return a second token to the first terminal when the first token is verified, so as to instruct the first terminal to send the second token to the server for validity verification. 2.
  • passing token verification automatically log in to the target account, where the first token is applied by the first terminal to the server by logging in the target account in advance, and the second token is the second terminal to the service by logging in the target account in advance.
  • the login request unit is further configured to perform a logout operation and clear the second token if it is detected that the user inputs an operation to log out of the target account on the first terminal.
  • the short-range communication unit is specifically configured to: before the token exchange unit receives the first token sent by the first terminal, establish a short-range communication connection with the first terminal.
  • the device further includes: a verification unit, configured to establish between the short-distance communication unit and the first terminal before the token exchange unit receives the first token sent by the first terminal After the short-range communication connection, receive the check code sent by the first terminal, where the check code is requested from the server by the first terminal in the case that the second terminal is a trusted device according to the short-range communication identifier; The check code is sent to the server for verification; the check code verification result returned by the server is received; the check code is confirmed to pass.
  • a verification unit configured to establish between the short-distance communication unit and the first terminal before the token exchange unit receives the first token sent by the first terminal
  • receive the check code sent by the first terminal where the check code is requested from the server by the first terminal in the case that the second terminal is a trusted device according to the short-range communication identifier
  • the check code is sent to the server for verification; the check code verification result returned by the server is received; the check code is confirmed to pass.
  • the verification unit is further configured to: send the unique identifier of the logged-in account to the first terminal, so that the first terminal determines that the received unique identifier of the account is unique to the account of the target account.
  • the logo is consistent.
  • the token verification unit is specifically configured to: receive the first token sent by the first terminal; send the first token to the server for validity verification; and receive the server to return The first token verification result; if the first token is verified, the second token is returned to the first terminal to instruct the first terminal to send the second token to the server for validity verification.
  • an embodiment of the present application provides a login authentication device, which is applied to a server, and includes:
  • the check code generation unit is used to receive the check code request sent by the first terminal, and return the check code to the first terminal when the first token is successfully verified, wherein the check code request carries the first
  • the token and verification code request is sent by the first terminal when it is determined that the second terminal is a trusted device, and the first token is applied by the first terminal to the server by logging in to the target account in advance.
  • the token verification unit is configured to receive the first token sent by the second terminal, and after verifying the validity of the first token, return the first token verification result to the second terminal; where the first token is the first token When a terminal confirms that the verification code has passed the verification, it is sent to the second terminal.
  • the token verification unit is also used to receive the second token sent by the first terminal, and after verifying the validity of the second token, return the second token verification result to the first terminal, so that the first terminal is in the second If the token is verified, the target account is automatically logged in; the second token is sent by the first terminal when it is determined that the first token is verified, and the second token is used by the second terminal to log in to the target account in advance. Apply to the server.
  • the token generation unit is further configured to: receive a token acquisition request sent by the second terminal; in the case where the verification of the target account login request of the second terminal is passed, to the first The second terminal returns the second token.
  • an embodiment of the present application provides an electronic device, including: a memory and a processor, the memory is configured to store a computer program; the processor is configured to execute the first aspect and the second aspect when the computer program is invoked. Aspect, or the method of the third aspect.
  • an embodiment of the present application provides a login authentication system, which is characterized by comprising: a first terminal, a second terminal, and a server, where the first terminal is used to execute the method described in the first aspect, and The second terminal is used to execute the method described in the second aspect, and the server is used to execute the method described in the third aspect.
  • an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, and the computer program is executed by a processor to implement the method described in the first, second, or third aspect.
  • embodiments of the present application provide a computer program product, which when the computer program product runs on an electronic device, causes the electronic device to execute the method described in the first, second, or third aspect above.
  • Figure 1 is a schematic structural diagram of a login authentication system provided by an embodiment of the application.
  • Figure 2 is a schematic diagram of some trusted device setting interfaces provided by embodiments of the application.
  • FIG. 3 is a schematic diagram of other trusted device setting interfaces provided by an embodiment of the application.
  • FIG. 4 is a schematic flowchart of a login authentication method provided by an embodiment of the application.
  • FIG. 5 is a schematic flowchart of a method for verifying account consistency provided by an embodiment of the application
  • FIG. 7 is a schematic structural diagram of a login authentication device provided by an embodiment of this application.
  • FIG. 8 is a schematic structural diagram of another login authentication device provided by an embodiment of this application.
  • FIG. 9 is a schematic structural diagram of another login authentication device provided by an embodiment of this application.
  • FIG. 10 is a schematic structural diagram of a terminal device provided by an embodiment of this application.
  • the embodiments of the present application provide a login authentication method, device and system.
  • the first terminal Before automatically logging in to a target account, the first terminal is determined according to the near-field communication identifier of a nearby second terminal. Whether the second terminal belongs to a trusted device, and then in the case of determining that the second terminal is a trusted device, the server verifies the first token that the first terminal applies to the server in advance and the first token that the second terminal applies to the server in advance. The validity of the second token is automatically logged in to the target account when the first token and the second token are both verified.
  • the embodiment of the present application improves the security of the automatic login of the first terminal through the above technical solution.
  • FIG. 1 is a schematic structural diagram of a login authentication system provided by an embodiment of the application.
  • the login authentication system provided in this embodiment may include a server 100 and a terminal device, where the terminal device may include a first terminal 200 And the second terminal 300, the first terminal 200 and the second terminal 300 can register an account in the server 100, and log in to the server 100 through the login account to obtain the service provided by the server 100; in addition, the first terminal 200 can use the The second terminal 300 performs an authentication process of automatic login to improve the security of automatic login.
  • the terminal device may be a non-portable device such as a vehicle-mounted terminal, a smart TV, a smart speaker, and a desktop computer, or it may be a portable device such as a tablet computer and a notebook computer.
  • the first terminal 200 is an in-vehicle terminal and the second terminal 300 is a mobile phone as an example for illustration.
  • the number of the first terminal 200 and the number of the second terminal 300 is at least one, and the specific number is not particularly limited in this embodiment.
  • the first terminal 200 there is no strict distinction between the first terminal 200 and the second terminal 300.
  • the second terminal 300 In some scenarios, and it can also be used in other scenarios. It can be used as the first terminal 200.
  • the automatic login process of the vehicle-mounted terminal can be authenticated through a tablet computer; in another scenario, the automatic login process of the tablet computer can also be authenticated through a mobile phone.
  • the automatic login process of authenticating the first terminal 200 through the second terminal 300 may be an automatic login process of authenticating the second terminal 300 through the first terminal 200.
  • the automatic login process of the smart speaker can be authenticated through the mobile phone; in another scene, the automatic login process of the mobile phone can also be authenticated through the smart speaker.
  • the automatic login process of authenticating the first terminal 200 through the second terminal 300 is taken as an example for illustration.
  • the first terminal 200 when logging in to the target account for the first time, may submit the user name and password of the target account to the server 100 to request to log in to the target account; the first terminal 200 may also request a QR code from the server 100, and then The user is prompted to scan the QR code through another terminal device that has logged in to the target account (for example, the second terminal 300) to authorize the first terminal 200 to log in to the target account on the server 100; the first terminal 200 can also log in to the server 100 in other ways For example, collect face information, and submit the collected face information to the server 100 to request to log in to the target account. This embodiment does not specifically limit the manner in which the first terminal 200 logs in to the server 100.
  • the first terminal 200 may send a token acquisition request to the server 100 to request the server 100 to return a unique token for the first terminal 200 when the first terminal 200 logs in successfully.
  • the token acquisition request can be sent to the server 100 before the first terminal 200 successfully logs in, for example: the first terminal 200 can submit the login information (such as the aforementioned user name and password, or face information) at the same time
  • the token acquisition request is submitted to the server 100 together; or the token acquisition request is sent to the server 100 when the QR code is requested from the server 100; the token acquisition request can also be sent to the server 100 after the first terminal 200 logs in successfully.
  • the server 100 sends it.
  • the token acquisition request can be sent to the server 100 before the first terminal 200 successfully logs in for example.
  • the server 100 may verify the login information submitted by the first terminal 200 after receiving the login information. If the verification fails, it may request the first terminal 200 to log in to the target account.
  • a terminal 200 returns the verification result; if the verification is passed, a unique token can be generated and returned to the first terminal 200, and at the same time, the first terminal 200 successfully logs in to the target account.
  • the server 100 may generate a unique token after receiving the authorization information submitted by the second terminal 300 and return it to the first terminal 200. At the same time, the first terminal 200 successfully logs in to the target account. After receiving the token (referred to as the first token) returned by the server 100, the first terminal 200 may store the first token for subsequent automatic login.
  • the token referred to as the first token
  • the server 100 may return the first token previously generated for the first terminal 200 to the first terminal 200 when the first terminal 200 requests the first token again; or may regenerate a first token and return it to the first terminal 200, so as to reduce the risk of the first token being stolen, thereby improving the security of the login of the first terminal 200.
  • the second terminal 300 logs in to the target account for the first time or logs in to the target account again after the user actively logs out of the target account, that is, when the second terminal 300 does not store the second token, it is also A token can be requested from the server 100, and the server 100 returns a unique token (referred to as the second token) to the second terminal 300 when the second terminal 300 logs in successfully, and the second terminal 300 receives the token.
  • the second token is stored afterwards; and the stored second token can be cleared when the user actively logs out of the target account.
  • the process of the second terminal 300 requesting the token from the server 100 is similar to the process of the first terminal 200 requesting the token from the server 100, and will not be repeated here.
  • a trusted list can be established to determine whether the second terminal 300 is a trusted device based on the trusted list.
  • the first terminal 200 may also establish a black and white list, and determine whether the second terminal 300 is a trusted device based on the black and white list.
  • the method of establishing a trusted list is more convenient. The list is taken as an example to illustrate.
  • the short-range communication identifier of the terminal 300 is added to the trusted list, and then whether to add it can be determined according to the user's selection operation; in addition, the first terminal 200 can also provide a record of the second terminal 300 with which it has established a short-range communication connection, and the user The selected short-range communication identifier of the second terminal 300 can be actively added to the trusted list based on the record.
  • other methods may also be used to establish the trusted list, and the specific implementation manner is not particularly limited in this embodiment.
  • the user can also delete the short-range communication identifiers in the trusted list.
  • the near field communication connection can be a Bluetooth connection, a near field communication (Near Field Communication, NFC) connection, a wireless fidelity (Wireless-Fidelity, WiFi) connection or a ZigBee (ZigBee) connection, etc., in order to improve the convenience of users.
  • Bluetooth connection can be preferably used; the short-range communication identifier is a unique identifier related to the short-range communication connection of the terminal device (including the first terminal 200 and the second terminal 300). If the Bluetooth connection is adopted, the short-range communication The corresponding communication identifier may be a Bluetooth Media Access Control (MAC) address or other unique identifiers of the Bluetooth device.
  • MAC Bluetooth Media Access Control
  • the following example illustrates the process of the user logging in the target account on the first terminal 200 and the second terminal 300 and establishing a trusted list.
  • the second terminal 300 may provide the user with a login interface for inputting the user name and password when the user needs to log in to the target account. After the user enters the user name and password of the target account on the login interface, the second terminal 300 combines the user name and password entered by the user. The password is submitted to the server 100 to log in to the target account.
  • the first terminal 200 may request a QR code from the server 100 to display it, and prompt the user to scan the QR code to log in through other terminal devices that are in the logged-in state; the user can use the logged-in target
  • the second terminal 300 of the account scans the QR code.
  • the second terminal 300 can send authorization information for authorizing the first terminal 200 to log in to the target account to the server 100, and can return the authorization confirmation on the server 100 Provide the user with a login confirmation interface when the information is provided; after the user confirms the login on the login confirmation interface, the second terminal 300 can return the confirmation login information to the server 100, and the server 100 can send the confirmation to the first terminal after receiving the confirmation login information. 200 returns the login success information of the target account, so that the first terminal 200 successfully logs in to the target account.
  • the user can directly select the device ID in the paired device column 20 to add the second terminal 300 corresponding to the device ID as a trusted device, and the first terminal 200 can add the Bluetooth MAC address of the second terminal 300 to the trusted device.
  • the first terminal 200 may display the device identification of the trusted device in the trusted device column 10, and does not display the trusted list.
  • the user can connect with the device by selecting the device pairing control 30
  • the second terminal 300 to be added establishes a Bluetooth connection to add the device identification of the second terminal 300 to the paired device column 20.
  • the first terminal 200 can jump to the Bluetooth connection interface and scan for nearby Bluetooth devices. If the user turns on Bluetooth on the second terminal 300 that has successfully logged in to the target account, first One terminal 200 can scan the second terminal 300 and perform pairing.
  • the first terminal 200 can display the paired first terminal on the Bluetooth connection interface.
  • the device identification of the second terminal 300 is displayed synchronously in the paired device column 20.
  • the user can select the device identification to add the corresponding second terminal 300 as a trusted device.
  • the first terminal 200 corresponds to the available device.
  • the device identification is displayed in the trusted device column 10, and the Bluetooth MAC address of the second terminal 300 is added to the trusted list.
  • FIG. 3 is a schematic diagram of some other trusted device setting interfaces provided by an embodiment of this application.
  • the user can perform the device identification "AAA" of the trusted device to be deleted Select operation (for example: click operation); as shown in Figure 3 (b), the first terminal 200 responds to the selection operation and can display the prompt message "Delete the selected device?" and provide "Cancel” and " Confirm” option; after the user selects the "Confirm” option, as shown in (c) in Figure 3, the first terminal 200 deletes the device identification "AAA” from the trusted device column 10 in response to the user's selection operation, and The Bluetooth MAC address of the second terminal 300 corresponding to the device identifier "AAA" is deleted from the trusted list.
  • Select operation for example: click operation
  • the first terminal 200 responds to the selection operation and can display the prompt message "Delete the selected device?" and provide "Cancel” and " Confirm” option; after the user selects the "Confirm” option, as shown in (c) in Figure 3, the first terminal 200 deletes the device identification "AAA” from the trusted device column 10 in response to the user's selection operation, and The Bluetooth MAC address
  • the trusted list may be associated with an account, that is, different accounts in the first terminal 200 correspond to different trusted lists; the trusted list may not be associated with an account, that is, different accounts in the first terminal 200 Correspond to the same trusted list.
  • the first terminal 200 may also clear the trusted list corresponding to the target account to better protect the user's data privacy; in this case, if the user actively logs out of the target account, the first terminal 200 may also clear the trusted list corresponding to the target account to better protect the user's data privacy; The user logs in to the target account again, and the first terminal 200 may re-establish the trusted list corresponding to the target account.
  • the first terminal 200 may also upload the trusted list corresponding to the target account to the server 100 for storage when the user actively logs out of the target account or updates the trusted list; When logging in to the target account again, the first terminal 200 only needs to obtain the trusted list corresponding to the target account from the server 100.
  • FIG. 4 is a schematic flowchart of a login authentication method provided by an embodiment of the application. As shown in FIG. 4, the method may include the following steps:
  • the first terminal establishes a Bluetooth connection with the second terminal.
  • the first terminal can obtain the first token and the trusted list by logging in to the target account in advance, and the second terminal can obtain the second token by logging in to the target account in advance;
  • the user can bring the second terminal close to the first terminal, and the first terminal can be based on the trusted list, the first token, and the second token Perform the automatic login authentication process, and determine whether to automatically log in based on the authentication result.
  • the first terminal may automatically establish a Bluetooth connection with the second terminal based on the Bluetooth connection record. After the two have established a connection, they can exchange data through the established Bluetooth connection.
  • the first terminal may scan the Bluetooth broadcast message of the second terminal to obtain the Bluetooth MAC address of the second terminal, or obtain the MAC address of the second terminal based on a Bluetooth connection request established with the second terminal.
  • the first terminal After the first terminal obtains the Bluetooth MAC address of the second terminal, it can check whether the Bluetooth MAC address exists in the trusted list. If it exists, the second terminal can be considered as a trusted device, and the first terminal can continue to follow up If it does not exist, it means that the authentication is not passed, and the first terminal can continue to remain logged out.
  • the first terminal may also establish a Bluetooth connection with the second terminal when it is determined that the second terminal is a trusted device or in the process of verifying whether the second terminal is a trusted device. That is to say, there is no strict time sequence execution relationship between step S110 and step S120. Step S110 can be executed before step S120, can also be executed after step S120, and can also be executed simultaneously with step S120. This embodiment does not make any special difference. limited.
  • the first terminal obtains the account unique identifier of the account logged in by the second terminal, and determines whether the account unique identifier of the second terminal is consistent with the account unique identifier of the target account; if so, step S140 is performed, otherwise, step S160 is performed.
  • the first terminal can verify the first token and the second token through the server; in order to further improve the security of the automatic login of the first terminal, this implementation
  • the first terminal may first perform a consistency check on the account logged in by the second terminal and the target account to be logged in by the first terminal.
  • the first terminal may first establish the trust of the second terminal to the first terminal through a verification code verification method before performing account consistency verification. .
  • FIG. 5 is a schematic flowchart of the method for verifying account consistency according to an embodiment of the application. As shown in FIG. 5, the method may include the following steps:
  • the server receives the verification code request, and verifies the validity of the first token.
  • the token issued by the server includes a header, a payload, and a signature.
  • the encryption algorithm of the signature is declared in the header; some valid information is stored in the signature, such as the issuance time of the token. And/or expiration time; the signature is generated by encrypting the header and the payload with the encryption algorithm declared in the key (secret) and the header.
  • the server verifies the first token, it can first parse the encryption algorithm from the header of the first token, and then use the original key and the parsed encryption algorithm to encrypt the header and payload of the first token.
  • the generated signature is compared with the signature in the first token, and if they are consistent, the first token is legal.
  • the server can verify the validity period of the first token according to the validity information carried in the payload of the first token. If the expiration time of the token is carried in the payload, it can directly determine whether the first token is valid according to the expiration time. Expiration: If the payload only carries the issuance time of the token, but does not carry the expiration time, you can calculate whether the first token has expired according to the issuance time. If both the signature and the validity period of the first token pass, then it can be confirmed that the first token passes the verification.
  • the server returns a verification code to the first terminal when the first token is successfully verified.
  • the server may generate a one-time verification code with a shorter validity period and return it to the first terminal.
  • the second terminal sends the received check code to the server for verification.
  • the second terminal after receiving the check code sent by the first terminal, the second terminal can send it to the server to request the server to verify whether it is valid.
  • the server receives the check code and verifies the check code.
  • the server After the server receives the check code sent by the second terminal, it can be verified.
  • the specific verification method can use various current check code verification methods, which is not particularly limited in this embodiment. .
  • the second terminal returns the account unique identifier of the logged-in account to the first terminal if the verification code is verified.
  • the second terminal after receiving the verification result of the verification code returned by the server, the second terminal can obtain whether the verification code has passed the verification. If the verification code is verified, the account unique identifier of the logged-in account can be sent to the first terminal; if the verification code is not verified, the verification code verification failure message can be returned to the first terminal to inform the first terminal to verify The code verification fails; the second terminal may not return any message if the verification code verification fails, and the first terminal does not receive the message returned by the second terminal within the preset time period, which can be considered as the verification code verification failure; If the first terminal determines that the verification code verification fails, it can continue to be logged out, or it can request the verification code again for authentication or perform other operations.
  • the subsequent account consistency verification step may not be performed.
  • the second terminal may also return to the first terminal a verification that does not carry the account's unique identifier when the verification code is verified.
  • a code verification success message to inform the first terminal that the verification code verification is successful.
  • the unique identification of the account may be a user identification number (Identity, ID), or may be other unique identification of the account.
  • the first terminal judges whether the received unique identifier of the account is consistent with the unique identifier of the target account.
  • the first terminal can compare it with the account unique identifier of the target account to be logged in to determine whether the two are consistent, that is, determine whether the account logged in by the second terminal is the same as the first terminal. Whether the accounts to be logged in to the terminals are consistent; if they are consistent, the subsequent authentication process can be continued; if they are inconsistent, the authentication fails, and the first terminal can continue to maintain the logout state.
  • the first terminal may store the account unique identifier of the target account while applying for and storing the first token in advance, and read the stored account unique identifier of the target account during the comparison;
  • a terminal may also send the first token to the server to request the unique identification of the target account before performing the comparison, and then perform the comparison.
  • step S140 The first terminal verifies whether the first token and the second token are both valid through the server; if so, step S150 is executed, otherwise, step S160 is executed.
  • the first terminal can verify the validity of the first token and the second token through the server.
  • it can be implemented in at least the following three ways:
  • the first terminal may first send the first token to the second terminal to further establish the trust of the second terminal to the first terminal; after receiving the first token, the second terminal sends it Send to the server for validity verification, and if the verification is passed, send the second token to the first terminal; after receiving the second token, the first terminal sends it to the server for validity verification, if the verification passes , It can be considered that the automatic login authentication is passed, and the first terminal performs automatic login; if the verification fails, it means that the second terminal is not reliable enough, and the first terminal can continue to remain logged out.
  • the second type the first terminal obtains the second token from the second terminal, and sends the first token and the second token to the server for validity verification.
  • the first terminal may send a token acquisition request to the second terminal, requesting the second terminal to send the second token to the first terminal; after receiving the second token, the first terminal may send The first token and the second token are sent to the server for validity verification, and then based on the token verification result returned by the server, it is determined whether to automatically log in.
  • the third type the first terminal sends the first token to the second terminal, and the second terminal sends the first token and the second token to the server for validity verification.
  • the first terminal may send the first token to the second terminal, and the second terminal sends the first token and the second token together to the server for validity verification, and then after receiving After the verification result returned by the server, the verification result is forwarded to the first terminal.
  • the second terminal and the first terminal authenticate each other, which is more secure.
  • the following takes the token verification method as the first token verification method and the encryption method as the asymmetric encryption method as an example to illustrate the specific implementation process of the token verification.
  • FIG. 6 is a schematic flowchart of a token verification method provided by an embodiment of the application. As shown in FIG. 6, the method may include the following steps:
  • the first terminal sends the pre-generated first public key to the second terminal.
  • the first terminal may use an asymmetric encryption algorithm to generate a key pair in advance, and the key pair includes a first public key and a first private key.
  • the information encrypted by the first public key must be encrypted by the first private key.
  • the key pair can be generated by the first terminal during the authentication process of this automatic login (before sending the first private key), that is, a different key pair can be used for each automatic login; the key pair is also It may be generated by the first terminal before the automatic login of the target account for the first time or during the authentication process of the automatic login of the target account for the first time, that is, the same key pair may be used for each automatic login.
  • the second terminal can also use an asymmetric encryption algorithm to generate a key pair in advance.
  • the key pair includes a second public key and a second private key.
  • the information encrypted by the second public key must be encrypted with the second private key. To decrypt.
  • the manner in which the second terminal generates the key pair is similar to the manner in which the first terminal generates the key pair, and will not be repeated here.
  • the first terminal can exchange the public key with the second terminal, that is, agree on the key, so that when interacting with the second terminal, the agreed key is used to encrypt and interact with the data. Decrypted.
  • the first terminal may first send the first public key to the second terminal, and request the second public key from the second terminal.
  • the second terminal After receiving the first public key, the second terminal sends the pre-generated second public key to the first terminal.
  • the first terminal receives the second public key, and uses the second public key to encrypt the first token.
  • the first terminal may use the second public key to encrypt the first token, and then send the encrypted first token to the second terminal for further The trust of the second terminal to the first terminal is established, so that the second terminal feeds back the second token to the first terminal when it is determined that the first terminal is credible.
  • the first terminal sends the encrypted first token to the second terminal.
  • the second terminal receives the encrypted first token, and uses the pre-generated second private key to decrypt the encrypted first token to obtain the first token.
  • the second terminal may decrypt the encrypted data by using the second private key corresponding to the second public key to obtain the first command Card.
  • the second terminal sends the first token to the server for verification.
  • the second terminal after decrypting and obtaining the first token, can send it to the server, requesting the server to verify whether the first token is valid, so as to confirm whether the first terminal is authentic.
  • the server receives the first token, and verifies the validity of the first token.
  • the server can respond to the request of the second terminal to verify the first token.
  • the specific verification process is similar to step S1302 and will not be repeated here.
  • the server returns the first token verification result to the second terminal.
  • the second terminal may determine whether the first token is verified. If the first token is verified, the second token can be encrypted with the first public key and sent to the first terminal to further establish the trust of the first terminal to the second terminal; if the first token is not verified , It may be similar to step S1308, returning a first token verification failure message to the first terminal or not returning any message to inform the first terminal that the first token verification failed.
  • the first terminal determines that the first token verification fails, , You can continue to log out, or you can prompt the user to log in to the target account again to apply for a new first token or perform other operations.
  • the second terminal sends the encrypted second token to the first terminal.
  • the first terminal receives the encrypted second token, and uses the pre-generated first private key to decrypt the encrypted second token to obtain the second token.
  • the first terminal after receiving the encrypted data (that is, the encrypted second token) sent by the second terminal, the first terminal can decrypt the encrypted data by using the first private key corresponding to the first public key to obtain the second command Card.
  • the first terminal sends the second token to the server for verification.
  • the display unit 240 may be used to display information input by the user or information provided to the user and various menus of the terminal device.
  • the terminal device can display the account login interface for the user to log in to the account through the display unit 240.
  • the terminal device can also display the trusted list for the user to set the trust list through the display unit 240. Setting interface and so on.
  • the terminal device provided in this embodiment can execute the foregoing method embodiments, and its implementation principles and technical effects are similar, and will not be repeated here.
  • the processor 320 is the control center of the server. It uses various interfaces and lines to connect the various parts of the entire server. It executes by running or executing software programs and/or modules stored in the memory 310 and calling data stored in the memory 310. Various functions and processing data of the server, so as to monitor the server as a whole.
  • the processor 320 may include one or more processing units.
  • the aforementioned integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer readable storage medium.
  • the computer program can be stored in a computer-readable storage medium. When executed by the processor, the steps of the foregoing method embodiments can be implemented.
  • the computer program includes computer program code, and the computer program code may be in the form of source code, object code, executable file, or some intermediate forms.
  • the computer-readable storage medium may at least include: any entity or device capable of carrying the computer program code to the photographing device/terminal device, recording medium, computer memory, read-only memory (ROM), random access Memory (Random Access Memory, RAM), electrical carrier signal, telecommunications signal, and software distribution medium.
  • ROM read-only memory
  • RAM random access Memory
  • electrical carrier signal telecommunications signal
  • software distribution medium for example, U disk, mobile hard disk, floppy disk or CD-ROM, etc.
  • computer-readable media cannot be electrical carrier signals and telecommunication signals.
  • the memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and/or non-volatile memory, such as read-only memory (ROM) or flash memory (flash RAM).
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash memory
  • the disclosed apparatus/equipment and method may be implemented in other ways.
  • the device/equipment embodiments described above are only illustrative.
  • the division of the modules or units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or Components can be combined or integrated into another system, or some features can be omitted or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or units, and may be in electrical, mechanical or other forms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computing Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本申请提供一种登录认证方法、装置与系统，涉及通信技术领域，其中，该方法包括：第一终端获取第二终端的近距离通信标识；若根据近距离通信标识确定第二终端属于可信任设备，则获取第二终端的第二令牌，并通过服务端验证第一令牌和第二令牌的有效性；在第二令牌均验证通过的情况下，自动登录目标账号，其中，第二令牌是第二终端通过预先登录目标账号向服务端申请的。本申请提供的技术方案可以提高终端设备自动登录的安全性。

Description

登录认证方法、装置与系统
本申请要求于2020年01月19日提交国家知识产权局、申请号为202010060167.2、申请名称为“登录认证方法、装置与系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及通信技术领域，尤其涉及一种登录认证方法、装置与系统。
背景技术
随着互联网技术的发展，越来越多的应用从电脑端扩展到了第二终端。为了方便用户使用，这些应用一般都允许用户同时在电脑端和第二终端登录同一账号，使用户可以在不同终端上同时享用相同的应用服务。
随着接入互联网的终端类型的增加，使得用户可以在更多类型的终端设备上登录应用。例如：有些应用开始支持用户在车载终端上登录账号以享用相关的应用服务，其中，在具体使用时，比较传统的登录方式是用户通过输入用户名和密码等账号信息登录应用；考虑到这种登录方式不够方便，目前，许多应用都提供了自动登录方式，例如：用户在车载终端上开启某应用的自动登录功能后，车载终端在启动车辆后基于首次登录时存储的账号信息自动登录该应用。
然而，上述自动登录方式，在车辆借出等情况下，存在车主个人信息被泄漏的风险，因而安全性较低。
发明内容
有鉴于此，本申请提供一种登录认证方法、装置与系统，用于提高终端设备自动登录的安全性。
为了实现上述目的，第一方面，本申请实施例提供一种登录认证方法，应用于第一终端，该方法可以包括：
获取第二终端的近距离通信标识；若根据近距离通信标识确定第二终端属于可信任设备，则获取所述第二终端的第二令牌，并通过服务端验证第二令牌的有效性；在第二令牌验证通过的情况下，自动登录目标账号。其中，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
本申请实施例提供的登录认证方法，第一终端在自动登录目标账号前，先根据附近第二终端的近距离通信标识确定该第二终端是否属于可信任设备，然后在确定第二终端属于可信任设备的情况下，通过服务端验证第二终端预先向服务端申请的第二令牌的有效性，在第二令牌验证通过时再自动登录目标账号，这样可以有效的提高第一终端自动登录的安全性。
在第一方面的一种可能的实施方式中，根据近距离通信标识确定第二终端属于可信任设备，包括：若预先建立的可信任列表中包括近距离通信标识，则确定第二终端属于可信任设备。
上述实施方式中，通过可信任列表确定第二终端是否是可信任设备，其可信任列表建立方式和可信任设备验证方式都较为简单方便。
在第一方面的一种可能的实施方式中，在获取第二终端的近距离通信标识之前，该方法还包括：在目标账号登录成功的情况下，基于用户的配置操作将第二终端的近距离通信标识加入可信任列表，其中，第二终端与第一终端建立有近距离通信连接。
上述实施方式中，根据用户的配置操作建立可信任列表，可以提高建立的可信任列表的可信度。
在第一方面的一种可能的实施方式中，获取第二终端的近距离通信标识，包括：在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识；其中，第一令牌是第一终端通过预先登录目标账号向服务端申请的。
则自动登录所述目标账号，包括：在第一令牌验证通过的情况下自动登录所述目标账号。
上述实施方式中，通过第一令牌自动登录目标账号，这样第一终端中就无需存储用户的账号密码等账号信息，从而就可以提高用户的数据安全性。
在第一方面的一种可能的实施方式中，在在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识之前，该方法还包括：若第一终端中未存储有第一令牌，则在登录目标账号的过程中，向服务端发送令牌获取请求，其中，令牌获取请求用于请求服务端在对第一终端的目标账号登录请求验证通过的情况下返回第一令牌；接收并存储服务端返回的第一令牌。
在第一方面的一种可能的实施方式中，该方法还包括：若检测到用户在第一终端上输入退出目标账号的操作，则执行登出操作，并清除第一令牌。这样可以更好的保护用户的数据隐私。
在第一方面的一种可能的实施方式中，在获取第二终端的第二令牌之前，该方法还包括：与第二终端建立近距离通信连接。这样可以方便第一终端与第二终端传输数据。
在第一方面的一种可能的实施方式中，在通过服务端验证第一令牌和第二令牌的有效性之前，与第二终端建立近距离通信连接之后，该方法还包括：
若根据近距离通信标识确定第二终端属于可信任设备，则向服务端发送校验码请求，其中，校验码请求中携带第一令牌，校验码请求用于指示服务端在对第一令牌验证通过的情况下返回校验码；在接收到服务端返回的校验码后，将校验码发送给第二终端，以指示第二终端将校验码发送到服务端进行验证；确定校验码验证通过。
上述实施方式中，在进行令牌验证前，先进行校验码验证，这样可以建立第二终端对第一终端的信任度，提高第二终端的数据安全性。
在第一方面的一种可能的实施方式中，确定校验码验证通过包括：若接收到第二终端返回的账号唯一标识，则确定校验码验证通过，其中，第二终端返回的账号唯一标识是第二终端在校验码验证通过的情况下发送的已登录账号的唯一标识。
则在获取第二终端的第二令牌之前，该方法还包括：确定接收到的账号唯一标识与目标账号的账号唯一标识一致。
上述实施方式中，在进行令牌验证前，进行账号一致性验证，这样可以进一步建立第一终端对第二终端的信任度，从而进一步提高第一终端自动登录的安全性。
在第一方面的一种可能的实施方式中，通过服务端验证第一令牌和第二令牌的有效性，包括：将第一令牌发送给第二终端，以指示第二终端将第一令牌发送到服务端进行有效性验证，并在第一令牌验证通过后返回第二令牌；若接收到第二终端发送的第二令牌，则将第二令牌发送到服务端进行有效性验证。
上述实施方式中，第二终端和第一终端互相进行令牌认证，可以提高第二终端和第一终端的数据安全性。
在第一方面的一种可能的实施方式中，第一终端发送给第二终端的第一令牌和从第二终端接收的第二令牌都是经过加密处理的，第二终端发送给服务端的第一令牌和第一终端发送给服务端的第二令牌都是经过解密处理得到的，加密处理和解密处理均是基于预先约定的密钥进行的。这样可以提高第一终端与第二终端之间数据交互的安全性。
在第一方面的一种可能的实施方式中，密钥为非对称密钥。这样可以进一步提高第一终端与第二终端之间数据交互的安全性。
在第一方面的一种可能的实施方式中，该方法还包括：按照预设时间间隔周期性将第二令牌发送至服务端进行验证；若验证不通过，则重新从第二终端获取第二令牌，并发送至服务端进行验证；若重新获取的第二令牌验证不通过，则执行登出操作。这样可以进一步提高第一终端自动登录的安全性。
第二方面，本申请实施例提供一种登录认证方法，应用于第二终端，包括：响应于第一终端获取近距离通信标识的请求，向第一终端发送近距离通信标识；在已成功登录目标账号的情况下，接收第一终端发送的第一令牌，并将第一令牌发送到服务端进行有效性验证，其中，第一令牌是第一终端在根据近距离通信标识确定第二终端属于可信任设备的情况下发送的；接收服务端返回的第一令牌验证结果，并在第一令牌验证通过的情况下向第一终端返回第二令牌，以指示第一终端将第二令牌发送到服务端进行有效性验证，并在第二令牌验证通过的情况下，自动登录目标账号；其中，第一令牌是第一终端通过预先登录目标账号向服务端申请的，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
在第二方面的一种可能的实施方式中，在在已成功登录所述目标账号的情况下，接收第一终端发送的第一令牌之前，该方法还包括：若第二终端中未存储有第二令牌，则在登录目标账号的过程中，向服务端发送令牌获取请求，其中，令牌获取请求用于请求服务端在对第二终端的目标账号登录请求验证通过的情况下返回第二令牌；接收并存储服务端返回的第二令牌。
在第二方面的一种可能的实施方式中，该方法还包括：若检测到用户在第一终端上输入退出目标账号的操作，则执行登出操作，并清除第二令牌。
在第二方面的一种可能的实施方式中，在接收第一终端发送的第一令牌之前，之前，该方法还包括：与第一终端建立近距离通信连接。
在第二方面的一种可能的实施方式中，在接收第一终端发送的第一令牌之前，之前，与第一终端建立近距离通信连接之后，该方法还包括：
接收第一终端发送的校验码，其中，校验码是第一终端在根据近距离通信标识确定第二终端属于可信任设备的情况下，从服务端请求的；将校验码发送到服务端进行验证；接收服务端返回的校验码验证结果；确定校验码验证通过。
在第二方面的一种可能的实施方式中，该方法还包括：向第一终端发送已登录账号的唯一标识，以使第一终端确定接收到的账号唯一标识与目标账号的账号唯一标识一致。
第三方面，本申请实施例提供一种登录认证方法，应用于服务端，包括：
接收第一终端发送的校验码请求，并在对第一令牌验证通过的情况下向第一终端返回校验码，其中，校验码请求中携带第一令牌，校验码请求是第一终端在确定第二终端属于可信任设备的情况下发送的，第一令牌是第一终端通过预先登录目标账号向服务端申请的。
接收第二终端发送的携带有校验码的校验码验证请求，并在校验码验证通过的情况下，向第二终端返回校验码验证结果，其中，校验码验证请求是第二终端接收到第一终端发送的校验码后发送的。
接收第二终端发送的第一令牌，并对第一令牌进行有效性验证，并向第二终端返回第一令牌验证结果，其中，第一令牌是第一终端在确定校验码验证通过的情况下向第二终端发送的。
接收第一终端发送的第二令牌，并在对第二令牌进行有效性验证后，向第一终端返回第二令牌验证结果，以使第一终端在第二令牌验证通过的情况下，自动登录目标账号，其中，第二令牌是第一终端在确定第一令牌验证通过的情况下发送的，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
在第三方面的一种可能的实施方式中，该方法还包括：接收第一终端发送的令牌获取请求；在对第一终端的目标账号登录请求验证通过的情况下，向第一终端返回第一令牌。
在第三方面的一种可能的实施方式中，该方法还包括：接收第二终端发送的令牌获取请求；在对第二终端的目标账号登录请求验证通过的情况下，向第二终端返回第二令牌。
在第三方面的一种可能的实施方式中，在接收第二终端发送的第一令牌之前，该方法还包括：接收第一终端发送的校验码请求，校验码请求中携带第一令牌；在对第一令牌验证通过的情况下向第一终端返回校验码；接收第二终端发送的携带有校验码的校验码验证请求；在校验码验证通过的情况下，向第二终端返回校验码验证结果。
第四方面，本申请实施例提供一种登录认证装置，应用于第一终端，包括：
近距离通信单元，用于在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识，并根据近距离通信标识确定第二终端是否属于可信任设备，其中，第一令牌是第一终端通过预先登录目标账号向服务端申请的。
令牌交换单元，用于在近距离通信单元根据近距离通信标识确定第二终端属于可信任设备的情况下，获取第二终端的第二令牌；
令牌验证单元，用于通过服务端验证第二令牌的有效性；其中，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
登录请求单元，用于在第二令牌验证通过的情况下，自动登录目标账号。
在第四方面的一种可能的实施方式中，近距离通信单元具体用于：若预先建立的可信任列表中包括近距离通信标识，则确定第二终端属于可信任设备。
在第四方面的一种可能的实施方式中，该装置还包括：可信任列表建立单元，用于在蓝牙匹配单元获取第二终端的近距离通信标识之前，在目标账号登录成功的情况下，基于用户的配置操作将第二终端的近距离通信标识加入可信任列表，其中，第二终端与第一终端建立有近距离通信连接。
在第四方面的一种可能的实施方式中，近距离通信单元具体用于：在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识；其中，第一令牌是第一终端通过预先登录目标账号向服务端申请的。
则登录请求单元具体用于：在第一令牌验证通过的情况下自动登录目标账号。
在第四方面的一种可能的实施方式中，登录请求单元还用于：在近距离通信单元在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识之前，若第一终端中未存储有第一令牌，则在登录目标账号的过程中，向服务端发送令牌获取请求，其中，令牌获取请求用于请求服务端在对第一终端的目标账号登录请求验证通过的情况下返回第一令牌；接收并存储服务端返回的第一令牌。
在第四方面的一种可能的实施方式中，登录请求单元还用于：若检测到用户在第一终端上输入退出目标账号的操作，则执行登出操作，并清除第一令牌。
在第四方面的一种可能的实施方式中，近距离通信单元还用于：在令牌交换单元获取第二终端的第二令牌之前，与第二终端建立近距离通信连接。这样可以方便第一终端与第二终端传输数据。
在第四方面的一种可能的实施方式中，该装置还包括：
校验单元，用于在令牌验证单元通过服务端验证第一令牌和第二令牌的有效性之前，近距离通信单元与第二终端建立近距离通信连接之后，在近距离通信单元根据近距离通信标识确定第二终端属于可信任设备的情况下，向服务端发送校验码请求，其中，校验码请求中携带第一令牌，校验码请求用于指示服务端在对第一令牌验证通过的情况下返回校验码；在接收到服务端返回的校验码后，将校验码发送给第二终端，以指示第二终端将校验码发送到服务端进行验证；确定校验码验证通过。
在第四方面的一种可能的实施方式中，校验单元具体用于：若接收到第二终端返回的账号唯一标识，则确定校验码验证通过，其中，第二终端返回的账号唯一标识是第二终端在校验码验证通过的情况下发送的已登录账号的唯一标识。
校验单元还用于：在令牌交换单元获取第二终端的第二令牌之前，确定接收到的账号唯一标识与目标账号的账号唯一标识一致。
在第四方面的一种可能的实施方式中，令牌交换单元具体用于：将第一令牌发送给第二终端，以指示第二终端将第一令牌发送到服务端进行有效性验证，并在第一令牌验证通过后返回第二令牌；若接收到第二终端发送的第二令牌，则指示令牌验证单元将第二令牌发送到服务端进行有效性验证。
在第四方面的一种可能的实施方式中，第一终端发送给第二终端的第一令牌和从第二终端接收的第二令牌都是经过加密处理的，第二终端发送给服务端的第一令牌和第一终端发送给服务端的第二令牌都是经过解密处理得到的，加密处理和解密处理均是基于预先约定的密钥进行的。
在第四方面的一种可能的实施方式中，密钥为非对称密钥。
在第四方面的一种可能的实施方式中，令牌验证单元还用于：按照预设时间间隔周期性将第二令牌发送至服务端进行验证；若验证不通过，则重新从第二终端获取第二令牌，并发送至服务端进行验证；若重新获取的第二令牌验证不通过，则指示登录请求单元执行登出操作。
第五方面，本申请实施例提供一种登录认证装置，应用于第二终端，包括：
近距离通信单元，用于响应于第一终端获取近距离通信标识的请求，向第一终端发送近距离通信标识。
令牌交换单元，用于在已成功登录目标账号的情况下，接收第一终端发送的第一令牌。
令牌验证单元，用于将第一令牌发送到服务端进行有效性验证，其中，第一令牌是第一终端在根据近距离通信标识确定第二终端属于可信任设备的情况下发送的；接收服务端返回的第一令牌验证结果。
令牌交换单元还用于：在第一令牌验证通过的情况下向第一终端返回第二令牌，以指示第一终端将第二令牌发送到服务端进行有效性验证，并在第二令牌验证通过的情况下，自动登录目标账号，其中，第一令牌是第一终端通过预先登录目标账号向服务端申请的，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
在第五方面的一种可能的实施方式中，该装置还包括：登录请求单元，用于在令牌交换单元在已成功登录目标账号的情况下，接收第一终端发送的第一令牌之前，若第二终端中未存储有第二令牌，则在登录目标账号的过程中，向服务端发送令牌获取请求，其中，令牌获取请求用于请求服务端在对第二终端的目标账号登录请求验证通过的情况下返回第二令牌；接收并存储服务端返回的第二令牌。
在第五方面的一种可能的实施方式中，登录请求单元还用于若检测到用户在第一终端上输入退出目标账号的操作，则执行登出操作，并清除第二令牌。
在第五方面的一种可能的实施方式中，近距离通信单元具体用于：在令牌交换单元接收第一终端发送的第一令牌之前，与第一终端建立近距离通信连接。
在第五方面的一种可能的实施方式中，该装置还包括：校验单元，用于在令牌交换单元接收第一终端发送的第一令牌之前，近距离通信单元与第一终端建立近距离通信连接之后，接收第一终端发送的校验码，其中，校验码是第一终端在根据近距离通信标识确定第二终端属于可信任设备的情况下，从服务端请求的；将校验码发送到服务端进行验证；接收服务端返回的校验码验证结果；确定校验码验证通过。
在第五方面的一种可能的实施方式中，校验单元还用于：向第一终端发送已登录账号的唯一标识，以使第一终端确定接收到的账号唯一标识与目标账号的账号唯一标识一致。
在第五方面的一种可能的实施方式中，令牌验证单元具体用于：接收第一终端发 送的第一令牌；将第一令牌发送到服务端进行有效性验证；接收服务端返回的第一令牌验证结果；在第一令牌验证通过的情况下向第一终端返回第二令牌，以指示第一终端将第二令牌发送到服务端进行有效性验证。
第六方面，本申请实施例提供一种登录认证装置，应用于服务端，包括：
校验码生成单元，用于接收第一终端发送的校验码请求，并在对第一令牌验证通过的情况下向第一终端返回校验码，其中，校验码请求中携带第一令牌，校验码请求是第一终端在确定第二终端属于可信任设备的情况下发送的，第一令牌是第一终端通过预先登录目标账号向服务端申请的。
校验码验证单元，用于接收第二终端发送的携带有校验码的校验码验证请求，并在校验码验证通过的情况下，向第二终端返回校验码验证结果，其中，校验码验证请求是第二终端接收到第一终端发送的校验码后发送的。
令牌验证单元，用于接收第二终端发送的第一令牌，并对第一令牌进行有效性验证后，向第二终端返回第一令牌验证结果；其中，第一令牌是第一终端在确定校验码验证通过的情况下向第二终端发送的。
令牌验证单元还用于接收第一终端发送的第二令牌，并对第二令牌进行有效性验证后，向第一终端返回第二令牌验证结果，以使第一终端在第二令牌验证通过的情况下，自动登录目标账号；其中，第二令牌是第一终端在确定第一令牌验证通过的情况下发送的，第二令牌是第二终端通过预先登录目标账号向服务端申请的。
在第六方面的一种可能的实施方式中，该装置还包括：令牌生成单元，用于接收第一终端发送的令牌获取请求；在对第一终端的目标账号登录请求验证通过的情况下，向第一终端返回第一令牌。
在第六方面的一种可能的实施方式中，令牌生成单元还用于：接收第二终端发送的令牌获取请求；在对第二终端的目标账号登录请求验证通过的情况下，向第二终端返回第二令牌。
第七方面，本申请实施例提供一种电子设备，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行上述第一方面、第二方面、或第三方面所述的方法。
第八方面，本申请实施例提供一种登录认证系统，其特征在于，包括：第一终端、第二终端和服务端，其中，第一终端用于执行上述第一方面所述的方法，所述第二终端用于执行上述第二方面所述的方法，所述服务端用于执行上述第三方面所述的方法。
第九方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述第一方面、第二方面或第三方面所述的方法。
第十方面，本申请实施例提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述第一方面、第二方面或第三方面所述的方法。
可以理解的是，上述第二方面至第十方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例或现有技术描述 中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的登录认证系统的结构示意图；
图2为本申请实施例提供的一些可信任设备设置界面的示意图；
图3为本申请实施例提供的另一些可信任设备设置界面的示意图；
图4为本申请实施例提供的登录认证方法的流程示意图；
图5为本申请实施例提供的账号一致性校验方法的流程示意图；
图6为本申请实施例提供的令牌验证方法的流程示意图；
图7为本申请实施例提供的一种登录认证装置的结构示意图；
图8为本申请实施例提供的另一种登录认证装置的结构示意图；
图9为本申请实施例提供的又一种登录认证装置的结构示意图；
图10为本申请实施例提供的终端设备的结构示意图；
图11为本申请实施例提供的服务端的结构示意图。
具体实施方式
针对目前的终端自动登录方式安全性低的技术问题，本申请实施例提供一种登录认证方法、装置与系统，在自动登录目标账号前，先根据附近第二终端的近距离通信标识确定该第二终端是否属于可信任设备，然后在确定第二终端属于可信任设备的情况下，通过服务端验证第一终端预先向服务端申请的第一令牌和第二终端预先向服务端申请的第二令牌的有效性，在第一令牌和第二令牌均验证通过时再自动登录目标账号。本申请实施例通过上述技术方案来提高第一终端自动登录的安全性。
下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。
图1为本申请实施例提供的登录认证系统的结构示意图，如图1所示，本实施例提供的登录认证系统可以包括：服务端100和终端设备，其中，终端设备可以包括第一终端200和第二终端300，第一终端200和第二终端300可以在服务端100中注册账号，通过登录账号登录服务端100，以获取服务端100提供的服务；另外，第一终端200可以通过第二终端300进行自动登录的认证过程，来提高自动登录的安全性。
本实施例中，终端设备可以是诸如车载终端、智能电视、智能音箱和台式电脑等的非便携设备，也可以是诸如平板电脑和笔记本电脑等的便携设备。图中是以第一终端200为车载终端，第二终端300为手机为例进行示例性说明。其中，第一终端200和第二终端300的数量均为至少一个，其具体数量本实施例不做特别限定。
需要说明的是，本实施例中，第一终端200和第二终端300之间没有严格的区分关系，对于同一终端设备，在一些场景中可以作为第二终端300使用，在另一些场景中也可以作为第一终端200使用。例如：在某场景中，可以通过平板电脑来认证车载终端的自动登录过程；在另一场景中，也可以通过手机来认证平板电脑的自动登录过程。
另外，在进行认证时，可以是通过第二终端300认证第一终端200的自动登录过 程，也可以是通过第一终端200认证第二终端300的自动登录过程。例如：在某场景中，可以通过手机来认证智能音箱的自动登录过程；在另一场景中，也可以通过智能音箱来认证手机的自动登录过程。本申请实施例中是以通过第二终端300认证第一终端200的自动登录过程为例进行示例性说明。
本实施例中，在首次登录目标账号时，第一终端200可以向服务端100提交目标账号的用户名和密码，请求登录目标账号；第一终端200也可以向服务端100请求二维码，然后提示用户通过已登录目标账号的其他终端设备(例如第二终端300)扫描二维码，以授权第一终端200在服务端100登录目标账号；第一终端200还可以通过其他方式登录服务端100，例如：采集人脸信息，将采集的人脸信息提交给服务端100，以请求登录目标账号，本实施例对第一终端200登录服务端100的方式不做特别限定。
第一终端200在登录服务端100的过程中，可以向服务端100发送令牌获取请求，以请求服务端100在第一终端200登录成功的情况下为第一终端200返回一个唯一性令牌；其中，令牌获取请求可以在第一终端200登录成功前发送给服务端100，例如：第一终端200可以在提交登录信息(如上述的用户名和密码，或者人脸信息)的同时，将令牌获取请求一起提交给服务端100；或者在向服务端100请求二维码的同时将令牌获取请求一起发送给服务端100；令牌获取请求也可以在第一终端200登录成功后向服务端100发送，本实施例中以令牌获取请求可以在第一终端200登录成功前发送给服务端100为例进行示例性说明。对于第一终端200通过向服务端100提交登录信息来请求登录目标账号的情况，服务端100可以在接收到第一终端200提交的登录信息后对其进行验证，若验证不通过，可以向第一终端200返回验证结果；若验证通过，可以生成一个唯一性令牌，返回给第一终端200，同时，第一终端200成功登录目标账号。对于第一终端200通过第二终端300扫描二维码来登录目标账号的情况，服务端100可以在接收到第二终端300提交的授权信息后，生成一个唯一性令牌，返回给第一终端200，同时，第一终端200成功登录目标账号。第一终端200接收到服务端100返回的令牌(称为第一令牌)后，可以存储第一令牌，以用于后期的自动登录。
为了满足用户需求，提高用户体验度，本实施例中，若用户主动退出目标账号，第一终端200则可以在执行登出操作之外，清除存储的第一令牌。这样用户可以登录其他账号或通过该方式停止目标账号的自动登录。其中，用户在主动退出目标账号时，可以通过在第一终端200上输入相关的退出操作实现，例如：可以通过点击退出账号的选项，或输入语音指令等；第一终端200在清除第一令牌之外，还可以清除目标账号的其他账号信息，例如用户名和密码等，以更好的保护用户的数据隐私。
基于此，用户若再次登录目标账号，第一终端200中此时未存储有目标账号对应的第一令牌，第一终端200则可以与首次登录目标账号类似，在登录时向服务端100重新请求第一令牌，将重新请求的第一令牌进行存储，其中，该重新请求的第一令牌与第一终端200上次存储的第一令牌可以相同，也可以不同，即服务端100可以在第一终端200重新请求第一令牌时，将之前为该第一终端200生成的第一令牌返回给第一终端200；也可以重新生成一个第一令牌返回给第一终端200，以减少第一令牌被盗取所产生的风险，从而提高第一终端200登录的安全性。
与第一终端200类似，第二终端300在首次登录目标账号或用户主动退出目标账 号后再次登录目标账号的情况下，也就是第二终端300在未存储有第二令牌的情况下，也可以向服务端100请求令牌，服务端100则在第二终端300登录成功的情况下给第二终端300返回一个唯一性令牌(称为第二令牌)，第二终端300接收到该第二令牌后进行存储；并在用户主动退出目标账号的情况下可以清除存储的第二令牌。其中，第二终端300向服务端100请求令牌的过程与第一终端200向服务端100请求令牌的过程类似，此处不再赘述。
本实施例中，第一终端200在目标账号首次登录成功后，可以建立可信任列表，以基于该可信任列表来判断第二终端300是否是可信任设备。当然，第一终端200也可以是建立一个黑白名单，基于黑白名单来判断第二终端300是否是可信任设备，其中，建立可信任列表的方式较为方便，本申请实施例中后续也以可信任列表为例进行示例性说明。
在具体实现时，在目标账号首次在第一终端200上登录成功后，用户可以将第二终端300与第一终端200建立近距离通信连接，将第二终端300的近距离通信标识添加到第一终端200的可信任列表中。当然，第一终端200也可以是在目标账号登录成功前与第二终端300建立的近距离通信连接，则在目标账号首次登录成功后，第一终端200可以提示用户是否将已连接的第二终端300的近距离通信标识添加到可信任列表中，然后可以根据用户的选择操作来确定是否添加；另外，第一终端200还可以提供与其建立过近距离通信连接的第二终端300记录，用户可以基于该记录将选择的第二终端300的近距离通信标识主动添加到可信任列表中。当然，本实施例中还可以采用其他方式建立可信任列表，具体的实现方式本实施例不做特别限定。另外，本实施例中，第一终端200在建立了可信任列表后，用户也可以对可信任列表中的近距离通信标识进行删除操作。
其中，近距离通信连接可以是蓝牙连接、近场通信(Near Field Communication，NFC)连接、无线保真(Wireless-Fidelity，WiFi)连接或紫蜂(ZigBee)连接等，为了提高用户使用的便利性，本实施例中可优选采用蓝牙连接；近距离通信标识为终端设备(包括第一终端200和第二终端300)的与近距离通信连接相关的唯一性标识，若采用蓝牙连接，则近距离通信标识对应可以为蓝牙媒体访问控制(Media Access Control，MAC)地址或蓝牙设备的其他唯一性标识。为了便于理解，本申请实施例中后续皆以近距离通信连接为蓝牙连接、近距离通信标识为蓝牙MAC地址为例进行示例性说明
下面举例说明用户在第一终端200和第二终端300上登录目标账号，并建立可信任列表的过程。
第二终端300可以在用户需要登录目标账号时，向用户提供用于输入用户名和密码的登录界面，用户在登录界面上输入目标账号的用户名和密码后，第二终端300将用户输入的用户名和密码提交给服务端100，以登录目标账号。第一终端200可以在用户需要登录目标账号时，向服务端100请求二维码后进行显示，并提示用户通过其他处于登录状态的终端设备扫描二维码进行登录；用户则可以通过已登录目标账号的第二终端300扫描该二维码，第二终端300扫描二维码后可以向服务端100发送用于授权第一终端200登录目标账号的授权信息，并可以在服务端100返回授权确认信息 时向用户提供确认登录界面；用户在确认登录界面上确认登录后，第二终端300则可以将确认登录信息返回给服务端100，服务端100接收到该确认登录信息后可以向第一终端200返回目标账号登录成功信息，使第一终端200成功登录目标账号。
第二终端300和第一终端200均成功登录目标账号后，第一终端200可以提供用于设置可信任设备的选项，用户选择该选项后，第一终端200可以提供可信任设备设置界面。图2为本申请实施例提供的一些可信任设备设置界面的示意图，如图2中的(a)所示，可信任设备设置界面中可以包括：可信任设备栏10、已配对设备栏20和用于建立蓝牙连接的设备配对控件30。其中，可信任设备栏10用于显示已添加的可信任设备，若未添加任何可信任设备，则可以显示用于表示未添加可信任设备的提示信息，如图2中的(a)所示的提示信息：“尚未添加任何设备”。已配对设备栏20用于显示与第一终端200已建立过蓝牙连接的第二终端300记录，为了便于用户识别，其具体可以显示第二终端300的设备标识，如图2中的(a)所示的“AAA”、“BBB”和“CCC”。
用户可以直接选择已配对设备栏20中的设备标识来将该设备标识对应的第二终端300添加为可信任设备，第一终端200则可以将该第二终端300的蓝牙MAC地址添加到可信任列表中，其中，为了方便用户识别，第一终端200可以在可信任设备栏10中显示出可信任设备的设备标识，对可信任列表不进行显示。
若已配对设备栏20中没有用户想要添加为可信任设备的第二终端300(例如上述已成功登录目标账号的第二终端300)的设备标识，用户则可以通过选择设备配对控件30来与待添加的第二终端300建立蓝牙连接，以将该第二终端300的设备标识添加到已配对设备栏20中。在具体实现时，用户选择设备配对控件30后，第一终端200可以跳转到蓝牙连接界面，扫描附近的蓝牙设备，若用户在已成功登录目标账号的第二终端300上开启了蓝牙，第一终端200就可以扫描到该第二终端300并进行配对，用户在该第二终端300和第一终端200上确认配对信息后，第一终端200可以在蓝牙连接界面中显示配对成功的该第二终端300的设备标识，并将其同步显示到已配对设备栏20中，用户则可以选择该设备标识以将其对应的第二终端300添加为可信任设备，第一终端200对应的在可信任设备栏10中显示出该设备标识，并将该第二终端300的蓝牙MAC地址添加到可信任列表中。
在具体添加可信任设备时，第一终端200可以在用户选择了已配对设备栏20中的设备标识后，显示用于提示用户是否添加对应第二终端300为可信任设备的提示信息。例如图2中的(a)所示，用户对已配对设备栏20中的设备标识“AAA”进行了选择操作(例如：点击操作)；如图2中的(b)所示，第一终端200响应该选择操作，可以显示提示信息“是否将所选设备添加为可信任设备？”，并提供“取消”和“确认”选项；用户选择“确认”选项后，如图2中的(c)所示，第一终端200响应于用户的选择操作，将设备标识“AAA”添加到可信任设备栏10中，并将设备标识“AAA”对应的第二终端300的蓝牙MAC地址添加到可信任列表中。
用户若需要删除某可信任设备，即删除可信任列表中该可信任设备对应的蓝牙MAC地址，可以在可信任设备栏10中删除该可信任设备的设备标识。图3为本申请实施例提供的另一些可信任设备设置界面的示意图，如图3中的(a)所示，在具体实 现时，用户可以对待删除的可信任设备的设备标识“AAA”进行选择操作(例如：点击操作)；如图3中的(b)所示，第一终端200响应该选择操作，可以显示提示信息“是否将所选设备删除？”，并提供“取消”和“确认”选项；用户选择“确认”选项后，如图3中的(c)所示，第一终端200响应于用户的选择操作，将设备标识“AAA”从可信任设备栏10中删除，并将设备标识“AAA”对应的第二终端300的蓝牙MAC地址从可信任列表中删除。
本实施例中，可信任列表可以与账号进行关联，即第一终端200中不同的账号对应不同的可信任列表；可信任列表也可以不与账号进行关联，即第一终端200中不同的账号对应同一可信任列表。
其中，对于可信任列表与账号进行关联的情况，若用户主动退出目标账号，第一终端200也可以将目标账号对应的可信任列表清除，以更好的保护用户的数据隐私；此时，若用户再次登录目标账号，第一终端200可以重新建立目标账号对应的可信任列表。
为了方便用户使用，本实施例中，第一终端200也可以在用户主动退出目标账号或者更新了可信任列表的情况下，将目标账号对应的可信任列表上传至服务端100进行保存；当用户再次登录目标账号时，第一终端200从服务端100获取目标账号对应的可信任列表即可。
通过上述过程，第一终端200上存储了第一令牌和可信任列表，第二终端300上存储了第二令牌，当第一终端200在存储有第一令牌且处于登出状态的情况下进行自动登录时，若第二终端300位于第一终端200的近距离通信范围内，第一终端200就可以获取到第二终端300的近距离通信标识，基于该近距离通信标识和可信任列表确定第二终端300是否是可信任设备；然后在确定第二终端300属于可信任设备的情况下，通过服务端100验证第一终端200的第一令牌和第二终端300的第二令牌的有效性，基于令牌验证结果来确定是否自动登录。该自动登录的具体实现过程可以参见后续的方法实施例，此处不再详述。
下面对第一终端的自动登录认证过程进行详细说明。
图4为本申请实施例提供的登录认证方法的流程示意图，如图4所示，该方法可以包括如下步骤：
S110、第一终端与第二终端建立蓝牙连接。
如前述实施例中所述，第一终端通过预先登录目标账号，可以得到第一令牌和可信任列表，第二终端通过预先登录目标账号可以得到第二令牌；当需要使第一终端在存储有第一令牌且处于登出状态的情况下自动登录目标账号时，用户可以将第二终端靠近第一终端，第一终端则可以基于可信任列表、第一令牌和第二令牌进行自动登录的认证过程，基于认证结果确定是否自动登录。
具体的，当与第一终端建立过蓝牙连接的第二终端靠近第一终端时，第一终端可以基于蓝牙连接记录自动与第二终端建立蓝牙连接。两者建立连接后，就可以通过建立的蓝牙连接进行数据交互。
S120、第一终端获取第二终端的蓝牙MAC地址，并根据蓝牙MAC地址确定第二终端是否属于可信任设备；若是，则执行步骤S130，否则执行步骤S160。
具体的，第一终端可以扫描第二终端的蓝牙广播消息来获取第二终端的蓝牙MAC地址，或者基于与第二终端之间建立的蓝牙连接请求获取第二终端的MAC地址。
第一终端在获取到第二终端的蓝牙MAC地址后，可以检验该蓝牙MAC地址是否存在于可信任列表中，若存在，可以认为该第二终端为可信任设备，第一终端可以继续进行后续的认证过程；若不存在，则说明认证不通过，第一终端可以继续保持登出状态。
需要说明的是，本实施例中，第一终端也可以在确定第二终端是可信任设备的情况下或者在验证第二终端是否是可信任设备的过程中与第二终端建立蓝牙连接，也就是说，步骤S110与步骤S120之间没有严格的时序执行关系，步骤S110可以在步骤S120之前执行，也可以在步骤S120之后执行，还可以与步骤S120同时执行，本实施例对此不做特别限定。
S130、第一终端获取第二终端登录的账号的账号唯一标识，并判断第二终端的账号唯一标识与目标账号的账号唯一标识是否一致；若是，则执行步骤S140，否则执行步骤S160。
本实施例中，第一终端在确定第二终端为可信任设备后，可以通过服务端对第一令牌和第二令牌进行验证；为了进一步提高第一终端自动登录的安全性，本实施例中，在进行令牌验证前，第一终端可以先对第二终端登录的账号与第一终端待登录的目标账号进行一致性校验。另外，为了提高第二终端中账号信息的安全性，本实施例中，第一终端在进行账号一致性校验前，可以先通过校验码验证方式来建立第二终端对第一终端的信任。具体的验证过程可以参见图5，图5为本申请实施例提供的账号一致性校验方法的流程示意图，如图5所示，该方法可以包括如下步骤：
S1301、第一终端将第一令牌携带在校验码请求中发送给服务端。
具体的，第一终端在确定第二终端为可信任设备后，可以先将第一令牌发送给服务端，请求服务端在第一令牌验证通过的情况下返回校验码。
S1302、服务端接收校验码请求，并验证第一令牌的有效性。
本实施例中，服务端收到第一终端发送的校验码请求后，可以对其中的第一令牌进行验证，以确定其是否有效。其中，在具体验证时，可以对第一令牌的有效期和其他内容进行验证。
举例说明，服务端发放的令牌包括头部(header)、载荷(payload)和签名(signature)，其中，header中声明signature的加密算法；signature中存放一些有效信息，例如：令牌的签发时间和/或过期时间；signature是采用密钥(secret)和header中声明的加密算法对header和payload加密而生成。
服务端在验证第一令牌时，可以先从第一令牌的header中解析出加密算法，然后使用原来的密钥和解析出的加密算法对第一令牌的header和payload进行加密，将生成的签名与第一令牌中的签名进行比对，若一致，说明第一令牌合法。另外，服务端可以根据第一令牌的payload中携带的有效信息对第一令牌的有效期进行验证，若payload中携带有令牌的过期时间，可以直接根据该过期时间确定第一令牌是否过期；若payload中只携带有令牌的签发时间，未携带过期时间，则可以根据签发时间计算第一令牌是否过期。若第一令牌的签名和有效期验证均通过，则可以确认第一令牌验 证通过。
当然，上述只是举例说明一种令牌验证方法，其并非用于限定本申请，本申请实施例中还可以采用其他的令牌验证方法对第一令牌进行验证，本实施例对此不做特别限定。
S1303、服务端在对第一令牌验证通过的情况下，向第一终端返回校验码。
具体的，服务端在对第一令牌验证通过后，可以生成一个一次性的有效期较短的校验码，将其返回给第一终端。
若第一令牌验证不通过，服务端可以向第一终端返回校验码验证失败消息，第一终端可以提示用户在第一终端上重新登录目标账号以重新申请第一令牌。
S1304、第一终端将接收的校验码发送给第二终端。
具体的，第一终端接收到服务端返回的校验码后，可以将其通过蓝牙连接发送给第二终端。
S1305、第二终端将接收的校验码发送到服务端进行验证。
具体的，第二终端接收到第一终端发送的校验码后，可以将其发送到服务端，请求服务端验证其是否有效。
S1306、服务端接收校验码，并对校验码进行验证。
本实施例中，服务端接收到第二终端发送的校验码后，可以对其进行验证，具体的验证方法可以采用目前的各种校验码验证方法，本实施例对此不做特别限定。
S1307、服务端向第二终端返回校验码验证结果。
具体的，服务端验证完校验码后，可以将校验码验证结果发送给第二终端，以告知第二终端校验码是否验证通过。
S1308、第二终端在校验码验证通过的情况下向第一终端返回已登录账号的账号唯一标识。
本实施例中，第二终端接收到服务端返回的校验码验证结果后，可以获取校验码是否验证通过。若校验码验证通过，可以将登录的账号的账号唯一标识发送给第一终端；若校验码验证不通过，可以向第一终端返回校验码验证失败消息，以告知第一终端校验码验证失败；第二终端也可以在校验码验证不通过的情况下不返回任何消息，第一终端在预设时间段内未收到第二终端返回的消息可以认为校验码验证失败；第一终端若确定校验码验证失败，可以继续保持登出状态，也可以再次请求校验码进行认证或进行其他操作。
另外，本实施例中，也可以不进行后续的账号一致性校验步骤，此种情况下，第二终端也可以在校验码验证通过时向第一终端返回未携带账号唯一标识的校验码验证成功消息，以告知第一终端校验码验证成功。
其中，账号唯一标识可以是用户身份标识号码(Identity，ID)，也可以是账号的其他唯一性标识。
S1309、第一终端判断接收到的账号唯一标识与目标账号的账号唯一标识是否一致。
具体的，第一终端接收到第二终端发送的账号唯一标识后，可以与待登录的目标账号的账号唯一标识进行比对，判断两者是否一致，即判断第二终端登录的账号和第一终端待登录的账号是否一致；如果一致，可以继续进行后续的认证过程；如果不一 致，则说明认证不通过，第一终端可以继续保持登出状态。
其中，对于目标账号的账号唯一标识，第一终端可以在预先申请并存储第一令牌的同时，存储目标账号的账号唯一标识，在比对时读取存储的目标账号的账号唯一标识；第一终端也可以在进行比对前，向服务端发送第一令牌来请求目标账号的账号唯一标识，然后进行比对。
S140、第一终端通过服务端验证第一令牌和第二令牌是否均有效；若是，则执行步骤S150，否则执行步骤S160。
具体的，第一终端在账号一致性校验通过后，可以通过服务端验证第一令牌和第二令牌的有效性。在具体实现时，可以至少采用如下三种方式实现：
第一种：第一终端与第二终端交换令牌，分别将令牌发送至服务端进行有效性验证。
具体的，该实施方式中，第一终端可以先将第一令牌发送给第二终端，以进一步建立第二终端对第一终端的信任度；第二终端接收到第一令牌后将其发送到服务端进行有效性验证，在验证通过的情况下将第二令牌发送给第一终端；第一终端接收到第二令牌后将其发送到服务端进行有效性验证，若验证通过，则可以认为自动登录认证通过，第一终端进行自动登录；若验证不通过则说明第二终端不够可靠，第一终端可以继续保持登出状态。
第二种：第一终端从第二终端获取第二令牌，将第一令牌和第二令牌发送至服务端进行有效性验证。
具体的，该实施方式中，第一终端可以向第二终端发送令牌获取请求，请求第二终端将第二令牌发送给第一终端；第一终端接收到第二令牌后，可以将第一令牌和第二令牌一起发送到服务端进行有效性验证，然后基于服务端返回的令牌验证结果确定是否自动登录。
其中，第一终端若在此之前进行了通过第一令牌请求校验码的过程，在进行令牌验证时，也可以只将第二令牌发送至服务端进行有效性验证。
第三种：第一终端将第一令牌发送给第二终端，由第二终端将第一令牌和第二令牌发送至服务端进行有效性验证。
具体的，该实施方式中，第一终端可以将第一令牌发送给第二终端，第二终端将第一令牌和第二令牌一起发送给服务端进行有效性验证，然后在接收到服务端返回的验证结果后，将验证结果转发给第一终端。
上述三种令牌验证方式中，第一种令牌验证方式，第二终端和第一终端互相认证，安全性更高。
为了提高第一终端与第二终端之间数据交互的安全性，本实施例中，第一终端和第二终端在传输数据时可以进行加密处理，其中，加密方式可以是对称加密方式，也可以是非对称加密方式，以进一步提高数据交互的安全性。
下面以令牌验证方式为第一种令牌验证方式、加密方式为非对称加密方式为例，说明令牌验证的具体实现过程。
图6为本申请实施例提供的令牌验证方法的流程示意图，如图6所示，该方法可以包括如下步骤：
S1401、第一终端将预先生成的第一公钥发送给第二终端。
具体的，第一终端可以预先采用非对称加密算法生成密钥对，该密钥对包含第一公钥和第一私钥，其中，采用第一公钥加密的信息须采用第一私钥才能解密；该密钥对可以是第一终端在本次自动登录的认证过程中(在发送第一私钥前)生成的，即每次自动登录可以采用不同的密钥对；该密钥对也可以是第一终端在首次进行目标账号自动登录前或首次进行目标账号自动登录的认证过程中生成的，即每次的自动登录可以采用相同的密钥对。
同样的，第二终端也可以预先采用非对称加密算法生成密钥对，该密钥对包含第二公钥和第二私钥，其中，采用第二公钥加密的信息须采用第二私钥才能解密。第二终端生成密钥对的方式与第一终端生成密钥对的方式类似，此处不再赘述。
第一终端可以在账号一致性校验通过后，与第二终端交换公钥，即约定好密钥，以便在与第二终端进行数据交互时，采用约定的密钥对交互的数据进行加密和解密。在具体实现时，第一终端可以先将第一公钥发送给第二终端，并向第二终端请求第二公钥。
S1402、第二终端接收到第一公钥后，将预先生成的第二公钥发送给第一终端。
S1403、第一终端接收第二公钥，采用第二公钥对第一令牌进行加密。
具体的，第一终端接收到第二终端发送的第二公钥后，可以采用第二公钥对第一令牌进行加密，然后将加密后的第一令牌发送给第二终端，以进一步建立第二终端对第一终端的信任度，使第二终端在确定第一终端可信的情况下将第二令牌反馈给第一终端。
S1404、第一终端将加密后的第一令牌发送给第二终端。
S1405、第二终端接收加密后的第一令牌，采用预先生成的第二私钥对加密后的第一令牌进行解密，得到第一令牌。
具体的，第二终端在接收到第一终端发送的加密数据(即加密后的第一令牌)后，可以采用第二公钥对应的第二私钥对加密数据进行解密，得到第一令牌。
S1406、第二终端将第一令牌发送到服务端进行验证。
本实施例中，第二终端在解密得到第一令牌后，可以将其发送到服务端，请求服务端验证第一令牌是否有效，以便确认第一终端是否可信。
S1407、服务端接收第一令牌，对第一令牌进行有效性验证。
具体的，服务端在接收到第一令牌后，可以响应第二终端的请求，对第一令牌进行验证，具体的验证过程与步骤S1302类似，此处不再赘述。
S1408、服务端向第二终端返回第一令牌验证结果。
S1409、第二终端在第一令牌验证通过的情况下，采用第一公钥对第二令牌进行加密。
具体的，第二终端在接收到服务端返回的第一令牌验证结果后，可以确定第一令牌是否验证通过。若第一令牌验证通过，则可以采用第一公钥对第二令牌加密后发送给第一终端，以进一步建立第一终端对第二终端的信任度；若第一令牌验证不通过，则可以与步骤S1308类似，向第一终端返回第一令牌验证失败消息或不返回任何消息，以告知第一终端第一令牌验证失败，第一终端在确定第一令牌验证失败时，可以继续 保持登出状态，也可以提示用户重新登录目标账号申请新的第一令牌或进行其他操作。
S1410、第二终端将加密后的第二令牌发送给第一终端。
S1411、第一终端接收加密后的第二令牌，采用预先生成的第一私钥对加密后的第二令牌进行解密，得到第二令牌。
具体的，第一终端接收到第二终端发送的加密数据(即加密后的第二令牌)后，可以采用第一公钥对应的第一私钥对该加密数据进行解密，得到第二令牌。
S1412、第一终端将第二令牌发送到服务端进行验证。
本实施例中，第一终端在解密得到第二令牌后，可以将其发送到服务端，请求服务端验证第二令牌是否有效，以进一步确定第二终端是否可信任。
S1413、服务端接收第二令牌，对第二令牌进行有效性验证。
具体的，服务端在接收到第二令牌后，可以响应第一终端的请求，对第二令牌进行验证，具体的验证过程与第一令牌的验证过程类似，此处不再赘述。
S1414、服务端向第一终端返回第二令牌验证结果。
S1415、第一终端接收第二令牌验证结果。
本实施例中，第一终端接收到服务端返回的第二令牌验证结果后，可以确定第二令牌是否验证通过，若验证通过，则可以确定第二终端可信，执行自动登录操作；若验证不通过，则可以继续保持登出状态。
S150、自动登录目标账号。
具体的，第一终端在第一令牌和第二令牌均验证通过后，可以执行目标账号的自动登录操作，从登出状态进入登录状态。
S160、保持登出状态。
具体的，在目标账号的自动登录认证过程中若出现信息验证不通过的情况，第一终端则可以认为认证失败而继续保持登出状态。
为了进一步提高第一终端自动登录的安全性，本实施例中，第一终端在自动登录目标账号后，可以每隔一预设时间间隔(例如五分钟)将第二终端的第一令牌发送至服务端进行验证，若验证通过，则继续保持登录状态；若验证不通过，第一终端可以重新从第二终端获取第二令牌，并发送至服务端进行验证，若验证通过，则继续保持登录状态，若验证仍不通过，则可以执行登出操作。
其中，第一终端在重新获取第二令牌时，也可以将第一令牌发送给第二终端，指示第二终端在第一令牌验证通过的情况下返回第二令牌。
本实施例提供的登录认证方法，第一终端在自动登录目标账号前，先根据附近第二终端的近距离通信标识确定该第二终端是否属于可信任设备，然后在确定第二终端属于可信任设备的情况下，校验第二终端登录的账号与目标账号的一致性，在两者一致的情况下再通过服务端验证第一终端预先向服务端申请的第一令牌和第二终端预先向服务端申请的第二令牌的有效性，在第一令牌和第二令牌均验证通过时再自动登录目标账号，这样可以有效的提高第一终端自动登录的安全性。
基于同一发明构思，作为对上述方法的实现，本申请实施例提供了登录认证装置，该装置实施例与前述方法实施例对应，为便于阅读，本装置实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的装置能够对应实现前述 方法实施例中的全部内容。
图7为本申请实施例提供的一种登录认证装置的结构示意图，如图7所示，本实施例提供的登录认证装置110可以包括：登录请求单元111、令牌存储单元112、可信任列表建立单元113、蓝牙匹配单元114、校验单元115、令牌加密单元116、令牌交换单元117、令牌解密单元118和令牌验证单元119。
其中，登录请求单元111用于支持第一终端执行上述实施例中所述的在未存储有第一令牌情况下的登录过程、S150、S160和/或本文所描述的技术的其它过程。
令牌存储单元112用于支持第一终端存储服务端下发的第一令牌。
可信任列表建立单元113用于支持第一终端执行上述实施例中所述的建立可信任列表的过程、存储可信任列表和/或本文所描述的技术的其它过程。
蓝牙匹配单元114用于支持第一终端执行上述实施例中的S110与第二终端建立蓝牙连接的操作、S120和/或本文所描述的技术的其它过程。
校验单元115用于支持第一终端执行上述实施例中S1301、S1304、S1309和/或本文所描述的技术的其它过程。
令牌加密单元116用于支持第一终端执行上述实施例中S1403和/或本文所描述的技术的其它过程。
令牌交换单元117用于支持第一终端执行上述实施例中S1401、S1404和/或本文所描述的技术的其它过程。
令牌解密单元118用于支持第一终端执行上述实施例中S1411和/或本文所描述的技术的其它过程。
令牌验证单元119用于支持第一终端执行上述实施例中S1412、S1415和/或本文所描述的技术的其它过程。
本实施例提供的登录认证装置可以执行上述方法实施例中第一终端执行的方法，其实现原理与技术效果类似，此处不再赘述。
图8为本申请实施例提供的另一种登录认证装置的结构示意图，如图8所示，本实施例提供的登录认证装置120可以包括：登录请求单元121、令牌存储单元122、蓝牙匹配单元123、校验单元124、令牌加密单元125、令牌交换单元126、令牌解密单元127和令牌验证单元128。
其中，登录请求单元121用于支持第二终端执行上述实施例中所述的在未存储有第二令牌情况下的登录过程和/或本文所描述的技术的其它过程。
令牌存储单元122用于支持第二终端存储服务端下发的第二令牌。
蓝牙匹配单元123用于支持第二终端执行上述实施例中的S110与第一终端建立蓝牙连接的操作和/或本文所描述的技术的其它过程。
校验单元124用于支持第二终端执行上述实施例中S1305、S1308和/或本文所描述的技术的其它过程。
令牌加密单元125用于支持第二终端执行上述实施例中S1409和/或本文所描述的技术的其它过程。
令牌交换单元126用于支持第二终端执行上述实施例中S1402、S1410和/或本文所描述的技术的其它过程。
令牌解密单元127用于支持第二终端执行上述实施例中S1405和/或本文所描述的技术的其它过程。
令牌验证单元128用于支持第二终端执行上述实施例中S1406、S1409中确定第一令牌是否验证通过的操作和/或本文所描述的技术的其它过程。
本实施例提供的登录认证装置可以执行上述方法实施例中第二终端执行的方法，其实现原理与技术效果类似，此处不再赘述。
图9为本申请实施例提供的又一种登录认证装置的结构示意图，如图9所示，本实施例提供的登录认证装置130可以包括：登录验证单元131、令牌生成单元132、校验码生成单元133、校验码验证单元134和令牌验证单元135。
其中，登录验证单元131用于支持服务端执行上述实施例中对终端设备在未存储有第一令牌情况下进行登录的验证过程。
令牌生成单元132用于支持服务端执行上述实施例中生成第一令牌和第二令牌的相关过程和/或本文所描述的技术的其它过程。
校验码生成单元133用于支持服务端执行上述实施例中的S1302中接收校验码请求的操作、S1303和/或本文所描述的技术的其它过程。
校验码验证单元134用于支持服务端执行上述实施例中的S1306、S1307和/或本文所描述的技术的其它过程。
令牌验证单元135用于支持服务端执行上述实施例中的S1302中验证第一令牌的有效性的操作、S1407、S1408、S1413、S1414和/或本文所描述的技术的其它过程。
本实施例提供的登录认证装置可以执行上述方法实施例中服务端执行的方法，其实现原理与技术效果类似，此处不再赘述。
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。实施例中的各功能单元、模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中，上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。另外，各功能单元、模块的具体名称也只是为了便于相互区分，并不用于限制本申请的保护范围。上述系统中单元、模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
基于同一发明构思，本申请实施例还提供了一种终端设备。图10为本申请实施例提供的终端设备的结构示意图，如图10所示，本实施例提供的终端设备可以包括：存储器210、处理器220、输入单元230、显示单元240和通信模块250等部件。
下面结合图10对终端设备的各个构成部件进行具体的介绍：
存储器210可用于存储计算机程序以及模块，处理器220通过运行存储在存储器210的计算机程序以及模块可以执行上述方法实施例中第一终端和/或第二终端所执行的方法。存储器210可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据终端设备的使用所创建的数据(比如音频数据、电话本等)等。 此外，存储器210可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
处理器220是终端设备的控制中心，利用各种接口和线路连接整个终端设备的各个部分，通过运行或执行存储在存储器210内的软件程序和/或模块，以及调用存储在存储器210内的数据，执行终端设备的各种功能和处理数据，从而对终端设备进行整体监控。可选的，处理器220可包括一个或多个处理单元。
输入单元230可用于接收输入的数字或字符信息，以及产生与终端设备的用户设置以及功能控制有关的键信号输入。用户可以通过输入单元230在终端设备上输入账号信息登录账号，当终端设备作为第一终端时，用户也可以通过输入单元230设置可信任列表等。
具体地，输入单元230可包括触控面板231以及其他输入设备232。触控面板231，也称为触摸屏，可收集用户在其上或附近的触摸操作(比如用户使用手指、触笔等任何适合的物体或附件在触控面板231上或在触控面板231附近的操作)，并根据预先设定的程式驱动相应的连接装置。可选的，触控面板231可包括触摸检测装置和触摸控制器两个部分。其中，触摸检测装置检测用户的触摸方位，并检测触摸操作带来的信号，将信号传送给触摸控制器；触摸控制器从触摸检测装置上接收触摸信息，并将它转换成触点坐标，再送给处理器220，并能接收处理器220发来的命令并加以执行。此外，可以采用电阻式、电容式、红外线以及表面声波等多种类型实现触控面板231。除了触控面板231，输入单元230还可以包括其他输入设备232。具体地，其他输入设备232可以包括但不限于物理键盘、功能键(比如音量控制按键、开关按键等)、轨迹球、鼠标、操作杆等中的一种或多种。
显示单元240可用于显示由用户输入的信息或提供给用户的信息以及终端设备的各种菜单。本实施例中，终端设备可通过显示单元240显示用于供用户登录账号的账号登录界面，当终端设备作为第一终端时，终端设备也可以通过显示单元240显示用于供用户设置可信任列表的设置界面等。
具体的，显示单元240可包括显示面板241，可选的，可以采用液晶显示器(Liquid Crystal Display，LCD)、有机发光二极管(Organic Light-Emitting Diode,OLED)等形式来配置显示面板241。进一步的，触控面板231可覆盖显示面板241，当触控面板231检测到在其上或附近的触摸操作后，传送给处理器220以确定触摸事件的类型，随后处理器220根据触摸事件的类型在显示面板241上提供相应的视觉输出。虽然在图8中，触控面板231与显示面板241是作为两个独立的部件来实现终端设备的输入和输入功能，但是在某些实施例中，可以将触控面板231与显示面板241集成而实现终端设备的输入和输出功能。
通信模块250可以提供应用在终端设备上的包括无线局域网(Wireless Local Area Networks，WLAN)(如Wi-Fi网络)、蓝牙、Zigbee、移动通信网络、全球导航卫星系统(global navigation satellite system，GNSS)、调频(frequency modulation，FM)、NFC和红外技术(infrared，IR)等通信的解决方案。通信模块可以是集成至少一个通信处理模块的一个或多个器件。该通信模块250可以包括天线，可以通过天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器。通信模块250还可以 从处理器220接收待发送的信号，对其进行调频、放大，经天线转为电磁波辐射出去。终端设备可以通过该通信模块250与其他终端设备建立近距离通信连接，以及与服务端进行通信。
本领域技术人员可以理解，图10仅仅是终端设备的举例，并不构成对终端设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
本实施例提供的终端设备可以执行上述方法实施例，其实现原理与技术效果类似，此处不再赘述。
基于同一发明构思，本申请实施例还提供了一种服务端。图11为本申请实施例提供的服务端的结构示意图，如图11所示，本实施例提供的服务端可以包括：存储器310、处理器320和通信模块330等部件。
其中，存储器310可用于存储计算机程序以及模块，处理器320通过运行存储在存储器310的计算机程序以及模块可以执行上述方法实施例中服务端所执行的方法。存储器310可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序(比如声音播放功能、图像播放功能等)等；存储数据区可存储根据服务端的使用所创建的数据(比如音频数据、电话本等)等。此外，存储器310可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。
处理器320是服务端的控制中心，利用各种接口和线路连接整个服务端的各个部分，通过运行或执行存储在存储器310内的软件程序和/或模块，以及调用存储在存储器310内的数据，执行服务端的各种功能和处理数据，从而对服务端进行整体监控。可选的，处理器320可包括一个或多个处理单元。
通信模块330可以提供应用在服务端上的包括无线局域网(Wireless Local Area Networks，WLAN)(如Wi-Fi网络)、蓝牙、Zigbee、移动通信网络、全球导航卫星系统(global navigation satellite system，GNSS)、调频(frequency modulation，FM)、NFC和红外技术(infrared，IR)等通信的解决方案。通信模块可以是集成至少一个通信处理模块的一个或多个器件。该通信模块330可以包括天线，可以通过天线接收电磁波，将电磁波信号调频以及滤波处理，将处理后的信号发送到处理器。通信模块330还可以从处理器320接收待发送的信号，对其进行调频、放大，经天线转为电磁波辐射出去。服务端可以通过该通信模块330与终端设备进行通信。
本领域技术人员可以理解，图11仅仅是服务端的举例，并不构成对服务端的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
本实施例提供的服务端端可以执行上述方法实施例，其实现原理与技术效果类似，此处不再赘述。
本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述方法实施例所述的方法。
本申请实施例还提供一种计算机程序产品，当计算机程序产品在电子设备上运行时，使得电子设备执行上述方法实施例所述的方法。其中，电子设备可以是上述终端设备或服务端。
上述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时， 可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实现上述实施例方法中的全部或部分流程，可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一计算机可读存储介质中，该计算机程序在被处理器执行时，可实现上述各个方法实施例的步骤。其中，所述计算机程序包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读存储介质至少可以包括：能够将计算机程序代码携带到拍照装置/终端设备的任何实体或装置、记录介质、计算机存储器、只读存储器(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、电载波信号、电信信号以及软件分发介质。例如U盘、移动硬盘、磁碟或者光盘等。在某些司法管辖区，根据立法和专利实践，计算机可读介质不可以是电载波信号和电信信号。
处理器可以是中央处理单元(Central Processing Unit，CPU)，还可以是其他通用处理器、数字信号处理器(Digital Signal Processor，DSP)、专用集成电路(Application Specific Integrated Circuit，ASIC)、现成可编程门阵列(Field-Programmable Gate Array，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。
在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述或记载的部分，可以参见其它实施例的相关描述。
本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
在本申请所提供的实施例中，应该理解到，所揭露的装置/设备和方法，可以通过其它的方式实现。例如，以上所描述的装置/设备实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通讯连接可以是通过一些接口，装置或单元的间接耦合或通讯连接，可以是电性，机械或其它的形式。
应当理解，当在本申请说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
还应当理解，在本申请说明书和所附权利要求书中使用的术语“和/或”是指相关联列出的项中的一个或多个的任何组合以及所有可能组合，并且包括这些组合。
如在本申请说明书和所附权利要求书中所使用的那样，术语“如果”可以依据上下文被解释为“当...时”或“一旦”或“响应于确定”或“响应于检测到”。类似地，短语“如果确定”或“如果检测到[所描述条件或事件]”可以依据上下文被解释为意 指“一旦确定”或“响应于确定”或“一旦检测到[所描述条件或事件]”或“响应于检测到[所描述条件或事件]”。
另外，在本申请说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
在本申请说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本申请的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (25)

  1. 一种登录认证方法，应用于第一终端，其特征在于，包括：
    获取第二终端的近距离通信标识；
    若根据所述近距离通信标识确定所述第二终端属于可信任设备，则获取所述第二终端的第二令牌，并通过服务端验证所述第二令牌的有效性；其中，所述第二令牌是所述第二终端通过预先登录所述目标账号向服务端申请的；
    若所述第二令牌验证通过，则自动登录所述目标账号。
  2. 根据权利要求1所述的方法，其特征在于，所述根据所述近距离通信标识确定所述第二终端属于可信任设备，包括：
    若预先建立的可信任列表中包括所述近距离通信标识，则确定所述第二终端属于可信任设备。
  3. 根据权利要求2所述的方法，其特征在于，在获取第二终端的近距离通信标识之前，所述方法还包括：
    在所述目标账号登录成功的情况下，基于用户的配置操作将所述第二终端的近距离通信标识加入所述可信任列表，其中，所述第二终端与所述第一终端建立有近距离通信连接。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述获取第二终端的近距离通信标识，包括：
    在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识；其中，所述第一令牌是所述第一终端通过预先登录目标账号向服务端申请的；
    则所述自动登录所述目标账号，包括：
    在所述第一令牌验证通过的情况下自动登录所述目标账号。
  5. 根据权利要求4所述的方法，其特征在于，在所述在第一终端存储有第一令牌且处于登出状态的情况下，获取第二终端的近距离通信标识之前，所述方法还包括：
    若所述第一终端中未存储有所述第一令牌，则在登录所述目标账号的过程中，向所述服务端发送令牌获取请求，所述令牌获取请求用于请求所述服务端在对所述第一终端的目标账号登录请求验证通过的情况下返回第一令牌；
    接收并存储所述服务端返回的第一令牌。
  6. 根据权利要求5所述的方法，其特征在于，所述方法还包括：
    若检测到用户在所述第一终端上输入退出所述目标账号的操作，则执行登出操作，并清除所述第一令牌。
  7. 根据权利要求4-6任一项所述的方法，其特征在于，在所述通过服务端验证所述第二令牌的有效性之前，所述方法还包括：
    与所述第二终端建立近距离通信连接。
  8. 根据权利要求7所述的方法，其特征在于，在所述获取所述第二终端的第二令牌之前，所述与所述第二终端建立近距离通信连接之后，所述方法还包括：
    若根据所述近距离通信标识确定所述第二终端属于可信任设备，则向所述服务端发送校验码请求，所述校验码请求中携带所述第一令牌，所述校验码请求用于指示所 述服务端在对所述第一令牌验证通过的情况下返回校验码；
    接收所述服务端返回的校验码，并将所述校验码发送给所述第二终端，以指示所述第二终端将所述校验码发送到所述服务端进行验证；
    确定所述校验码验证通过。
  9. 根据权利要求8所述的方法，其特征在于，所述确定所述校验码验证通过，包括：
    若接收到所述第二终端返回的账号唯一标识，则确定所述校验码验证通过；所述第二终端返回的账号唯一标识是所述第二终端在所述校验码验证通过的情况下发送的已登录账号的唯一标识；
    则在所述获取所述第二终端的第二令牌之前，所述方法还包括：
    确定接收到的账号唯一标识与所述目标账号的账号唯一标识一致。
  10. 根据权利要求7-9任一项所述的方法，其特征在于，所述获取所述第二终端的第二令牌，并通过服务端验证所述第二令牌的有效性，包括：
    将所述第一令牌发送给所述第二终端，以指示所述第二终端将所述第一令牌发送到所述服务端进行有效性验证，并在所述第一令牌验证通过后返回第二令牌；
    接收所述第二终端发送的第二令牌，将所述第二令牌发送到所述服务端进行有效性验证。
  11. 根据权利要求10所述的方法，其特征在于，所述第一终端发送给所述第二终端的第一令牌和从所述第二终端接收的第二令牌都是经过加密处理的，所述第二终端发送给所述服务端的第一令牌和所述第一终端发送给所述服务端的第二令牌都是经过解密处理得到的，所述加密处理和解密处理均是基于预先约定的密钥进行的。
  12. 根据权利要求11所述的方法，其特征在于，所述密钥为非对称密钥。
  13. 根据权利要求1-12任一项所述的方法，其特征在于，所述方法还包括：
    按照预设时间间隔周期性将所述第二令牌发送至所述服务端进行验证；
    若验证不通过，则重新从所述第二终端获取第二令牌，并发送至服务端进行验证；
    若重新获取的第二令牌验证不通过，则执行登出操作。
  14. 一种登录认证方法，应用于第二终端，其特征在于，包括：
    响应于第一终端获取近距离通信标识的请求，向所述第一终端发送近距离通信标识；
    在已成功登录目标账号的情况下，接收所述第一终端发送的第一令牌，并将所述第一令牌发送到服务端进行有效性验证；所述第一令牌是所述第一终端在根据所述近距离通信标识确定所述第二终端属于可信任设备的情况下发送的；
    接收所述服务端返回的第一令牌验证结果，并在所述第一令牌验证通过的情况下向所述第一终端返回第二令牌，以指示所述第一终端将所述第二令牌发送到所述服务端进行有效性验证，并在所述第二令牌验证通过的情况下，自动登录所述目标账号；其中，所述第一令牌是所述第一终端通过预先登录所述目标账号向服务端申请的，所述第二令牌是所述第二终端通过预先登录所述目标账号向服务端申请的。
  15. 根据权利要求14所述的方法，其特征在于，在所述在已成功登录所述目标账号的情况下，接收所述第一终端发送的第一令牌之前，所述方法还包括：
    若所述第二终端中未存储有所述第二令牌，则在登录所述目标账号的过程中，向所述服务端发送令牌获取请求，所述令牌获取请求用于请求所述服务端在对所述第二终端的目标账号登录请求验证通过的情况下返回第二令牌；
    接收并存储所述服务端返回的第二令牌。
  16. 根据权利要求15所述的方法，其特征在于，所述方法还包括：
    若检测到用户在所述第一终端上输入退出所述目标账号的操作，则执行登出操作，并清除所述第二令牌。
  17. 根据权利要求14-16任一项所述的方法，其特征在于，在所述接收所述第一终端发送的第一令牌之前，所述方法还包括：
    与所述第一终端建立近距离通信连接。
  18. 根据权利要求17所述的方法，其特征在于，在所述接收所述第一终端发送的第一令牌之前，所述与所述第一终端建立近距离通信连接之后，所述方法还包括：
    接收所述第一终端发送的校验码，所述校验码是所述第一终端在根据所述近距离通信标识确定所述第二终端属于可信任设备的情况下，从所述服务端请求的；
    将所述校验码发送到所述服务端进行验证；
    接收所述服务端返回的校验码验证结果；
    确定所述校验码验证通过。
  19. 根据权利要求18所述的方法，其特征在于，所述方法还包括：
    向所述第一终端发送已登录账号的唯一标识，以使所述第一终端确定接收到的账号唯一标识与所述目标账号的账号唯一标识一致。
  20. 一种登录认证方法，应用于服务端，其特征在于，包括：
    接收第一终端发送的校验码请求，并在对第一令牌验证通过的情况下向所述第一终端返回校验码；其中，所述校验码请求中携带所述第一令牌，所述校验码请求是所述第一终端在确定第二终端属于可信任设备的情况下发送的，所述第一令牌是所述第一终端通过预先登录目标账号向服务端申请的；
    接收所述第二终端发送的携带有所述校验码的校验码验证请求，并在所述校验码验证通过的情况下，向所述第二终端返回校验码验证结果；其中，所述校验码验证请求是所述第二终端接收到所述第一终端发送的校验码后发送的；
    接收第二终端发送的第一令牌，并对所述第一令牌进行有效性验证后，向所述第二终端返回第一令牌验证结果；其中，所述第一令牌是第一终端在确定校验码验证通过的情况下向所述第二终端发送的；
    接收第一终端发送的第二令牌，并对所述第二令牌进行有效性验证；其中，所述第二令牌是所述第一终端在确定第一令牌验证通过的情况下发送的，所述第二令牌是所述第二终端通过预先登录所述目标账号向服务端申请的；
    向所述第一终端返回第二令牌验证结果，以使所述第一终端在所述第二令牌验证通过的情况下，自动登录所述目标账号。
  21. 根据权利要求20所述的方法，其特征在于，所述方法还包括：
    接收所述第一终端发送的令牌获取请求；
    在对所述第一终端的目标账号登录请求验证通过的情况下，向所述第一终端返回 第一令牌。
  22. 根据权利要求20或21所述的方法，其特征在于，所述方法还包括：
    接收所述第二终端发送的令牌获取请求；
    在对所述第二终端的目标账号登录请求验证通过的情况下，向所述第二终端返回第二令牌。
  23. 一种电子设备，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行如权利要求1-22任一项所述的方法。
  24. 一种登录认证系统，其特征在于，包括：第一终端、第二终端和服务端，所述第一终端用于执行如权利要求1-13所述的方法，所述第二终端用于执行如权利要求14-19所述的方法，所述服务端用于执行如权利要求20-22所述的方法。
  25. 一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-22任一项所述的方法。
PCT/CN2020/125209 2020-01-19 2020-10-30 登录认证方法、装置与系统 WO2021143280A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20914463.3A EP4092955A4 (en) 2020-01-19 2020-10-30 LOGIN AUTHENTICATION METHOD, DEVICE AND SYSTEM
US17/793,322 US20230353363A1 (en) 2020-01-19 2020-10-30 Login authentication method, apparatus, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010060167.2A CN113225188B (zh) 2020-01-19 2020-01-19 登录认证方法、装置与系统
CN202010060167.2 2020-01-19

Publications (1)

Publication Number Publication Date
WO2021143280A1 true WO2021143280A1 (zh) 2021-07-22

Family

ID=76863530

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/125209 WO2021143280A1 (zh) 2020-01-19 2020-10-30 登录认证方法、装置与系统

Country Status (4)

Country Link
US (1) US20230353363A1 (zh)
EP (1) EP4092955A4 (zh)
CN (1) CN113225188B (zh)
WO (1) WO2021143280A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114006700A (zh) * 2021-08-09 2022-02-01 招银云创信息技术有限公司 客户端登录方法、装置、计算机设备和存储介质
CN115834095A (zh) * 2021-09-17 2023-03-21 聚好看科技股份有限公司 一种多设备协同登录方法及显示设备、服务器
WO2024060655A1 (zh) * 2022-09-19 2024-03-28 中兴通讯股份有限公司 条形码信息处理方法、电子设备、计算机可读介质

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IL285030B (en) * 2021-07-21 2022-04-01 Nayax Ltd System, device and method for digital payment
CN117652134A (zh) * 2021-08-11 2024-03-05 聚好看科技股份有限公司 终端设备、服务器及多设备协同登录方法
CN113963465B (zh) * 2021-10-15 2024-05-28 广州小鹏汽车科技有限公司 车机登录方法、装置、车辆及存储介质
CN114866324A (zh) * 2022-05-10 2022-08-05 中国建设银行股份有限公司 信息处理方法、系统、设备及存储介质
CN116436905B (zh) * 2023-04-19 2023-11-28 广州市迪士普音响科技有限公司 网络化广播通信方法及装置、存储介质及计算机设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104135494A (zh) * 2014-08-22 2014-11-05 北京京东尚科信息技术有限公司 一种基于可信终端的同账户非可信终端登录方法及系统
CN105069345A (zh) * 2015-08-12 2015-11-18 惠州Tcl移动通信有限公司 一种移动终端的隐私保护方法及系统
CN105471913A (zh) * 2015-12-31 2016-04-06 广州多益网络科技有限公司 一种通过共享区域信息的客户端登录方法及系统
CN108292454A (zh) * 2015-12-03 2018-07-17 诺基亚技术有限公司 访问管理
WO2018138713A1 (en) * 2017-01-29 2018-08-02 Beame. Io Ltd. Establishing an ad-hoc secure connection between two electronic computing devices using a self-expiring locally transmitted information packet

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8627438B1 (en) * 2011-09-08 2014-01-07 Amazon Technologies, Inc. Passwordless strong authentication using trusted devices
US8850037B2 (en) * 2012-05-24 2014-09-30 Fmr Llc Communication session transfer between devices
US20140173695A1 (en) * 2012-12-18 2014-06-19 Google Inc. Token based account access
US8782766B1 (en) * 2012-12-27 2014-07-15 Motorola Solutions, Inc. Method and apparatus for single sign-on collaboration among mobile devices
CN103986738B (zh) * 2013-02-07 2018-10-16 百度在线网络技术（北京）有限公司 一种多终端间的同步方法及系统
CN105592011B (zh) * 2014-10-23 2019-12-24 阿里巴巴集团控股有限公司 一种账号登录方法及装置
CN105245541B (zh) * 2015-10-28 2020-02-18 腾讯科技（深圳）有限公司 鉴权方法、设备及系统
US10541992B2 (en) * 2016-12-30 2020-01-21 Google Llc Two-token based authenticated session management
CN109309683B (zh) * 2018-10-30 2021-09-14 泰华智慧产业集团股份有限公司 基于token的客户端身份验证的方法及系统
US20200137056A1 (en) * 2018-10-31 2020-04-30 Hewlett Packard Enterprise Development Lp Client device re-authentication
US11323431B2 (en) * 2019-01-31 2022-05-03 Citrix Systems, Inc. Secure sign-on using personal authentication tag
CN110278187B (zh) * 2019-05-13 2021-11-16 网宿科技股份有限公司 多终端单点登录方法、系统、同步服务器及介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104135494A (zh) * 2014-08-22 2014-11-05 北京京东尚科信息技术有限公司 一种基于可信终端的同账户非可信终端登录方法及系统
CN105069345A (zh) * 2015-08-12 2015-11-18 惠州Tcl移动通信有限公司 一种移动终端的隐私保护方法及系统
CN108292454A (zh) * 2015-12-03 2018-07-17 诺基亚技术有限公司 访问管理
CN105471913A (zh) * 2015-12-31 2016-04-06 广州多益网络科技有限公司 一种通过共享区域信息的客户端登录方法及系统
WO2018138713A1 (en) * 2017-01-29 2018-08-02 Beame. Io Ltd. Establishing an ad-hoc secure connection between two electronic computing devices using a self-expiring locally transmitted information packet

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114006700A (zh) * 2021-08-09 2022-02-01 招银云创信息技术有限公司 客户端登录方法、装置、计算机设备和存储介质
CN115834095A (zh) * 2021-09-17 2023-03-21 聚好看科技股份有限公司 一种多设备协同登录方法及显示设备、服务器
WO2024060655A1 (zh) * 2022-09-19 2024-03-28 中兴通讯股份有限公司 条形码信息处理方法、电子设备、计算机可读介质

Also Published As

Publication number Publication date
US20230353363A1 (en) 2023-11-02
CN113225188B (zh) 2023-09-22
EP4092955A4 (en) 2023-05-31
EP4092955A1 (en) 2022-11-23
CN113225188A (zh) 2021-08-06

Similar Documents

Publication Publication Date Title
WO2021143280A1 (zh) 登录认证方法、装置与系统
US10645581B2 (en) Method and apparatus for remote portable wireless device authentication
US10033701B2 (en) Enhanced 2CHK authentication security with information conversion based on user-selected persona
US10025920B2 (en) Enterprise triggered 2CHK association
CN108809659B (zh) 动态口令的生成、验证方法及系统、动态口令系统
US9444809B2 (en) Secure and efficient authentication using plug-in hardware compatible with desktops, laptops and/or smart mobile communication devices such as iPhones™
WO2017197974A1 (zh) 一种基于生物特征的安全认证方法、装置及电子设备
US20160189136A1 (en) Authentication of mobile device for secure transaction
WO2021258993A1 (zh) 车辆与蓝牙钥匙安全连接的方法、蓝牙模块、蓝牙钥匙
CN109920100B (zh) 一种智能锁开锁方法及系统
WO2022143130A1 (zh) 一种应用程序登录方法及系统
CN114238900A (zh) 一种数据传输方法及电子设备
CN108696361B (zh) 智能卡的配置方法、生成方法及装置
CN105325021B (zh) 用于远程便携式无线设备认证的方法和装置
WO2017000340A1 (zh) 一种加密方法及装置
KR101835718B1 (ko) 이종 기기 사이의 근거리 무선 통신을 이용한 모바일 인증 방법
US20230401300A1 (en) Data transmission method and electronic device
CN115103356A (zh) 计算机安全验证系统、方法、移动终端及可读存储介质
JP6273240B2 (ja) 継承システム、サーバ装置、端末装置、継承方法及び継承プログラム
WO2023288037A1 (en) Device and systems for remotely provisioning sim profile with strong identity and strong authentication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20914463

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2020914463

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE