关于https请求和自定义加密请求中的身份认证

https加密请求

平时我们使用淘宝、京东等网站时，只需要走https协议与这些网站进行交互，即可保证消息的消息完整性，消息保密性。我们知道，通过https协议，我们即可确认要访问的网站是否是安全的，因为浏览器内置了CA的公钥，通过公钥验签，可以验证https证书是否有效的。当确定目标网站是安全的，浏览器会生成一个对称秘钥，然后用https证书的公钥对对称秘钥进行加密，发送到服务端（目标网站），之后，浏览器和服务端使用对称秘钥进行会话。

客户端通过https协议认证了服务端的身份，那么如果服务端如果需要认证客户端用户的身份，是怎么做的呢？答案就是通过用户的token等信息，比如用户在淘宝登录之后，淘宝会给用户颁发一个token，用户后续请求时带着这个token去请求服务端，服务端通过这个token信息，就知道这个用户是谁了。

RSA + AES 加密请求

我们在做开放平台的时候，开放平台需要认证客户端身份，客户端也可能需要认证开放平台的身份，这里的客户端指的是接入开放平台的客户。这里的双向认证，我们可以通过双方（开放平台与客户端）互相持有对方的公钥来解决。客户端发送数据时，对数据用自己的私钥进行加签，服务端收到数据请求后，用客户端的公钥进行验签，以认证对方身份。

如果有加密的需要，客户端可以生成一个AES秘钥，然后利用AES秘钥对数据进行加密，为了保证AES秘钥的安全性，需要用对方的公钥对AES秘钥进行加密。最后，再用自己的私钥对请求的数据进行加签之后发送出去。服务端收到数据之后，先用客户端的公钥进行验签，如果验签成功，再用自己的私钥解密出AES秘钥，然后利用AES秘钥对数据进行解密。

PS：私钥加签的作用主要是为了防数据篡改和确认请求者身份。

平时我们和其它公司进行接口请求交互的时候，可能很多人有疑问：我们已经走了https请求了，为什么还要在要https里面在做个签名呢？https不是已经可以对消息进行加密、保证消息不会篡改了吗？是的，https确实能够保证消息不被篡改、可以对消息进行加密。但是，我们平时走的一般是https的单项认证，https的单项认证只能让客户端确认服务端的身份，不能让服务端确认客户端的身份。也就是说，你请求其它公司的接口的时候，单纯的https单项认证请求是不能让服务端确认你的身份的，因此在https请求中必须加一些措施，来使对方确认你的身份，比如说走https双向认证请求、在请求中加上token（服务端线下将token分配给你i）、在请求中加上签名。