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

最近在开发一个系统,需要提供 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 时传递过去进行认证?还是用于对传输的数据进行消息签名,以便服务端判断是否有数据篡改?或者还有其他作用?

相关文章

7 thoughts on “日常用到的 ak 和 sk 的正确使用方式是什么?

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

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

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

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

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

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

    没用过阿里云的 API,通常用 ak 和 sk 做验证的 API,是只传 ak,用 sk 给消息体算签名(哈希算法),这样如果有中间人截获消息,没有 sk 没法算出正确的签名(哈希值),同时在消息体中包含时间戳防止重放攻击。

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

    如果中间人能够截获请求和响应,不管在不在请求里传 sk,只要拿到响应里的 access_token 就万事大吉了。就有了用户身份。

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

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

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

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

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

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

发表评论

电子邮件地址不会被公开。 必填项已用*标注