日常用到的 ak 和 sk 的正确使用方式是什么？

[dandankele]

最近在开发一个系统，需要提供 openAPI 给外部系统使用，那么 API 肯定需要设计一些认证、鉴权的流程。根据以往使用的一些公有云 API 以及微信 API 等来看，大多数平台都会给使用者提供 ak 和 sk 来调用 API 。

这里的 ak/sk 可能有的也会设计为 appId/appSecret 之类的，像阿里云的是 accessKeyId 和 accessKeySecret 。

我目前的看到和理解的有这么几种：

1. 不传输 secret，调用 API 时，只传递 ak 和必要的数据。像阿里云 API，sk 是用作对称加密并进行消息签名，但我比较好奇的是，都说非对称加密安全性要高一些，为啥阿里云却选择了对称加密？

2. 传输 secret，像 OAuth2 授权，在去获取 code 时，ak 和 sk 都要传递过去，那传递过程中不怕被截获吗？

所以疑问是：sk 的作用到底是什么？是仅仅像帐号密码中的“密码”一样，在调用 API 时传递过去进行认证？还是用于对传输的数据进行消息签名，以便服务端判断是否有数据篡改？或者还有其他作用？

额，OAuth2 部分我看错了，获得 code 时的确不需要传 sk，code 换 token 时才需要传 sk，而且是在服务端传

[boris93]

传输期间用 HTTPS 就不怕被截获了吧

[boris93]

ak 和 sk 可以作为一个密钥对用来认证
比如一种常见做法就是 ak + : + sk，然后把字符串 Base64，然后拿去做 HTTP Basic 认证

签名我理解更偏向于防止伪造和重放请求，签名里的 sk 作为密钥别人不知道也不应该知道，签名里的时间戳则保证了请求的时效性

[guyskk0x0]

个人看法：
和系统安全等级有关，一般用 hmac 对消息签名可以达到鉴权+防篡改，消息内带时间戳可以校验有效期，整个流程不需要传输秘钥。公网流量套上 HTTPS 。

安全性要求很高，可以做端到端 HTTPS 双向认证，也就是非对称加密。

[sunsulei]

有的 sk 二次获取的时候是需要检验密码的。
如果接口也传了个 sk，可能是为了进一步保证安全吧(如果 ak 泄漏的话)。

[mrchi]

不传输 secret，调用 API 时，只传递 ak 和必要的数据。像阿里云 API，sk 是用作对称加密并进行消息签名，但我比较好奇的是，都说非对称加密安全性要高一些，为啥阿里云却选择了对称加密？
---
没用过阿里云的 API，通常用 ak 和 sk 做验证的 API，是只传 ak，用 sk 给消息体算签名（哈希算法），这样如果有中间人截获消息，没有 sk 没法算出正确的签名（哈希值），同时在消息体中包含时间戳防止重放攻击。

传输 secret，像 OAuth2 授权，在去获取 code 时，ak 和 sk 都要传递过去，那传递过程中不怕被截获吗？
---
如果中间人能够截获请求和响应，不管在不在请求里传 sk，只要拿到响应里的 access_token 就万事大吉了。就有了用户身份。

我的理解是，前者的响应是资源，保护的是用户身份。后者的响应就是用户身份，所以传不传的无所谓。

[eason1874]

ak 相当于账号，可以公开，一般直接透传； sk 相当于密码，要严格保密，一般只作为计算签名的参数。

个别场景可能允许 sk 透传，但这个场景一定是发生在服务端，比如 OAuth2 获取 Access Token 就透传 sk 。你说的获取 Authorization Code 环节发生在客户端，那时不传 sk 只传 ak 。

非对称加密效率低，主要用途是在不可信的网络环境中建立双方可信的通信来传递密钥，传递密钥之后一般还是用回对称加密来传递信息的，比如 HTTPS 就是这样。

开发者跟开放平台之间用不着在不可信的环境中传递密钥，所以直接用对称加密就行了。

[nieyujiang]

阿里云的 sk 可以拿来计算签名的，只要有 ak 和签名就行了

[xuanbg]

ak 是 key，sk 其实是 value 。调用者用 sk 加密数据，并把 ak 一起传过去。服务端用 ak 查询对应的 sk 解密数据。就是这样