CN111125655A - Method for secure communication of OSS-API interface - Google Patents

Abstract

The invention relates to a method for OSS-API interface secure communication, which relates to the technical field of OSS-API interface secure communication application, and comprises the following steps of S1, generating a signature from a kong server, wherein the kong server can expand the existing functions through plug-ins, and the plug-ins are executed in the life cycle of an API request response cycle; s2, generating a header JWT, wherein the JWT generally has two application scenarios: authorization, which is the most common JWT usage scenario, once a user logs in, each subsequent request will contain a JWT as a token for the user to access the resource; information exchange, which can securely transmit information between various systems using JWT, whose characteristics allow a receiver to verify whether received contents are tampered; s3, integrating Signature and JWT to directly access the API server; s4, the API server processes the Signature and the JWT, the communication safety of the API interface is guaranteed through four mechanisms, and the JWT is applied to the header of the API, so that the high safety level of the API safety communication is effectively guaranteed.

Description

Method for secure communication of OSS-API interface

Technical Field

The invention relates to the technical field of OSS-API interface secure communication application, in particular to a method for OSS-API interface secure communication.

Background

The API is some predefined functions or conventions for linking different components of a software system, and aims to provide the capability of an application program and a developer to access a set of routines based on certain software or hardware without accessing original codes or understanding details of an internal working mechanism, and how an OSS provides a relevant API interface externally, how to ensure OSS-API secure communication is important.

In order to ensure that data of an interface is not tampered and repeated calling, a Token authorization mechanism, a timestamp timeout mechanism and a signature mechanism are mainly considered, and at present, only one or two mechanisms are generally applied in the existing general technical scheme, and the security level is not high. Therefore, it is necessary to provide a method for secure communication of OSS-API interface for overcoming the disadvantages of the prior art.

Disclosure of Invention

In order to overcome the defects in the prior art, the method for the secure communication of the OSS-API interface has the advantage that the security level of the API secure communication is high.

In order to achieve the above object, the method for secure communication of OSS-API interface of the present invention includes the following steps:

s1, generating a signature from the kong server;

s2, generating a header JWT;

s3, integrating Signature and JWT to directly access the API server;

s4, the API server processes the Signature and the JWT.

Preferably, in S1, API params of the kong server includes AK, AKs, expire, base64(param1), base64(param2), … … base64 (paramN).

Preferably, in S2, the JWT is composed of three parts, Header, Payload and Signature.

Preferably, in S4, the API server mainly performs the following operations on Signature and JW design:

s401, removing the reader to obtain JWT for Decode to judge whether the timestamp and the signature are valid;

s402, confirming whether the Signature is effective or not by the kong removing server;

s403, judging whether AK and AKS are legal or not, wherein when AK and AKS are invalid, the API server can directly respond to AK or AKS invalid;

s404, carrying out base64 decryption on all param parameters;

and S405, responding to the request interface.

The invention has the following beneficial effects:

the communication security of the API interface is ensured through four mechanisms, and the JWT is applied to the header of the API, so that the high security level of the API security communication is effectively ensured.

Drawings

The present invention will be further described and illustrated with reference to the following drawings.

FIG. 1 is a flow diagram of a method for secure communication for an OSS-API interface.

Detailed Description

The technical solution of the present invention will be more clearly and completely explained by the description of the preferred embodiments of the present invention with reference to the accompanying drawings.

Examples

As shown in fig. 1, a method for secure communication for OSS-API interface includes the following steps:

s1, generating signatures from the Kong server, which can extend existing functions through plug-ins, which are executed during the life cycle of the API request response loop, the plug-ins being written in Lua, and Kong having several basic functions as follows: HTTP basic authentication, key authentication, CORS (Cross-domain Resource Sharing), TCP, UDP, file logging, API request throttling, request forwarding, and nginx monitoring;

s2, generating a header JWT, wherein the JWT generally has two application scenarios: authorization, which is the most common JWT usage scenario, once a user logs in, each subsequent request will contain a JWT as a token for the user to access the resource; information exchange, which can securely transmit information between various systems using JWT, whose characteristics allow a receiver to verify whether received contents are tampered;

s3, integrating Signature and JWT to directly access the API server;

s4, the API server processes the Signature and the JWT.

In S1, the API params of the kong server includes AK, AKs, expire, base64(param1), base64(param2), … … base64 (paramN).

By adopting the technical scheme, the OSS verifies the identity of a certain request sender by using an AK and AKS symmetric encryption method, wherein the AK is used for identifying a user; AKS is a key used by a user to encrypt a signature string and used by OSS to verify the signature string, and must be kept secret; expire is a time stamp, the survival time of one key can be set by using an expire command, and redis can automatically delete the expire command after the time; base64 is one of the most common encoding methods for transmitting 8-Bit byte codes on a network, and base64 is a method for representing binary data based on 64 printable characters, and can be used for encryption.

In S2, the JWT is composed of a Header, Payload, and Signature as a technical optimization scheme of the present invention.

By adopting the technical scheme, the first part is a Header and generally comprises two parts: the type of token and the encryption algorithm used, parameters are exemplified as follows:

{

"alg":"HS256",

"typ":"JWT"

}，

wherein the Header uses base encryption;

the second part is Payload, which is a carrier in which custom information can be placed, as well as expiration time, publisher, etc., and examples of parameters are as follows:

{

"timeStamp":"1572861099530"

}，

wherein the carrier parameter is timeStamp, which is accurate to ms, and the effective time is 5 m;

the third part is Signature, and four parts of information are needed for calculating the Signature: algorithm information in the Header, Payload and a custom key are received by the JWT, a signature is calculated again by using the same information, and the signature is compared with the signature in the JWT, if the signature is different, the content in the JWT is tampered, and the parameters are as follows: HMACSHA256(

base64UrlEncode(header)+"."+

base64UrlEncode(payload),

UnicloudSmaug

)。

As a technical optimization scheme of the present invention, in S4, the main operations of the API server on Signature and JW design include:

s401, removing the reader to obtain JWT for Decode to judge whether the timestamp and the signature are valid;

s402, confirming whether the Signature is effective or not by the kong removing server;

s403, judging whether AK and AKS are legal or not, wherein when AK and AKS are invalid, the API server can directly respond to AK or AKS invalid;

s404, carrying out base64 decryption on all param parameters;

and S405, responding to the request interface.

The working principle of the invention is as follows:

1. access key mechanism (AK and AKS)

Access Key (AK) refers to access key id and access key secret used in access authentication. The OSS verifies the identity of the sender of a request by using a symmetric encryption method using AccessKeyId and AccessKeySecret. The Access KeyId is used for identifying the user; AccessKeySecret is a key used by the user to encrypt the signature string and used by the OSS to verify the signature string, and must be kept secret.

2. Parameter encryption mechanism

Of the request parameters (get signature and access API server), all except AK, AKs and expiration parameters (expire) need to be encrypted via Base 64.

The kong server does not decrypt the parameters. When the integrated Signature and JWT directly access the API server, the API server decrypts all the parameters.

3. Parameter third party plug-in signature mechanism (kong server signature authentication)

Kong is an API gateway that forwards API communications between clients and (micro) services, and functions can be extended by plug-ins to implement signature functions.

The AK, AKS parameters and expire parameters of the user, as well as all other parameters encrypted by Base64, are used together to a Kong server for signature authentication, and a signature is generated.

When the Signature and JWT are integrated to directly access the API server, the API server goes to the kong server to confirm whether the Signature is valid. When the Signature is invalid, the API server directly responds to the invalidation of the Signature.

4. The Header token mechanism: JWT token authentication (timestamp included in authentication parameters) is used.

JSON Web Token (JWT) is a secure, lightweight, complete way to transfer data between parties, using a JSON object format.

The term "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJ0aW1lU3RhbXAiIxNyODYxMDk5N TMwIn0. svtXizpE522Et7vZmDgZZyWORh _ XXcJVxTeXZAvebw" is the JWT finally generated by the above parameter example.

"Bearer" + JWT generates a header.

When the Signature and the JWT are integrated to directly access the API server, the API server takes the header to remove the 'beer' and takes the JWT to carry out Decode to judge whether the timestamp is valid or not and the Signature is valid. When the timestamp or signature is invalid, the API server will directly influence the invalidation of Authorization.

The above detailed description merely describes preferred embodiments of the present invention and does not limit the scope of the invention. Without departing from the spirit and scope of the present invention, it should be understood that various changes, substitutions and alterations can be made herein by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims and their equivalents. The scope of the invention is defined by the claims.

Claims (4)

1. A method for secure communication for OSS-API interface, comprising the steps of:

s1, generating a signature from the kong server;

s2, generating a header JWT;

s3, integrating Signature and JWT to directly access the API server;

s4, the API server processes the Signature and the JWT.

2. The method of claim 1 for secure communication for OSS-API interface, characterized by: in the S1, API params of the kong server includes AK, AKs, expire, base64(param1), base64(param2), … … base64 (paramN).

3. The method of claim 1 for secure communication for OSS-API interface, characterized by: in the S2, the JWT is composed of three parts, i.e., a Header, Payload, and Signature.

4. The method of claim 1 for secure communication for OSS-API interface, characterized by: in S4, the API server mainly performs Signature and JW design operations including:

s401, removing the reader to obtain JWT for Decode to judge whether the timestamp and the signature are valid;

s402, confirming whether the Signature is effective or not by the kong removing server;

s403, judging whether AK and AKS are legal or not, wherein when AK and AKS are invalid, the API server can directly respond to AK or AKS invalid;

s404, carrying out base64 decryption on all param parameters;

and S405, responding to the request interface.

Images