CN114615071B - Method for unified authentication of RESTful API under micro-service architecture - Google Patents

Method for unified authentication of RESTful API under micro-service architecture Download PDF

Info

Publication number
CN114615071B
CN114615071B CN202210281798.6A CN202210281798A CN114615071B CN 114615071 B CN114615071 B CN 114615071B CN 202210281798 A CN202210281798 A CN 202210281798A CN 114615071 B CN114615071 B CN 114615071B
Authority
CN
China
Prior art keywords
authentication
authority
service
token
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.)
Active
Application number
CN202210281798.6A
Other languages
Chinese (zh)
Other versions
CN114615071A (en
Inventor
周小波
蓝文良
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Chongqing Changan Automobile Co Ltd
Original Assignee
Chongqing Changan Automobile Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Chongqing Changan Automobile Co Ltd filed Critical Chongqing Changan Automobile Co Ltd
Priority to CN202210281798.6A priority Critical patent/CN114615071B/en
Publication of CN114615071A publication Critical patent/CN114615071A/en
Application granted granted Critical
Publication of CN114615071B publication Critical patent/CN114615071B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

The invention relates to a method for unified authentication of RESTful API under a micro-service architecture, which specifically comprises the following steps: rights configuration, user authorization, client application Token, gateway authentication. The invention is based on RBAC authority model and Token mechanism, uses wildcard and HTTP Method as authority identification, realizes flexible definition of RESTful API authority, solves the problem of difficulty in unified authentication of RESTful API, and simultaneously uses Token mechanism to avoid risk of authority information leakage caused by using JWT (JSON Web Token) mechanism in the prior art, so that each micro-service module only focuses on service logic realization, and improves development efficiency of service.

Description

Method for unified authentication of RESTful API under micro-service architecture
Technical Field
The invention belongs to the technical field of computer application, and particularly relates to a method for unified authentication of 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 is only focused on the logic implementation of the service itself, and some common logic processing is put on a micro-service gateway to be implemented, including: authentication, etc., each service provides an API in RESTful form to the client call through the gateway.
In the era of microservices popularity, authentication and authentication methods are generally and previously almost the same, but due to different scene architectures, the schemes applicable to them are also different, and in general, there are four schemes: one is Single Sign On (SSO); secondly, a distributed Session scheme; thirdly, a client Token scheme; and fourthly, the client Token is combined with the API gateway. In the prior art, as CN110225039B, there is provided a rights model acquisition and authentication method, gateway, server and storage medium, so that the rights model is decoupled from the API request; CN113098695 also provides a micro-service unified authority control method based on user attribute, and provides a standardized authority control interface at gateway layer, which is convenient for unified management, and introduces user attribute information to refine granularity of resource access, and improves security of authority management. However, the operability of the above technical solution in the RESTful architecture style is not high enough to solve the authentication problem of RESTful API in the micro-service architecture.
Disclosure of Invention
Aiming at the defects in the prior art, the invention aims to provide a method for unified authentication of RESTful APIs under a micro-service architecture, so as to avoid the problem of difficult unified authentication of the RESTful APIs.
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 permission; establishing a user table, a role table, a permission table, a user role relation table and a role permission relation table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the authority configured in the step S1 with a role, and associating the user with the role;
s3: the client applies for Token; the client acquires a Token from authentication service provided by the micro-service gateway through legal user names and passwords, and stores the Token and authority information of the corresponding user into redis;
s4: gateway authentication; after receiving the access request of the client, the micro-service gateway performs the identity authentication of the client and returns authentication result information to perform logic judgment, and if the authentication is judged to be failed, 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 side does not have access to the current API, the micro-service gateway returns an unauthorized access prompt message to the client side; and if the authentication result is that the client side has authority to the currently accessed API, the micro-service gateway forwards the access request to the micro-service module at the back end to perform corresponding service logic processing.
Further perfecting the technical scheme, in the step S1,
the user table comprises a user ID, a user name and a password field;
the role table comprises a role ID and a role name field;
the permission table comprises a permission ID and a permission identification field;
the user role relation table comprises a user ID and role ID field;
the role authority relationship table includes a role ID and an authority ID field.
Further, the format to be satisfied by each rights identification field in the rights table is: url_path http_method;
wherein, url_path represents the access PATH of RESTful API, http_method represents the way the client requests the url_path; the format of the URL_PATH accords with Apache Ant style, and the HTTP_METHOD meets HTTP/1.1 protocol specification.
Further, the step S2 further includes:
s21: adding records of the association of roles and rights in the role rights relation table: associating the role ID in the role authority relation table to the role table, and associating the authority ID in the role authority relation table to the authority table;
s22: adding records of association of users and roles in the user role relation table: and associating the user ID in the user role relation table to the user table, and associating the role ID in the user role relation table to the role table.
Further, in the step S3, the authentication service after the micro service gateway provides a username and password authentication API and a Token authentication API, the authentication service performs a judgment check on the username 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 corresponding user into redis for the subsequent service API to authenticate through the Token; wherein, the key of 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, which is 36 bits in length;
when the authentication service generates Token, the user ID obtained in the step S2 is used for associatively inquiring a user role relation table, a role authority relation table and an authority table in a database to obtain an authority list of the user, and the authority list of the user is stored in a redis in the form of a JSON character string, wherein 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, in step S4, after receiving the access request of the client, the micro-service gateway needs to add the Token value 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 Token value from the Header and invokes the Token authentication API provided by the authentication service to perform client identity authentication, and the authentication service queries the Token value in redis, and if there is a Token, 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 API path (request_url_path) and a request mode (request_http_method) of access;
s42: traversing the authority list in a circulating way, identifying each authority in the authority list, splitting the authority list into an array according to a colon, judging the condition, if the condition judgment result is that the condition is satisfied, indicating that the API accessed currently has the authority, terminating the circulation, and forwarding the request to a micro-service module at the rear end by a micro-service gateway for service logic processing; otherwise, continuing to traverse until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the condition judgment result indicates that the client side does not have access to the current API, and the micro-service gateway returns an unauthorized access prompt message to the client side.
Further, the array comprises two elements, wherein the element before the colon is represented by perm_arr0, and the element after the colon is represented by perm_arr1;
the condition judgment includes:
first condition: judging whether perm_arr0 is matched with an accessed API path (request_url_path);
second condition: judging whether perm_arr1 contains a request_http_method;
the first condition and the second condition being satisfied at the same time indicates that the condition judgment result is satisfied.
Compared with the prior art, the invention has the following beneficial effects:
the Method for unified authentication of RESTful API under the micro-service architecture is based on RBAC authority model and Token mechanism, uses wild card and HTTP Method as authority identification, realizes flexible definition of RESTful API authority, solves the problem of unified authentication difficulty of RESTful API, and simultaneously uses Token mechanism, avoids the risk of authority information leakage caused by using JWT (JSON Web Token) mechanism in the prior art, and allows each micro-service module to only concentrate on service logic implementation, thereby improving the development efficiency of service.
Drawings
FIG. 1 is a flow chart of a method for unified authentication of RESTful APIs under a micro-service architecture according to an embodiment;
FIG. 2 is a schematic diagram of an RBAC rights model employed by the present invention;
FIG. 3 is a flow chart of a client application Token of the present invention;
fig. 4 is a flow chart of gateway authentication according to the present invention.
Detailed Description
The following describes the embodiments of the present invention in further detail with reference to the drawings.
Referring to the figure, a method for unified authentication of RESTful API under micro-service architecture in the embodiment specifically includes the following steps:
s1: configuring permission; establishing a user table, a role table, a permission table, a user role relation table and a role permission relation table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the authority configured in the step S1 with a role, and associating the user with the role;
s3: a client applies Token; the client acquires a Token from authentication service provided by the micro-service gateway through legal user names and passwords, and stores the Token and authority information of the corresponding user into redis;
s4: gateway authentication; after receiving the access request of the client, the micro-service gateway performs the identity authentication of the client and returns authentication result information to perform logic judgment, and if the authentication is judged to be failed, 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 side does not have access to the current API, the micro-service gateway returns an unauthorized access prompt message to the client side; and if the authentication result is that the client side has authority to the currently accessed API, the micro-service gateway forwards the access request to the micro-service module at the back end to perform corresponding service logic processing.
According to the Method for unified authentication of RESTful API under the micro-service architecture, based on RBAC authority model and Token mechanism, universal symbol and HTTP Method are used as authority identifiers, flexible definition of RESTful API authority is achieved, the problem of difficulty in unified authentication of RESTful API is solved, meanwhile, the Token mechanism is used, the risk of authority information leakage caused by the JWT (JSON Web Token) mechanism in the prior art is avoided, each micro-service module only focuses on service logic implementation, and service development efficiency is improved.
With continued reference to the drawing, in step S1,
the user table comprises a user ID, a user name and a password field;
the role table comprises a role ID and a role name field;
the permission table comprises a permission ID and a permission identification field;
the user role relation table comprises a user ID and role ID field;
the role authority relationship table includes a role ID and an authority ID field.
Thus, an RBAC (Role-Based Access Control) rights model is employed, which is a rights design model common in the industry by associating users with rights through roles. Briefly, a User (User) has several roles (Role), each having several rights (Perm), and thus an authorization model of "User-Role-rights" is constructed in which there is a general many-to-many relationship between users and roles, and between roles and rights.
Wherein, the format that each authority identification field in the authority table needs to satisfy is: url_path http_method;
wherein, url_path represents the access PATH of RESTful API, http_method represents the way the client requests the url_path; the format of the URL_PATH accords with Apache Ant style, and the HTTP_METHOD meets HTTP/1.1 protocol specification.
In implementation, the path of the Apache Ant pattern has three wild card matching methods, as shown in the following table:
wild card symbol Description of the invention
Matching any single character
* Matching 0 or any number of characters
** Matching 0 or more ordersRecording device
In this way, batch identification of a class of resources may be achieved using wild cards.
In particular, some wild card usage examples are listed here, please see the following table:
Figure BDA0003557223230000051
meanwhile, common values of the HTTP/1.1 protocol specification are shown in the following table:
Figure BDA0003557223230000052
the http_method values are one or more of the tables above, and when multiple, comma splitting is used between each value, such as: "GET, POST" or "GET, POST, PUT"; the "x" representation is used when any legal HTTP/1.1Method is allowed to be used; and splitting the URL_PATH and the HTTP_METHOD by using a colon number during authentication.
Thus, according to this specification convention, flexible configuration of the RESTful APIs can be satisfied, such as:
1) Obtaining information of a user a, wherein the authority identification is as follows: GET/user/a
2) 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 identification is as follows: user/. DELTA.ETE
4) All rights, identified as: /**:*
Wherein, the step S2 further includes:
s21: adding records of the association of roles and rights in the role rights relation table: associating the role ID in the role authority relation table to the role table, and associating the authority ID in the role authority relation table to the authority table;
s22: adding records of association of users and roles in the user role relation table: and associating the user ID in the user role relation table to the user table, and associating the role ID in the user role relation table to the role table.
In the step S3, the authentication service after the micro-service gateway provides a user name password authentication API and a Token authentication API, the authentication service performs judgment and verification on the user name and the 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 corresponding user into redis for the subsequent service API to authenticate through the Token; wherein, the key of redis is the value of the current Token, and the value is the authority information of the user corresponding to the Token.
In practice, under the micro-service architecture, an independent authentication service is usually split, and at least 2 RESTful APIs are provided in the authentication service, namely a user name password authentication API and a Token authentication API.
Wherein the Token is generated by using a UUID, and the length of the Token is 36 bits;
when the authentication service generates Token, the user ID obtained in the step S2 is used for associatively inquiring a user role relation table, a role authority relation table and an authority table in a database to obtain an authority list of the user, and the authority list of the user is stored in a redis in the form of a JSON character string, wherein 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, the permission list is in the format of JSON string, and examples are as follows:
{"perms_list":["/user/a:GET","/user/b:POST","/role/*:GET,POST"]}
in the step S4, after receiving the access request of the client, the micro-service gateway needs to add the Token value obtained in the 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 Token value from the Header and invokes the Token authentication API provided by the authentication service to perform the client identity authentication, and the authentication service queries the Token value in redis, and if there is a Token, 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 API path (request_url_path) and a request mode (request_http_method) of access;
examples: the client accesses the api/user/a in a GET mode, wherein the request_url_path=/user/a, the request_http_method = GET;
s42: traversing the authority list in a circulating way, identifying each authority in the authority list, splitting the authority list into an array according to a colon, judging the condition, if the condition judgment result is that the condition is satisfied, indicating that the API accessed currently has the authority, terminating the circulation, and forwarding the request to a micro-service module at the rear end by a micro-service gateway for service logic processing; otherwise, continuing to traverse until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the condition judgment result indicates that the client side does not have access to the current API, and the micro-service gateway returns an unauthorized access prompt message to the client side.
Wherein, the array comprises two elements, the element before the colon is represented by perm_arr0, and the element after the colon is represented by perm_arr1;
the condition judgment includes:
first condition: judging whether perm_arr0 is matched with an accessed API path (request_url_path);
second condition: judging whether perm_arr1 contains a request_http_method;
the first condition and the second condition being satisfied at the same time indicates that the condition judgment result is satisfied.
In implementation, in the first condition, the match detection of perm_arr0 and the accessed API path (request_url_path) may be implemented by using the match method of the AntPathMatche class provided in Spring.
Finally, it is noted that the above embodiments are only for illustrating the technical solution of the present invention and not for limiting the same, and 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 and equivalents may be made thereto without departing from the spirit and scope of the technical solution of the present invention, which is intended to be covered by the scope of the claims of the present invention.

Claims (4)

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 permission; establishing a user table, a role table, a permission table, a user role relation table and a role permission relation table in a database, and designing a permission identification field in the permission table;
s2: user authorization; associating the authority configured in the step S1 with a role, and associating the user with the role;
s3: the client applies for Token; the client acquires a Token from authentication service provided by the micro-service gateway through legal user names and passwords, and stores the Token and authority information of the corresponding user into redis;
s4: gateway authentication; after receiving the access request of the client, the micro-service gateway performs the identity authentication of the client and returns authentication result information to perform logic judgment, and if the authentication is judged to be failed, 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 side does not have access to the current API, the micro-service gateway returns an unauthorized access prompt message to the client side; if the authentication result is that the client side has authority to the API accessed currently, the micro-service gateway forwards the access request to a micro-service module at the back end to perform corresponding service logic processing;
the step S2 further includes:
s21: adding records of the association of roles and rights in the role rights relation table: associating the role ID in the role authority relation table to the role table, and associating the authority ID in the role authority relation table to the authority table;
s22: adding records of association of users and roles in the user role relation table: associating the user ID in the user role relation table to the user table, and associating the role ID in the user role relation table to the role table;
in the step S3, the authentication service behind the micro-service gateway provides a user name password authentication API and a Token authentication API, the authentication service performs judgment and verification on the user name and the 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 corresponding user into redis for the subsequent service API to authenticate through the Token; wherein, the key of redis is the value of the current Token, and the value is the authority information of the user corresponding to the Token;
the Token is generated by using a UUID, and the length of the Token is 36 bits;
when the authentication service generates Token, the user ID obtained in the step S2 is used for associatively inquiring a user role relation table, a role authority relation table and an authority table in a database to obtain an authority list of the user, and the authority list of the user is stored in a redis in the form of a JSON character string, wherein 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 the step S4, after receiving the access request of the client, the micro-service gateway needs to add the Token value obtained in the step S3 to the HTTP Header of each accessed micro-service API, where the name of the Header is Token, and the micro-service gateway obtains the Token value from the Header and invokes the Token authentication API provided by the authentication service to perform client identity authentication, and the authentication service queries the Token value in redis, and if there is a Token, 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 API path and a request mode of access;
s42: traversing the authority list in a circulating way, identifying each authority in the authority list, splitting the authority list into an array according to a colon, judging the condition, if the condition judgment result is that the condition is satisfied, indicating that the API accessed currently has the authority, terminating the circulation, and forwarding the request to a micro-service module at the rear end by a micro-service gateway for service logic processing; otherwise, continuing to traverse until the circulation is finished;
s43: after the circulation is finished, if the condition judgment result is still unsatisfied, the client is not authorized to access the current API, and the micro-service gateway returns an unauthorized access prompt message to the client;
the elements before the colon are the API paths accessed in the step S41, and the elements after the colon are the request mode.
2. The method for unified authentication of RESTful API under micro-service architecture according to claim 1, wherein: in the step S1 of the above-mentioned process,
the user table comprises a user ID, a user name and a password field;
the role table comprises a role ID and a role name field;
the permission table comprises a permission ID and a permission identification field;
the user role relation table comprises a user ID and role ID field;
the role authority relationship table includes a role ID and an authority ID field.
3. The method for unified authentication of RESTful API under micro-service architecture according to claim 2, wherein: the format to be satisfied by each authority identification field in the authority table is: url_path http_method;
wherein, url_path represents the access PATH of RESTful API, http_method represents the way the client requests the url_path; the format of the URL_PATH accords with Apache Ant style, and the HTTP_METHOD meets HTTP/1.1 protocol specification.
4. The method for unified authentication of RESTful API under micro-service architecture according to claim 1, wherein: the array comprises two elements, wherein the element before the colon is represented by perm_arr0, and the element after the colon is represented by perm_arr1;
the condition judgment includes:
first condition: judging whether perm_arr0 is matched with the accessed API path;
second condition: judging whether perm_arr1 contains the request mode;
the first condition and the second condition being satisfied at the same time indicates that the condition judgment result is satisfied.
CN202210281798.6A 2022-03-21 2022-03-21 Method for unified authentication of RESTful API under micro-service architecture Active CN114615071B (en)

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 CN114615071A (en) 2022-06-10
CN114615071B true 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)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115277234B (en) * 2022-08-01 2024-01-09 重庆标能瑞源储能技术研究院有限公司 Security authentication method and system based on Internet of things platform micro-service
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

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9851952B2 (en) * 2014-09-25 2017-12-26 Oracle International Corporation Seamless restful API generation and consumption through a single channel
US11611436B2 (en) * 2020-04-24 2023-03-21 Netapp, Inc. Management services API gateway

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
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)

* Cited by examiner, † Cited by third party
Title
A Token-Based User Authentication Mechanism for Data Exchange in RESTful API;Xiang-Wen Huang;2015 18th International Conference on Network-Based Information Systems;全文 *
Method of information system authority control based on rbac in web environment;Yongping Zhang;2010 2nd International Conference on Advanced Computer Control;全文 *
RESTful Web Service Implementation on Unklab Information System Using JSON Web Token (JWT);Stenly Ibrahim Adam;2020 2nd International Conference on Cybernetics and Intelligent System (ICORIS);全文 *
公安警务综合认证鉴权服务中心的设计与实现;王东;樊燕红;;信息技术与信息化(第06期);全文 *
基于微服务架构的MOOC平台重构;侯海平;;九江学院学报(自然科学版)(第03期);全文 *

Also Published As

Publication number Publication date
CN114615071A (en) 2022-06-10

Similar Documents

Publication Publication Date Title
CN114615071B (en) Method for unified authentication of RESTful API under micro-service architecture
US9935936B2 (en) Federated realm discovery
US7845003B2 (en) Techniques for variable security access information
US7571473B1 (en) Identity management system and method
US8474017B2 (en) Identity management and single sign-on in a heterogeneous composite service scenario
US9413750B2 (en) Facilitating single sign-on (SSO) across multiple browser instance
US8978100B2 (en) Policy-based authentication
US8209394B2 (en) Device-specific identity
US8838959B2 (en) Method and apparatus for securely synchronizing password systems
US20200106766A1 (en) Method and system for security assertion markup language (saml) service provider-initiated single sign-on
US20100299738A1 (en) Claims-based authorization at an identity provider
JP2011525656A (en) Improved biometric authentication and identification
KR20040049272A (en) Methods and systems for authentication of a user for sub-locations of a network location
US7945950B2 (en) Generic interactive challenges in a distributed system
US8656468B2 (en) Method and system for validating authenticity of identity claims
CA2476340A1 (en) Moving principals across security boundaries without service interruption
CN108234122A (en) Token method of calibration and device
WO2021143028A1 (en) Internet of things equipment authentication method, electronic device and storage medium
US8533783B1 (en) Method and system for enabling automatic access to an online account
US20230008404A1 (en) Generating and validating activation codes without data persistence
US20080109894A1 (en) Authorizing a user to a device
US11716316B2 (en) Access to federated identities on a shared kiosk computing device
US7606917B1 (en) Method, apparatus and system for principle mapping within an application container
CN118199979A (en) Zero-trust input limited terminal authorization method, device, computer equipment and storage medium
CN115001808A (en) Domain user login method, device, equipment and 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