Method for authorization, and device, system and storage medium

Abstract

The embodiments of the present disclosure relate to the technical field of communications. Disclosed are a method for authorization, and a device and a computer-readable storage medium. The method for authorization comprises: a first entity determining, on the basis of an identifier of a second entity, whether to authorize an application program interface (API) caller. In the embodiments of the present disclosure, whether to authorize an API caller is determined on the basis of an identifier of a second entity, thereby determining whether the API caller requires access to specific resources in an authorization process.

Description

Method, device, system and storage medium for authorization Technical Field

[0001] The present disclosure relates to the field of communication technology, and in particular to a method, device, system, and storage medium for authorization. Background Art

[0002] Currently, the security aspects of the Common API Framework (CAPIF) interface and the corresponding security information flows are open. Therefore, CAPIF will support a large number of services with different architectures and performance requirements.

[0003] Summary of the Invention

[0004] Embodiments of the present disclosure provide a method, device, system, and storage medium for authorization.

[0005] According to a first aspect of an embodiment of the present disclosure, a method for authorization is provided, which is applied to a first entity. The method includes:

[0006] Based on the identifier of the second entity, it is determined whether to authorize the application program interface (API) caller.

[0007] According to a second aspect of an embodiment of the present disclosure, a first entity for authorization is provided, including:

[0008] The processing module is used to determine whether to authorize the application program interface (API) caller based on the identifier of the second entity.

[0009] According to a third aspect of the embodiments of the present disclosure, a first entity for authorization is provided, including:

[0010] one or more processors;

[0011] The terminal is used to execute the optional implementation of the aforementioned first aspect.

[0012] According to a fourth aspect of an embodiment of the present disclosure, a communication system is proposed, comprising: a first entity and a second entity, wherein the first entity is used to implement the method described in the optional implementation manner of the first aspect, to implement authorization or non-authorization of an application program interface (API) caller, wherein the API caller is the second entity, or an API caller on the second entity.

[0013] According to a fifth aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, in which executable instructions are stored. The executable instructions are loaded and executed by the processor to implement the method described in the optional implementation manner of the aforementioned first aspect.

[0014] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0016] FIG1a is a schematic structural diagram of a communication system according to an exemplary embodiment;

[0017] FIG1b is a schematic flow chart showing a method for authorization according to an exemplary embodiment;

[0018] FIG1c is a schematic flow chart showing a method for authorization according to an exemplary embodiment;

[0019] FIG2 is a flow chart showing a method for authorization according to an exemplary embodiment;

[0020] FIG3a is a schematic flow chart of a method for authorization according to an embodiment of the present disclosure;

[0021] FIG3 b is a schematic flow chart of a method for authorization according to an embodiment of the present disclosure;

[0022] FIG3 c is a flow chart of a method for authorization according to an embodiment of the present disclosure;

[0023] FIG4 is a flow chart of a method for authorization according to an embodiment of the present disclosure;

[0024] FIG5 is a schematic structural diagram of a first entity for authorization proposed in an embodiment of the present disclosure;

[0025] FIG6 is a flow chart of a method for authorization according to an embodiment of the present disclosure;

[0026] FIG7a is a schematic structural diagram of a communication device proposed in an embodiment of the present disclosure;

[0027] FIG7 b is a schematic structural diagram of a chip proposed in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0028] The embodiments of the present disclosure provide a method, a device, a communication system, and a storage medium for authorization.

[0029] In a first aspect, an embodiment of the present disclosure provides a method for authorization, which is applied to a first entity. The method includes:

[0030] Based on the identifier of the second entity, it is determined whether to authorize the application program interface (API) caller.

[0031] In the above embodiment, when the second entity is a terminal, determining whether to authorize the API caller based on the second entity's identifier enables the first entity to determine the relationship between the second entity's identifier and the resource owner's identifier, thereby enabling the terminal or the API caller on the terminal to only process resources of a specific resource owner, and enabling the first entity to restrict the terminal or the API caller on the terminal to only apply for tokens related to the terminal's own resources, thereby preventing the terminal or the API caller on the terminal from applying for tokens related to resources of other terminals. The terminal or the API caller on the terminal can only process operations on the resources of a specific resource owner, including but not limited to: request, update, delete, and other operations.

[0032] In the above embodiment, when the second entity is an API caller, determining whether to authorize the API caller through the identifier of the second entity enables the first entity to restrict the API caller to only process resources belonging to a specific resource owner, where the identifier of the specific resource owner is the same as or associated with the identifier of the API caller. This has the beneficial effect of enabling the first entity to restrict the API caller to only apply for tokens related to the resources of the specific resource owner, preventing the API caller from applying for tokens related to resources of other resource owners. The terminal or the API caller on the terminal can only process operations on the resources of a specific resource owner, including but not limited to: request, update, delete, and other operations.

[0033] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes:

[0034] receiving a request message from the second entity; and wherein,

[0035] The determining whether to authorize the API caller based on the identifier of the second entity includes:

[0036] Based on the request message and the identifier of the second entity, it is determined whether to authorize the API caller.

[0037] In the above embodiment, whether to authorize the API caller is determined by the request message and the identifier of the second entity. When the second entity is a terminal, the first entity can limit the terminal or the API caller on the terminal to only apply for resource-related tokens of the terminal itself, preventing the terminal or the API caller on the terminal from applying for resource-related tokens of other terminals. When the second entity is an API caller, the first entity can limit the API caller to only apply for resource-related tokens of the specific resource owner, and the identifier of the specific resource owner is the same as or associated with the identifier of the API caller.

[0038] In conjunction with some embodiments of the first aspect, in some embodiments, the request message includes an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes:

[0039] Based on the first condition, determining whether to authorize the API caller;

[0040] The first condition includes: the identifier of the second entity is the same as the identifier of the first resource owner, or the identifier of the second entity has a corresponding relationship with the identifier of the first resource owner.

[0041] In the above embodiment, when the second entity is a terminal, by determining whether to authorize the API caller based on a first condition determined based on the identifier of the second entity and the identifier of the resource owner included in the request message, the first entity can limit the terminal or the API caller on the terminal to only apply for resource-related tokens of the terminal itself, and prevent the terminal or the API caller on the terminal from applying for resource-related tokens of other terminals. When the second entity is an API caller, the first entity can limit the API caller to only apply for resource-related tokens of the specific resource owner, and the identifier of the specific resource owner is the same as or associated with the identifier of the API caller.

[0042] In combination with some embodiments of the first aspect, in some embodiments, determining whether to authorize the API caller based on the first condition includes: the identifier of the second entity meets the first condition, determining to authorize the API caller or determining to continue to determine whether to authorize the API caller.

[0043] In the above embodiment, when the identifier of the second entity is the same as the identifier of the first resource owner included in the request message, or has a corresponding relationship with the identifier of the first resource owner, it can be determined that the API caller is authorized or it can be determined to continue to determine whether to authorize the API caller.

[0044] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes:

[0045] When it is determined that the API caller is authorized, a response message is sent to the second entity, the response message including a token generated for the API caller and including the identification of the first resource owner.

[0046] In combination with some embodiments of the first aspect, in some embodiments, determining whether to authorize the API caller based on the first condition includes: if the identifier of the second entity does not meet the first condition, determining not to authorize the API caller.

[0047] In the above embodiment, when the identifier of the second entity is different from the identifier of the first resource owner included in the request message, or there is no corresponding relationship between them, it can be determined that the API caller is not authorized.

[0048] In combination with some embodiments of the first aspect, in some embodiments, the correspondence between the identifier of the second entity and the identifier of the first resource owner is stored by the first entity.

[0049] In conjunction with some embodiments of the first aspect, in some embodiments, the request message does not include an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes:

[0050] Based on the second condition, determining whether to authorize the API caller;

[0051] The second condition includes: the identifier of the second entity is the same as the identifier of the second resource owner, or the identifier of the second entity corresponds to the identifier of the second resource owner;

[0052] The identifier of the second resource owner is one of at least one identifier of a resource owner stored by the first entity.

[0053] In the above embodiment, when the second entity is a terminal, whether to authorize the API caller is determined by a second condition determined based on the identifier of the second entity and the identifier of the resource owner stored by the first entity, so that the first entity can limit the terminal or the API caller on the terminal to only apply for resource-related tokens of the terminal itself, and prevent the terminal or the API caller on the terminal from applying for resource-related tokens of other terminals. When the first entity is an API caller, the first entity can limit the API caller to only apply for resource-related tokens of the specific resource owner, and the identifier of the specific resource owner is the same as or associated with the identifier of the API caller.

[0054] In combination with some embodiments of the first aspect, in some embodiments, determining whether to authorize the API caller based on the second condition includes: the identifier of the second entity meets the second condition, determining to authorize the API caller or determining to continue to determine whether to authorize the API caller.

[0055] In the above embodiment, when the identifier of the second entity is the same as one of the identifiers of at least one resource owner stored by the first entity, or has a corresponding relationship with one of the identifiers, the authorized API caller can be determined.

[0056] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes:

[0057] A response message is sent to the second entity, the response message including a token generated for the API caller and including an identification of the second resource owner.

[0058] In combination with some embodiments of the first aspect, in some embodiments, determining whether to authorize the API caller based on the second condition includes: if the identifier of the second entity does not meet the second condition, determining not to authorize the API caller.

[0059] In the above embodiment, when the identifier of the second entity is different from the identifiers of the resource owners stored by the first entity, or does not have a corresponding relationship with each other, it can be determined that the API caller is not authorized.

[0060] In combination with some embodiments of the first aspect, in some embodiments, the correspondence between the identifier of the second entity and the identifier of the at least one resource owner is stored by the first entity.

[0061] In conjunction with some embodiments of the first aspect, in some embodiments, the method further includes:

[0062] A response message is sent to the second entity, where the response message is used to indicate that authorization of the API caller is rejected.

[0063] In combination with some embodiments of the first aspect, in some embodiments, the identifier of the second entity is an identifier of the second entity authenticated by the first entity.

[0064] In combination with some embodiments of the first aspect, in some embodiments, the identifier of the second entity authenticated by the first entity is obtained before the first entity sends the authorization code to the second entity; or,

[0065] The identification of the second entity authenticated by the first entity is obtained before the first entity sends a token to the second entity.

[0066] In combination with some embodiments of the first aspect, in some embodiments, the API caller is an API caller on the second entity.

[0067] In combination with some embodiments of the first aspect, in some embodiments, the second entity includes a terminal, or the API caller.

[0068] In conjunction with some embodiments of the first aspect, in some embodiments, the second entity is a terminal, and determining whether to authorize the application program interface (API) caller based on the identifier of the second entity includes:

[0069] Based on the identifier of the second entity, it is determined whether to authorize the API caller on the second entity.

[0070] In combination with some embodiments of the first aspect, in some embodiments, the first entity includes an entity that implements an authorization function, or an entity that implements a core function of a general application program interface framework.

[0071] In a second aspect, an embodiment of the present disclosure provides a first entity for authorization, including:

[0072] The processing module is used to determine whether to authorize the application program interface (API) caller based on the identifier of the second entity.

[0073] In a third aspect, an embodiment of the present disclosure provides a first entity for authorization, including:

[0074] one or more processors;

[0075] The terminal executes the method described in the optional implementation manner of the first aspect.

[0076] In a fourth aspect, an embodiment of the present disclosure proposes a communication system, comprising a first entity and a second entity, wherein the first entity is used to implement the method described in the optional implementation manner of the first aspect, to implement authorization or non-authorization of an application program interface API caller, wherein the API caller is the second entity, or an API caller on the second entity.

[0077] In a fifth aspect, an embodiment of the present disclosure proposes a storage medium, which stores instructions. When the instructions are executed on a communication device, the communication device executes the method described in the optional implementation manner of the first aspect.

[0078] In a sixth aspect, an embodiment of the present disclosure proposes a program product. When the program product is executed by a communication device, the communication device executes the method described in the optional implementation manner of the first aspect.

[0079] In a seventh aspect, an embodiment of the present disclosure proposes a computer program, which, when executed on a computer, enables the computer to execute the method described in the optional implementation manner of the first aspect.

[0080] In an eighth aspect, an embodiment of the present disclosure proposes a chip or a chip system, which includes a processing circuit for executing the method described in the optional implementation manner of the first aspect above.

[0081] It is understandable that the above-mentioned communication devices, communication systems, storage media, program products, and computer programs are all used to perform the methods proposed in the embodiments of the present disclosure. Therefore, the beneficial effects that can be achieved can refer to the beneficial effects of the corresponding methods and will not be repeated here. Among them, the communication device can be the first entity that implements the authorization function or the core function of the universal application program interface framework.

[0082] The present disclosure provides methods, communication devices, communication systems, and storage media for authorization. In some embodiments, the terms "method for authorization" and "information processing method" and "determining information processing mode" are interchangeable, and the terms "information processing system" and "communication system" are interchangeable.

[0083] The embodiments of the present disclosure are not exhaustive and are merely illustrative of some embodiments, and are not intended to be a specific limitation on the scope of protection of the embodiments of the present disclosure. In the absence of contradiction, each step in a certain embodiment can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a certain embodiment can also be implemented as an independent embodiment, and the order of the steps in a certain embodiment can be arbitrarily exchanged. In addition, the optional implementation methods in a certain embodiment can be arbitrarily combined; in addition, the embodiments can be arbitrarily combined. For example, some or all steps of different embodiments can be arbitrarily combined, and a certain embodiment can be arbitrarily combined with the optional implementation methods of other embodiments.

[0084] In each embodiment of the present disclosure, unless otherwise specified or provided for by logic, the terms and / or descriptions between the embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form a new embodiment based on their inherent logical relationships.

[0085] The terms used in the embodiments of the present disclosure are only for the purpose of describing specific embodiments and are not intended to limit the embodiments of the present disclosure.

[0086] In the embodiments of the present disclosure, unless otherwise specified, elements expressed in the singular, such as "a", "an", "the", "above", "said", "the", "the", etc., may mean "one and only one", or "one or more", "at least one", etc. For example, when using articles such as "a", "an", "the" in English in translation, the noun following the article may be understood as a singular expression or a plural expression.

[0087] In the embodiments of the present disclosure, “plurality” refers to two or more.

[0088] In some embodiments, the terms "at least one of", "at least one of", "at least one of", "one or more", "a plurality of", "multiple", etc. can be used interchangeably.

[0089] In the embodiments of the present disclosure, descriptions such as “at least one of A, B, C…”, “A and / or B and / or C…”, etc. include the situation where any one of A, B, C… exists alone, and also include any combination of any multiple of A, B, C…, and each situation can exist alone; for example, “at least one of A, B, C” includes the situation where A exists alone, B exists alone, C exists alone, the combination of A and B, the combination of A and C, the combination of B and C, and the combination of A, B, and C; for example, A and / or B includes the situation where A exists alone, B exists alone, and the combination of A and B.

[0090] In some embodiments, descriptions such as "in one case A, in another case B," or "in response to one case A, in response to another case B," may include the following technical solutions depending on the situation: executing A independently of B (in some embodiments, A); executing B independently of A (in some embodiments, B); selectively executing A and B (in some embodiments, selecting between A and B); and executing both A and B (in some embodiments, A and B). The same applies when there are more branches, such as A, B, and C.

[0091] The prefixes such as "first" and "second" in the embodiments of the present disclosure are only used to distinguish different description objects and do not constitute any restriction on the position, order, priority, quantity or content of the description objects. For the statement of the description object, please refer to the description in the context of the claims or embodiments, and no unnecessary restriction should be constituted due to the use of prefixes. For example, if the description object is a "field", the ordinal number before the "field" in the "first field" and the "second field" does not limit the position or order between the "fields". "First" and "second" do not limit whether the "fields" they modify are in the same message, nor do they limit the order of the "first field" and the "second field". For another example, if the description object is a "level", the ordinal number before the "level" in the "first level" and the "second level" does not limit the priority between the "levels". For another example, the number of description objects is not limited by the ordinal number and can be one or more. Taking "first device" as an example, the number of "devices" can be one or more. In addition, the objects modified by different prefixes can be the same or different. For example, if the description object is "device", then the "first device" and the "second device" can be the same device or different devices, and their types can be the same or different. For another example, if the description object is "information", then the "first configuration" and the "second configuration" can be the same information or different information, and their contents can be the same or different.

[0092] In some embodiments, “including A,” “comprising A,” “used to indicate A,” and “carrying A” can be interpreted as directly carrying A or indirectly indicating A.

[0093] In some embodiments, terms such as "in response to...", "in response to determining...", "in the case of...", "at the time of...", "when...", "if...", "if...", etc. can be used interchangeably.

[0094] In some embodiments, terms such as "greater than", "greater than or equal to", "not less than", "more than", "more than or equal to", "not less than", "higher than", "higher than or equal to", "not less than", and "above" can be replaced with each other, and terms such as "less than", "less than or equal to", "not greater than", "less than", "less than or equal to", "not more than", "lower than", "lower than or equal to", "not higher than", and "below" can be replaced with each other.

[0095] In some embodiments, devices, etc. can be interpreted as physical or virtual, and their names are not limited to the names recorded in the embodiments. Terms such as "device", "equipment", "device", "circuit", "network element", "node", "function", "unit", "section", "system", "network", "chip", "chip system", "entity", and "subject" can be used interchangeably.

[0096] In some embodiments, the determination or judgment can be performed by a value represented by 1 bit (0 or 1), or by a true or false value (Boolean value) represented by true or false, or by comparison of numerical values ​​(for example, comparison with a predetermined value), but is not limited thereto.

[0097] In some embodiments, obtaining data, information, etc. may comply with the laws and regulations of the country where the data is obtained.

[0098] In some embodiments, data, information, etc. may be obtained with the user's consent.

[0099] FIG1a is a schematic diagram showing the architecture of a communication system according to an embodiment of the present disclosure.

[0100] The system 100 shown in FIG. 1 a includes one or more API callers 102 , 104 , a common application program interface framework CAPIF core function CCF 106 , an application program interface exposing function (API Exposing Function, AEF) 108 , an API publishing function 109 and an API management function 110 .

[0101] In some embodiments, one or more API callers 102 and 104 may be at least one of a computer, a mobile phone, a wearable device, an IoT device, a car with communication capabilities, a smart car, a tablet computer, a computer with wireless transceiver capabilities, a virtual reality (VR) terminal device, an augmented reality (AR) terminal device, a wireless terminal device in industrial control, a wireless terminal device in self-driving, a wireless terminal device in remote medical surgery, a wireless terminal device in a smart grid, a wireless terminal device in transportation safety, a wireless terminal device in a smart city, a wireless terminal device in a smart home, a server, or any other device attempting to access the AEF 108 to obtain one or more service APIs, but is not limited thereto.

[0102] In some embodiments, one or more API callers 102 and 104 may be a part of the terminal, an application function, or an application running on the terminal, but is not limited thereto.

[0103] In some embodiments, one or more API callers may be configured to call one or more service APIs present on the network. CCF 106 is a functional entity that may be configured to accumulate all common aspects of a service API. CCF 106 may be configured for authentication, monitoring, logging authorization, discovery, which are common to all service APIs. AEF 108 is an entity that may be configured to expose one or more service APIs to API callers (i.e., 102 and 104). API caller 102 may connect directly to AEF 108 to call a service API. API caller 102 may not have a direct connection to API publishing function 109 and API management function 110. API publishing function 109 may be configured to publish a library of service APIs on CCF 106. In addition, API management function 110 may be configured to manage functions related to the management of logging and auditing of logs stored in CCF 106.

[0104] In an embodiment, API callers 104 existing in a public land mobile network (PLMN) trust domain are trusted by the operator, and API callers 102 existing outside the PLMN trust domain may not be trusted by the operator. API callers 104 trusted by the operator may not be subject to any security checks. API callers 102 existing outside the PLMN trust domain may be subject to a higher level of security checks.

[0105] In addition, the system 100 includes one or more interfaces / reference points. The one or more interfaces include CAPIF-1, CAPIF-1e, CAPIF-2, CAPIF-2e, CAPIF-3, CAPIF-4 and CAPIF-5 interfaces. These interfaces are defined in the Third Generation Partnership Project (3GPP), and the CAPIF functions can refer to the definitions in the relevant technologies. The CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4 and CAPIF-5 interfaces exist within the public land mobile network (PLMN) trust domain, while the CAPIF-1e and CAPIF-2e interfaces exist between the CCF 106 and the API caller 102 and between the AEF 108 access point and the API caller 102, and the API caller 102 exists outside the PLMN trust domain. The security of the CAPIF-1, CAPIF-2, CAPIF-3, CAPIF-4 and CAPIF-5 interfaces supports transport layer security (TLS), and for details, please refer to the definitions in the relevant technologies in 3GPP.

[0106] API callers (i.e., 102, 104) both within and outside the PLMN trust domain require authentication and authorization. To authenticate and authorize API callers 102 outside the PLMN trust domain, CCF 106 needs to collaborate with AEF 108 and utilize CAPIF-1e, CAPIF-2e, and CAPIF-3 interfaces to authenticate and authorize API callers 102 before granting access to CAPIF services / service APIs. When API callers 104 are within the PLMN trust domain, CCF 106, in collaboration with AEF 108, can perform authentication and authorization of API callers 104 via CAPIF-1, CAPIF-2, and CAPIF-3 interfaces before granting access to CAPIF services.

[0107] CAPIF-1 / 1-e is between the API caller 102 and the CCF 106. In addition, the system 100 authenticates the API caller 102 based on the identity and credentials of the API caller 102 or by presenting a valid security token. There is mutual authentication between the API caller and the CCF. In addition, the system 100 provides authorization for the API caller before accessing one or more service APIs. For CAPIF-2 / 2e between the API caller 102 and the AEF 108, the system 100 authenticates the API caller 102 based on the identity and credentials of the API caller 102 or by presenting a valid security token (OAuth). In addition, the system 100 provides authorization for the API caller 102 before accessing the service API. In addition, there is authorization and verification of the API caller when accessing the service API. In addition, the system 100 controls service API access based on policies configured by the PLMN operator. CAPIF-1e and CAPIF-2e are reference points where the API caller 102 is outside the PLMN trust domain.

[0108] Research on resource owner awareness North API Access (RNAA) security is about obtaining authorization from resource owners. Existing authorization methods include the following:

[0109] The first is the authorization code process. As shown in Figure 1b, the process includes the following steps:

[0110] S111. The client initiates the process by directing the resource owner's user agent to the authorization endpoint. The client's authorization request includes its client identifier, the requested scope, local state, and a redirection URI. The authorization server redirects the user agent back to the URI when access is granted (or denied).

[0111] S112: The authorization server (through the user agent) authenticates the resource owner and determines whether the resource owner approves or denies the client's access request.

[0112] S113. Assuming the resource owner grants access, the authorization server redirects the user agent back to the client using the redirection URI provided in the request or in the client registration. The redirection URI contains an authorization code and any local state provided by the client.

[0113] S114: The client uses the authorization code obtained in step S113 to request an access token from the authorization server's token endpoint. When initiating a token request, the client authenticates its identity with the authorization server. The client includes the redirect URI used to obtain the authorization code for verification purposes.

[0114] S115. After receiving the token request, the authorization server authenticates the client (e.g., verifies the validity of parameters such as code, client_id, client_secret, and redirect_uri), verifies the authorization code, and confirms that the received redirection URI is consistent with the URI used to redirect the client in step S113. If valid, the authorization server issues an access token and, optionally, a refresh token.

[0115] The second type is the client credential process. As shown in Figure 1c, this process includes the following steps:

[0116] S121. The client authenticates on the authorization server and requests an access token from the token endpoint.

[0117] S122. The authorization server authenticates the client. If the authentication is valid, the authorization server issues an access token.

[0118] The third type is the authorization code process with PKCE (Proof Key for Code Exchange).

[0119] PKCE is a mechanism that ensures that the application requesting the authorization code and the application using the authorization code to exchange for an access token are the same application. This prevents malicious processes from intercepting the authorization code and using it to obtain an access token.

[0120] Specifically as shown in Figure 1b, the process includes the following steps:

[0121] S111. The client initiates the process by directing the resource owner's user agent to the authorization endpoint. When the client initiates the authorization request, it generates an additional parameter (code_verifier).

[0122] Among them, the value of code_verifier is a high-entropy encrypted and random string, which is composed of characters such as [AZ], [az], [0-9], "-", ".", "_", "~", and the length is preferably between 43 and 128 characters. After the client generates the high-entropy string, it does not directly attach it to the authorization request. Instead, it first performs a SHA-256 hash calculation on the code_verifier, and then performs BASE64-URL encoding on the hashed value. The final calculated result is called a challenge code (code_challenge), and the challenge code is carried in the authorization request. At the same time, the client also needs to store the value of code_verifier in a session cookie or other local storage, and needs to carry code_verifier when sending a token request in step S114.

[0123] In some embodiments, the authorization request may also carry a parameter (code_challenge_method). Generally, the value of code_challenge_method is S256, indicating that the value of code_challenge is the result of a SHA-256 hash calculation on code_verifier. However, for some clients that are not capable of SHA256 hash calculation, PKCE allows the value of code_verifier to be directly assigned to code_challenge. In this case, the value of code_challenge_method is plain.

[0124] S113. After receiving the user's authorization permission, the authorization server issues an authorization code to the client. At the same time, the authorization server associates and saves the generated authorization code with the code_challenge and code_challenge_method in the authorization request.

[0125] S114: The client uses the authorization code obtained in step S113 to request an access token from the authorization server's token endpoint. When initiating a token request, the client authenticates its identity with the authorization server. The client includes the redirection URI used to retrieve the authorization code for verification purposes. Furthermore, the client sends the code_verifier it saved locally in step S111 to the authorization server.

[0126] S115. After receiving the token request, the authorization server verifies the validity of parameters such as code, client_id, client_secret, and redirect_uri. In addition, the authorization server also verifies the value of the code_verifier parameter.

[0127] Specifically, after receiving the token request, the authorization server:

[0128] Verify whether the current authorization code exists. If so, query the code_challenge and code_challenge_method associated with the current authorization code (as described above, in step S113, the authorization server associates and stores the authorization code it generates with the code_challenge and code_challenge_method in the authorization request).

[0129] If the associated code_challenge_method is plain, the authorization server only needs to compare whether the code_verifier in the current token request is equal to the code_challenge stored on the authorization server.

[0130] If code_challenge_method is SHA256, the authorization server only needs to hash and BASE64-URL encode code_verifier according to the method used by the client to calculate the challenge code when initiating the authorization request in step S111. If the result of the hashing is equal to the code_challenge stored by the authorization server, it can be determined that the authorization request and the token request came from the same client. Otherwise, a response message denying authorization will be returned for the token request.

[0131] In the RNAA scenario, the terminal or the API caller on the terminal needs to be restricted to processing only the resources of the terminal itself during the process of accessing resources. The API caller on the terminal can be a part of the terminal or an API caller residing on the terminal (API invoker residing on UE). The API caller residing on the terminal (API invoker residing on UE) can be an application running on the terminal. However, using the existing authorization method, the CCF can only authorize the API caller to access specific resources of a specific resource owner, but the CCF cannot determine whether there is an association relationship between the resource owner, the API caller (invoker), and the terminal related to the API caller. Therefore, the CCF cannot determine during the authorization process whether the terminal or the API caller on the terminal is applying to process the resources of the terminal itself. The solution provided by the embodiment of the present disclosure provides a method for authorization, which can determine whether the terminal or the API caller on the terminal requests the resources of the terminal itself during the authorization process.

[0132] In the RNAA scenario, three types of API callers are considered (i.e., the API caller is an application function external to the UE, the API caller is an application resident on the UE, and the API caller is a part of the UE). The API caller on the UE indicates that the API caller is resident on the UE or the API caller is a part of the UE.

[0133] Based on the above communication system, various embodiments of the communication method proposed in the present disclosure are described in detail below.

[0134] FIG2 is an interactive diagram of a method for authorization according to an embodiment of the present disclosure. As shown in FIG2 , the method for authorization is used in a communication system 100, and the method includes:

[0135] S201: A first entity authenticates an identifier of a second entity.

[0136] In some embodiments, the first entity may be an entity that implements the authorization function, or an entity that implements the Common API Framework (CAPIF) core function (CAPIF Core Function, CCF).

[0137] In some embodiments, the identifier of the second entity is a unique identifier for identifying the second entity, for example, a mobile phone number or a Generic Public Subscription Identifier (GPSI).

[0138] In some embodiments, the second entity may be a terminal.

[0139] In some embodiments, the second entity may be an API caller.

[0140] In some embodiments, when the second entity is an API caller, the identifier of the second entity is an API caller identifier (API invoker ID).

[0141] In some embodiments, the name of the identifier is not limited to the name described in the embodiments and can be replaced with "ID".

[0142] In some embodiments, the first entity may authenticate the identifier of the second entity using an identity authentication method in related technologies, which will not be described in detail for the sake of brevity.

[0143] In some optional embodiments, the first entity obtains the identity of the second entity authenticated by the first entity by authenticating the identity of the second entity.

[0144] In some optional embodiments, the identity of the second entity authenticated by the first entity is obtained before the first entity sends the authorization code to the second entity.

[0145] In another optional embodiment, the identity of the second entity authenticated by the first entity is obtained before the first entity sends the token to the second entity.

[0146] In some embodiments, the first entity may authenticate the second entity during the process of receiving the request message and obtain the authenticated identification of the second entity.

[0147] In some embodiments, the names of messages, etc. are not limited to the names described in the embodiments, and terms such as "terminal", "terminal device", "user equipment (UE)", "user terminal", "mobile station (MS)", "mobile terminal (MT)", subscriber station, mobile unit, subscriber unit, wireless unit, remote unit, mobile device, wireless device, wireless communication device, remote device, mobile subscriber station, access terminal, mobile terminal, wireless terminal, remote terminal, handset, user agent, mobile client, and client can be used interchangeably.

[0148] Optionally, the above step S201 can be omitted.

[0149] S202: The second entity sends a request message to the first entity.

[0150] In some embodiments, the names of messages, etc. are not limited to the names described in the embodiments, and terms such as "information", "message", "signal", "signaling", "report", "configuration", "indication", "instruction", "command", "channel", "parameter", "domain", "field", "symbol", and "data" can be used interchangeably.

[0151] In some embodiments, terms such as "send", "transmit", "report", "download", "transmit", "bidirectional transmission", "send and / or receive" can be used interchangeably.

[0152] In some embodiments, the request message may be a token-related request message used to request a token, such as a token request message.

[0153] In some embodiments, the request message may include an identifier of the resource owner.

[0154] Exemplarily, the identifier of the resource owner may be a Generic Public Subscription Identifier (GPSI), etc., but is not limited thereto.

[0155] In some embodiments, the request message may not include the resource owner's identification.

[0156] In some embodiments, an API caller on the second entity sends a request message to the first entity. Optionally, the API caller may be a part of the second entity, or an API caller residing on the second entity.

[0157] In some embodiments, the resource owner client on the second entity sends a request message to the first entity. Optionally, the resource owner client may correspond to the user agent in FIG1b .

[0158] S203: The first entity determines whether to authorize the API caller based on the request message and the identifier of the second entity.

[0159] In some embodiments, the first entity is able to identify the second entity sending the token request message after authentication of the second entity.

[0160] In some embodiments, names such as identification are not limited to the names described in the embodiments, and terms such as "identify", "determine", "obtain", and "get" can be used interchangeably.

[0161] In some embodiments, the API caller may be an API caller on the second entity.

[0162] In some embodiments, when the second entity is a terminal, whether to authorize the API caller on the second entity is determined based on an identifier of the second entity.

[0163] In some embodiments, the API caller on the second entity indicates an API caller that resides on the second entity or is a part of the second entity.

[0164] Optionally, some of the API callers of the second entity may be the second entity itself, and the API callers residing on the second entity may be various applications (Application, APP) on the second entity, exemplarily, QQ, WeChat, etc., but not limited thereto.

[0165] In some embodiments, if the request message includes an identifier of a resource owner, for example, an identifier of a first resource owner, the first entity 102 determines whether to authorize the API caller based on a first condition.

[0166] Optionally, the first condition is determined based on an association between the identifier of the second entity and the identifier of the resource owner included in the request message.

[0167] In some embodiments, the first condition includes: the identifier of the second entity is the same as the identifier of the first resource owner, or the identifier of the second entity has a corresponding relationship with the identifier of the first resource owner.

[0168] In some embodiments, the names of corresponding relationships are not limited to the names described in the embodiments, and terms such as "correspondence, corresponding relationship", "mapping relationship", "binding relationship", and "association relationship" can be used interchangeably.

[0169] Optionally, the identifier of the second entity is associated with the identifier of the first resource owner.

[0170] In some embodiments, the correspondence between the identification of the second entity and the identification of the first resource owner is stored by the first entity.

[0171] Optionally, the first entity locally stores a correspondence between the identifier of the second entity and the identifier of the first resource owner.

[0172] Illustratively, the first entity may find the identifier of the resource owner corresponding to or associated with the second entity based on the identifier of the second entity, for example, the identifier of the first resource owner.

[0173] In some embodiments, if the identifier of the second entity satisfies the first condition, it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

[0174] Optionally, if the identifier of the second entity is the same as the identifier of the first resource owner, it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

[0175] Optionally, if the identifier of the second entity corresponds to the identifier of the first resource owner, the process continues to determine whether to determine the authorized API caller.

[0176] In some embodiments, the specific implementation process of the first entity authorizing the API caller can be implemented using relevant technologies, which will not be repeated for the sake of brevity.

[0177] In some embodiments, if the identifier of the second entity does not satisfy the first condition, it is determined that the API caller is not authorized.

[0178] Optionally, if the identifier of the second entity is different from the identifier of the first resource owner, it is determined that the API caller is not authorized.

[0179] Optionally, if the identifier of the second entity does not correspond to the identifier of the first resource owner, it is determined that the API caller is not authorized.

[0180] In some embodiments, if the request message does not include the identity of the resource owner, the first entity 102 determines whether to authorize the API caller based on the second condition.

[0181] Optionally, the second condition is determined based on the identifier of the second entity and the identifier of the resource owner stored locally by the first entity and the association relationship between the identifier of the resource owner and the identifier of the second entity.

[0182] In some embodiments, the second condition includes: the identifier of the second entity is the same as the identifier of the second resource owner, or the identifier of the second entity corresponds to the identifier of the second resource owner, wherein the identifier of the second resource owner is one of the identifiers of at least one resource owner stored by the first entity.

[0183] Optionally, the second condition includes: the identifier of the second entity is the same as one of the identifiers of at least one resource owner stored locally by the first entity (for example, the identifier of the second resource owner), or the identifier of the second entity has a corresponding relationship with one of the identifiers of at least one resource owner stored locally by the first entity.

[0184] In some embodiments, the correspondence between the identification of the second entity and the identification of at least one resource owner is stored by the first entity.

[0185] Optionally, the first entity locally stores a correspondence between the identifier of the second entity and the identifier of at least one resource owner.

[0186] In some embodiments, the identifier of the second entity satisfies the second condition, and the API caller is determined to be authorized or to continue to determine whether to authorize the API caller.

[0187] Optionally, if the identifier of the second entity is the same as the identifier of the second resource owner in the at least one identifier of the resource owner stored locally by the first entity, it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

[0188] Optionally, if the identifier of the second entity corresponds to the identifier of the second resource owner among the at least one identifier of the resource owner stored locally by the first entity, it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

[0189] In some embodiments, the identifier of the second entity does not satisfy the second condition described above, and the authorized API caller is determined.

[0190] Optionally, if the identifier of the second entity is different from the identifiers of each resource owner stored locally by the first entity, it is determined that the API caller is not authorized.

[0191] Optionally, if the identifier of the second entity does not correspond to the identifiers of the resource owners stored locally by the first entity, it is determined that the API caller is not authorized.

[0192] Exemplarily, the first entity searches its locally stored correspondences based on the authenticated second entity's identifier for an identifier of the resource owner that is identical to, associated with, bound to, or corresponding to the second entity's identifier. If the identifier is found, the API caller is authorized; otherwise, the API caller is not authorized.

[0193] In some embodiments, terms such as "in the case of", "at the time of", "when", "if", and "if" can be used interchangeably.

[0194] S204: The first entity sends a response message to the second entity.

[0195] In some embodiments, if the API caller is determined to be authorized, the response message includes a token generated for the authorized API caller and including an identifier of the corresponding resource owner.

[0196] In some embodiments, if the request message includes an identifier of a resource owner, for example, an identifier of a first resource owner, and the API caller is determined to be authorized, the response message includes a token generated for the API caller and including the identifier of the first resource owner.

[0197] In some embodiments, if the request message does not include the identification of the resource owner and it is determined that the API caller is authorized, the response message includes a token generated for the API caller and including the identification of the second resource owner.

[0198] Optionally, based on the authenticated second entity's identifier, the first entity searches its locally stored correspondence for a resource owner identifier that is identical to, associated with, bound to, or corresponding to the second entity's identifier. If the resource owner identifier is found, for example, the second resource owner identifier is found, the first entity determines the authorized API caller, generates a token including the second resource owner identifier, and sends the token to the second entity via a response message.

[0199] In some embodiments, if it is determined that the API caller is not authorized, the response message is used to indicate the refusal to authorize the API caller.

[0200] Optionally, the first entity searches, based on the authenticated second entity's identifier, a locally stored correspondence for an identifier of the resource owner that is identical to, associated with, bound to, or corresponding to the second entity's identifier. If the resource owner identifier is not found, the first entity determines that the API caller is not authorized, and rejects the authorization request through a response message.

[0201] In some embodiments, the first entity may correspond to the authorization server in Figures 1a to 1c. The second entity may correspond to the client in Figures 1b and 1c. When the second entity is an API caller, the API caller may also correspond to the client in Figures 1b and 1c.

[0202] The method involved in the embodiments of the present disclosure may include at least one of steps S201 to S204. For example, step S203 may be implemented as an independent embodiment, steps S202 and S203 may be implemented as independent embodiments, and steps S202, S203, and S204 may be implemented as independent embodiments, but are not limited thereto.

[0203] In some embodiments, steps S201 and S202 may be performed in an interchangeable order or simultaneously.

[0204] In some embodiments, step S201 is optional, and one or more of these steps may be omitted or replaced in different embodiments.

[0205] FIG3a is a flow chart of a method for authorization according to an embodiment of the present disclosure. As shown in FIG3a , the method can be performed by a first entity, and the method includes:

[0206] S301: Authenticate the identity of the second entity.

[0207] In some embodiments, the second entity may be a terminal.

[0208] In some embodiments, the second entity may be an API caller.

[0209] In some embodiments, when the second entity is an API caller, the identifier of the second entity is an API caller identifier.

[0210] The optional implementation of step S301 can refer to the optional implementation of step S201 in Figure 2 and other related parts in the embodiment involved in Figure 2, which will not be repeated here.

[0211] S302: Receive a request message sent by the second entity.

[0212] In some embodiments, the request message may include an identifier of the resource owner.

[0213] In some embodiments, the first entity may authenticate the second entity during the process of receiving the request message and obtain the authenticated identification of the second entity.

[0214] In some embodiments, the request message may be a token-related request message for requesting a token.

[0215] In some embodiments, the receiving entity sends a request message, but is not limited thereto, and the receiving entity may also receive a request message sent by other entities.

[0216] In some embodiments, the request message is received from an API caller on the second entity. Optionally, the API caller may be part of the second entity, or the API caller may reside on the second entity.

[0217] In some embodiments, the receiving request message is received from the resource owner client on the second entity. Optionally, the resource owner client may correspond to the user agent in FIG1b .

[0218] The optional implementation of step S302 can refer to the optional implementation of step S202 in Figure 2 and other related parts in the embodiment involved in Figure 2, which will not be repeated here.

[0219] S303: Determine whether to authorize the API caller based on the request message and the identifier of the second entity.

[0220] In some embodiments, the first entity 102 is able to identify the second entity sending the token request message after authentication of the second entity.

[0221] In some embodiments, the first entity 102 can authenticate the identity of the second entity upon receipt of the token request message.

[0222] In some embodiments, the first entity 102 is able to identify the second entity as the entity sending the request message after authentication of the second entity.

[0223] In some embodiments, if the request message includes an identifier of the resource owner, whether to authorize the API caller is determined based on a first condition, wherein the first condition is determined based on an association between the identifier of the second entity and the identifier of the resource owner included in the request message.

[0224] In some embodiments, if the request message does not include the identifier of the resource owner, whether to authorize the API caller is determined based on a second condition, wherein the second condition is determined based on the identifier of the second entity and the identifier of the resource owner stored locally by the first entity and the association relationship between the identifier and the identifier of the second entity.

[0225] In some embodiments, the API caller may be an API caller on the second entity.

[0226] In some embodiments, when the second entity is a terminal, whether to authorize the API caller on the second entity is determined based on an identifier of the second entity.

[0227] The optional implementation of step S303 can refer to the optional implementation of step S203 in FIG. 2 and other related parts in the embodiment involved in FIG. 2 , which will not be described in detail here.

[0228] S304: Send a response message to the second entity.

[0229] In some embodiments, if the API caller is determined to be authorized, the response message includes a token generated for the authorized API caller and including an identifier of the corresponding resource owner.

[0230] In some embodiments, if it is determined that the API caller is authorized, the existing related technologies may be referred to to continue determining whether to authorize the API caller.

[0231] In some embodiments, if it is determined that the API caller is not authorized, the response message is used to indicate the refusal to authorize the API caller.

[0232] The optional implementation of step S304 can refer to the optional implementation of step S204 in FIG. 2 and other related parts in the embodiment involved in FIG. 2 , which will not be described in detail here.

[0233] The method involved in the embodiments of the present disclosure may include at least one of steps S301 to S304. For example, step S303 may be implemented as an independent embodiment, steps S302 and S303 may be implemented as independent embodiments, and steps S301, S302, and S303 may be implemented as independent embodiments, but are not limited thereto.

[0234] In some embodiments, step S301 is optional, and one or more of these steps may be omitted or replaced in different embodiments.

[0235] FIG3 b is a flow chart of a method for authorization according to an embodiment of the present disclosure. As shown in FIG3 b , the method may be performed by a first entity, and the method includes:

[0236] S311. Receive a request message sent by the second entity.

[0237] In some embodiments, the request message may include an identifier of the resource owner.

[0238] In some embodiments, the first entity may authenticate the second entity during the process of receiving the request message and obtain the authenticated identification of the second entity.

[0239] In some embodiments, the request message may be a token-related request message for requesting a token.

[0240] In some embodiments, the receiving entity sends a request message, but is not limited thereto, and the receiving entity may also receive a request message sent by other entities.

[0241] In some embodiments, the request message is received from an API caller on the second entity. Optionally, the API caller may be part of the second entity, or the API caller may reside on the second entity.

[0242] In some embodiments, the receiving request message is received from the resource owner client on the second entity. Optionally, the resource owner client may correspond to the user agent in FIG1b .

[0243] The optional implementation of step S311 can refer to the optional implementation of step S202 in FIG. 2 and other related parts in the embodiment involved in FIG. 2 , which will not be described in detail here.

[0244] S312: Determine whether to authorize the API caller based on the request message and the identifier of the second entity.

[0245] In some embodiments, if the request message includes an identifier of the resource owner, whether to authorize the API caller is determined based on a first condition, wherein the first condition is determined based on an association between the identifier of the second entity and the identifier of the resource owner included in the request message.

[0246] In some embodiments, if the request message does not include an identifier of the resource owner, whether to authorize the API caller is determined based on a second condition, wherein the second condition is determined based on the identifier of the second entity and the identifier of the resource owner stored locally by the first entity and the association between the identifier and the identifier of the second entity.

[0247] In some embodiments, the API caller may be an API caller on the second entity.

[0248] In some embodiments, when the second entity is a terminal, whether to authorize the API caller on the second entity is determined based on an identifier of the second entity.

[0249] The optional implementation of step S312 can refer to the optional implementation of step S203 in FIG2 and other related parts in the embodiment involved in FIG2 , which will not be described in detail here.

[0250] S313. Send a response message to the second entity.

[0251] In some embodiments, if the API caller is determined to be authorized, the response message includes a token generated for the authorized API caller and including an identifier of the corresponding resource owner.

[0252] In some embodiments, if it is determined that the API caller is authorized, the existing related technologies may be referred to to continue determining whether to authorize the API caller.

[0253] In some embodiments, if it is determined that the API caller is not authorized, the response message is used to indicate the refusal to authorize the API caller.

[0254] The optional implementation of step S313 can refer to the optional implementation of step S204 in FIG2 and other related parts in the embodiment involved in FIG2 , which will not be described in detail here.

[0255] The method involved in the embodiment of the present disclosure may include at least one of steps S310 to S313. For example, step S312 may be implemented as an independent embodiment, and steps S310 and S312 may be implemented as independent embodiments, but are not limited thereto.

[0256] FIG3c is a flow chart of a method for authorization according to an embodiment of the present disclosure. As shown in FIG3c, the method can be performed by a first entity, and the method includes:

[0257] S321: Determine whether to authorize the application programming interface (API) caller based on the identifier of the second entity.

[0258] Optional implementations of step S321 may refer to the optional implementations of step S203 in FIG. 2 , step S303 in FIG. 3 a , step S312 in FIG. 3 b , and other related parts in the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be described in detail here.

[0259] In some embodiments, further comprising: receiving a request message from a second entity; and wherein,

[0260] Determining whether to authorize the API caller based on the identifier of the second entity includes:

[0261] Based on the request message and the identifier of the second entity, it is determined whether the API caller is authorized.

[0262] Optional implementations of the above optional embodiments can refer to the optional implementations of step S202 in FIG. 2 , step S302 in FIG. 3 a , step S311 in FIG. 3 b , and other related parts of the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be repeated here.

[0263] In some embodiments, the request message includes an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes:

[0264] Based on the first condition, determining whether to authorize the API caller;

[0265] The first condition includes: the identifier of the second entity is the same as the identifier of the first resource owner, or the identifier of the second entity has a corresponding relationship with the identifier of the first resource owner.

[0266] In some embodiments, determining whether to authorize the API caller based on the first condition includes: if the identifier of the second entity meets the first condition, determining to authorize the API caller or determining to continue to determine whether to authorize the API caller.

[0267] In some embodiments, the method further includes: if it is determined that the API caller is authorized, sending a response message to the second entity, the response message including a token generated for the API caller and including an identifier of the first resource owner.

[0268] For the optional implementation of the above optional embodiment, reference may be made to the optional implementation of step S204 in FIG. 2 , step S304 in FIG. 3 a , step S313 in FIG. 3 b , and other related parts in the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be described in detail here.

[0269] In some embodiments, determining whether to authorize the API caller based on the first condition includes: if the identifier of the second entity does not meet the first condition, determining not to authorize the API caller.

[0270] In some embodiments, the correspondence between the identification of the second entity and the identification of the first resource owner is stored by the first entity.

[0271] In some embodiments, the request message does not include an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes: determining whether to authorize the API caller based on a second condition;

[0272] The second condition includes: the identifier of the second entity is the same as the identifier of the second resource owner, or the identifier of the second entity is in a corresponding relationship with the identifier of the second resource owner;

[0273] The identifier of the second resource owner is one of the identifiers of at least one resource owner stored by the first entity.

[0274] In some embodiments, determining whether to authorize the API caller based on the second condition includes: if the identifier of the second entity meets the second condition, determining to authorize the API caller or determining to continue to determine whether to authorize the API caller.

[0275] In some embodiments, the method further comprises sending a response message to the second entity, the response message comprising a token generated for the API caller and comprising an identification of the second resource owner.

[0276] Optional implementations of the above optional embodiments can refer to the optional implementations of step S202 in FIG. 2 , step S302 in FIG. 3 a , step S311 in FIG. 3 b , and other related parts of the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be repeated here.

[0277] In some embodiments, determining whether to authorize the API caller based on the second condition includes: if the identifier of the second entity does not satisfy the second condition, determining not to authorize the API caller.

[0278] In some embodiments, the correspondence between the identification of the second entity and the identification of at least one resource owner is stored by the first entity.

[0279] In some embodiments, the method further includes: sending a response message to the second entity, where the response message is used to indicate a refusal to authorize the API caller.

[0280] Optional implementations of the above optional embodiments can refer to the optional implementations of step S202 in FIG. 2 , step S302 in FIG. 3 a , step S311 in FIG. 3 b , and other related parts of the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be repeated here.

[0281] In some embodiments, the identification of the second entity is an identification of the second entity authenticated by the first entity.

[0282] In some embodiments, the identity of the second entity authenticated by the first entity is obtained before the first entity sends the authorization code to the second entity; or, the identity of the second entity authenticated by the first entity is obtained before the first entity sends the token to the second entity.

[0283] The optional implementation of the above optional embodiment can refer to the optional implementation of step S201 in Figure 2, step S301 in Figure 3a, and other related parts in the embodiments involved in Figures 2 and 3a, which will not be repeated here.

[0284] In some embodiments, the API caller is an API caller on the second entity.

[0285] In some embodiments, the second entity includes a terminal, or an API caller.

[0286] In some embodiments, the second entity is a terminal, and step S321 may specifically include: determining whether to authorize the API caller on the second entity based on the identifier of the second entity.

[0287] Optional implementations of step S321 may refer to the optional implementations of step S203 in FIG. 2 , step S303 in FIG. 3 a , step S312 in FIG. 3 b , and other related parts in the embodiments involved in FIG. 2 and FIG. 3 a - 3 b , which will not be described in detail here.

[0288] In some embodiments, the first entity includes an entity that implements authorization functions, or an entity that implements core functions of a general application programming interface framework.

[0289] FIG4 is a flow chart of a communication method according to an embodiment of the present disclosure. As shown in FIG4 , the method according to the embodiment of the present disclosure is used in a communication system 100, and the method includes:

[0290] S401: The second entity sends a request message to the first entity.

[0291] Optional implementations of step S402 may refer to the optional implementations of step S202 in Figure 2 and other related parts of the embodiment involved in Figure 2, which will not be repeated here. In some embodiments, the first entity may authenticate the second entity during the process of receiving the request message and obtain the authenticated identification of the second entity.

[0292] S402: The first entity determines whether to authorize the application program interface (API) caller based on the request message and the identifier of the second entity.

[0293] The optional implementation of step S402 can refer to the optional implementation of step S203 in Figure 2, step S303 in Figure 3a, step S312 in Figure 3b, step 321 in Figure 3c, and other related parts in the embodiments involved in Figure 2 and Figures 3a to 3c, which will not be repeated here.

[0294] The present disclosure also provides an optional implementation scheme, in which the first entity (e.g., CCF / authorization function) may correspond to the authorization server in FIG1c, and the second entity (e.g., UE, terminal, API invoker on the terminal, API invoker) may correspond to the client in FIG1c. Authenticated before or during step S501 as shown in FIG5. The first entity (e.g., CCF / authorization function) is able to identify the second entity identifier or terminal identifier or UE identifier related to the second entity that sends the request message or token request message after the second entity (e.g., UE, terminal, API invoker on the terminal, API invoker) is authenticated.

[0295] S501. A second entity sends a token-related request message to a CCF / authorization function. The process by which a first entity (e.g., CCF / authorization function) authenticates a second entity may be described with reference to the implementation of step S121 in FIG. 1c . The token-related request message may include a resource owner identifier. In some embodiments, the first entity may authenticate the second entity during receipt of the request message and obtain the second entity's authenticated identifier.

[0296] The second entity (e.g., UE, terminal, API invoker on the terminal, API invoker) is authenticated before or during step S501 as shown in Figure 5. The first entity (e.g., CCF / authorization function) is able to identify the second entity identifier or terminal identifier or UE identifier related to the second entity sending the request message or token request message after the second entity (e.g., UE, terminal, API invoker on the terminal, API invoker) is authenticated. The first entity (e.g., CCF / authorization function) needs to check the relationship between the resource owner identifier and the authenticated second entity identifier or terminal identifier or UE identifier.

[0297] If the request message associated with the token includes a resource owner identifier, the first entity (e.g., CCF / authorization function) first checks whether the authenticated second entity identifier or terminal identifier or UE identifier is the same as the resource owner identifier, or whether the authenticated second entity identifier or terminal identifier or UE identifier can be mapped to the resource owner identifier in the request message. If the two are the same or have a mapping relationship, the first entity (e.g., CCF / authorization function) further authorizes the API caller based on the authenticated API caller identifier (e.g., API invoker ID, WeChat ID, etc.) as described in step S121 in reference to Figure 1c. Otherwise, CCF will reject the token request.

[0298] If the request message associated with the token does not include a resource owner identifier, the CCF / authorization function assumes that the API caller requests access to the resources of a specific terminal. When the API caller is an API caller residing on a terminal (API invoker residing on UE), the specific terminal is the terminal where the API invoker resides. When the API caller is part of the terminal, the specific terminal is the terminal corresponding to the API caller. The CCF / authorization function retrieves the locally stored resource owner identifier based on the authenticated second entity identifier or terminal identifier or UE identifier. If a resource owner identifier that is identical to the authenticated second entity identifier or terminal identifier or UE identifier is retrieved, or a resource owner identifier that has a mapping relationship with the authenticated second entity identifier or terminal identifier or UE identifier is retrieved, the CCF / authorization function issues a token containing the resource owner identifier to the API caller. If not retrieved, the CCF rejects the token request.

[0299] S502: If the second entity is authorized, the CCF / authorization function sends the token to the second entity via a token response message.

[0300] The present disclosure also provides an optional implementation scheme, in which the CCF / authorization function may correspond to the authorization server in FIG1b, and the second entity may correspond to the client in FIG1b. The second entity (e.g., UE) may be authenticated before step S111, or between step S111 and step S112, or between step S112 and step S113. The first entity (e.g., CCF / authorization function) is able to identify the second entity identifier, terminal identifier, or UE identifier that sends the request message or token request message after the second entity (e.g., UE) is authenticated.

[0301] S111. The API caller sends a request message to the CCF / authorization function. The request message may include a resource owner identifier.

[0302] S112: The CCF / authorization function authenticates the resource owner. The CCF obtains the authenticated resource owner ID.

[0303] S113. The CCF / authorization function may check the relationship between the resource owner identifier and the authenticated second entity identifier or terminal identifier or UE identifier.

[0304] If the authenticated second entity identifier or terminal identifier or UE identifier is the same as the resource owner identifier or can be mapped to the resource owner identifier, the CCF / authorization function further authorizes the API caller based on the authenticated API caller ID, which can be implemented with reference to step S114 in Figure 1b. Otherwise, the CCF / authorization function will reject the token request.

[0305] The embodiments of the present disclosure further provide a device for implementing any of the above methods. For example, a device is provided, which includes units or modules for implementing each step performed by the first entity in any of the above methods.

[0306] It should be understood that the division of the various units or modules in the above device is merely a division of logical functions. In actual implementation, they may be fully or partially integrated into a physical entity, or they may be physically separated. In addition, the units or modules in the device may be implemented in the form of a processor calling software: for example, the device includes a processor, the processor is connected to a memory, and the memory stores instructions. The processor calls the instructions stored in the memory to implement any of the above methods or implement the functions of the various units or modules of the above device, wherein the processor is, for example, a general-purpose processor, such as a central processing unit (CPU) or a microprocessor, and the memory is a memory within the device or a memory outside the device. Alternatively, the units or modules in the device can be implemented in the form of hardware circuits, and the functions of some or all of the units or modules can be realized by designing the hardware circuits. The above-mentioned hardware circuits can be understood as one or more processors; for example, in one implementation, the above-mentioned hardware circuit is an application-specific integrated circuit (ASIC), and the functions of some or all of the above units or modules are realized by designing the logical relationship of the elements in the circuit; for example, in another implementation, the above-mentioned hardware circuit can be implemented by a programmable logic device (PLD), taking a field programmable gate array (FPGA) as an example, which can include a large number of logic gate circuits, and the connection relationship between the logic gate circuits is configured by a configuration file, thereby realizing the functions of some or all of the above units or modules.

[0307] All units or modules of the above devices can be implemented in the form of software called by the processor, or in the form of hardware circuits, or partially implemented in the form of software called by the processor, and the remaining part implemented in the form of hardware circuits. In the embodiment of the present disclosure, the processor is a circuit with signal processing capabilities. In one implementation, the processor can be a circuit with instruction reading and execution capabilities, such as a central processing unit (CPU), a microprocessor, a graphics processing unit (GPU) (which can be understood as a microprocessor), or a digital signal processor (DSP); in another implementation, the processor can implement certain functions through the logical relationship of the hardware circuit. The logical relationship of the above hardware circuit is fixed or reconfigurable, such as a hardware circuit implemented by a processor as an application-specific integrated circuit (ASIC) or a programmable logic device (PLD), such as an FPGA. In a reconfigurable hardware circuit, the process of the processor loading a configuration document to implement the hardware circuit configuration can be understood as the process of the processor loading instructions to implement the functions of some or all of the above units or modules. In addition, it can also be a hardware circuit designed for artificial intelligence, which can be understood as ASIC, such as a neural network processing unit (NPU), a tensor processing unit (TPU), a deep learning processing unit (DPU), etc.

[0308] Figure 6 is a schematic diagram of the structure of a first entity for authorization proposed in an embodiment of the present disclosure. As shown in Figure 6, the first entity may include: at least one of a transceiver module 601, a processing module 602, etc.

[0309] In some embodiments, the processing module 602 is configured to determine whether to authorize the application programming interface (API) caller based on the identification of the second entity.

[0310] Optionally, the processing module 602 is further configured to execute authentication-related steps performed by the first entity in any of the above methods, such as step S201 shown in FIG. 2 , which will not be described in detail here.

[0311] Optionally, the above-mentioned transceiver module 601 is also used to execute the steps related to sending and receiving signaling performed by the first entity in any of the above methods, for example: at least one of steps S202 and S204 shown in Figure 2, which will not be repeated here.

[0312] Figure 7a is a schematic diagram of the structure of a communication device 7100 proposed in an embodiment of the present disclosure. Communication device 7100 can be a first entity implementing authorization functions, or a first entity implementing the core functions of a universal application program interface framework, or a chip, chip system, or processor that supports the first entity in implementing any of the above methods. Communication device 7100 can be used to implement the methods described in the above method embodiments. For details, please refer to the description of the above method embodiments.

[0313] As shown in Figure 7a, the communication device 7100 includes one or more processors 7101. The processor 7101 can be a general-purpose processor or a dedicated processor, for example, a baseband processor or a central processing unit. The baseband processor can be used to process communication protocols and communication data, and the central processing unit can be used to control the communication device (such as a base station, baseband chip, terminal device, terminal device chip, DU or CU, etc.), execute programs, and process program data. The processor 7101 is used to call instructions to enable the communication device 7100 to perform any of the above methods.

[0314] In some embodiments, the communication device 7100 further includes one or more transceivers 7102. When the communication device 7100 includes one or more transceivers 7102, the transceiver 7102 performs at least one of the communication steps such as sending and / or receiving in the above method (for example, at least one of steps S202 and S204 shown in FIG2 , but not limited thereto), and the processor 7101 performs at least one of the other steps (for example, at least one of steps S201 and S203 shown in FIG2 , but not limited thereto). In an optional embodiment, the transceiver may include a receiver and / or a transmitter, and the receiver and transmitter may be separate or integrated. Optionally, the terms transceiver, transceiver unit, transceiver, transceiver circuit, interface circuit, and interface may be interchangeable, the terms transmitter, transmitting unit, transmitter, and transmitting circuit may be interchangeable, and the terms receiver, receiving unit, receiver, and receiving circuit may be interchangeable.

[0315] In some embodiments, the communication device 7100 further includes one or more memories 7102 for storing instructions. Optionally, all or part of the memories 7102 may be located outside the communication device 7100.

[0316] In some embodiments, the communication device 7100 further includes one or more transceivers 7103. When the communication device 7100 includes one or more transceivers 7103, the communication steps such as sending and receiving in the above method are performed by the transceiver 7103, and the other steps are performed by the processor 7101.

[0317] In some embodiments, a transceiver may include a receiver and a transmitter, which may be separate or integrated. Optionally, the terms transceiver, transceiver unit, transceiver, and transceiver circuit may be used interchangeably; the terms transmitter, transmitting unit, transmitter, and transmitting circuit may be used interchangeably; and the terms receiver, receiving unit, receiver, and receiving circuit may be used interchangeably.

[0318] Optionally, the communication device 7100 further includes one or more interface circuits 7104, which are connected to the memory 7102. The interface circuits 7104 may be configured to receive signals from the memory 7102 or other devices, and may be configured to send signals to the memory 7102 or other devices. For example, the interface circuits 7104 may read instructions stored in the memory 7102 and send the instructions to the processor 7101.

[0319] The communication device 7100 described in the above embodiment may be the first entity that implements the authorization function, or the first entity that implements the core function of the general application program interface framework, but the scope of the communication device 7100 described in the embodiment of the present disclosure is not limited to this, and the structure of the communication device 7100 may not be limited by Figure 7a. The communication device may be an independent device or may be part of a larger device. For example, the communication device may be: 1) an independent integrated circuit IC, or a chip, or a chip system or subsystem; (2) a collection of one or more ICs, optionally, the above IC collection may also include a storage component for storing data and programs; (3) an ASIC, such as a modem; (4) a module that can be embedded in other devices; (5) a receiver, a terminal device, an intelligent terminal device, a cellular phone, a wireless device, a handheld device, a mobile unit, an in-vehicle device, a network device, a cloud device, an artificial intelligence device, etc.; (6) others, etc.

[0320] FIG7 b is a schematic diagram of the structure of a chip 7200 according to an embodiment of the present disclosure. If the communication device 7100 can be a chip or a chip system, reference can be made to the schematic diagram of the structure of the chip 7200 shown in FIG7 b , but the present disclosure is not limited thereto.

[0321] The chip 7200 includes one or more processors 7201. The chip 7200 is configured to execute any of the above methods.

[0322] In some embodiments, chip 7200 further includes one or more interface circuits 7202. Alternatively, terms such as interface circuit, interface, and transceiver pins may be used interchangeably. In some embodiments, chip 7200 further includes one or more memories 7203 for storing data. Alternatively, all or part of memory 7203 may be located external to chip 7200. Optionally, interface circuit 7202 is connected to memory 7203 and may be used to receive data from memory 7203 or other devices, or may be used to send data to memory 7203 or other devices. For example, interface circuit 7202 may read data stored in memory 7203 and send the data to processor 7201.

[0323] In some embodiments, the interface circuit 7202 performs at least one of the communication steps, such as sending and / or receiving, in the above-described method (e.g., at least one of steps S202 and S204 shown in FIG. 2 , but not limited thereto). The interface circuit 7202 performing the communication steps, such as sending and / or receiving, in the above-described method, for example, means that the interface circuit 7202 performs data exchange between the processor 7201, the chip 7200, the memory 7203, or the transceiver device. In some embodiments, the processor 7201 performs at least one of the other steps (e.g., at least one of steps S201 and S203 shown in FIG. 2 , but not limited thereto).

[0324] The present disclosure also provides a program product, which, when executed by the communication device 7100, enables the communication device 7100 to perform any of the above methods. Optionally, the program product is a computer program product.

[0325] The present disclosure also proposes a computer program, which, when executed on a computer, causes the computer to perform any one of the above methods.

[0326] The technical solutions described in the embodiments of the present disclosure can be combined arbitrarily unless there is any conflict.

[0327] Other embodiments of the present invention will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of the invention that follow from the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

[0328] It should be understood that the present invention is not limited to the exact construction described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A method for authorization, characterized in that Applied to a first entity, the method comprises: Based on the identification of the second entity, determine whether to authorize the application programming interface (API) caller.

2. The method according to claim 1, characterized in that Also includes: receiving a request message from the second entity; And among them, The determining whether to authorize the API caller based on the identifier of the second entity includes: Based on the request message and the identifier of the second entity, determine whether to authorize the API caller.

3. The method according to claim 2, characterized in that The request message includes an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes: Based on the first condition, determining whether to authorize the API caller; The first condition includes: the identifier of the second entity is the same as the identifier of the first resource owner, or the identifier of the second entity corresponds to the identifier of the first resource owner.

4. The method according to claim 3, characterized in that The determining whether to authorize the API caller based on the first condition includes: The identifier of the second entity satisfies the first condition, and it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

5. The method according to claim 4, characterized in that The method further comprises: If it is determined that the API caller is authorized, a response message is sent to the second entity, the response message including a token generated for the API caller and including the identifier of the first resource owner.

6. The method according to claim 3, characterized in that The determining whether to authorize the API caller based on the first condition includes: The identifier of the second entity does not satisfy the first condition, and it is determined that the API caller is not authorized.

7. The method according to any one of claims 3 to 6, characterized in that: The correspondence between the identifier of the second entity and the identifier of the first resource owner is stored by the first entity.

8. The method according to claim 2, characterized in that: The request message does not include an identifier of the first resource owner, and determining whether to authorize the API caller based on the request message and the identifier of the second entity includes: Based on the second condition, determining whether to authorize the API caller; The second condition includes: the identifier of the second entity is the same as the identifier of the second resource owner, or the identifier of the second entity is in a corresponding relationship with the identifier of the second resource owner; The identifier of the second resource owner is one of the identifiers of at least one resource owner stored by the first entity.

9. The method according to claim 8, characterized in that The determining whether to authorize the API caller based on the second condition includes: The identifier of the second entity satisfies the second condition, and it is determined to authorize the API caller or to continue to determine whether to authorize the API caller.

10. The method according to claim 9, characterized in that The method further comprises: If it is determined that the API caller is authorized, a response message is sent to the second entity, the response message including a token generated for the API caller and including an identifier of the second resource owner.

11. The method according to claim 8, characterized in that The determining whether to authorize the API caller based on the second condition includes: The identifier of the second entity does not satisfy the second condition, and it is determined that the API caller is not authorized.

12. The method according to any one of claims 8 to 11, characterized in that The correspondence between the identifier of the second entity and the identifier of the at least one resource owner is stored by the first entity.

13. The method according to claim 6 or 11, characterized in that: The method further comprises: A response message is sent to the second entity, where the response message is used to indicate that authorization of the API caller is rejected.

14. The method according to any one of claims 1 to 13, characterized in that The identifier of the second entity is an identifier of the second entity authenticated by the first entity.

15. The method according to claim 14, characterized in that The identifier of the second entity authenticated by the first entity is obtained before the first entity sends the authorization code to the second entity; or The identification of the second entity authenticated by the first entity is obtained before the first entity sends a token to the second entity.

16. The method according to any one of claims 1 to 15, characterized in that The API caller is an API caller on the second entity.

17. The method according to any one of claims 1 to 15, characterized in that The second entity includes a terminal, or the API caller.

18. The method according to claim 17, characterized in that The second entity is a terminal, and determining whether to authorize the application program interface API caller based on the identifier of the second entity includes: Based on the identifier of the second entity, determine whether to authorize the API caller on the second entity.

19. The method according to any one of claims 1 to 18, characterized in that The first entity includes an entity that implements an authorization function, or the first entity includes an entity that implements a core function of a general application programming interface framework.

20. A first entity for authorization, characterized in that: include: The processing module is used to determine whether to authorize the application program interface API caller based on the identification of the second entity.

21. A first entity for authorization, characterized in that: include: one or more processors; The first entity is used to execute any one of the methods in claims 1 to 19.

22. A communication system, characterized in that: include: A first entity and a second entity, wherein the first entity is used to execute the method for authorization described in any one of claims 1 to 19 to implement authorization or non-authorization of an application program interface API caller, wherein the API caller is the second entity, or an API caller on the second entity.

23. A storage medium storing instructions, characterized in that: When the instruction is executed on a communication device, the communication device is caused to execute the method according to any one of claims 1 to 19.

Images