CN114615071A - Method for carrying out unified authentication on RESTful API under micro-service architecture - Google Patents
Method for carrying out unified authentication on RESTful API under micro-service architecture Download PDFInfo
- Publication number
- CN114615071A CN114615071A CN202210281798.6A CN202210281798A CN114615071A CN 114615071 A CN114615071 A CN 114615071A CN 202210281798 A CN202210281798 A CN 202210281798A CN 114615071 A CN114615071 A CN 114615071A
- Authority
- CN
- China
- Prior art keywords
- authority
- authentication
- token
- role
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/102—Entity profiles
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Abstract
The invention relates to a method for carrying out unified authentication on RESTful API under a micro-service architecture, which specifically comprises the following steps: permission configuration, user authorization, client application Token and gateway authentication. The invention is based on an RBAC authority model and a Token mechanism, uses a wildcard character and an HTTP Method as an authority identifier, realizes flexible definition of RESTful API authority, solves the problem of difficulty in uniform authentication of RESTful API, and simultaneously uses the Token mechanism, avoids the risk of authority information leakage caused by using a JWT (JSON Web Token) mechanism in the prior art, enables each micro-service module to only concentrate on business logic realization, and improves the development efficiency of business services.
Description
Technical Field
The invention belongs to the technical field of computer application, and particularly relates to a method for carrying out unified authentication on RESTful API under a micro-service architecture.
Background
With the popularity of micro-service architecture, more and more enterprises micro-service traditional single applications, each micro-service only focuses on the logic implementation of the service itself, and some common logic processing is put on the micro-service gateway for implementation, including: authentication, authentication and the like, and each service provides the API to the client to call through the gateway in a RESTful form.
In the era of popular micro-services, the authentication and authorization method is almost the same as before, but due to different scene architectures, the scheme applicable to the authentication and authorization method is different, and generally, there are four schemes: one is Single Sign On (SSO); second, the distributed Session scheme; thirdly, a client Token scheme; and fourthly, combining the client Token with the API gateway. In the prior art, CN110225039B provides a rights model obtaining and authenticating method, gateway, server and storage medium, so that the rights model is decoupled from the API request; CN113098695 also provides a micro-service unified right control method based on user attributes, which provides a standardized right control interface at a gateway layer, facilitates unified management, introduces user attribute information to refine granularity of resource access, and improves security of right management. However, the operability of the above technical solution in the RESTful architecture style is not high enough to solve the authentication problem of the RESTful API in the micro service architecture.
Disclosure of Invention
Aiming at the defects in the prior art, the technical problem to be solved by the invention is to provide a method for uniformly authenticating RESTful API under a micro-service architecture, and avoid the problem of difficult uniform authentication of RESTful API.
In order to solve the technical problems, the invention adopts the following technical scheme:
a method for unified authentication of RESTful API under micro-service architecture specifically comprises the following steps:
s1: configuring the authority; establishing a user table, a role table, a permission table, a user role relationship table and a role permission relationship table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the permissions configured in step S1 with roles, associating users with roles;
s3: a client applies for Token; the client acquires a Token in an authentication service provided by the micro service gateway through a legal user name and a password, and stores the Token and the authority information of the corresponding user into a redis;
s4: gateway authentication; after receiving an access request of a client, the micro service gateway authenticates the identity of the client and returns authentication result information to perform logic judgment, and if the judgment fails, the micro service gateway returns error information to the client; if the authentication is judged to be successful, authentication processing is carried out, and if the authentication result is that the client does not have the right to access the current API, the micro service gateway returns no-right access prompt information to the client; and if the authentication result is that the client has the authority to the currently accessed API, the micro-service gateway forwards the access request to a micro-service module at the rear end for corresponding service logic processing.
Further perfecting the technical scheme, in the step S1,
the user table comprises user ID, user name and password fields;
the role table comprises role ID and role name fields;
the authority table comprises an authority ID and an authority identification field;
the user role relation table comprises user ID and role ID fields;
the role authority relationship table comprises role ID and authority ID fields.
Further, the format that each authority identification field in the authority table needs to satisfy is as follows: URL _ PATH, HTTP _ METHOD;
the URL _ PATH represents an access PATH of RESTful API, and the HTTP _ METHOD represents a mode that the client requests the URL _ PATH; the format of the URL _ PATH conforms to Apache Ant style, and the HTTP _ METHOD satisfies the HTTP/1.1 protocol specification.
Further, the step S2 further includes:
s21: adding records of role and authority association in the role authority relationship table: associating the role ID in the role authority relationship table to a role table, and associating the authority ID in the role authority relationship table to an authority table;
s22: adding records of association between users and roles in the user role relationship table: and associating the user ID in the user role relationship table to the user table, and associating the role ID in the user role relationship table to the role table.
Further, in step S3, the authentication service behind the microservice gateway provides a user name and password authentication API and a Token authentication API, the authentication service performs judgment and verification on the user name and password input by the client, after the verification is passed, the authentication service provides a Token, and stores the Token and the authority information of the user corresponding to the Token in the redis for the subsequent service API to authenticate through the Token; the key of the redis is the value of the current Token, and the value is the authority information of the user corresponding to the Token.
Further, the Token is generated using a UUID, and has a length of 36 bits;
when the authentication service generates Token, the user role relationship table, the role authority relationship table and the authority table in the database are related and inquired through the user ID obtained in step S2 to obtain the authority list of the user, and the authority list of the user is stored into redis in a JSON character string form, where key of the redis is the value of current Token, and value is the authority information of the user corresponding to Token.
Further, in step S4, after the micro service gateway receives the access request of the client, the client needs to add the value of Token obtained in step S3 to the HTTP Header of each accessed micro service API, where the name of the Header is Token, the micro service gateway obtains the value of Token from the Header and calls the Token authentication API provided by the authentication service to perform client identity authentication, the authentication service queries the value of Token in redis, and if the value exists, returns authentication success information and authority information of the Token to the micro service gateway; if not, returning authentication failure information to the micro service gateway;
the logic judgment of the authentication result information returned by the received authentication service by the micro service gateway specifically comprises the following steps:
s41: acquiring an accessed API path (request _ url _ path) and a request mode (request _ http _ method);
s42: circularly traversing the authority list, identifying each authority in the authority list, splitting the authority list into arrays according to the colon, carrying out condition judgment, if the condition judgment result is that the condition is met, indicating that the currently accessed API has the authority, terminating the circulation, and simultaneously forwarding the request to a rear-end micro-service module by the micro-service gateway for service logic processing; otherwise, continuously traversing until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the client side is indicated to have no right to access the current API, and the micro service gateway returns no right access prompt information to the client side.
Further, the arrays each include two elements, the elements before the colon are represented by perm _ arr [0], and the elements after the colon are represented by perm _ arr [1 ];
the condition judgment comprises the following steps:
the first condition is that: judging whether perm _ arr [0] is matched with the accessed API path (request _ url _ path);
the second condition is that: judging whether perm _ arr [1] contains or not or a request mode (request _ http _ method);
and if the first condition and the second condition are simultaneously met, the condition judgment result is that the condition is met.
Compared with the prior art, the invention has the following beneficial effects:
the Method for the RESTful API unified authentication under the micro-service architecture is based on an RBAC authority model and a Token mechanism, uses a wildcard character and an HTTP Method as authority identifiers, realizes flexible definition of the RESTful API authority, solves the problem of difficulty in RESTful API unified authentication, simultaneously uses the Token mechanism, avoids the risk of authority information leakage caused by using a JWT (JSON Web Token) mechanism in the prior art, enables each micro-service module to be only concentrated on business logic realization, and improves the development efficiency of business services.
Drawings
Fig. 1 is a flowchart of a method for unified authentication of RESTful APIs under a micro service architecture according to an embodiment;
FIG. 2 is a diagram of the RBAC privilege model adopted by the present invention;
FIG. 3 is a flowchart of a client applying for Token according to the present invention;
fig. 4 is a flowchart of gateway authentication according to the present invention.
Detailed Description
The following describes embodiments of the present invention in further detail with reference to the accompanying drawings.
Referring to fig. 1, a method for unified authentication of a RESTful API under a micro service architecture in an embodiment specifically includes the following steps:
s1: configuring the authority; establishing a user table, a role table, a permission table, a user role relationship table and a role permission relationship table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the authority configured in step S1 with a role, associating the user with the role;
s3: client application Token; the client acquires a Token in an authentication service provided by the micro service gateway through a legal user name and a legal password, and stores the Token and the authority information of the corresponding user into the redis;
s4: gateway authentication; after receiving an access request of a client, the micro service gateway authenticates the identity of the client and returns authentication result information to perform logic judgment, and if the authentication fails, the micro service gateway returns error information to the client; if the authentication is judged to be successful, authentication processing is carried out, and if the authentication result is that the client does not have the right to access the current API, the micro service gateway returns no-right access prompt information to the client; and if the authentication result is that the client has the authority to the currently accessed API, the micro-service gateway forwards the access request to a micro-service module at the rear end for corresponding service logic processing.
The Method for the RESTful API unified authentication under the micro-service architecture is based on an RBAC authority model and a Token mechanism, uses a wildcard and an HTTP Method as an authority identifier, realizes flexible definition of the RESTful API authority, solves the problem of difficulty in RESTful API unified authentication, and simultaneously uses the Token mechanism, avoids the risk of authority information leakage caused by using a JWT (JSON Web Token) mechanism in the prior art, ensures that each micro-service module is only concentrated on business logic realization, and improves the development efficiency of business services.
Please refer to the drawings continuously, wherein, in the step S1,
the user table comprises user ID, user name and password fields;
the role table comprises role ID and role name fields;
the authority table comprises an authority ID and an authority identification field;
the user role relation table comprises user ID and role ID fields;
the role authority relationship table comprises role ID and authority ID fields.
Thus, an RBAC (Role-Based Access Control) authority model is adopted, is a general authority design model in the industry, and is realized by associating users with authorities through roles. In short, a User (User) has several roles (Role), each Role has several permissions (Perm), and thus, a "User-Role-permission" authorization model is constructed in which there are many-to-many relationships between users and roles, between roles and permissions, and generally.
Wherein, the format that each authority identification field in the authority table needs to satisfy is as follows: URL _ PATH, HTTP _ METHOD;
the METHOD comprises the steps that URL _ PATH represents an access PATH of RESTful API, HTTP _ METHOD represents a mode that a client requests the URL _ PATH; the format of the URL _ PATH conforms to Apache Ant style, and the HTTP _ METHOD satisfies the HTTP/1.1 protocol specification.
In implementation, the Apache Ant style path has three wildcard matching methods, as shown in the following table:
| wildcard character | Description of the preferred embodiment |
| ？ | Matching any single character |
| * | Match 0 or any number of characters |
| ** | Matching 0 or more directories |
In this way, bulk identification of a certain class of resources can be achieved using wildcards.
In particular, some examples of wildcard use are listed here, see the following table:
meanwhile, the common values of the HTTP/1.1 protocol specification are shown in the following table:
the value of HTTP _ METHOD is one or more of the above tables, and when there are more, comma division is used between each value, such as: "GET, POST" or "GET, POST, PUT"; the "+" notation is used when any legitimate HTTP/1.1Method is allowed; and the URL _ PATH and the HTTP _ METHOD use colon segmentation to split the URL _ PATH and the HTTP _ METHOD through colon during authentication.
Thus, according to this specification convention, flexible configuration of the RESTful API can be satisfied, such as:
1) acquiring the information of a user a, wherein the authority identification is as follows: GET/user/a
2) And updating the information of the user a, wherein the authority identification is as follows: PUT/user/a
3) Deleting the information of all users, wherein the authority marks are as follows: DELETE/user
4) All rights, identified as: /**:*
Wherein, the step S2 further includes:
s21: adding records of association of roles and authorities in the role authority relationship table: associating the role ID in the role authority relation table to a role table, and associating the authority ID in the role authority relation table to an authority table;
s22: adding records of association between users and roles in the user role relationship table: and associating the user ID in the user role relationship table to the user table, and associating the role ID in the user role relationship table to the role table.
In step S3, the authentication service behind the microservice gateway provides a user name and password authentication API and a Token authentication API, the authentication service determines and verifies the user name and password input by the client, and after the verification is passed, the authentication service provides a Token and stores the Token and the authority information of the user corresponding to the Token into a redis for the subsequent service API to authenticate through the Token; the key of the redis is the value of the current Token, and the value is the authority information of the user corresponding to the Token.
In implementation, under a micro-service architecture, an independent authentication service is usually split, and at least 2 RESTful APIs, namely a username and password authentication API and a Token authentication API, need to be provided in the authentication service.
Wherein the Token is generated using a UUID and has a length of 36 bits;
when the authentication service generates Token, the user role relationship table, the role authority relationship table and the authority table in the database are related and inquired through the user ID obtained in step S2 to obtain the authority list of the user, and the authority list of the user is stored into redis in a JSON character string form, where key of the redis is the value of current Token, and value is the authority information of the user corresponding to Token.
In practice, the format of the permission list is JSON character string, which is exemplified as follows:
{"perms_list":["/user/a:GET","/user/b:POST","/role/*:GET,POST"]}
in step S4, after the micro service gateway receives the access request from the client, the client needs to add the value of Token obtained in step S3 to the HTTP Header of each accessed micro service API, where the name of the Header is Token, the micro service gateway obtains the value of Token from the Header and calls the Token authentication API provided by the authentication service to perform client identity authentication, the authentication service queries the value of Token in redis, and if the value exists, returns authentication success information and authority information of the Token to the micro service gateway; if not, returning authentication failure information to the micro service gateway;
the logic judgment of the authentication result information returned by the received authentication service by the micro service gateway specifically comprises the following steps:
s41: acquiring an accessed API path (request _ url _ path) and a request mode (request _ http _ method);
example (c): the client accesses the api/user/a in a GET mode, wherein request _ url _ path is equal to/user/a, and request _ http _ method is equal to GET;
s42: circularly traversing the authority list, identifying each authority in the authority list, splitting each authority into arrays according to the colon number, carrying out condition judgment, if the condition judgment result is that the condition is satisfied, indicating that the currently accessed API has the authority, terminating the circulation, and simultaneously forwarding the request to a rear-end micro-service module by the micro-service gateway for service logic processing; otherwise, continuously traversing until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the client side is indicated to have no right to access the current API, and the micro service gateway returns no right access prompt information to the client side.
Wherein, the arrays comprise two elements, the element before colon is represented by perm _ arr [0], and the element after colon is represented by perm _ arr [1 ];
the condition judgment comprises the following steps:
the first condition is that: judging whether perm _ arr [0] is matched with the accessed API path (request _ url _ path);
the second condition is that: judging whether perm _ arr [1] contains or not or a request mode (request _ http _ method);
and if the first condition and the second condition are simultaneously met, the condition judgment result indicates that the condition is met.
In implementation, in the first condition, matching detection of perm _ arr [0] and the accessed API path (request _ url _ path) may be implemented by using a match method of the antpthmatch class provided in Spring.
Finally, the above embodiments are only for illustrating the technical solutions of the present invention and not for limiting, although the present invention has been described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions may be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all of them should be covered in the claims of the present invention.
Claims (8)
1. A method for unified authentication of RESTful API under micro-service architecture is characterized in that: the method specifically comprises the following steps:
s1: configuring the authority; establishing a user table, a role table, a permission table, a user role relationship table and a role permission relationship table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the permissions configured in step S1 with roles, associating users with roles;
s3: a client applies for Token; the client acquires a Token in an authentication service provided by the micro service gateway through a legal user name and a legal password, and stores the Token and the authority information of the corresponding user into the redis;
s4: gateway authentication; after receiving an access request of a client, the micro service gateway authenticates the identity of the client and returns authentication result information to perform logic judgment, and if the judgment fails, the micro service gateway returns error information to the client; if the authentication is judged to be successful, authentication processing is carried out, and if the authentication result is that the client does not have the right to access the current API, the micro service gateway returns no-right access prompt information to the client; and if the authentication result is that the client has the authority to the currently accessed API, the micro-service gateway forwards the access request to a micro-service module at the rear end for corresponding service logic processing.
2. The method of claim 1 for unified authentication of RESTful APIs under micro service architecture, characterized in that: in the step S1, in the above step,
the user table comprises user ID, user name and password fields;
the role table comprises role ID and role name fields;
the authority table comprises an authority ID and an authority identification field;
the user role relation table comprises user ID and role ID fields;
the role authority relationship table comprises role ID and authority ID fields.
3. The method of claim 2, wherein the method for unified authentication of RESTful API under micro service architecture comprises: the format that each authority identification field in the authority table needs to satisfy is as follows: URL _ PATH, HTTP _ METHOD;
the URL _ PATH represents an access PATH of RESTful API, and the HTTP _ METHOD represents a mode that the client requests the URL _ PATH; the format of the URL _ PATH conforms to Apache Ant style, and the HTTP _ METHOD satisfies the HTTP/1.1 protocol specification.
4. The method of claim 1 for unified authentication of RESTful APIs under micro service architecture, characterized in that: the step S2 further includes:
s21: adding records of role and authority association in the role authority relationship table: associating the role ID in the role authority relation table to a role table, and associating the authority ID in the role authority relation table to an authority table;
s22: adding records of association between users and roles in the user role relationship table: and associating the user ID in the user role relationship table to the user table, and associating the role ID in the user role relationship table to the role table.
5. The method of claim 3, wherein the method for unified authentication of RESTful API under micro service architecture comprises: in step S3, the authentication service behind the microservice gateway provides a user name and password authentication API and a Token authentication API, the authentication service determines and verifies the user name and password input by the client, and after the verification is passed, the authentication service provides a Token and stores the Token and the authority information of the user corresponding to the Token into a redis for the subsequent service API to authenticate through the Token; the key of the redis is the value of the current Token, and the value is the authority information of the user corresponding to the Token.
6. The method of claim 5, wherein the method for unified authentication of RESTful API under micro service architecture comprises: the Token is generated using a UUID and has a length of 36 bits;
when the authentication service generates Token, the user role relationship table, the role authority relationship table and the authority table in the database are related and inquired through the user ID obtained in step S2 to obtain the authority list of the user, and the authority list of the user is stored into redis in a JSON character string form, where key of the redis is the value of current Token, and value is the authority information of the user corresponding to Token.
7. The method of claim 5, wherein the method for unified authentication of RESTful API under micro service architecture comprises: in step S4, after the micro service gateway receives the access request from the client, the client needs to add the value of Token obtained in step S3 to the HTTP Header of each accessed micro service API, where the name of the Header is Token, the micro service gateway obtains the value of Token from the Header and calls the Token authentication API provided by the authentication service to perform client identity authentication, the authentication service queries the value of Token in redis, and if the value exists, returns authentication success information and authority information of the Token to the micro service gateway; if not, returning authentication failure information to the micro service gateway;
the logic judgment of the authentication result information returned by the received authentication service by the micro service gateway specifically comprises the following steps:
s41: obtaining an accessed API path and a request mode;
s42: circularly traversing the authority list, identifying each authority in the authority list, splitting each authority into arrays according to the colon number, carrying out condition judgment, if the condition judgment result is that the condition is satisfied, indicating that the currently accessed API has the authority, terminating the circulation, and simultaneously forwarding the request to a rear-end micro-service module by the micro-service gateway for service logic processing; otherwise, continuously traversing until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the client side is indicated to have no right to access the current API, and the micro service gateway returns no right access prompt information to the client side.
8. The method of claim 7, wherein the method for unified authentication of RESTful API under micro service architecture comprises: the arrays all comprise two elements, the element before the colon is represented by perm _ arr [0], and the element after the colon is represented by perm _ arr [1 ];
the condition judgment comprises the following steps:
the first condition is that: judging whether perm _ arr [0] is matched with the accessed API path;
the second condition is that: judging whether perm _ arr [1] contains the index or the request mode;
and if the first condition and the second condition are simultaneously met, the condition judgment result indicates that the condition is met.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210281798.6A CN114615071B (en) | 2022-03-21 | 2022-03-21 | Method for unified authentication of RESTful API under micro-service architecture |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210281798.6A CN114615071B (en) | 2022-03-21 | 2022-03-21 | Method for unified authentication of RESTful API under micro-service architecture |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114615071A true CN114615071A (en) | 2022-06-10 |
| CN114615071B CN114615071B (en) | 2023-06-06 |
Family
ID=81864666
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210281798.6A Active CN114615071B (en) | 2022-03-21 | 2022-03-21 | Method for unified authentication of RESTful API under micro-service architecture |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114615071B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115085944A (en) * | 2022-08-22 | 2022-09-20 | 四川蜀天信息技术有限公司 | Multi-space scene RESTful API unified user authentication management method and system |
| CN115277234A (en) * | 2022-08-01 | 2022-11-01 | 重庆标能瑞源储能技术研究院有限公司 | Security authentication method and system based on Internet of things platform micro-service |
| CN116208668A (en) * | 2023-05-05 | 2023-06-02 | 北京零壹视界科技有限公司 | Data caching method, device, equipment and medium based on content distribution network |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160092173A1 (en) * | 2014-09-25 | 2016-03-31 | Oracle International Corporation | Seamless restful api generation and consumption through a single channel |
| CN108762950A (en) * | 2018-05-23 | 2018-11-06 | 山东浪潮商用系统有限公司 | A kind of standardization RESTful micro services exchange methods |
| CN108810029A (en) * | 2018-07-23 | 2018-11-13 | 珠海宏桥高科技有限公司 | Right discriminating system and optimization method between a kind of micro services infrastructure services |
| CN110225039A (en) * | 2019-06-14 | 2019-09-10 | 无锡华云数据技术服务有限公司 | Authority models acquisition, method for authenticating, gateway, server and storage medium |
| CN112039909A (en) * | 2020-09-03 | 2020-12-04 | 平安科技（深圳）有限公司 | Authentication method, device, equipment and storage medium based on unified gateway |
| CN113055367A (en) * | 2021-03-08 | 2021-06-29 | 浪潮云信息技术股份公司 | Method and system for realizing micro-service gateway authentication |
| CN113098695A (en) * | 2021-04-21 | 2021-07-09 | 金陵科技学院 | Micro-service unified authority control method and system based on user attributes |
| US20210336788A1 (en) * | 2020-04-24 | 2021-10-28 | Netapp, Inc. | Management services api gateway |
| CN114039759A (en) * | 2021-11-02 | 2022-02-11 | 中国软件与技术服务股份有限公司 | High-performance gateway authentication method and system for credit creation field |
| CN114710521A (en) * | 2022-03-11 | 2022-07-05 | 重庆长安汽车股份有限公司 | Vehicle cloud platform architecture system and method for realizing vehicle-mounted software payment authorization |
-
2022
- 2022-03-21 CN CN202210281798.6A patent/CN114615071B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20160092173A1 (en) * | 2014-09-25 | 2016-03-31 | Oracle International Corporation | Seamless restful api generation and consumption through a single channel |
| CN108762950A (en) * | 2018-05-23 | 2018-11-06 | 山东浪潮商用系统有限公司 | A kind of standardization RESTful micro services exchange methods |
| CN108810029A (en) * | 2018-07-23 | 2018-11-13 | 珠海宏桥高科技有限公司 | Right discriminating system and optimization method between a kind of micro services infrastructure services |
| CN110225039A (en) * | 2019-06-14 | 2019-09-10 | 无锡华云数据技术服务有限公司 | Authority models acquisition, method for authenticating, gateway, server and storage medium |
| US20210336788A1 (en) * | 2020-04-24 | 2021-10-28 | Netapp, Inc. | Management services api gateway |
| CN112039909A (en) * | 2020-09-03 | 2020-12-04 | 平安科技（深圳）有限公司 | Authentication method, device, equipment and storage medium based on unified gateway |
| CN113055367A (en) * | 2021-03-08 | 2021-06-29 | 浪潮云信息技术股份公司 | Method and system for realizing micro-service gateway authentication |
| CN113098695A (en) * | 2021-04-21 | 2021-07-09 | 金陵科技学院 | Micro-service unified authority control method and system based on user attributes |
| CN114039759A (en) * | 2021-11-02 | 2022-02-11 | 中国软件与技术服务股份有限公司 | High-performance gateway authentication method and system for credit creation field |
| CN114710521A (en) * | 2022-03-11 | 2022-07-05 | 重庆长安汽车股份有限公司 | Vehicle cloud platform architecture system and method for realizing vehicle-mounted software payment authorization |
Non-Patent Citations (5)
| Title |
|---|
| STENLY IBRAHIM ADAM: "RESTful Web Service Implementation on Unklab Information System Using JSON Web Token (JWT)", 2020 2ND INTERNATIONAL CONFERENCE ON CYBERNETICS AND INTELLIGENT SYSTEM (ICORIS) * |
| XIANG-WEN HUANG: "A Token-Based User Authentication Mechanism for Data Exchange in RESTful API", 2015 18TH INTERNATIONAL CONFERENCE ON NETWORK-BASED INFORMATION SYSTEMS * |
| YONGPING ZHANG: "Method of information system authority control based on rbac in web environment", 2010 2ND INTERNATIONAL CONFERENCE ON ADVANCED COMPUTER CONTROL * |
| 侯海平;: "基于微服务架构的MOOC平台重构", 九江学院学报(自然科学版), no. 03 * |
| 王东;樊燕红;: "公安警务综合认证鉴权服务中心的设计与实现", 信息技术与信息化, no. 06 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115277234A (en) * | 2022-08-01 | 2022-11-01 | 重庆标能瑞源储能技术研究院有限公司 | Security authentication method and system based on Internet of things platform micro-service |
| CN115277234B (en) * | 2022-08-01 | 2024-01-09 | 重庆标能瑞源储能技术研究院有限公司 | Security authentication method and system based on Internet of things platform micro-service |
| CN115085944A (en) * | 2022-08-22 | 2022-09-20 | 四川蜀天信息技术有限公司 | Multi-space scene RESTful API unified user authentication management method and system |
| CN115085944B (en) * | 2022-08-22 | 2022-11-01 | 四川蜀天信息技术有限公司 | Multi-space scene RESTful API unified user authentication management method and system |
| CN116208668A (en) * | 2023-05-05 | 2023-06-02 | 北京零壹视界科技有限公司 | Data caching method, device, equipment and medium based on content distribution network |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114615071B (en) | 2023-06-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10771459B2 (en) | Terminal apparatus, server apparatus, blockchain and method for FIDO universal authentication using the same | |
| WO2020207233A1 (en) | Permission control method and apparatus for blockchain | |
| US9935936B2 (en) | Federated realm discovery | |
| US8978100B2 (en) | Policy-based authentication | |
| CN114615071A (en) | Method for carrying out unified authentication on RESTful API under micro-service architecture | |
| US8245051B2 (en) | Extensible account authentication system | |
| US8572710B2 (en) | Pluggable token provider model to implement authentication across multiple web services | |
| US9094398B2 (en) | Enhancing directory service authentication and authorization using contextual information | |
| US8370901B2 (en) | Method and apparatus for providing identity management for users in a web environment | |
| US9613224B2 (en) | Integrating a user's security context in a database for access control | |
| US10049205B2 (en) | Asserting identities of application users in a database system based on delegated trust | |
| US20150215348A1 (en) | Virtual identity of a user based on disparate identity services | |
| CN112804258B (en) | Authentication and authorization method, authorization server, API gateway, system and storage medium | |
| US11836243B2 (en) | Centralized applications credentials management | |
| CN108449348B (en) | Online authentication system and method supporting user identity privacy protection | |
| US20130312068A1 (en) | Systems and methods for administrating access in an on-demand computing environment | |
| US10749868B2 (en) | Registration of the same domain with different cloud services networks | |
| US7661125B2 (en) | System for providing and utilizing a network trusted context | |
| US20230334140A1 (en) | Management of applications’ access to data resources | |
| US20230198960A1 (en) | Data masking | |
| WO2010072158A1 (en) | Method, device and system for authenticating user identity in service chain | |
| CN114070616A (en) | Distributed session sharing method and system based on redis cache | |
| US7606917B1 (en) | Method, apparatus and system for principle mapping within an application container | |
| US11477189B2 (en) | Primary domain and secondary domain authentication | |
| WO2023280009A1 (en) | Access control method and apparatus, device, and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |