User permission verification method supporting multiple login modes

Abstract

This invention discloses a user permission verification method supporting multiple login methods, relating to the field of information security. The method includes: obtaining the account identifier, login method, timestamp, device identifier, and historical login records of the current login request; obtaining the credibility of a single login verification based on the login method, historical usage frequency, and device familiarity; calculating the user verification baseline strength based on the credibility of each login method in the historical login records; analyzing the deviation between the single credibility and the baseline strength to obtain a verification method drift index; calculating the login method transfer risk degree based on the conversion frequency between the previous and current login methods; determining the initial permission level and session timeout threshold based on the drift index and transfer risk degree; and determining whether to re-verify when a high-risk operation request is detected. This invention solves the technical problem that existing permission verification methods are unable to dynamically assess login risk and adaptively adjust permissions by incorporating users' historical login behavior.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a user permission verification method that supports multiple login methods. Background Technology

[0002] With the widespread use of internet applications, users' account information security faces increasingly serious risks, making user permission verification a crucial aspect of ensuring application system security. To balance security and ease of use, application systems typically support multiple login methods, such as username and password login, mobile verification code login, facial recognition login, and third-party account login. After logging in, users are granted corresponding permission levels and are logged out after the session times out.

[0003] However, existing user permission verification methods have the following shortcomings: Login verification usually relies solely on the verification method used for the current login, without considering the security strength of the login method itself or the user's historical usage habits of that login method and device, making it difficult to accurately assess the trustworthiness of the current login; a verification baseline is not established using the user's historical login behavior, making it difficult to promptly identify deviations between login behavior and the user's historical habits, and abnormal drifts in login behavior are difficult to detect; after logging in, users receive a fixed permission level and session timeout threshold, without adaptive adjustments based on login risks. In low-risk scenarios, restricted permissions affect the user experience, while in high-risk scenarios, excessively high permissions pose security risks; and there is a lack of dynamic re-verification mechanisms for high-risk operations after login, making it difficult to cope with permission escalation requirements relying solely on the verification results at login, thus posing a risk of unauthorized operations. Summary of the Invention

[0004] This invention provides a user permission verification method that supports multiple login methods, which solves the technical problem that existing user permission verification methods are unable to dynamically assess login risks and adaptively adjust permission levels and session timeouts based on users' historical login behavior, resulting in insufficient accuracy and security of permission verification.

[0005] This invention provides a user permission verification method that supports multiple login methods, the method including:

[0006] Get the account identifier, login method type, login timestamp, and device identifier of the current login request, and get the historical login records corresponding to the account identifier;

[0007] Based on the current login method type, the frequency of use of the current login method type in historical login records, and the device familiarity of the current device identifier, the credibility of the single login verification for this login is analyzed and obtained.

[0008] Calculate the user verification baseline strength of the account identifier based on the single login verification credibility of each login method type in the historical login records.

[0009] Analyze the deviation between the credibility of a single login verification and the strength of the user verification baseline to obtain the verification method drift index;

[0010] Obtain the previous login method type from the historical login records, and calculate the login method transfer risk level based on the frequency of conditional transitions between the previous login method type and the current login method type in the historical login records;

[0011] Based on the verification method drift index and login method transfer risk level, the initial permission level and session timeout threshold for this login are determined. When a high-risk operation request is detected, it is determined whether to require re-authentication based on the verification method drift index and login method transfer risk level.

[0012] One or more technical solutions provided in this invention have at least the following technical effects or advantages:

[0013] First, by combining the login method type, historical usage frequency, and device familiarity to analyze and obtain the credibility of a single login verification, compared with the existing technology that judges solely based on the current login verification method, this method integrates the security strength of the login method itself with the user's historical usage habits, and more accurately assesses the credibility of the current login.

[0014] Second, by calculating the user verification baseline strength based on historical login records and analyzing the deviation between the credibility of a single login verification and the user verification baseline strength to obtain the verification method drift index, compared with the existing technology that does not establish a user verification baseline, it can identify abnormal drifts in user login behavior and promptly detect deviations between login behavior and historical habits.

[0015] Third, by determining the initial permission level and session timeout threshold based on the verification method drift index and login method transfer risk level, compared with the existing technology where the permission level and session timeout threshold are fixed, the system achieves adaptive adjustment of the permission level and session timeout threshold, balancing the ease of use in low-risk scenarios with the security in high-risk scenarios.

[0016] Fourth, by determining whether to require re-verification based on the verification method drift index and login method transfer risk when a high-risk operation request is detected, the security protection of privilege escalation scenarios after login is enhanced and the risk of unauthorized operations is reduced compared with the lack of dynamic re-verification mechanism in existing technologies. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating a user permission verification method supporting multiple login methods provided in an embodiment of the present invention.

[0019] Figure 2 This is a logic diagram of a user permission verification method supporting multiple login methods provided in an embodiment of the present invention;

[0020] Figure 3 This is a schematic diagram of the re-verification decision process of the user permission verification method supporting multiple login methods provided in the embodiments of the present invention. Detailed Implementation

[0021] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention.

[0022] Examples, such as Figure 1 , Figure 2 , Figure 3 As shown, this invention provides a user permission verification method that supports multiple login methods, including:

[0023] S10: Obtain the account identifier, current login method type, current login timestamp, and current device identifier of the current login request, and obtain the historical login records corresponding to the account identifier;

[0024] Step S10 provided in this embodiment of the invention includes:

[0025] Read the account identifier, current login method type, current login timestamp, and current device identifier from the current login request. The current login method type includes one of the following: account and password login, mobile verification code login, face recognition login, and third-party account login.

[0026] Based on the account identifier, query the login log database for the historical login records corresponding to the account identifier. Each record in the historical login records includes the historical login timestamp, historical login method type, historical login device identifier, and historical login result, which includes success or failure.

[0027] The specific implementation method is as follows:

[0028] The current login request retrieves the account identifier, current login method type, current login timestamp, and current device identifier. The current login request is generated by the client when the user submits the login operation. The account identifier is the account information entered by the user, which can be a mobile phone number, username, or email address. The current login method type is the verification method used for this login, determined by the user's selection, including password login, mobile verification code login, facial recognition login, and third-party account login. The current login timestamp is the time information when the login request was initiated. The current device identifier is a unique identifier of the device initiating the login request, generated and persistently stored by the client when the device is first used. For example, a user uses mobile phone number 138xxxxxxxx as the account identifier, selects facial recognition login, and initiates a login request at 2026-08-26T09:30:15Z, using device identifier DEV-3F8AxxxxxD01.

[0029] Then, based on the account identifier, the historical login records corresponding to that account are retrieved from the login log database. The login log database contains historical login records for all accounts, with one record written for each login event. Each historical login record includes a historical login timestamp, historical login method type, historical login device identifier, and historical login result, which is either success or failure. The authorization verification service uses the account identifier as the query condition to retrieve all historical login records corresponding to that account, sorting them by historical login timestamp for subsequent analysis.

[0030] For example, the five most recent login records corresponding to account identifier 138xxxxxxxx are as follows: 2026-08-24T08:12:30Z Login with username and password, device DEV-3F8AxxxxxD01, successful; 2026-08-20T18:45:00Z Login with mobile verification code, device DEV-3F8AxxxxxD01, successful; 2026-08-18T07:30:45Z Login with username and password, device DEV-5E21xxxxx902, failed; 2026-08-15T21:10:20Z Login with face recognition, device DEV-3F8AxxxxxD01, successful; 2026-08-10T09:00:00Z Login with third-party account, device DEV-3F8AxxxxxD01, successful.

[0031] S20: Analyze and obtain the credibility of a single login verification based on the current login method type, the frequency of use of the current login method type in historical login records, and the device familiarity of the current device identifier;

[0032] Step S20 provided in this embodiment of the invention includes:

[0033] Based on the current login method type, the basic trustworthiness is obtained from the preset login method basic trustworthiness mapping table. The basic trustworthiness is the inherent security strength of the login method type itself. The basic trustworthiness of face recognition login is greater than that of mobile phone verification code login, which is greater than that of account password login, which is greater than that of third-party account login.

[0034] The percentage of successful logins using the current login method in historical login records is used as the frequency of use of the current login method.

[0035] Obtain the preset baseline usage frequency, subtract the baseline usage frequency from the current login method usage frequency, and multiply the difference by the preset frequency adjustment coefficient to obtain the frequency adjustment amount;

[0036] The percentage of successful logins corresponding to the current device identifier in the historical login records is used as a measure of device familiarity.

[0037] Obtain the preset baseline equipment familiarity level, subtract the baseline equipment familiarity level from the current equipment familiarity level, and multiply the difference by the preset equipment adjustment coefficient to obtain the equipment adjustment amount;

[0038] By combining the frequency adjustment amount and the equipment adjustment amount, the credibility of the single login verification for this login is calculated and obtained.

[0039] The specific implementation method is as follows:

[0040] Based on the current login method type, the basic credibility is obtained from a preset login method basic credibility mapping table. This table stores the basic credibility corresponding to each login method type. The basic credibility reflects the inherent security strength of the login method type itself. Based on the probability of abnormal events occurring after logging in using each login method type from historical login behavior data, the basic credibility is calculated as: Basic Credibility = 1 - Abnormal Event Occurrence Rate for that Login Method Type. Abnormal events are those actions that are judged as account theft or unauthorized operation after login. For example, statistical analysis of historical login behavior data shows that the probabilities of abnormal events occurring after facial recognition login, mobile verification code login, account password login, and third-party account login are 0.1, 0.25, 0.4, and 0.5, respectively. The basic credibility of facial recognition login is 1 - 0.1 = 0.9, the basic credibility of mobile verification code login is 1 - 0.25 = 0.75, the basic credibility of account password login is 1 - 0.4 = 0.6, and the basic credibility of third-party account login is 1 - 0.5 = 0.5. The calibration results are consistent with the inherent characteristics of facial recognition login, which is based on biometrics and has the highest anti-counterfeiting capability; mobile verification code login, which relies on SMS channels and dynamic verification codes and has the second highest security strength; account password login, which is susceptible to weak passwords and credential stuffing attacks and has the lowest security strength; and third-party account login, which relies on the security level of third-party platforms and has the lowest security strength. For example, this login uses facial recognition, and the basic credibility score is 0.9.

[0041] The proportion of successful logins using the current login method out of all successful logins in historical login records is used as the frequency of use for the current login method. For example, in the historical login records of account 138xxxxxxxx, there were 4 successful logins, including 1 successful login using facial recognition. The frequency of use for the current login method is 1 ÷ 4 = 0.25. A preset baseline frequency of use is obtained. The current login method frequency is subtracted from the baseline frequency of use, and the difference is multiplied by a preset frequency adjustment coefficient to obtain the frequency adjustment amount. The frequency adjustment amount is used to measure the degree of deviation of the current login method's usage frequency from the account's historical usage level, and is used to adjust the basic credibility accordingly. A positive frequency adjustment amount indicates that the usage frequency is higher than the historical usage level, suggesting that the user is familiar with the method, and credibility should be increased; a negative frequency adjustment amount indicates that the usage frequency is lower than the historical usage level, suggesting that the login method is less common, and credibility should be decreased.

[0042] The baseline usage frequency is a reference frequency used to determine whether a user has developed a habit of using this login method. It is determined by statistically analyzing historical login data for all accounts in the login log database and taking the average usage frequency of this login method type within the database. For example, statistical analysis of historical login data in the login log database shows that the average usage frequencies for account password login, mobile verification code login, facial recognition login, and third-party account login are 0.4, 0.3, 0.2, and 0.1, respectively. Since facial recognition login is used in this instance, the baseline usage frequency is set to 0.2. The frequency adjustment coefficient is the adjustment strength of credibility based on the deviation of the usage frequency from the baseline level. It is determined by the correlation between the deviation of the usage frequency from the baseline level and changes in login risk in historical login behavior statistics. For example, for every 0.1 deviation of the usage frequency from the baseline level, the credibility is adjusted by 10%, and the frequency adjustment coefficient is set to 1.0. The frequency adjustment amount = (0.25 - 0.2) × 1.0 = 0.05.

[0043] The proportion of successful logins for the current device identifier in historical login records is used as the device familiarity level. For example, if device identifier DEV-3F8AxxxxxD01 has successfully logged in 4 times in historical login records, the device familiarity level = 4 ÷ 4 = 1.0. A preset baseline device familiarity level is obtained. This baseline device familiarity level is subtracted from the current device familiarity level, and the difference is multiplied by a preset device adjustment coefficient to obtain the device adjustment amount. The device adjustment amount measures the deviation of the current device familiarity level from the baseline level for that account, and adjusts the basic credibility accordingly. A positive device adjustment amount indicates that the device familiarity level is higher than the baseline, suggesting that the current device is a frequently used device and credibility should be increased; a negative device adjustment amount indicates that the device familiarity level is lower than the baseline, suggesting that the current device is relatively unfamiliar and credibility should be decreased.

[0044] The baseline device familiarity level serves as a reference value for determining whether a device is a frequently used device by the user. It is determined by statistically analyzing historical login data for all accounts in the login log database to calculate the average level of device familiarity for each account. For example, the average level of device familiarity for accounts in the login log database is 0.6, and the baseline device familiarity level is also set to 0.6. The device adjustment coefficient represents the adjustment strength of credibility based on the deviation of device familiarity from the baseline level. It is determined by the correlation between the deviation of device familiarity from the baseline level and changes in login risk in historical login behavior statistics. For example, for every 0.1 deviation of device familiarity from the baseline level, the credibility is adjusted by 5%, and the device adjustment coefficient is set to 0.5. The device adjustment amount = (1.0 - 0.6) × 0.5 = 0.2.

[0045] The credibility of a single login verification is calculated by combining the frequency adjustment and device adjustment amounts. The credibility of a single login verification is calculated as: Credibility of a Single Login Verification = Base Credibility × (1 + Frequency Adjustment Amount + Device Adjustment Amount). Using the base credibility as a benchmark, the frequency adjustment and device adjustment amounts are used to adjust the base credibility from two dimensions: login method usage habits and device familiarity, respectively. This comprehensively reflects the credibility of the current login. The credibility of a single login verification is limited to between zero and one. Values ​​exceeding the upper limit are taken as the upper limit (1), and values ​​below the lower limit are taken as the lower limit (0), ensuring that the credibility value falls within a uniform range for easy comparison with the strength of subsequent user verification baselines. For example, the credibility of a single login verification is calculated as: 0.9 × (1 + (-0.05) + 0.2) = 0.9 × 1.15 = 1.035, which is greater than 1. After the limitation, it is taken as 1.0, and the credibility of the single login verification for this login is 1.0.

[0046] The following technical effects were achieved through this step:

[0047] By combining the basic trustworthiness of the login method, historical usage frequency, and device familiarity to calculate the trustworthiness of a single login verification, this approach integrates the security strength of the login method itself with the user's historical usage habits. Compared to judging solely based on the current login verification method, it more accurately assesses the trustworthiness of the login. By limiting the trustworthiness of a single login verification to between zero and one, the consistency and comparability of trustworthiness values ​​are ensured, providing a unified scale of input for subsequent calculations of user verification baseline strength and verification method drift index.

[0048] S30: Calculate the user verification baseline strength of the account identifier based on the single login verification credibility of each login method type in the historical login records;

[0049] Step S30 provided in this embodiment of the invention includes:

[0050] Select all successful login records within the most recent preset period from the historical login records to form a recent successful login record set;

[0051] For each successful login record in the recent successful login record set, obtain the historical login method type and historical login device identifier corresponding to the successful login record, and calculate the credibility of the historical single login verification corresponding to the successful login record.

[0052] The average login interval is calculated by taking the median of all successful login intervals between two consecutive successful logins in the historical login records.

[0053] Obtain the preset time decay base coefficient, multiply the time decay base coefficient by the time interval between the current login timestamp and the historical login timestamp of the successful login record, and then divide by the historical average login interval to obtain the decay index term;

[0054] The time decay weight of successful login records is calculated based on the decay index term.

[0055] Multiply the historical single login verification credibility of each successful login record by the corresponding time decay weight to obtain the weighted credibility of the successful login record;

[0056] Sum the weighted credibility scores of all successful login records to obtain the total weighted credibility score, and sum the time decay weights of all successful login records to obtain the total weight score;

[0057] By combining the weighted confidence sum and the weight sum, the user verification baseline strength for obtaining account identifiers is calculated.

[0058] The specific implementation method is as follows:

[0059] First, all successful login records within the most recent preset period are selected from the historical login records to form a recent successful login record set. The most recent preset period is the most recent time range for selecting historical login records, determined based on the account's login frequency, and selected as a reasonable time range that can cover the account's recent login behavior characteristics. For example, if the account's login interval is approximately 5 days, the most recent preset period is 30 days, and there are 4 records from the historical login records that are within the most recent 30 days and have a successful login result, this constitutes the recent successful login record set.

[0060] For each successful login record in the recent successful login record set, obtain the historical login method type and historical login device identifier corresponding to the successful login record, and calculate the historical single login verification credibility corresponding to the successful login record according to the method in step S20. The historical single login verification credibility reflects the credibility of the historical successful login. For example, the historical single login verification credibility corresponding to the four records in the recent successful login record set are as follows: 0.62 for account password login record, 0.78 for mobile phone verification code login record, 0.95 for face recognition login record, and 0.55 for third-party account login record.

[0061] The historical average login interval is calculated by taking the median of the time intervals between two consecutive successful logins in the historical login records. This median interval reflects the frequency of successful logins for the account and serves as a benchmark for calculating time decay. A larger historical average login interval indicates a lower login frequency and a smaller decay rate per unit time interval. For example, if the account's four most recent successful logins were on August 10th, 15th, 20th, and 24th, with time intervals of 5 days, 5 days, and 4 days respectively, the median historical average login interval is 5 days.

[0062] The preset time decay base coefficient is obtained. This base coefficient is then multiplied by the time interval between the current login timestamp and the historical login timestamps of successful login records, and divided by the historical average login interval to obtain the decay index. The time decay base coefficient is determined based on the changing rhythm of the account's historical login behavior. The changing rhythm of historical login behavior is characterized by the login behavior change cycle, which is the average time interval between adjacent successful logins where the login method type or device identifier changes in the account's historical login records. The time decay base coefficient matches the duration of the impact of historical login records with the changing rhythm of the account's login behavior. Time decay base coefficient = historical average login interval ÷ login behavior change cycle. For example, if the average time interval between adjacent successful logins where the login method type changes in the account's historical login records is 10 days, the login behavior change cycle is 10 days, and the historical average login interval is 5 days, then the time decay base coefficient = 5 ÷ 10 = 0.5. The decay index is used to measure the relative distance of the historical login record from the current time. The larger the decay index, the further back the record is from the current time, and the smaller its time decay weight. For example, the time interval between the historical login time of 08-24 and the current login time of 08-26 is 2 days, and the attenuation index term = 0.5 × 2 ÷ 5 = 0.2; the time interval between the historical login time of 08-15 and the current login time is 10.5 days, and the attenuation index term = 0.5 × 10.5 ÷ 5 = 1.05.

[0063] The time decay weight of a successful login record is calculated based on the decay exponent, where time decay weight = exp(-decay exponent). The time decay weight measures the contribution of this historical successful login record to the strength of the user verification baseline. A larger time decay weight indicates that the record is closer to the current time and contributes more to the baseline; a smaller time decay weight indicates that the record is older and contributes less to the baseline. For example, for a record with a historical login time of 08-24, the time decay weight = exp(-0.2) = 0.819; for a record with a historical login time of 08-20, the time decay weight = exp(-0.56) = 0.571; for a record with a historical login time of 08-15, the time decay weight = exp(-1.05) = 0.35; and for a record with a historical login time of 08-10, the time decay weight = exp(-1.6) = 0.202.

[0064] The weighted credibility scores of all successful login records are summed to obtain the total weighted credibility score. The time decay weights of all successful login records are then summed to obtain the total weight score. For example, the total weighted credibility score = 0.508 + 0.445 + 0.333 + 0.111 = 1.397, and the total weight score = 0.819 + 0.571 + 0.35 + 0.202 = 1.942.

[0065] Finally, the user verification baseline strength is calculated by combining the weighted credibility sum and the weighted average. User verification baseline strength = weighted credibility sum ÷ weighted average, which is the weighted average of the credibility of each historical successful login record, weighted by time decay, reflecting the baseline level of credibility formed by the account in historical login behavior. For example, user verification baseline strength = 1.397 ÷ 1.942 ≈ 0.719.

[0066] The following technical effects were achieved through this step:

[0067] By weighting the credibility of historical successful login records based on time decay, the user verification baseline strength primarily reflects recent login behavior and weakens the influence of older records. Compared to simply averaging historical credibility, this approach more accurately characterizes the current login credibility benchmark level of the account. By controlling the time decay rate using the historical average login interval as a scale benchmark, the baseline strength becomes adaptive to accounts with different login frequencies, providing a reasonable reference benchmark for subsequent analysis of the deviation between the current login and the baseline, and for obtaining the verification method drift index.

[0068] S40: Analyze the deviation between the credibility of a single login verification and the strength of the user verification baseline to obtain the verification method drift index;

[0069] Step S40 provided in this embodiment of the invention includes:

[0070] Calculate the deviation between the credibility of a single login verification and the strength of the user verification baseline to obtain the verification method drift index, where the verification method drift index is a signed value.

[0071] The specific implementation method is as follows:

[0072] The deviation between the credibility of a single login verification and the strength of the user verification baseline is calculated to obtain the verification method drift index. The verification method drift index = credibility of single login verification - strength of user verification baseline, and is a signed value. The verification method drift index quantifies the degree and direction of deviation of the credibility of this login from the historical baseline level of the account. A positive verification method drift index indicates that the credibility of this single login verification is higher than the strength of the user verification baseline, meaning that a more reliable login method or device was used than the account's historical habits; this is a positive drift, and the login risk is relatively reduced. A negative verification method drift index indicates that the credibility of this single login verification is lower than the strength of the user verification baseline, meaning that a less reliable login method or device was used than the account's historical habits; this is a negative drift, and the login risk is relatively increased. The absolute value of the verification method drift index reflects the degree of deviation; the larger the absolute value, the more significant the deviation of this login from the historical baseline.

[0073] For example, step S20 calculates the single login verification credibility of this login as 1.0, step S30 calculates the user verification baseline strength of the account as 0.719, and the verification method drift index = 1.0 - 0.719 = 0.281, which is a positive number. This means that this login uses face recognition login and uses a common device, and the credibility is higher than the baseline level of the account's historical login behavior. It belongs to positive drift, and the credibility of this login is higher than the account's historical habits.

[0074] In another example, if the login uses a third-party account and the single login verification credibility is 0.55, then the verification method drift index = 0.55 - 0.719 = -0.169, which is negative. This means that the login used a login method that is rarely used in the history of this account and has low security strength. The credibility is lower than the historical baseline, which is a negative drift. The login risk of this login is relatively high.

[0075] The following technical effects were achieved through this step:

[0076] By calculating the deviation between the credibility of a single login verification and the strength of the user verification baseline, the verification method drift index is obtained. The credibility of this login is quantitatively compared with the benchmark level of the account's historical login behavior. This can identify the direction and degree of deviation of this login from historical habits, providing a basis for determining the initial permission level and session timeout threshold, and determining whether re-verification is required.

[0077] S50: Obtain the previous login method type from the historical login records, and calculate the login method transfer risk level based on the conditional conversion frequency between the previous login method type and the current login method type in the historical login records;

[0078] Step S50 provided in this embodiment of the invention includes:

[0079] Select the most recent successful login record from the historical login records, obtain the historical login method type corresponding to the successful login record, and use it as the previous login method type;

[0080] Count the number of successful conversions from the previous login method type to the current login method type in the historical login records, and count the total number of times the previous login method type appears in the historical login records. The number of successful conversions is the number of times the previous login method type appears and the next successful login is with the current login method type.

[0081] Divide the number of successful conversions by the total number of times the above login method type appears to obtain the conditional conversion frequency.

[0082] The risk level of login method switching is calculated based on the frequency of conditional transitions.

[0083] The specific implementation method is as follows:

[0084] First, select the most recent successful login record from the historical login history and obtain the corresponding historical login method type as the previous login method type. The previous login method type is the login method used for the most recent successful login of this account before this login, and is used to determine the starting point of the current login method conversion path. For example, the most recent successful login record for this account was on August 24, 2026, using username and password login, and the previous login method type was username and password login.

[0085] This section counts the number of successful transitions from the previous login method to the current login method in historical login records, and also counts the total number of times the previous login method appeared in historical login records. The successful transition count is the number of times the previous login method appeared in historical login records and the next successful login was also the current login method. This count is used to determine the number of times the account historically used this transition path from the previous login method to the current login method. The total number of times the previous login method appeared is the total number of records in historical login records where the previous login method was used, including both successful and failed records. For example, in the historical login records of this account, the total number of times account / password login appeared was 2, specifically on August 24, 2026, and August 18, 2026. In the successful login sequence of this account, the number of successful transitions starting with account / password login and the next successful login being face recognition login was 0, meaning there are no records of successfully switching from account / password login to face recognition login in the historical login records.

[0086] Divide the number of successful transitions by the total number of times the previous login method type occurred to obtain the conditional transition frequency. The conditional transition frequency reflects how frequently the account has switched from the previous login method type to the current login method in its historical behavior. A higher conditional transition frequency indicates that the account has historically used the path of switching from the previous login method to the current login method more frequently. For example, conditional transition frequency = 0 ÷ 2 = 0.

[0087] Based on the frequency of conditional transitions, the risk level of login method transfer is calculated. The risk level reflects the rarity of the transition path from the previous login method to the current login method. The rarer the transition path, the less frequently the account has used this transition method historically, and the more likely this transition is an abnormal login behavior not performed by the user, thus increasing the risk. The risk level of login method transfer is negatively correlated with the frequency of conditional transitions: Risk level = 1 - Frequency of conditional transitions. For example, a risk level of 1 - 0 = 1 indicates that the account has never historically switched from password login to facial recognition login, making this login a rare occurrence, resulting in a high risk level of login method transfer.

[0088] The following technical effects were achieved through this step:

[0089] By statistically analyzing the frequency of conditional switching from the previous login method to the current login method in historical login records, and calculating the risk level of login method switching accordingly, the commonality of login method switching paths can be quantified as a risk indicator. This allows us to identify whether the login method switching path conforms to the account's historical behavior habits, providing a risk basis for subsequently determining the initial permission level and session timeout threshold.

[0090] S60: Determine the initial permission level and session timeout threshold for this login based on the verification method drift index and login method transfer risk level, and determine whether to require re-authentication when a high-risk operation request is detected based on the verification method drift index and login method transfer risk level.

[0091] Step S60 provided in this embodiment of the invention includes:

[0092] Based on the authentication method drift index and login method transfer risk level, determine the initial permission level and session timeout threshold for this login, including:

[0093] Select all login records within the most recent preset period from the historical login records, count the number of records in all login records where the historical login result was failed, and take the number of recent failed logins as the number of recent failed logins. Divide the number of recent failed logins by the total number of all login records to get the recent login failure rate.

[0094] Based on the sign of the verification method drift index, the verification method drift index is converted into a drift risk component;

[0095] Multiply the login method transfer risk level by a preset transfer risk weighting coefficient, and the resulting product is used as the transfer risk component. Multiply the recent login failure rate by a preset failure rate weighting coefficient, and the resulting product is used as the failure rate component.

[0096] When the verification method drift index is positive, calculate the sum of the transfer risk component and the failure rate component, then subtract the drift risk component, and use the difference as the comprehensive login risk score.

[0097] When the verification method drift index is negative, the sum of the transfer risk component, failure rate component and drift risk component is calculated, and the sum is used as the comprehensive login risk score.

[0098] Obtain the preset permission level mapping rules. The permission level mapping rules divide the value range of the comprehensive login risk score into multiple risk score intervals. Each risk score interval corresponds to an initial permission level. Determine the initial permission level for this login based on the risk score interval into which the comprehensive login risk score falls.

[0099] The baseline session timeout threshold is adjusted based on comprehensive login risk to obtain the session timeout threshold for this login.

[0100] The specific implementation method is as follows:

[0101] The system selects all login records from the historical login history within the most recent preset period, counts the number of records where the login attempt failed, and calculates the recent login failure count. This recent failure count is then divided by the total number of login records to obtain the recent login failure rate. The recent login failure rate reflects the account's recent login failure activity; a higher failure rate indicates more abnormal login attempts and a higher login risk. The preset period is determined based on the account's login frequency, covering a time range that encompasses the account's recent login behavior. For example, if the most recent preset period is 30 days, and the account has 5 historical login records within the last 30 days, with 1 record failing, the recent login failure count = 1, and the recent login failure rate = 1 ÷ 5 = 0.2.

[0102] Based on the sign of the verification method drift index, the verification method drift index is converted into a drift risk component. The drift risk component is used to quantify the verification method drift index as a correction to the overall login risk. Specifically, when the verification method drift index is positive, the credibility of this login is higher than the historical baseline, indicating a positive drift, and the drift risk component serves as a reduction in overall login risk. When the verification method drift index is negative, the credibility of this login is lower than the historical baseline, indicating a negative drift, and the drift risk component serves as an increase in overall login risk. For example, the verification method drift index for this login is 0.281, which is positive. Dividing the verification method drift index by a preset maximum positive drift reference value and multiplying it by a preset positive drift adjustment coefficient yields the positive drift risk reduction, which is used as the drift risk component.

[0103] The maximum positive drift reference value is the maximum positive value of the verification method drift index. Since the credibility of a single login verification and the strength of the user verification baseline are both limited to between zero and one, the maximum positive value of the verification method drift index is 1-0=1, and the maximum positive drift reference value is 1. The positive drift adjustment coefficient is the strength of the reduction in overall login risk caused by positive drift. It is determined based on the correlation between the degree of positive drift and the incidence of abnormal operations after login in historical login behavior statistics. For example, when the verification method drift index reaches the maximum positive value of 1, the probability of abnormal operations after login is reduced by 30% compared to the historical baseline. The positive drift adjustment coefficient is 0.3, so that the drift risk component corresponding to the maximum positive drift = 1 ÷ 1 × 0.3 = 0.3, that is, the overall login risk score is reduced by a maximum of 0.3. Drift risk component = 0.281 ÷ 1.0 × 0.3 = 0.084.

[0104] The risk level of login method transfer is multiplied by a preset transfer risk weighting coefficient, and the resulting product is taken as the transfer risk component. Similarly, the recent login failure rate is multiplied by a preset failure rate weighting coefficient, and the resulting product is taken as the failure rate component. The transfer risk component quantifies the contribution of the rarity of login method switching paths to the overall login risk, while the failure rate component quantifies the contribution of recent login failures to the overall login risk. The transfer risk weighting coefficient and the failure rate weighting coefficient are determined based on the degree of influence of each risk factor on the overall login risk. Regression analysis is performed using the overall login risk score for each login in historical login behavior data as the dependent variable, and the login method transfer risk level and recent login failure rate as independent variables to obtain the influence weights of the login method transfer risk level and recent login failure rate on the overall login risk. For example, after regression analysis on historical login behavior data, the influence weight of the login method transfer risk level on the overall login risk is 0.4, the influence weight of the recent login failure rate on the overall login risk is 0.3, the transfer risk weighting coefficient is 0.4, the failure rate weighting coefficient is 0.3, and the sum of the weights of all risk factors is 1. Risk transfer component = 1.0 × 0.4 = 0.4, failure rate component = 0.2 × 0.3 = 0.06.

[0105] When the verification method drift index is positive, the sum of the transfer risk component and the failure rate component is calculated, and then the drift risk component is subtracted. The difference is used as the comprehensive login risk score. The comprehensive login risk score is used to comprehensively quantify the overall risk level of this login. The transfer risk component and the failure rate component reflect the sources of increased risk, while the drift risk component reflects the sources of reduced risk when drifting positively. For example, when the verification method drift index is positive, the comprehensive login risk score = 0.4 + 0.06 - 0.084 = 0.376. When the verification method drift index is negative, the sum of the transfer risk component, the failure rate component, and the drift risk component is calculated, and the sum is used as the comprehensive login risk score. For example, if the verification method drift index is -0.169, the absolute value of the verification method drift index is divided by a preset maximum negative drift reference value and multiplied by a preset negative drift adjustment coefficient to obtain the amount of negative drift risk increase, which is used as the drift risk component.

[0106] The maximum negative drift reference value is the maximum negative value of the verification method drift index. Since the credibility of a single login verification and the strength of the user verification baseline are both limited to between zero and one, the maximum absolute negative value of the verification method drift index is the absolute value of 0-1, i.e., 1. Therefore, the maximum negative drift reference value is 1. The negative drift adjustment coefficient represents the degree of risk increase that negative drift brings to the overall login risk. It is determined based on the correlation between the degree of negative drift and the incidence of abnormal operations after login in historical login behavior statistics. For example, when the verification method drift index reaches its maximum negative value, the probability of abnormal operations occurring after login is 50% higher than the historical baseline, and the negative drift adjustment coefficient is 0.5. Since negative drift represents a risk scenario where credibility is lower than the historical baseline, its risk increase is greater than the risk reduction of positive drift. Therefore, the negative drift adjustment coefficient of 0.5 is greater than the positive drift adjustment coefficient of 0.3. Drift risk component = 0.169 ÷ 1.0 × 0.5 = 0.085, Comprehensive login risk score = 0.4 + 0.06 + 0.085 = 0.545.

[0107] The system retrieves preset permission level mapping rules and determines the initial permission level for this login based on the risk score range into which the comprehensive login risk score falls. The permission level mapping rules divide the comprehensive login risk score range into multiple risk score ranges, each corresponding to an initial permission level. The rules are set according to the correspondence between the comprehensive login risk score and the required permission level; the higher the comprehensive login risk score, the greater the login risk, and the lower the assigned initial permission level. The permission level mapping rules are also set based on the changing characteristics of the incidence rate of risk events within different comprehensive login risk score ranges in historical login behavior statistics. For example, statistical analysis of historical login data shows that when the comprehensive login risk score is below 0.3, the probability of a risk event occurring after login is low; between 0.3 and 0.6, the probability is moderate; and above 0.6, the probability significantly increases. Therefore, the comprehensive login risk score range is divided into three risk score ranges: [0, 0.3), [0.3, 0.6), and [0.6, 1], corresponding to initial permission levels 3, 2, and 1, respectively. The overall login risk score for this login is 0.376, which falls within the range of [0.3, 0.6). The initial permission level is set to 2.

[0108] The baseline session timeout threshold is adjusted based on the overall login risk to obtain the session timeout threshold for this login. The session timeout threshold limits the effective duration of the current login session; the higher the overall login risk, the lower the session timeout threshold, thus reducing the session duration of high-risk logins. The baseline session timeout threshold is the session timeout benchmark value under no-risk adjustment conditions, determined based on the statistical analysis of the duration of historical login sessions for this account, taking the average of the historical login session durations. For example, if the average duration of historical login sessions for this account is 30 minutes, the baseline session timeout threshold is set to 30 minutes. The session timeout threshold = 30 × (1 - 0.376) = 18.72 minutes, and the session timeout threshold for this login is 18.72 minutes.

[0109] Step S60 provided in this embodiment of the invention further includes:

[0110] When a high-risk operation request is detected, a decision is made on whether to require re-authentication based on the authentication method drift index and the login method transfer risk level, including:

[0111] During this login session, monitor the user's operation requests and obtain the minimum permission level required for the operation requests;

[0112] When the minimum permission level required for an operation request is higher than the initial permission level for this login, the operation request will be judged as a high-risk operation request.

[0113] The verification method drift index and login method transfer risk of this login are input into the pre-built re-verification decision model, and the re-verification decision model outputs the probability of requiring re-verification;

[0114] Get the preset re-verification probability threshold. When the probability of requiring re-verification is greater than the re-verification probability threshold, require the user to re-verify through strong verification. After successful re-verification, temporarily upgrade the permission level to the minimum permission level required for the operation request.

[0115] When the probability of requiring re-authentication is less than or equal to the re-authentication probability threshold, the permission level is temporarily raised to the minimum permission level required for the operation request, allowing the user to continue executing the operation request, and the session timeout threshold for this login is temporarily updated to the temporary session timeout threshold.

[0116] Temporary session timeout threshold and comprehensive login risk score are negatively correlated.

[0117] This includes re-validating the pre-built decision model, including:

[0118] Obtain multiple historical high-risk operation request samples. Each historical high-risk operation request sample includes the verification method drift index, login method transfer risk degree, and whether the historical high-risk operation request was ultimately identified as an attack behavior.

[0119] A logistic regression model is constructed as the revalidation decision model. The model inputs are the validation method drift index and the login method transfer risk degree, and the model output is the probability of requiring revalidation.

[0120] Using the labeled results as output labels, and minimizing the cross-entropy loss between the model output probability and the output label as the training objective, the parameters of the logistic regression model are iteratively updated until the cross-entropy loss converges, resulting in a pre-built re-validation decision model.

[0121] The specific implementation method is as follows:

[0122] During this login session, the system monitors user-initiated operation requests and obtains the minimum permission level required for each request. The minimum permission level required for an operation request is the lowest level of permission needed to execute that request, used to determine if the current initial permission level is sufficient to perform the operation. For example, if a user initiates a request to change their account password during this login session, the minimum permission level required for this request is 3. When the minimum permission level required for an operation request is higher than the initial permission level for this login session, the operation request is considered a high-risk request. For example, if the initial permission level for this login session is 2, and the minimum permission level required for the operation request is 3, since 3 is greater than 2, the request to change the account password is considered a high-risk request.

[0123] The verification method drift index and login method transfer risk level of this login session are input into a pre-built re-verification decision model. The re-verification decision model outputs the probability of requiring re-verification. This model predicts whether re-verification is required for high-risk operations based on the verification method drift index and login method transfer risk level. A higher probability of requiring re-verification indicates a higher risk level for the current login status and a greater need for re-verification. For example, inputting a verification method drift index of 0.281 and a login method transfer risk level of 1.0 into the re-verification decision model results in an output probability of 0.75 requiring re-verification.

[0124] The pre-construction process of the re-verification decision model is as follows: Multiple historical high-risk operation request samples are obtained. Each sample includes the verification method drift index, login method transfer risk level, and whether the historical high-risk operation request was ultimately judged as an attack. A total of 500 historical high-risk operation request samples are obtained. Each sample records the verification method drift index and login method transfer risk level at the time of the request, and is labeled according to whether the request was ultimately judged as an attack: attack behavior is labeled as 1, and normal behavior is labeled as 0. A logistic regression model is constructed as the re-verification decision model. The model input is the verification method drift index and login method transfer risk level, and the model output is the probability of requiring re-verification. The output probability of the logistic regression model is 1 ÷ {1 + exp[-(w1 × verification method drift index + w2 × login method transfer risk level + b)]}, where w1, w2, and b are model parameters. Cross-entropy loss = Where N is the number of samples, y i For the labeling result of the i-th sample, attack behavior is labeled as 1 and normal behavior is labeled as 0, p i The cross-entropy loss represents the probability of revalidating the model's output for the i-th sample. A smaller cross-entropy loss indicates that the model's output probability is more consistent with the true label. The parameters w1, w2, and b of the logistic regression model are iteratively updated until the cross-entropy loss converges, resulting in a pre-built revalidation decision model.

[0125] A preset re-verification probability threshold is obtained. When the probability of requiring re-verification exceeds this threshold, the user is required to re-verify using strong authentication. Upon successful re-verification, the user's privilege level is temporarily elevated to the minimum privilege level required for the operation request. The re-verification probability threshold is determined based on the correlation between the probability of re-verification requests in historical high-risk operation requests and the attack interception rate and the normal operation false interception rate, selecting a value that results in a high attack interception rate and a low normal operation false interception rate. For example, statistical analysis of historical high-risk operation requests shows that when the re-verification probability threshold is 0.5, the attack interception rate reaches 95%, and the proportion of normal operations requiring re-verification is 8%, achieving a balance between interception effectiveness and user experience. Therefore, the re-verification probability threshold is set to 0.5. For example, if the probability of requiring re-verification is 0.75, which is greater than the re-verification probability threshold of 0.5, the user is required to re-verify using facial recognition. Upon successful re-verification, the user's privilege level is temporarily elevated to the minimum privilege level 3 required for the operation request, allowing the user to execute a request to change their account password.

[0126] When the probability of requiring re-authentication is less than or equal to the re-authentication probability threshold, the privilege level is temporarily elevated to the minimum privilege level required for the operation request, allowing the user to continue executing the operation request, and the session timeout threshold for this login is temporarily updated to the temporary session timeout threshold. The temporary session timeout threshold is negatively correlated with the comprehensive login risk score; the higher the comprehensive login risk score, the smaller the temporary session timeout threshold. That is, in the case of temporarily elevating privileges, the risk brought about by the privilege elevation is reduced by shortening the session timeout time. The temporary session timeout threshold is determined based on the baseline session timeout threshold and the comprehensive login risk score. For example, if the probability of requiring re-authentication is 0.4, which is less than the re-authentication probability threshold of 0.5, then the privilege level is temporarily elevated to the minimum privilege level 3 required for the operation request. The temporary session timeout threshold = baseline session timeout threshold × (1 - comprehensive login risk score) = 30 × (1 - 0.376) = 18.72 minutes, and the session timeout threshold for this login is temporarily updated to 18.72 minutes.

[0127] The following technical effects were achieved through this step:

[0128] The initial permission level and session timeout threshold are determined based on the verification method drift index and login method transfer risk. This allows the permission level and session timeout threshold to adaptively adjust with login risk. Low-risk logins receive higher permissions and longer session timeouts to improve user experience, while high-risk logins receive lower permissions and shorter session timeouts to reduce security risks. When a high-risk operation request is detected, a re-verification decision model determines whether re-verification is required. When temporarily elevating permissions, the session timeout is shortened based on the overall login risk, balancing the convenience and security of permission escalation while reducing the risk of unauthorized operations.

Claims

1. A user permission verification method that supports multiple login methods, characterized in that, include: Obtain the account identifier, login method type, login timestamp, and device identifier of the current login request, and obtain the historical login records corresponding to the account identifier; Based on the current login method type, the frequency of use of the current login method type in the historical login records, and the device familiarity of the current device identifier, the credibility of the single login verification for this login is analyzed and obtained. Based on the single login verification credibility corresponding to each login method type in the historical login records, calculate the user verification baseline strength of the account identifier; Analyze the deviation between the credibility of the single login verification and the strength of the user verification baseline in this login session to obtain the verification method drift index; Obtain the previous login method type from the historical login records, and calculate the login method transfer risk degree based on the conditional switching frequency between the previous login method type and the current login method type in the historical login records; Based on the verification method drift index and the login method transfer risk level, the initial permission level and session timeout threshold for this login are determined. When a high-risk operation request is detected, it is determined whether to require re-verification based on the verification method drift index and the login method transfer risk level.

2. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The step of obtaining the account identifier, current login method type, current login timestamp, and current device identifier of the current login request, and obtaining the historical login records corresponding to the account identifier, includes: Read the account identifier, current login method type, current login timestamp, and current device identifier from the current login request. The current login method type includes one of the following: account password login, mobile verification code login, face recognition login, and third-party account login. Based on the account identifier, query the login log database for the historical login records corresponding to the account identifier. Each record in the historical login records includes a historical login timestamp, a historical login method type, a historical login device identifier, and a historical login result, which includes success or failure.

3. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The step of analyzing and obtaining the single login verification credibility based on the current login method type, the frequency of use of the current login method type in the historical login records, and the device familiarity of the current device identifier includes: Based on the current login method type, the basic credibility is obtained from the preset login method basic credibility mapping table, wherein the basic credibility is the inherent security strength of the login method type itself, and the basic credibility of face recognition login is greater than that of mobile phone verification code login, which is greater than that of account password login, which is greater than that of third-party account login. The proportion of successful logins corresponding to the current login method type in the historical login records is used as the frequency of use of the current login method. Obtain a preset baseline usage frequency, subtract the baseline usage frequency from the current login method usage frequency, and multiply the difference by a preset frequency adjustment coefficient to obtain the frequency adjustment amount; The percentage of successful logins corresponding to the current device identifier in the historical login records is used as the device familiarity rate. Obtain a preset baseline equipment familiarity level, subtract the baseline equipment familiarity level from the equipment familiarity level, and multiply the difference by a preset equipment adjustment coefficient to obtain the equipment adjustment amount; By combining the frequency adjustment amount and the device adjustment amount, the credibility of a single login verification is calculated and obtained.

4. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The step of calculating the user verification baseline strength of the account identifier based on the single login verification credibility corresponding to each login method type in the historical login records includes: Select all successful login records within the most recent preset period from the historical login records to form a recent successful login record set; For each successful login record in the recent successful login record set, obtain the historical login method type and historical login device identifier corresponding to the successful login record, and calculate the historical single login verification credibility corresponding to the successful login record. The time interval between two consecutive successful logins in the historical login records is counted, and the median of all time intervals is taken as the historical average login interval. Obtain a preset time decay base coefficient, multiply the time decay base coefficient by the time interval between the current login timestamp and the historical login timestamp of the successful login record, and then divide by the historical average login interval to obtain the decay index term; The time decay weight of the successful login record is calculated based on the decay index term. The weighted credibility of each successful login record is obtained by multiplying the historical single login verification credibility by the corresponding time decay weight. Sum the weighted credibility scores of all successful login records to obtain the total weighted credibility score, and sum the time decay weights of all successful login records to obtain the total weight score; By combining the weighted confidence sum and the weight sum, the user verification baseline strength of the account identifier is calculated.

5. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The analysis of the deviation between the credibility of the single login verification and the strength of the user verification baseline in this login session, and the acquisition of the verification method drift index, includes: Calculate the deviation between the credibility of the single login verification and the strength of the user verification baseline to obtain the verification method drift index, wherein the verification method drift index is a signed value.

6. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The step of obtaining the previous login method type from the historical login records and calculating the login method transfer risk level based on the frequency of conditional transitions between the previous login method type and the current login method type in the historical login records includes: Select the most recent successful login record from the historical login records, obtain the historical login method type corresponding to the successful login record, and use it as the previous login method type; The number of successful conversions from the previous login method type to the current login method type in the historical login records is counted, and the total number of times the previous login method type appears in the historical login records is counted. The number of successful conversions is the number of times the previous login method type appears and the next successful login is of the current login method type. Divide the number of successful conversions by the total number of times the previous login method type appeared to obtain the conditional conversion frequency. Based on the aforementioned condition switching frequency, the risk level of login method transfer is calculated.

7. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, The step of determining the initial permission level and session timeout threshold for this login based on the verification method drift index and the login method transfer risk level includes: Select all login records within the most recent preset period from the historical login records, count the number of records in the all login records where the historical login result was failed, and take the number of recent failed logins as the number of recent failed logins. Divide the number of recent failed logins by the total number of all login records to obtain the recent login failure rate. Based on the sign of the drift index of the verification method, the drift index of the verification method is converted into a drift risk component; The risk level of the login method is multiplied by a preset transfer risk weighting coefficient, and the resulting product is used as the transfer risk component. The recent login failure rate is multiplied by a preset failure rate weighting coefficient, and the resulting product is used as the failure rate component. When the verification method drift index is positive, calculate the sum of the transfer risk component and the failure rate component, then subtract the drift risk component, and use the difference as the comprehensive login risk score. When the verification method drift index is negative, the sum of the transfer risk component, the failure rate component, and the drift risk component is calculated, and the resulting sum is used as the comprehensive login risk score. Obtain a preset permission level mapping rule, which divides the value range of the comprehensive login risk score into multiple risk score intervals. Each risk score interval corresponds to an initial permission level. Determine the initial permission level for this login based on the risk score interval into which the comprehensive login risk score falls. The baseline session timeout threshold is corrected using the comprehensive login risk to obtain the session timeout threshold for this login.

8. The user permission verification method supporting multiple login methods according to claim 1, characterized in that, When a high-risk operation request is detected, determining whether to require re-verification based on the verification method drift index and the login method transfer risk level includes: During this login session, monitor the user's operation requests and obtain the minimum permission level required for those operation requests; When the minimum permission level required for the operation request is higher than the initial permission level of this login, the operation request is determined to be a high-risk operation request. The verification method drift index and login method transfer risk of this login are input into a pre-built re-verification decision model, and the re-verification decision model outputs the probability of requiring re-verification; Obtain a preset re-verification probability threshold. When the probability of requiring re-verification is greater than the re-verification probability threshold, require the user to re-verify through strong verification. After successful re-verification, temporarily upgrade the user's permission level to the minimum permission level required for the operation request. When the probability of requiring re-authentication is less than or equal to the re-authentication probability threshold, the permission level is temporarily raised to the minimum permission level required for the operation request, allowing the user to continue executing the operation request, and the session timeout threshold for this login is temporarily updated to the temporary session timeout threshold.

9. The user permission verification method supporting multiple login methods according to claim 8, characterized in that, The temporary session timeout threshold and the comprehensive login risk score are negatively correlated.

10. The user permission verification method supporting multiple login methods according to claim 8, characterized in that, The pre-construction of the re-validation decision model includes: Multiple historical high-risk operation request samples are obtained. Each historical high-risk operation request sample includes the verification method drift index, login method transfer risk degree, and whether the historical high-risk operation request is ultimately identified as an attack behavior. A logistic regression model is constructed as the revalidation decision model. The model inputs are the validation method drift index and the login method transfer risk degree, and the model output is the probability of requiring revalidation. Using the labeled results as output labels, and minimizing the cross-entropy loss between the model output probability and the output labels as the training objective, the parameters of the logistic regression model are iteratively updated until the cross-entropy loss converges, thus obtaining a pre-built re-validation decision model.

Images