System and method for multi-factor authentication
By introducing a mechanism in the client system to call back the server to generate and verify a unique authentication code, the problem that the existing authentication mechanism cannot prevent unauthorized access is solved, and more efficient user authentication and system access control are achieved.
Patent Information
- Application Number
- CN202380093156.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-12-07
- Filing Date
- 2023-12-06
- Publication Date
- 2025-09-12
AI Technical Summary
Existing authentication mechanisms are based solely on user credentials and cannot effectively prevent access by unauthorized users, especially in the face of data hacking attacks and credential theft, which can lead to unauthorized access to sensitive data and systems.
A callback server associated with the client system is used to generate a unique authentication code and store it on the callback server. The validity of the code is verified between the authentication server and the callback server to ensure that only authorized users can access the security system.
It improves the security of authentication, prevents unauthorized access, and can accurately identify legitimate users even when user credentials are stolen or tampered with, thereby enhancing the system's protection capabilities.
Smart Images
Figure CN120641895A_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present disclosure relate to authentication and system access, such as to verify user authorization to access remote systems and / or servers. Background Art
[0002] Many computer systems operate remotely from their respective users, yet still hold and maintain sensitive data and / or perform proprietary functions. Consequently, users are often required to authenticate themselves to verify that they are authorized to access content on the service provider's system. However, current authentication mechanisms are limited to verifying that a user possesses certain credentials. Therefore, if a user possesses credentials, they are granted access even if they are not actually authorized. Therefore, there is a need for an authentication system and method that, in addition to user credentials, verifies that a login attempt is authorized. BRIEF DESCRIPTION OF THE DRAWINGS
[0003] The accompanying drawings are incorporated herein and constitute a part of this specification.
[0004] Figure 1 An exemplary authentication environment according to an embodiment is shown.
[0005] Figure 2 A block diagram of an exemplary authentication system is shown in accordance with various embodiments.
[0006] Figure 3 A process flow diagram of an exemplary authentication process is shown in accordance with various embodiments.
[0007] Figure 4 A flow chart illustrating an exemplary authentication method according to various embodiments is shown.
[0008] Figure 5 A flow chart of an exemplary authentication method according to an embodiment is shown.
[0009] Figure 6 An example computer system is shown for implementing some aspects of the present disclosure, or portion(s) thereof.
[0010] In the drawings, reference numbers generally refer to the same or similar elements.Also, generally, the leftmost digit(s) of a reference number identifies the drawing in which the reference number first appears. DETAILED DESCRIPTION
[0011] Provided herein are a method, system, computer program product embodiments, and / or combinations and sub-combinations thereof for authenticating a user and providing access to a secure system.
[0012] The disclosed embodiments involve authenticating users based on communications with a client callback server. In other words, a security system can employ an authentication server at its front end to intercept users seeking access to the system. When a user seeks access to the security system, a client associated with the user generates a unique code, which it stores at the client callback server. Once the user establishes possession of the credentials, the authentication server communicates with the client callback server to verify that the code received from the user is valid. The callback server verifies the validity of the code and responds to the authentication server. Depending on whether the verification succeeds or fails, the authentication server either authorizes or denies the user access to the security system. This authentication ensures that a user in possession of an authentication credential is also authorized by the client associated with that credential. In other words, this authentication prevents access by bad actors for whom such an authentication code has not been generated.
[0013] Many computer systems operate remotely from their respective users, yet still hold and maintain sensitive data and / or perform proprietary functions. Consequently, users are often required to authenticate themselves to verify that they are authorized to access content on the service provider's system. However, current authentication mechanisms are limited to verifying that the user possesses certain credentials. Therefore, if a user possesses the credentials, they are granted access, even if they are not actually authorized. Given the current environment of data hacking and other login exposure, this can lead to bad actors gaining unauthorized access to sensitive data and systems.
[0014] Specifically, hackers often break into user databases and obtain login and password data for users of the system. Similarly, even without direct intrusion, user credentials are eventually exposed during access attempts, whether during entry into online forms, via HTTP headers, or other means. Thus, an outside observer can obtain a user's credentials by monitoring their activity. Bad actors can then use the user's credentials to gain access to secure systems.
[0015] Even modern two-factor authentication can be compromised in a variety of different ways. For example, most two-factor authentication methods employ a text message or email notification to the so-called "owner" to alert them to the login attempt and request that they verify the attempt. However, a hacker with access to the user's data can update the user's data to replace the correct contact information with contact information accessible to the hacker (e.g., a fake email address or phone number). Thus, when the bad actor enters the user's credentials, the second factor will be sent to the bad actor and quickly approved. Other mechanisms exist for bad actors to spoof or otherwise falsify two-factor authentication. Therefore, there is a need for an authentication system and method that can authenticate a user based on the provided credentials and also authenticate the user based on another factor that cannot be easily compromised by a bad actor.
[0016] Embodiments of the present disclosure employ a callback server associated with a client system. A client may be an entity associated with a user and having some supervisory authority over the user's access to a service, and the client system may include one or more computer systems and / or servers, including the callback server. During the registration process, the client system associated with the client notifies the authentication server of the address and / or contact method of the callback server. When a user associated with the client seeks to make a login attempt at the authentication server, the client system generates a unique authentication code, which is stored at the callback server. The user then proceeds to attempt to log into the security system normally by providing the user's credentials to the system. The authentication server first checks for a match between the user's authentication information and the stored authentication information. If there is a match, the authentication server proceeds to the second stage of the authentication process.
[0017] In the next phase of authentication, the authentication server verifies the login attempt. In other words, the client generates an authentication code only when there is an upcoming login attempt by a known user. Therefore, the login will only be valid if there is a valid authentication code. When the login occurs, the authentication server will obtain the authentication code through any of the various methods described herein. Once the user's credentials have been verified, the authentication server sends the authentication code to the client's known server. The client verifies whether the authentication code is valid and responds to the authentication server with a success or failure message. The authentication server then grants or denies access to the user based on this response. Because there is no user involvement in the second authentication factor, and because the authentication code must be generated and verified by the registered client server, the ability of bad actors to gain access to secure systems protected by the authentication server is severely impaired.
[0018] Various embodiments of these features will now be discussed with reference to the corresponding drawings.
[0019] Figure 1 An exemplary authentication environment 100 according to an embodiment is shown. Figure 1 As shown in FIG, there are a user terminal 110 and a callback server 120 on the client system 105 side, and an authentication server and one or more databases 180 on the service 185 side. The user terminal 110 can be any suitable device capable of accessing the service 185, such as, but not limited to, a personal computer, a smart phone, a PDA, a gaming system, etc. In embodiments, a user is associated with a client. For example, in some embodiments, the user is an employee or other staff member who registers to access the service 185 on behalf of the client. In other embodiments, the user can be a resident who authorizes their residents to access the facilities of the service 185, or a member of some other authorized group.
[0020] In one embodiment, callback server 120 is owned, operated, and / or maintained by the client. In other embodiments, callback server 105 is associated only with the client and may be a general-purpose server owned and operated by a third party. In either scenario, prior to any login attempt, the client registers with service 185. At this point, one or more users may register with service 185. In other words, the client identifies to service 185 certain users who have authorization to access service 185 on behalf of client 105. At this point, the client may also provide the service with the login credentials of the registered users. Alternatively, the user may log in separately after the client has been registered to provide their credentials to service 185.
[0021] As part of the registration process, the client system 105 provides the service 185 with a contact address and / or contact method for verifying login attempts made by users associated with the client. In embodiments, the contact address is an IP address, URL, email address, or other address. In embodiments, the contact method may include, but is not limited to, SIP signaling, Ethernet protocol, email, SMS messaging, or direct messaging. Together, the contact address and contact method provide the service 185 with a means for verifying login attempts made by the client.
[0022] like Figure 1 As shown in FIG, service 185 is accessed by user device 110. In one embodiment, the user navigates to service 185 using one or more input devices (such as a mouse, keyboard, etc.). In one embodiment, service 185 can be accessed via network 150 at a specific URL via an HTTP interface. In one embodiment, network 150 can be any network suitable for providing electronic communication between user device 110 and callback server 120 (such as a WAN, LAN, WLAN, VPN, etc.). When the user navigates to service 185, callback server 120 is notified of the attempt and callback server 120 generates an authentication code. The callback server can be notified of the login attempt in a variety of different ways. For example, in one embodiment, user device 110 accesses service 185 via a VPN associated with the client. Upon detecting the service URL, client system 105 (e.g., callback server 120) automatically generates an authentication code and stores it in callback server 120. In another embodiment, the user first requests login authorization from client 105, which authorizes the login, generates a code, and stores the authorization code in callback server 120.
[0023] While this document has described a user as a human user and a user device as a device that can be used by such a user, in other embodiments, the user and user device may be replaced by a system or application that takes action on behalf of the user due to other triggers, such as, but not limited to, system events, alarms / monitoring, scheduled / batch jobs, remote applications, etc. In other words, the user / user device may be another client or application in business-to-business communications over the Internet.
[0024] Regardless of how the client system 105 is notified, when a user accesses the service 185, the client 105 generates an authorization code and a corresponding expiration time. In one embodiment, the expiration time is predetermined to expire at a preset time (e.g., 1 minute from issuance, etc.) from when the code is generated or from when a login attempt is detected. Once the authentication code has been generated, the client 105 stores the authentication code along with the expiration time in the callback server 120. Similarly, the client 105 provides the authentication code to the user device 110. In one embodiment, all of this occurs without user interaction or knowledge. That is, when a user accesses the service 185, the client 105 automatically detects the action, generates a code, and provides the code to the user device 110 without any involvement by the user.
[0025] A user accesses the authentication server 170 of service 185 over the network, at which point the user is requested to provide login credentials for accessing service 185. The user uses the input device of the user device to enter the login credentials, which may include but are not limited to a login ID, password, token, answer to a security question, username, biometric information, etc. Once the user enters this information into the corresponding form fields, the user submits the information to the authentication server 170. At this point, the authentication code provided by the service to the user device 110 is also submitted. In one embodiment, this is performed manually by the user. That is, the code is provided to the user, and the user enters it into the form field for submission. However, in another embodiment, the authentication code is automatically provided to the service 185 by the user device without user interaction or knowledge. In this embodiment, the code (which may or may not be known to the user) can be injected into the HTTP header by the user device when the form is submitted. In this way, the code remains confidential, and these additional authentication steps are performed seamlessly and without the user's knowledge.
[0026] Authentication server 170 receives the user's credentials and authentication code. First, authentication server 170 verifies the user's credentials. Specifically, as described above, authentication server 170 stores the user credentials of all users who have registered to access service 185. In one embodiment, the registered credentials are stored locally in onboard memory at authentication server 170. In other embodiments, the registered credentials are stored remotely in a separate database or server. Therefore, in one embodiment, the verification of the user's credentials includes authentication server 170 identifying the user based on one or more of the provided credentials (e.g., user name, user ID, etc.) and retrieving the user's credentials from storage based on this identification. Once retrieved, authentication server 170 compares the credentials provided by the user with the credentials retrieved from storage to determine whether they match.
[0027] If the credentials do not match, then the authentication server 170 denies the user access and does not proceed to the second stage of the authentication process. Alternatively, if the authentication server 170 determines that the credentials match, then the authentication server 170 proceeds to the next stage of authentication.
[0028] During the second phase of the authentication process, authentication server 170 sends a code verification request to callback server 120 of client 105. Specifically, as described above, authentication server 170 stores user data in association with its associated client. Authentication server 170 also stores the callback address and contact method associated with callback server 105. Therefore, when a user's login attempt passes the first phase of the authentication process, authentication server 170 identifies client 105 associated with the user based on the user's credentials. Authentication server 170 then retrieves the callback server contact information from storage and receives an authentication code from the login. As described above, in various embodiments, the authentication code may be manually provided by the user or automatically obtained by authentication server 170 without the user's involvement and / or knowledge. In one example, authentication server 170 obtains the authentication code from an HTTP header associated with the login request.
[0029] Once the authentication server 170 obtains the callback server contact information and the authentication code, the authentication server 170 sends a message as defined by the callback server contact server to the client's callback server 120. In one embodiment, the message is a REQUEST type message that includes the authentication code. As described above, in one embodiment, the message is a SIP message, an SMS message, or a proprietary message.
[0030] Callback server 120 receives a code verification request message from authentication server 170 and checks the received authentication code against the current code. In other words, each time any user associated with client 105 attempts to log in, a code is generated and maintained at callback server 120 until the code expires, at which point it is deleted or otherwise marked as invalid and / or expired. Therefore, when callback server 120 receives a request message from authentication server 170, callback server 120 compares the received authentication code with the stored authentication codes and verifies whether the received authentication code matches one of the stored authentication codes and whether the code has not expired. If either of these checks fails, callback server 120 sends a FAILURE reply message to authentication server 170 via network 150, indicating that verification of the authentication code failed. Alternatively, if both checks are met, callback server 120 sends a SUCCESS reply message to authentication server 170 via network 150, indicating that the code is valid.
[0031] In response to authentication server 170 receiving a FAILURE reply message from callback server 120, authentication server 170 denies the user access. Alternatively, if the reply message is a SUCCESS message, authentication server 170 grants the user access to service 185. In this manner, users can be accurately authenticated even when their credentials have been stolen or otherwise misappropriated, as a bad actor attempting to access server 185 will not have access to a valid authentication code. In various embodiments, this may be because client 105 did not detect the login attempt and never generated such a code, because the bad actor was unable to properly submit the authentication code to authentication server 170, or because the valid code expired before it could be used by the bad actor. Therefore, unlike traditional two-factor authentication, access cannot be gained through possession of the user's device or by intercepting or redirecting messages sent from the authentication server. Instead, because the authentication code is generated and stored by the client system, is only valid for a limited period of time, and requires contact from the authentication server in the manner agreed upon during registration, authentication can be accurately performed regardless of bad actor intervention.
[0032] Figure 2 1 shows a block diagram of an exemplary authentication system 200 according to various embodiments. Figure 2As shown in FIG, the authentication system includes a callback server 220 and an authentication server 270. The callback server includes a transceiver 225 and several functional blocks, including a read request block 222, a code comparison block 224, a generate response block 226, a login detection block 228, and a code generator block 227, and may represent an exemplary embodiment of the callback server 120. Similarly, the authentication server includes a transceiver 275 and several functional blocks, including a credential verification block 272, a client identifier block 274, a code verification block 276, a code request block 278, and an access decision block 280, and may represent an exemplary embodiment of the authentication server 270. In an embodiment, the callback server 220 and the authentication server 270 each include a memory or other computer-readable storage medium and one or more processors (not shown), and the functional blocks of each of the callback server 220 and the authentication server 270 are implemented by programming code stored in the memory and executed by the one or more processors.
[0033] like Figure 2 As shown in FIG, the authentication server 220 includes a login detection block 228 that identifies whether a user is attempting to log into the service 185. In one embodiment, the login detection block 228 is explicitly notified of the user's login attempt, which transmits a message to the code generator block 227. However, in another embodiment, the login detection block 228 automatically detects the login attempt based on user activity, such as by detecting that the user has visited a URL corresponding to the server 185. In one embodiment, the initial URL detection is performed at the user device, and the user device then automatically notifies the client via the login detection block 220. In an embodiment, the login detection is performed by monitoring user activity or Internet traffic at the user device.
[0034] Once a login has been detected, the code generator block 227 generates an authentication code for the user's login attempt. In one embodiment, the authentication code is a numerical binary value, such as a 16-bit, 32-bit, or higher number. Once the code has been generated, the callback server 220 sends the authentication code to the user device 110 via the transceiver 225. The callback server 220 also stores the authentication code in memory along with an expiration time. In one embodiment, the expiration time is a predetermined time from the creation of the code, such as 30 seconds, 1 minute, 2 minutes, etc.
[0035] Simultaneously, authentication server 270 receives a login request from the user, which includes the user's login credentials. As described above, the login credentials may include a login ID, user ID, username, email address, password, biometric information, answers to security questions, tokens, etc. In one embodiment, the user may also manually submit an authentication code. However, in another embodiment, authentication server 270 automatically obtains the authentication code without user action, such as by extracting the authentication code from an HTTP header associated with the login request.
[0036] Once the user's credentials have been obtained, the credential verification block 272 retrieves the stored credentials associated with the user and determines whether the credentials match. If the credential verification block 272 determines that the credentials provided by the user do not match the stored credentials, the access decision block 280 rejects the login attempt and denies access to the user. On the other hand, if the credential verification block 272 determines that the credentials provided by the user do match the stored credentials, the authentication server 270 proceeds to the second authentication stage.
[0037] Specifically, during the second authentication phase, client identification block 274 identifies the client associated with the user. In one embodiment, this determination is based on the user's authentication credentials. Once the client has been identified, authentication server 270 also obtains contact information for a callback server associated with the client. In one embodiment, the contact information includes the communication address of callback server 220 and the communication method for communicating with callback server 220.
[0038] Once the callback communication information has been obtained, the code request module 278 generates a code verification request. The code verification request is prepared by the code request module 278 according to the specifications of the callback communication information. Specifically, in an embodiment, the callback communication information may specify the format of the request or the destination address. Accordingly, the code request module 278 generates a request message according to these specifications and causes the transceiver 275 to send the request to the callback server 220. In one embodiment, the code verification request message includes the authentication code obtained during the login process.
[0039] Callback server 220 receives a code verification request message from authentication server 270 via transceiver 225. Request read module 222 extracts relevant information from the request message, including the authentication code and reply information. Code comparison module 224 scans a database of stored authentication codes. In one embodiment, only current (e.g., valid) codes are stored. In another embodiment, all codes are stored along with a status identifier that identifies each code as valid or invalid. Based on the scan, code comparison module 224 determines whether the code included in the request message matches any valid codes.
[0040] After the code comparison, generate-response block 226 generates a reply message to be sent to authentication server 270. If the received code matches a valid code at callback server 220, generate-response block 226 generates the reply message as a SUCCESS message. In one embodiment, the SUCCESS message informs authentication server 270 that the verification of the authentication code was successful and that the user should be granted access to service 185. Alternatively, if the received code does not match any valid code at callback server 220, generate-response block 226 generates the reply message as a FAILURE message. In one embodiment, the FAILURE message informs authentication server 270 that the code verification failed and that the user should be denied access. In one embodiment, any reply message includes the authentication code or some other indicator of the login request to which the message applies. Callback server 220 sends the reply message via transceiver 225.
[0041] The authentication server 270 receives the reply message via the transceiver 275. The code verification block 276 receives the reply message and determines whether the reply message indicates that the code has been verified. Specifically, a FAILURE reply message indicates to the authentication server 270 that the code has not been verified and the user should not be granted access. Meanwhile, a SUCCESS reply message indicates to the authentication server 270 that the code has been verified and the user should be granted access to the service 185.
[0042] Based on the code verification block 276, the access decision block 280 determines whether the user's access is authorized. In one embodiment, the user is authorized to access the service 185 only if all provided credentials match the stored credentials and the code has been verified by the callback server. Based on this determination, the access decision block 280 authorizes or denies the user access to the service.
[0043] Figure 3 1 shows a process flow diagram of an exemplary authentication process 300 according to various embodiments. Figure 3 As shown in , process 300 involves the exchange of messages between a user device 305, a client system 310, a client callback system 320, and a server 330. In one embodiment, user device 305 represents an exemplary embodiment of user device 110, client system 310 represents an exemplary embodiment of client system 105, client callback system 320 represents an exemplary embodiment of callback server 120, and server 330 represents an exemplary embodiment of authentication server 170.
[0044] like Figure 3As shown in FIG, the process begins at step 301A, where the user device navigates to a service protected by authentication server 330. Then, in step 301B, user device 305 notifies client 310 that the user is attempting to access the service. Depending on the specific implementation, steps 301A and 301B may occur in reverse order. For example, the user may explicitly request a code from client system 310, in which case step 301B may occur before navigating to 301A. In embodiments, client system 310 automatically detects the user's login attempt or detects that the user navigates to a URL associated with server 185. In other embodiments, the user manually notifies the client of an impending login attempt.
[0045] In step 302 , the client system 310 generates an authentication code and stores it at the client callback system 320 .
[0046] After the code has been generated, the user device 305 submits an authentication request in step 304. In an embodiment, the authentication request is submitted by a user associated with the client. In one embodiment, the authentication request requires the user to provide login credentials and an authentication code to the server 330. As described above, the login credentials may include one or more of a login ID, a user ID, a username, an email address, a password, biometric information, an answer to a security question, a token, etc. Furthermore, while the code may be known to the user and manually provided to the server 330, in other embodiments, the code is unknown to the user and is automatically provided to the server 330, such as by being included in an HTTP header.
[0047] After receiving the credentials, the server 330 performs a verification process 306 to verify the client credentials 306. In one embodiment, the verification process 306 includes comparing the provided credentials with the stored credentials to determine whether they match. If the credentials do not match, the process effectively terminates, with the server 330 denying the user access to the service 185.
[0048] However, Figure 3 Assume successful authentication. Figure 3In one embodiment shown in FIG, if the credentials are successfully verified (e.g., verification process 306 determines that the provided credentials match stored credentials), server 330 is authenticated in step 307. In this step, server 330 provides certain credentials to client callback system 320 to verify its identity. Such credentials may include keys, certificates, identifiers, etc. In one embodiment, server authentication 307 is mutual Transport Layer Security (mTLS) authentication. mTLS is a mutual authentication method in which both client callback system 320 and server 330 authenticate each other using the TLS protocol. In one embodiment, mTLS authentication occurs during the initial connection of the SSL / TLS handshake. In another embodiment, server authentication 307 can be performed using Open Authentication (OAuth). OAuth is an open standard authorization protocol / framework that provides applications with the ability to "securely specify access." In other words, it allows limited access before server 330 has been fully authenticated. In this way, server 330 can be contacted and client credentials 306 verified before full authentication 307.
[0049] After verifying the client credentials 306, the server 330 transmits a request 308 to the client callback system 320 requesting verification of the authentication code. In one embodiment, the request 308 is sent to a location and uses a communication method defined by the stored callback communication information provided by the client during an earlier registration or other similar process. In one embodiment, the request 308 includes the authentication code obtained by the server 330.
[0050] The client callback system 320 receives the request and extracts the authentication code from it. The client callback system 320 then performs a verification process 312 to verify whether the authentication code included in the request message is valid. As described above, in an embodiment, the client callback system 320 stores and maintains a database of all valid authentication codes (e.g., codes that have been issued and have not yet expired). The verification process 312 includes comparing the received code with the database to ensure that the authentication code is valid. In one embodiment, when the code is initially generated and stored in step 302, the code is stored along with an indicator of the user to whom the code has been provided. Therefore, as a further check, in some embodiments, the verification process 312 also checks the user identification information included in the request message to verify that the authentication code is not only valid, but also associated with the login request of the correct user.
[0051] If the verification process 312 fails to identify a valid code that matches the code included in the request message, the client callback system 320 transmits a FAILURE message to the server 330 indicating that the authentication code could not be verified. Figure 3 Assume a successful login attempt. Therefore, if Figure 3 As shown in FIG, if the client callback system 320 verifies the code, the client callback system 320 transmits a SUCCESS message 314 to the server 330 informing the server that the code is successfully verified.
[0052] After receiving the reply message from the client callback system 320, the server 330 makes a final determination as to whether the user is authorized to access the service 185. In an embodiment, if the reply message is a FAILURE message, the server 330 denies access and terminates the login attempt. Figure 3 As shown in , if the reply message is a SUCCESS message, the server 330 authorizes the user to access the service 185 in step 316 .
[0053] While the above embodiments have been described with respect to users associated with a larger client, these embodiments may also be extended to the individual level. For example, in one embodiment, the client and callback server may be replaced with an app running on the user device 110. The app is associated with an authentication server (e.g., a banking app associated with a banking website) and performs substantially the same functions as the client 105 and callback server 120. Specifically, the app detects the user's login attempt and generates an authentication code, which it stores in its memory. After the user provides valid credentials, the authentication server 170 pings the app based on the app identification information stored in association with the registered user credentials. The app verifies the code included in the ping and responds with a response as to whether the code is valid.
[0054] In another embodiment, machine learning algorithms are also employed at the authentication server to further enhance the verification process. For example, machine learning can be employed to analyze and store normal behaviors associated with specific users and / or clients. Thus, when a login attempt is performed that deviates from these normal behaviors, the login attempt can be further reviewed. Such behaviors can include, but are not limited to, the means of accessing the authentication server (e.g., via an API, from a specific IP address, etc.), date and time, request volume, failure rate, etc. If any of these or any other monitored aspects of the login deviate from the learned norms, the login attempt is further reviewed and / or rejected.
[0055] Figure 4 A flow chart of an exemplary authentication method 400 is shown in accordance with various embodiments.
[0056] Method 400 begins by the client detecting the user's authentication action in step 410. In an embodiment, this can be performed by manually notifying the client by the user. In another embodiment, the client automatically performs this detection based on some action of the user (such as the user navigating to a URL associated with service 185).
[0057] In step 420, the client generates an authentication code associated with the user's login attempt. In one embodiment, the authentication code is a numeric value represented by multiple bits, such as a 16-bit, 32-bit, or higher number. In one embodiment, the client also encrypts the authentication code, which needs to be decrypted during a future verification phase. In one embodiment, the authentication code is also associated with an expiration time, which can be the current duration from when the code was created.
[0058] In step 430, the client stores the authentication code at the callback server. In one embodiment, the authentication code is stored in association with an expiration time. The authentication code is considered valid until the expiration time expires. In one embodiment, the authentication code is also stored in an encrypted format.
[0059] In step 435, a check is made as to whether the authentication code has expired. In one embodiment, this is performed by comparing the expiration time associated with the authentication code with the current time. In one embodiment, this check is repeated as long as the code remains valid. If the current time is after the expiration time (435-Yes), the code is invalid and deleted in step 440. On the other hand, if the current time is before the expiration time, the code is valid. In this case (435-Yes), the authentication code is maintained in the database.
[0060] In an alternative configuration, all codes can be maintained indefinitely along with their expiration dates. Furthermore, rather than repeatedly checking the validity of authentication codes, the codes can simply be stored along with their expiration dates and checked upon request. In this way, computing power is reduced at the expense of storage capacity. In yet another embodiment, codes are maintained regardless of their expiration dates but are deleted during periodic database cleanups (e.g., which can occur weekly, monthly, etc.). During these cleanups, all codes that have expired beyond a certain period from the time of the cleanup are deleted, while all other codes are maintained until a future cleanup.
[0061] At step 450, the callback server 450 receives a code verification request. In one embodiment, the code verification request includes an authentication code. In another embodiment, the code verification request also includes a user credential or user identifier.
[0062] In response, the callback server determines in step 455 whether a valid code that matches the code included in the code verification request is available. In embodiments where codes are deleted upon expiration, this check is performed by determining whether a code that matches the received code exists in the database. In embodiments where codes are maintained for a period of time after expiration, this check includes determining whether a code that matches the received code exists in the database, and determining whether the matching code is valid (e.g., not expired). Additionally, in some embodiments, the authentication code may be stored with a user identifier of the user to whom the authentication code was provided. In this embodiment, this check also includes obtaining user identification information from the received request and verifying whether the received user identification information matches the user identification information associated with the stored code.
[0063] If there is no valid authentication code (455-No), a FAILURE message is prepared and sent to the authentication server in step 460. In one embodiment, the FAILURE message includes the authentication code.
[0064] Alternatively, if there is a valid authentication code (455-Yes), a SUCCESS message is sent to the authentication server in step 470. In one embodiment, the SUCCESS message includes the authentication code.
[0065] Figure 5 FIG. 5 shows a flow chart of an exemplary authentication method 500 according to an embodiment. Figure 5 As shown in FIG5 , the authentication server receives an authentication request from a user in step 510. The authentication request includes the user's login credentials, including but not limited to a login ID, a user ID, a username, an email address, a password, biometric information, answers to security questions, tokens, etc. In one embodiment, the authentication request is entered into a form field of an HTML page managed by the authentication server or a front-end server associated therewith.
[0066] In step 520, the authentication server obtains the user's login credentials from the login request and also obtains an authentication code associated with the login request. In one embodiment, the authentication code is manually entered by the user when logging in. However, in another embodiment, the authentication server automatically retrieves the authentication code, such as from an HTTP header, without user intervention.
[0067] In step 530, the authentication server authenticates the user's credentials. In one embodiment, this step includes comparing the received user credentials with the user credentials previously registered with the user. In other words, during the registration process, the user is registered and the user's login credentials are stored in memory. In this embodiment, the authentication server identifies the supposed user based on the received login credentials and then compares the received login credentials with the login credentials associated with the user.
[0068] In step 535, the authentication server determines whether the user's credentials match the stored credentials. If they do not match, the authentication server denies the user access to the service in step 570. Alternatively, if there is a match between the received credentials and the registered credentials (535-Yes), the authentication server sends the received authentication code to the callback server in step 540. In one embodiment, the code is transmitted to the callback server in a request message as indicated by the callback communication information stored at the authentication server.
[0069] In response to the request message, the authentication server receives a reply message from the callback server in step 550. The reply message indicates whether the code check is SUCCESS or FAILURE. In one embodiment, the reply message includes the authentication code.
[0070] In step 555, the authentication server determines whether the authentication code is verified. If the reply message indicates that the authentication code is successfully verified (555-Success), the authentication server authorizes the user's access in step 560. Alternatively, if the reply message indicates that the authentication code is not verified (555-Failure), the authentication server denies the user access to the service.
[0071] The description of the above method is merely exemplary. In any of the methods disclosed herein, the order of many different steps can be rearranged within the scope of the present disclosure. Additionally, according to the above disclosure, depending on the specific embodiment implemented, each in the method can include fewer or more aspects.
[0072] For example, one or more well-known computer systems (such as Figure 6 For example, one or more computer systems 600 may be used to implement any of the embodiments discussed herein, as well as combinations and subcombinations thereof.
[0073] Computer system 600 may include one or more processors (also referred to as central processing units or CPUs), such as processor 604. Processor 604 may be connected to a communication infrastructure or bus 606.
[0074] The computer system 600 may also include user input / output device(s) 603 , such as a display, keyboard, pointing device, etc., which may communicate with the communication infrastructure 606 via the user input / output interface(s) 602 .
[0075] One or more of the processors (such as processor 604) may be a graphics processing unit (GPU). In one embodiment, a GPU may be a specialized electronic circuit designed to process mathematically intensive applications. A GPU may have a parallel architecture that is efficient for processing large blocks of data in parallel, such as mathematically intensive data common to computer graphics applications, images, videos, and the like.
[0076] The computer system 600 may also include a main memory or primary storage 608, such as random access memory (RAM). The main memory 608 may include one or more levels of cache. The main memory 608 may have control logic (i.e., computer software) and / or data stored therein.
[0077] The computer system 600 may also include one or more secondary storage devices or memories 610. The secondary storage 610 may include, for example, a hard disk drive 612 and / or a removable storage device or drive 614. The removable storage drive 614 may be a floppy disk drive, a tape drive, an optical disk drive, an optical storage device, a tape backup device, and / or any other storage device / drive.
[0078] The removable storage drive 614 can interact with a removable storage unit 618. The removable storage unit 618 may include a computer-usable or readable storage device having computer software (control logic) and / or data stored thereon. The removable storage unit 618 may be a floppy disk, a magnetic disk, a magnetic tape, an optical disk, a DVD, an optical storage disk, and / or any other computer data storage device. The removable storage drive 614 can read from and / or write to the removable storage unit 618.
[0079] Secondary memory 610 may include other means, devices, components, tools, or other methods for allowing computer programs and / or other instructions and / or data to be accessed by computer system 600. Such means, devices, components, tools, or other methods may include, for example, a removable storage unit 622 and an interface 620. Examples of removable storage unit 622 and interface 620 may include a program card and card interface (such as those found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated sockets, a memory stick and USB port, a memory card and associated memory card slot, and / or any other removable storage unit and associated interface.
[0080] The computer system 600 may also include a communication or network interface 624. The communication interface 624 may enable the computer system 600 to communicate and interact with any combination of external devices, external networks, external entities, and the like (individually and collectively referenced by reference numeral 628). For example, the communication interface 624 may allow the computer system 600 to communicate with an external or remote device 628 via a communication path 626, which may be wired and / or wireless (or a combination thereof), and which may include any combination of a LAN, a WAN, the Internet, and the like. Control logic and / or data may be sent to or from the computer system 600 via the communication path 626.
[0081] The computer system 600 may also be a personal digital assistant (PDA), a desktop workstation, a laptop or notebook computer, a netbook, a tablet computer, a smart phone, a smart watch or other wearable device, a home appliance, part of the Internet of Things, and / or an embedded system, to name a few non-limiting examples, or any combination thereof.
[0082] The computer system 600 can be a client or server, accessing or hosting any applications and / or data through any delivery paradigm, including but not limited to remote or distributed cloud computing technology solutions; local or on-site deployment of software ("on-site" cloud-based technology solutions); "as a service" models (e.g., Content as a Service (CaaS), Digital Content as a Service (DCaaS), Software as a Service (SaaS), Managed Software as a Service (MSaaS), Platform as a Service (PaaS), Desktop as a Service (DaaS), Framework as a Service (FaaS), Backend as a Service (BaaS), Mobile Backend as a Service (MBaaS), Infrastructure as a Service (IaaS), etc.); and / or hybrid models including any combination of the foregoing examples or other services or delivery paradigms.
[0083] Any applicable data structures, file formats, and schemas in computer system 600 may be derived from standards including, but not limited to, JavaScript Object Notation (JSON), Extensible Markup Language (XML), another markup language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representation (alone or in combination). Alternatively, proprietary data structures, formats, or schemas may be used, alone or in combination with known or open standards.
[0084] In some embodiments, a tangible, non-transitory device or article of manufacture comprising a tangible, non-transitory computer-usable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 600, main memory 608, secondary memory 610, and removable storage units 618 and 622, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 600), may cause such data processing devices to operate as described herein.
[0085] Based on the teachings contained in this disclosure, it will be apparent to those skilled in the relevant art(s) how to use Figure 6 Embodiments of the present disclosure may be utilized with data processing devices, computer systems, and / or computer architectures other than those shown in . In particular, the embodiments may operate with software, hardware, and / or operating system implementations other than those described herein.
[0086] It should be understood that the detailed description section, and not any other section, is intended to be used to interpret the claims. The other sections may set forth one or more, but not all, exemplary embodiments as foreseen by the inventor(s), and therefore, are not intended to limit the present disclosure or the appended claims in any way.
[0087] Although the present disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the present disclosure is not limited thereto. Other embodiments and modifications thereof are possible and are within the scope and spirit of the present disclosure. For example, but without limiting the generality of this paragraph, the embodiments are not limited to the software, hardware, firmware and / or entities shown in the figures and / or described herein. In addition, the embodiments (whether or not explicitly described herein) have important utility for fields and applications beyond the examples described herein.
[0088] Embodiments have been described herein with the aid of functional building blocks that illustrate the implementation of specified functions and their relationships. For ease of description, the boundaries of these functional building blocks have been arbitrarily defined herein. Alternative boundaries may be defined so long as the specified functions and relationships (or their equivalents) are appropriately performed. Furthermore, alternative embodiments may perform functional blocks, steps, operations, methods, etc., in a different order than those described herein.
[0089] References herein to "one embodiment," "an embodiment," "an example embodiment," or similar phrases indicate that the described embodiment may include a particular feature, structure, or characteristic, but each embodiment may not necessarily include the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when describing a particular feature, structure, or characteristic in conjunction with an embodiment, (a plurality of) persons skilled in the relevant art will appreciate that such features, structures, or characteristics may be incorporated into other embodiments, regardless of whether explicitly mentioned or described herein. Additionally, some embodiments may be described using "coupled" and "connected," and their derivatives. These terms are not necessarily synonymous with each other. For example, some embodiments may be described using the terms "connected" and / or "coupled," to indicate that two or more elements are in direct physical or electrical contact with each other. However, the term "coupled" may also mean that two or more elements are not in direct contact with each other, but still collaborate or interact with each other.
[0090] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
Claims
1. An authentication server, comprising: a transceiver configured to send and receive electronic messages; a memory configured to store user authentication credentials; as well as One or more processors configured to: receiving an authentication request from a user, the authentication request including an authentication credential and an authentication code; comparing the received authentication credentials with the stored user authentication credentials to determine if there is a match; causing the transceiver to transmit a request message to a callback system associated with the user, the request message including the authentication code; receiving a reply message from the callback system in response to the request message, the reply message being one of a success message and a failure message; as well as Access to the user is authorized or denied based on the received reply message. 2 . The authentication server according to claim 1 , wherein the received authentication credentials include a login ID and a password. The authentication server according to claim 2 , wherein the received authentication credentials further include a client identifier. 4 . The authentication server of claim 1 , wherein the one or more processors are further configured to extract the authentication code from an HTTP header associated with the authentication request.
5. The authentication server of claim 1 , wherein the one or more processors are further configured to: receiving, via the transceiver, a registration request to register the client with the authentication server, the registration request including a client identifier; and The received client identifier is stored in the memory.
6. The authentication server according to claim 5, wherein the registration request further includes a communication address for the callback system, and The one or more processors are further configured to store the communication address in the memory.
7. The authentication server of claim 6, wherein the one or more processors are further configured to: identifying the client identifier based on the authentication request; retrieving the communication address of the callback system based on the client identifier; and The transceiver is caused to transmit the request message to the communication address.
8. A method for authenticating a user, comprising: receiving an authentication request from a user, the authentication request including an authentication credential and an authentication code; comparing the received authentication credentials to stored user authentication credentials to determine if there is a match; transmitting, in response to the determining, a request message to a callback system associated with the user, the request message including the authentication code; receiving a reply message from the callback system in response to the request message, the reply message being one of a success message and a failure message; as well as Access to the user is authorized or denied based on the received reply message.
9. The method of claim 8, wherein the received authentication credentials include a login ID and a password.
10. The method of claim 9, wherein the received authentication credentials further include a client identifier.
11. The method of claim 8, further comprising extracting the authentication code from an HTTP header associated with the authentication request.
12. The method according to claim 8, further comprising: receiving a registration request for registering the client with the authentication server, the registration request including a client identifier; as well as The received client identifier is stored in a memory.
13. The method of claim 12, wherein the registration request further includes a communication address for the callback system, and The request message is transmitted to the communication address.
14. The method according to claim 13, further comprising: identifying the client identifier based on the authentication request; retrieving the communication address of the callback system from the memory based on the client identifier; as well as The request message is transmitted to the communication address in response to the retrieval.
15. A method for providing authentication support to a remote authentication server, the method comprising: Detecting authentication actions performed by users; generating a first authentication code associated with the user; storing the first authentication code and the corresponding expiration time in a memory; receiving a code request from the remote authentication server, the code request including a second authentication code; comparing the received second authentication code with the first authentication code; as well as A reply message indicating success or failure of the code request is transmitted to the remote authentication server based on the comparison.
16. The method according to claim 15, further comprising: determining that the expiration time has passed; as well as The first authentication code is deleted from the memory in response to the determination.
17. The method of claim 15, wherein the comparing determines that the second authentication code does not match the first authentication code, or that the first authentication code has been deleted. The method of claim 17 , wherein the reply message indicates a failure in response to the comparison.
19. The method of claim 15, wherein the comparing determines that the first authentication code matches the second authentication code, and wherein the reply message indicates success in response to the comparison.
20. The method of claim 15, wherein the reply message further includes a status identifier indicating a reason for at least one of success or failure.