Cross-domain identity authentication method based on multilevel identity alliance

Abstract

The invention discloses a cross-domain identity authentication method based on a multistage identity alliance, and relates to the technical field of identity authentication, a user tries to access a resource, an identity provider generates an identity token, the identity of the user is verified through a corresponding process, the identity provider issues the identity token after successfully verifying the identity of the user, and the identity authentication is completed. The identity token comprises safety information related to the identity of the user, when the user uses the identity token to access resources of other domains, the identity token is exchanged into an access token for the domain, and after receiving the access token, a resource provider verifies the legality of the token and performs access control on the user based on declaration information in the token. And on the basis of a token resuming mechanism, the user continues scheme resources. According to the authentication method, the secure identity token and the token exchange mechanism are used, fine control over the resources is achieved, it is ensured that only legal users can access the corresponding resources, the security of the system is effectively improved, and the risks of identity information leakage, counterfeiting, tampering and the like are prevented.

Description

Technical Field

[0001] The present invention relates to the technical field of identity authentication, and in particular to a cross-domain identity authentication method based on a multi-level identity alliance. Background Art

[0002] Cross-origin-identity-federation refers to establishing a trust relationship between different domains to achieve user authentication and access control in these domains. In the Internet environment, users may need to access resources in multiple domains, for example, seamlessly switch between multiple websites through single sign-on (SSO) without re-entering credentials;

[0003] The prior art has the following defects:

[0004] The existing authentication method only opens the corresponding permissions after authenticating the user during the cross-domain identity authentication process. However, this authentication method is rough and cannot improve the security of the system. It is easy to cause risks such as identity information leakage, forgery and tampering. Summary of the invention

[0005] The purpose of the present invention is to provide a cross-domain identity authentication method based on multi-level identity alliance to solve the shortcomings of the background technology.

[0006] In order to achieve the above object, the present invention provides the following technical solution: a cross-domain identity authentication method based on a multi-level identity alliance, the authentication method comprising the following steps:

[0007] Establish identity providers in a multi-level identity federation. Each participant's identity provider is registered and provides relevant metadata during the registration process.

[0008] Identity providers exchange metadata to establish mutual trust. The metadata includes encryption algorithms, signature algorithms, and trust chain information.

[0009] The user authenticates through the identity provider. When the user tries to access a resource, the identity provider generates an identity token and authenticates the user through the corresponding process.

[0010] After the identity provider successfully verifies the user's identity, it issues an identity token, which includes security information about the user's identity;

[0011] When a user uses an identity token to access resources in another domain, the identity token is exchanged for an access token for that domain.

[0012] After receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to access solution resources based on the token renewal mechanism.

[0013] Preferably, an identity provider is established in a multi-level identity federation, and the identity provider of each participant is registered and provides relevant metadata during the registration process, including the following steps:

[0014] The identity provider of the participating party sends a registration request to the registration center of the identity alliance, which contains basic information about the identity provider, including domain name, public key, supported encryption algorithm, and trust level. After receiving the registration request, the registration center of the identity alliance verifies the legitimacy of the request and generates metadata of the identity provider based on the verified registration request, including the endpoint address of the identity provider, supported identity authentication protocols, and trust chain information. The user signs the generated metadata and publishes the signed metadata to the metadata storage of the identity alliance or the public metadata endpoint.

[0015] Preferably, exchanging metadata between identity providers to establish a mutual trust relationship includes the following steps:

[0016] An identity provider initiates a metadata request to another identity provider, requesting the other party's metadata information. The requested party generates metadata about itself, including supported encryption algorithms, signature algorithms, and trust chain information. The requested party passes the generated metadata to the requesting party through direct transmission and secure communication channels. After receiving the metadata, the requesting party verifies the validity of the metadata, including checking the legitimacy of the digital signature and the integrity of the metadata. If the metadata contains trust chain information, the requesting party needs to verify the trust chain to ensure that the requested party is a trusted identity provider, including verifying the digital certificate and the certificate authority. After the verification is successful, the requesting party and the requested party establish a trust relationship.

[0017] Preferably, the user is authenticated by an identity provider. When the user attempts to access a resource, the identity provider generates an identity token and authenticates the user through a corresponding process, including the following steps:

[0018] The user sends an authentication request to the identity provider, including the credentials provided by the user. After receiving the authentication request, the identity provider verifies the credentials provided by the user. If the credentials provided by the user are verified, the identity provider generates an identity token containing information about the user's identity. The identity token includes the user's unique identifier, access rights, and token expiration time information. The identity provider uses its own private key to sign the generated identity token. The identity provider passes the signed identity token to the user and directly passes it to the user's application through a secure channel or through redirection. The user's application stores the identity token in a secure location. When the user's application requests access to resources from the resource provider, it attaches the identity token to the request. The resource provider verifies the user's identity and permissions through the token. If the identity token has an expiration time, the user's application obtains a new token before the token expires.

[0019] Preferably, after the identity provider successfully verifies the user's identity, it issues an identity token, which includes security information about the user's identity, including the following steps:

[0020] The identity provider uses a secure method to generate an identity token. The identity token contains information about the user's identity, including the user's unique identifier, role, permissions, and access scope. The identity provider uses its own private key to sign the generated identity token. When the token is transmitted over an untrusted channel, the identity provider chooses to encrypt the token. The identity provider passes the signed identity token to the user, directly to the user's application, and through redirection, when the user's application needs to access resources, the token is attached to the resource request. After the resource server receives the request containing the identity token, it first verifies the signature and integrity of the token. If the verification passes, the resource server parses the declaration information in the token and decides whether to allow the user to access the resource based on this information.

[0021] Preferably, when a user uses an identity token to access resources in another domain, exchanging the identity token for an access token for the domain includes the following steps:

[0022] The user's application initiates a resource request to the resource provider of the target domain, including carrying the user's identity token. The user's application attaches the user's identity token to the resource request and sends the request to the resource provider of the target domain. After receiving the request, the resource provider of the target domain first verifies the user's identity token, which involves the steps of signature verification and expiration time check of the token. If the identity token verification passes, the resource provider parses the declaration information in the identity token, obtains the user's identity information and related permissions and access scopes. If the resource provider of the target domain supports token exchange, the resource provider will initiate a token exchange request and request an access token for the domain from the identity provider. After receiving the token exchange request, the identity provider of the target domain verifies the user's identity token. If the identity token verification passes, the identity provider generates an access token for the target domain, which contains the user's identity information and access rights in the target domain. The identity provider passes the generated access token to the resource provider of the target domain. After receiving the access token, the resource provider of the target domain verifies the validity of the token, parses the declaration information in the token, and decides whether to allow the user to access the resource based on this information.

[0023] Preferably, after receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to use the solution resources based on the token renewal mechanism, including the following steps:

[0024] The resource provider first verifies the received access token, including checking whether the signature of the token is valid, whether the token is expired, and the integrity of the token. If the token verification fails, the access request is rejected. If the token verification passes, the resource provider parses the declaration information in the token, including the user's identity, permissions, and access scope information, for subsequent access control decisions. Based on the parsed declaration information, the resource provider makes access control decisions, including determining whether the user has permission to access specific resources and whether additional authorization verification is required during the access process. If the access control decision passes, the resource provider allows the user to access the requested resources, returns the requested resource data to the user, or performs corresponding operations. If the access token contains renewal information, the resource provider decides whether to renew the token based on the renewal mechanism, regularly initiates token renewal requests to the identity provider, or ensures that the validity of the token is maintained through other means.

[0025] Preferably, after receiving the token exchange request, the identity provider of the target domain verifies the identity token of the user, and if the identity token verification passes, the identity provider generates an access token for the target domain, including the following steps: after receiving the token exchange request, the identity provider of the target domain obtains the token structure integrity, token expiration index, identity consistency index and digital signature index of the user's identity token;

[0026] The token coefficient is obtained by comprehensively calculating the token structure integrity, token expiration index, identity consistency index and digital signature index. The expression is:

[0027] Where lpx is the token coefficient, gqz is the token expiration index, jgw, fsz, szq are the token structure integrity, identity consistency index and digital signature index respectively, α, β, γ are the proportional coefficients of the token structure integrity, identity consistency index and digital signature index respectively, and α, β, γ are all greater than 0;

[0028] From the calculation expression of the token coefficient, it can be seen that the larger the token coefficient is, the higher the quality of the user's identity token is. Therefore, after obtaining the user's token coefficient, the token coefficient is compared with the verification threshold;

[0029] If the token coefficient is greater than or equal to the verification threshold, it is determined that the user's identity token has passed the verification;

[0030] If the token coefficient is less than the verification threshold, it is determined that the user's identity token has not passed the verification.

[0031] In the above technical solution, the technical effects and advantages provided by the present invention are:

[0032] 1. The present invention establishes a mutual trust relationship by exchanging metadata between identity providers. The metadata includes encryption algorithm, signature algorithm, and trust chain information. Users authenticate their identities through identity providers. When users try to access resources, identity providers generate identity tokens and authenticate users through corresponding processes. After the identity provider successfully verifies the user's identity, it issues an identity token. The identity token includes security information about the user's identity. When the user uses the identity token to access resources in other domains, the identity token is exchanged for an access token for the domain. After receiving the access token, the resource provider verifies the legitimacy of the token and controls the user's access based on the declaration information in the token, and allows the user to continue to use the program resources based on the token renewal mechanism. This authentication method uses a secure identity token and a token exchange mechanism, and realizes refined control of resources, ensuring that only legitimate users can access corresponding resources, effectively improving the security of the system, and preventing risks such as identity information leakage, forgery, and tampering.

[0033] 2. After receiving the token exchange request through the identity provider of the target domain, the present invention obtains the token structure integrity, token expiration index, identity consistency index and digital signature index of the user's identity token, comprehensively calculates the token structure integrity, token expiration index, identity consistency index and digital signature index to obtain the token coefficient, and determines whether the user's identity token has passed the verification based on the comparison result of the token coefficient and the verification threshold. The comprehensive analysis method is conducive to improving the accuracy of token verification, and determining whether the user's identity token has passed the verification based on the comparison result of the token coefficient and the verification threshold can effectively ensure secure transactions between users. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0035] Figure 1 The figure is a flow chart of the method of the present invention. DETAILED DESCRIPTION

[0036] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0037] Example: See Figure 1 As shown, the cross-domain identity authentication method based on multi-level identity alliance described in this embodiment includes the following steps:

[0038] Establish identity providers in a multi-level identity federation. Each participant's identity provider is registered and provides relevant metadata during the registration process.

[0039] Identity providers exchange metadata to establish mutual trust. The metadata includes encryption algorithms, signature algorithms, and trust chain information.

[0040] The user authenticates through the identity provider. When the user tries to access a resource, the identity provider generates an identity token and authenticates the user through the corresponding process.

[0041] After the identity provider successfully verifies the user's identity, it issues an identity token, which includes security information about the user's identity;

[0042] When a user uses an identity token to access resources in another domain, the identity token is exchanged for an access token for that domain.

[0043] After receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to access solution resources based on the token renewal mechanism.

[0044] In a multi-level identity alliance, the first thing to do is to establish an identity provider. Each participant's identity provider must be registered, and during the registration process, relevant metadata, such as public key, trust level, etc., must be provided. Identity providers need to exchange metadata to establish a mutual trust relationship. Metadata usually includes information such as encryption algorithm, signature algorithm, trust chain, etc. Users authenticate through identity providers. When a user tries to access a resource, the identity provider generates an identity token and authenticates the user through an appropriate process. After the identity provider successfully verifies the user's identity, it issues an identity token. The token contains a statement about the user's identity, as well as a signature and other security information. When a user tries to access resources in other domains with an identity token, the identity token needs to be exchanged for an access token for that domain. After receiving the access token, the resource provider verifies the legitimacy of the token and controls the user's access based on the declaration information in the token. Considering the situation where users access resources for a long time, a token renewal or refresh mechanism is designed to ensure the user's continuous access experience.

[0045] This application establishes a mutual trust relationship by exchanging metadata between identity providers. The metadata includes encryption algorithms, signature algorithms, and trust chain information. Users authenticate through identity providers. When users try to access resources, identity providers generate identity tokens and authenticate users through corresponding processes. After the identity provider successfully verifies the user's identity, it issues an identity token. The identity token includes security information about the user's identity. When the user uses the identity token to access resources in other domains, the identity token is exchanged for an access token for the domain. After receiving the access token, the resource provider verifies the legitimacy of the token and controls user access based on the declaration information in the token, and allows users to continue to use the program resources based on the token renewal mechanism. This authentication method uses secure identity tokens and token exchange mechanisms, and implements refined control of resources, ensuring that only legitimate users can access corresponding resources, effectively improving the security of the system, and preventing risks such as identity information leakage, forgery, and tampering.

[0046] To establish identity providers in a multi-level identity federation, each participant's identity provider is registered and provides relevant metadata during the registration process, including the following steps:

[0047] Registration request: The identity provider of the participating party sends a registration request to the registration center of the identity alliance, which contains basic information about the identity provider, such as domain name, public key, supported encryption algorithms, trust level, etc.

[0048] Registration center verification: After receiving the registration request, the registration center of the identity alliance verifies the legitimacy of the request to ensure that the request comes from a legitimate identity provider and contains the necessary information.

[0049] Metadata generation: The registration center generates metadata for the identity provider based on the verified registration request, including the endpoint address of the identity provider, supported authentication protocols, trust chain, etc. Metadata is an important basis for other participants to understand the identity provider.

[0050] Metadata signature: The generated metadata needs to be signed to ensure the integrity of the metadata and the credibility of the source. The registration center uses the private key to sign the metadata, and other identity providers can use the corresponding public key to verify the validity of the signature.

[0051] Metadata publishing:

[0052] The registry publishes the signed metadata to the identity federation's metadata storage or public metadata endpoint so that other identity providers can retrieve and understand the identity provider's information.

[0053] Metadata update mechanism: Design a metadata update mechanism to ensure that when the identity provider's information changes, other participants can obtain the latest metadata in a timely manner. This can be achieved through regular updates, event triggers, or other mechanisms.

[0054] Trust chain establishment of metadata: Trust chain information can be included in metadata to build a trust relationship between participants. This can involve the certificate authority (CA) or other trust mechanisms of each party.

[0055] Registration result notification: The registration center sends a notification of successful registration to the identity provider, including information such as the storage location of the metadata and the update mechanism, so that the identity provider can cooperate with other participants in the subsequent process.

[0056] Identity providers exchange metadata to establish a mutual trust relationship. The metadata includes encryption algorithms, signature algorithms, and trust chain information. The following steps are included:

[0057] Metadata request: An identity provider initiates a metadata request to another identity provider to obtain the other party's metadata information.

[0058] Metadata response: The requested party generates metadata about itself, including supported encryption algorithms, signature algorithms, trust chain information, etc. The generated metadata needs to contain a digital signature to ensure integrity.

[0059] Metadata delivery: The requested party delivers the generated metadata to the requesting party. This can be done through direct transmission, secure communication channels (such as HTTPS), etc. to prevent man-in-the-middle attacks and information leakage.

[0060] Metadata verification: After receiving the metadata, the requester verifies the validity of the metadata. This includes checking the legitimacy of the digital signature, the integrity of the metadata, and ensuring that the metadata has not been tampered with.

[0061] Trust chain establishment: If the metadata contains trust chain information, the requester needs to verify the trust chain to ensure that the requested party is a trusted identity provider. This may involve verifying digital certificates, verifying the certificate authority (CA), etc.

[0062] Trust relationship establishment: After verification, the requester and the requested party establish a trust relationship. This means that the requester trusts the identity information provided by the requested party and can use this information in subsequent identity authentication and authorization processes.

[0063] Regular updates: To keep metadata up to date, it is recommended to update metadata regularly. This can be achieved by periodically re-initiating metadata requests, using caching and invalidation mechanisms, etc.

[0064] Error handling: Considering the possible problems of the network and system, it is necessary to establish an error handling mechanism. For example, when metadata cannot be obtained or verified, formulate a corresponding error handling strategy to ensure the stability of the system.

[0065] The user authenticates with the identity provider. When the user tries to access a resource, the identity provider generates an identity token and authenticates the user through a process that includes the following steps:

[0066] User authentication request: A user sends an authentication request to an identity provider, typically including user-supplied credentials (such as a username and password) or other authentication factors.

[0067] Authentication processing: After the identity provider receives the authentication request, it verifies the credentials provided by the user. This may involve password verification, two-factor authentication, etc.

[0068] Issuing an identity token: If the credentials provided by the user are verified, the identity provider generates an identity token containing information about the user's identity. The identity token usually includes information such as the user's unique identifier, access rights, and token expiration time.

[0069] Token signing: The identity provider signs the generated identity token using its own private key to ensure the integrity and authenticity of the token.

[0070] Token delivery to user: The identity provider delivers the signed identity token to the user. This can be delivered directly to the user's application over a secure channel (such as HTTPS) or through a redirect, etc.

[0071] Token storage and management: Your application will typically store identity tokens in a secure location for use in subsequent resource access requests. This may include client-side storage, server-side storage, or a secure token storage service.

[0072] Use of tokens: When a user's application requests access to resources from a resource provider, it attaches the identity token to the request. The resource provider can verify the user's identity and permissions through the token.

[0073] Token expiration handling: If the identity token has an expiration date set, the user's application needs to obtain a new token before the token expires. This may require using a token refresh mechanism or re-authentication.

[0074] Access control: After receiving a request containing an identity token, the resource provider verifies the signature and validity of the token and performs access control on the user based on the claims in the token.

[0075] After the identity provider successfully authenticates the user, it issues an identity token that includes security information about the user's identity, including the following steps:

[0076] Identity token generation: The identity provider generates an identity token in a secure way. This token is usually a data structure containing user identity information, permissions, expiration time, etc.

[0077] Claim information includes: The identity token contains information about the user's identity, such as the user's unique identifier, role, permissions, access scope, etc. This information usually exists in the form of claims.

[0078] Token signing: The identity provider signs the generated identity token using its own private key. Token signing is to ensure the integrity of the token and prevent tampering. Other services can use the identity provider's public key to verify the signature of the token.

[0079] Token encryption: In some scenarios, especially when tokens need to be transmitted over untrusted channels, identity providers can choose to encrypt tokens to ensure the confidentiality of token contents during transmission.

[0080] Token delivery to user: The identity provider delivers the signed identity token to the user. This may be done directly to the user's application, via a redirect, or in some other suitable manner.

[0081] Token storage and management: After the user's application receives the identity token, it may store the token in a secure place, such as client-side storage, server-side storage, or a dedicated token management service.

[0082] Passing the token to the resource server: When the user's application needs to access a resource, it will attach the token to the resource request. This can be through the request header, request parameters, etc.

[0083] Resource server verifies token: After receiving a request containing an identity token, the resource server first verifies the signature and integrity of the token. If the verification passes, the resource server parses the claim information in the token and decides whether to allow the user to access the resource based on this information.

[0084] Expiration and refresh mechanisms: Identity providers can set expiration times in tokens, and the user's application needs to obtain a new token before the token expires. This may require the use of a token refresh mechanism to avoid users having to authenticate frequently.

[0085] Token revocation: Consider implementing a token revocation mechanism so that the token can be invalidated in a timely manner when the user actively logs out or for other reasons.

[0086] When a user uses an identity token to access resources in another domain, the identity token is exchanged for an access token for that domain, which includes the following steps:

[0087] User requests resources: The user's application initiates a resource request to the resource provider of the target domain, including the user's identity token.

[0088] Identity token delivery: The user's application attaches the user's identity token to the resource request and sends the request to the resource provider of the target domain.

[0089] Resource provider verifies identity token: After receiving the request, the resource provider of the target domain first verifies the user's identity token. This involves steps such as token signature verification and expiration time check.

[0090] Identity token parsing: If the identity token is verified, the resource provider parses the claim information in the identity token to obtain the user's identity information and related permissions and access scopes.

[0091] Token exchange request: If the resource provider of the target domain supports token exchange, the resource provider will initiate a token exchange request to request an access token for the domain from the identity provider.

[0092] The identity provider verifies the identity token: After receiving the token exchange request, the identity provider of the target domain verifies the user's identity token. This ensures the trust relationship between the identity provider and the resource provider.

[0093] Access token generation: If the identity token is verified, the identity provider generates an access token for the target domain. The access token contains the user's identity information and access rights in the target domain.

[0094] Token passed to resource provider: The identity provider passes the generated access token to the resource provider of the target domain. This is usually done by returning it directly to the user's application, or by redirection, etc.

[0095] Resource access: After receiving the access token, the resource provider of the target domain verifies the validity of the token, parses the claim information in the token, and decides whether to allow the user to access the resource based on this information.

[0096] Access result return: The resource provider returns the corresponding resources to the user's application or performs the requested operation.

[0097] After receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to use the solution resources based on the token renewal mechanism, including the following steps:

[0098] Token verification: The resource provider first verifies the received access token. This includes checking whether the token's signature is valid, whether the token has expired, the integrity of the token, etc. If the token verification fails, the access request is rejected.

[0099] Claim information parsing: If the token is verified, the resource provider parses the claim information in the token. These claim information contain information such as the user's identity, permissions, and access scope, which are used for subsequent access control decisions.

[0100] Access control decision: Based on the parsed declaration information, the resource provider makes an access control decision. This includes determining whether the user has permission to access a specific resource and whether additional authorization verification is required during the access process.

[0101] Resource access: If the access control decision passes, the resource provider allows the user to access the requested resource. This may involve returning the requested resource data to the user or performing the corresponding operation.

[0102] Token renewal mechanism: If the access token contains renewal information, the resource provider decides whether to renew the token based on the renewal mechanism. The renewal mechanism can be to regularly initiate token renewal requests to the identity provider, or to ensure that the validity of the token is maintained by other means.

[0103] Token refresh: If the access token expires but a refresh token exists, the resource provider can use the refresh token to request a new access token from the identity provider to extend the user's access rights.

[0104] Access auditing and logging: Resource providers may record information about access requests for auditing and logging purposes, including user identity, access time, and accessed resources, in order to monitor and trace access history.

[0105] Notify the identity provider: When access occurs, the resource provider can send a notification to the identity provider so that the identity provider can record the user's activities or perform other related operations.

[0106] After receiving the token exchange request, the identity provider of the target domain verifies the user's identity token. If the identity token verification is successful, the identity provider generates an access token for the target domain, including the following steps:

[0107] After receiving the token exchange request, the identity provider of the target domain obtains the token structure integrity, token expiration index, identity consistency index and digital signature index of the user identity token;

[0108] The token coefficient is obtained by comprehensively calculating the token structure integrity, token expiration index, identity consistency index and digital signature index. The expression is:

[0109] Where lpx is the token coefficient, gqz is the token expiration index, jgw, fsz, szq are the token structure integrity, identity consistency index and digital signature index respectively, α, β, γ are the proportional coefficients of the token structure integrity, identity consistency index and digital signature index respectively, and α, β, γ are all greater than 0;

[0110] After receiving a token exchange request through the identity provider of the target domain, the present application obtains the token structure integrity, token expiration index, identity consistency index and digital signature index of the user's identity token, calculates the token structure integrity, token expiration index, identity consistency index and digital signature index comprehensively to obtain the token coefficient, and determines whether the user's identity token has passed the verification based on the comparison result of the token coefficient and the verification threshold. The comprehensive analysis method is helpful to improve the accuracy of token verification, and determining whether the user's identity token has passed the verification based on the comparison result of the token coefficient and the verification threshold can effectively ensure secure transactions between users.

[0111] From the calculation expression of the token coefficient, it can be seen that the larger the token coefficient is, the higher the quality of the user's identity token is. Therefore, after obtaining the user's token coefficient, the token coefficient is compared with the verification threshold;

[0112] If the token coefficient is greater than or equal to the verification threshold, it is determined that the user's identity token has passed the verification;

[0113] If the token coefficient is less than the verification threshold, it is determined that the user's identity token has not passed the verification.

[0114] If the identity token has not expired, the token expiration index is 1; if the identity token has expired, the token expiration index is 0;

[0115] Token structure integrity:

[0116] Token structural integrity refers to the correctness of the format and components of the token. To obtain token structural integrity online, you can view the relevant token specification documents or standards. For example, if the token is based on the JSON Web Token (JWT) specification, you can refer to the JWT specification document to understand the standard fields and format of the token. In addition, developers can also use online JWT parsing tools to parse the token input and check its structural integrity.

[0117] Identity consistency index:

[0118] Identity consistency refers to whether the user identity information contained in the token is consistent with the actual user identity. Methods for obtaining identity consistency index online usually include:

[0119] Parse tokens: Use appropriate parsing tools or libraries to parse the tokens into readable data structures.

[0120] View the claim information: View the claim information in the token, including the user's unique identifier, role, permissions, etc. Make sure that this information is consistent with the actual user identity.

[0121] Call the identity provider API: If feasible, you can call the identity provider's API to verify that the user information in the token is consistent with the identity provider's records.

[0122] Digital Signature Index:

[0123] The digital signature index indicates whether the digital signature of the token is valid. Methods for obtaining the digital signature index online include:

[0124] Use a verification tool: You can use an online JWT verification tool or a related token verification tool to enter the token and verify its signature. These tools usually provide a verification result indicating whether the signature is valid.

[0125] Using a development library: Use the corresponding development library in your own application to programmatically verify the signature of the token.

[0126] Consult the documentation: Verification of token signatures usually requires the use of a public key or certificate. The relevant documentation or specifications will explain how to obtain and use this information.

[0127] The above formulas are all dimensionless and numerical calculations. The formula is a formula for the most recent real situation obtained by collecting a large amount of data and performing software simulation. The preset parameters in the formula are set by technicians in this field according to actual conditions.

[0128] In the description of this specification, the description with reference to the terms "one embodiment", "example", "specific example", etc. means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0129] The preferred embodiments of the present invention disclosed above are only used to help explain the present invention. The preferred embodiments do not describe all the details in detail, nor do they limit the invention to only specific implementation methods. Obviously, many modifications and changes can be made according to the content of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the present invention, so that those skilled in the art can understand and use the present invention well. The present invention is limited only by the claims and their full scope and equivalents.

Claims

1. A cross-domain identity authentication method based on multi-level identity alliance, characterized by: The authentication method comprises the following steps: Establish identity providers in a multi-level identity federation. Each participant's identity provider is registered and provides relevant metadata during the registration process. Identity providers exchange metadata to establish mutual trust. The metadata includes encryption algorithms, signature algorithms, and trust chain information. The user authenticates through the identity provider. When the user tries to access a resource, the identity provider generates an identity token and authenticates the user through the corresponding process. After the identity provider successfully verifies the user's identity, it issues an identity token, which includes security information about the user's identity; When a user uses an identity token to access resources in another domain, the identity token is exchanged for an access token for that domain. After receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to access solution resources based on the token renewal mechanism.

2. According to claim 1, a cross-domain identity authentication method based on multi-level identity alliance is characterized in that: After receiving the token exchange request, the identity provider of the target domain verifies the identity token of the user. If the identity token verification is successful, the identity provider generates an access token for the target domain, including the following steps: after receiving the token exchange request, the identity provider of the target domain obtains the token structure integrity, token expiration index, identity consistency index and digital signature index of the user's identity token; The token coefficient is obtained by comprehensively calculating the token structure integrity, token expiration index, identity consistency index and digital signature index. The expression is: Where lpx is the token coefficient, gqz is the token expiration index, jgw, fsz, szq are the token structure integrity, identity consistency index and digital signature index respectively, α, β, γ are the proportional coefficients of the token structure integrity, identity consistency index and digital signature index respectively, and α, β, γ are all greater than 0; From the calculation expression of the token coefficient, it can be seen that the larger the token coefficient is, the higher the quality of the user's identity token is. Therefore, after obtaining the user's token coefficient, the token coefficient is compared with the verification threshold; If the token coefficient is greater than or equal to the verification threshold, it is determined that the user's identity token has passed the verification; If the token coefficient is less than the verification threshold, it is determined that the user's identity token has not passed the verification.

3. According to claim 2, a cross-domain identity authentication method based on multi-level identity alliance is characterized in that: Identity providers exchange metadata and establish a mutual trust relationship, including the following steps: An identity provider initiates a metadata request to another identity provider, requesting the other party's metadata information. The requested party generates metadata about itself, including supported encryption algorithms, signature algorithms, and trust chain information. The requested party passes the generated metadata to the requesting party through direct transmission and secure communication channels. After receiving the metadata, the requesting party verifies the validity of the metadata, including checking the legitimacy of the digital signature and the integrity of the metadata. If the metadata contains trust chain information, the requesting party needs to verify the trust chain to ensure that the requested party is a trusted identity provider, including verifying the digital certificate and the certificate authority. After the verification is successful, the requesting party and the requested party establish a trust relationship.

4. According to claim 3, a cross-domain identity authentication method based on multi-level identity alliance is characterized in that: The user authenticates with the identity provider. When the user tries to access a resource, the identity provider generates an identity token and authenticates the user through a process that includes the following steps: The user sends an authentication request to the identity provider, including the credentials provided by the user. After receiving the authentication request, the identity provider verifies the credentials provided by the user. If the credentials provided by the user are verified, the identity provider generates an identity token containing information about the user's identity. The identity token includes the user's unique identifier, access rights, and token expiration time information. The identity provider uses its own private key to sign the generated identity token. The identity provider passes the signed identity token to the user and directly passes it to the user's application through a secure channel or through redirection. The user's application stores the identity token in a secure location. When the user's application requests access to resources from the resource provider, it attaches the identity token to the request. The resource provider verifies the user's identity and permissions through the token. If the identity token has an expiration time, the user's application obtains a new token before the token expires.

5. According to claim 4, a cross-domain identity authentication method based on multi-level identity alliance is characterized in that: After the identity provider successfully authenticates the user, it issues an identity token that includes security information about the user's identity, including the following steps: The identity provider uses a secure method to generate an identity token. The identity token contains information about the user's identity, including the user's unique identifier, role, permissions, and access scope. The identity provider uses its own private key to sign the generated identity token. When the token is transmitted over an untrusted channel, the identity provider chooses to encrypt the token. The identity provider passes the signed identity token to the user, directly to the user's application, and through redirection, when the user's application needs to access resources, the token is attached to the resource request. After the resource server receives the request containing the identity token, it first verifies the signature and integrity of the token. If the verification passes, the resource server parses the declaration information in the token and decides whether to allow the user to access the resource based on this information.

6. A cross-domain identity authentication method based on multi-level identity alliance according to claim 5, characterized in that: When a user uses an identity token to access resources in another domain, the identity token is exchanged for an access token for that domain, which includes the following steps: The user's application initiates a resource request to the resource provider of the target domain, including carrying the user's identity token. The user's application attaches the user's identity token to the resource request and sends the request to the resource provider of the target domain. After receiving the request, the resource provider of the target domain first verifies the user's identity token, which involves the steps of signature verification and expiration time check of the token. If the identity token verification passes, the resource provider parses the declaration information in the identity token, obtains the user's identity information and related permissions and access scopes. If the resource provider of the target domain supports token exchange, the resource provider will initiate a token exchange request and request an access token for the domain from the identity provider. After receiving the token exchange request, the identity provider of the target domain verifies the user's identity token. If the identity token verification passes, the identity provider generates an access token for the target domain, which contains the user's identity information and access rights in the target domain. The identity provider passes the generated access token to the resource provider of the target domain. After receiving the access token, the resource provider of the target domain verifies the validity of the token, parses the declaration information in the token, and decides whether to allow the user to access the resource based on this information.

7. A cross-domain identity authentication method based on multi-level identity alliance according to claim 6, characterized in that: After receiving the access token, the resource provider verifies the legitimacy of the token, performs access control on the user based on the declaration information in the token, and allows the user to continue to use the solution resources based on the token renewal mechanism, including the following steps: The resource provider first verifies the received access token, including checking whether the signature of the token is valid, whether the token is expired, and the integrity of the token. If the token verification fails, the access request is rejected. If the token verification passes, the resource provider parses the declaration information in the token, including the user's identity, permissions, and access scope information, for subsequent access control decisions. Based on the parsed declaration information, the resource provider makes access control decisions, including determining whether the user has permission to access specific resources and whether additional authorization verification is required during the access process. If the access control decision passes, the resource provider allows the user to access the requested resources, returns the requested resource data to the user, or performs corresponding operations. If the access token contains renewal information, the resource provider decides whether to renew the token based on the renewal mechanism, regularly initiates token renewal requests to the identity provider, or ensures that the validity of the token is maintained through other means.

8. A cross-domain identity authentication method based on multi-level identity alliance according to claim 6, characterized in that: To establish identity providers in a multi-level identity federation, each participant's identity provider is registered and provides relevant metadata during the registration process, including the following steps: The identity provider of the participating party sends a registration request to the registration center of the identity alliance, which contains basic information about the identity provider, including domain name, public key, supported encryption algorithm, and trust level. After receiving the registration request, the registration center of the identity alliance verifies the legitimacy of the request and generates metadata of the identity provider based on the verified registration request, including the endpoint address of the identity provider, supported identity authentication protocols, and trust chain information. The user signs the generated metadata and publishes the signed metadata to the metadata storage of the identity alliance or the public metadata endpoint.

Images