小程序身份认证有 陷阱？一文梳理流程与风险

先来看一下小程序登录过程的时序图：

可以看到整个认证过程涉及用户、小程序前端、开发者服务器、微信服务器四方交互。交互过程中的所涉及的敏感数据，均基于对称加密算法（AES-128-CBC）进行保护。详情见下图：校验与解密开放数据流图。

解密算法如下：

a. 对称解密使用的算法为 AES-128-CBC，数据采用PKCS#7填充。

b. 对称解密的目标密文为 Base64_Decode(encryptedData)。

c. 对称解密秘钥 aeskey = Base64_Decode(session_key), aeskey 是16字节。

d. 对称解密算法初始向量 为Base64_Decode(iv)，其中iv由数据接口返回。

from WXBizDataCrypt import WXBizDataCryptdef main():    appId = 'wx4f4bc4dec97d474b'    sessionKey = 'tiihtNczf5v6AKRyjwEUhQ=='    encryptedData ='CiyLU1Aw2KjvrjMdj8YKliAjtP4gsMZMQmRzooG2xrDcvSnxIMXFufNstNGTyaGS9uT5geRa0W4oTOb1WT7fJlAC+oNPdbB+3hVbJSRgv+4lGOETKUQz6OYStslQ142dNCuabNPGBzlooOmB231qMM85d2/fV6ChevvXvQP8Hkue1poOFtnEtpyxVLW1zAo6/1Xx1COxFvrc2d7UL/lmHInNlxuacJXwu0fjpXfz/YqYzBIBzD6WUfTIF9GRHpOn/Hz7saL8xz+W//FRAUid1OksQaQx4CMs8LOddcQhULW4ucetDf96JcR3g0gfRK4PC7E/r7Z6xNrXd2UIeorGj5Ef7b1pJAYB6Y5anaHqZ9J6nKEBvB4DnNLIVWSgARns/8wR2SiRS7MNACwTyrGvt9ts8p12PKFdlqYTopNHR1Vf7XjfhQlVsAJdNiKdYmYVoKlaRv85IfVunYzO0IKXsyl7JCUjCpoG20f0a04COwfneQAGGwd5oa+T8yO5hzuyDb/XcxxmK01EpqOyuxINew=='    iv = 'r7BXXKkLb8qrSNn05n0qiA=='    pc = WXBizDataCrypt(appId, sessionKey)    print pc.decrypt(encryptedData, iv)if __name__ == '__main__':    main()

用户点击登录 → 小程序调用wx.login()接口，从微信服务器获取一次性临时凭证code。

小程序通过wx.request()将code发送至开发者服务器。

开发者服务器调用微信接口auth.code2Session，提交code+appid+appsecret，换取用户的openid（唯一标识）和session_key（会话密钥）

关键代码示例：

# 服务端请求微信接口response = requests.get(   "https://api.weixin.qq.com/sns/jscode2session",   params={        "appid": "小程序ID：appid",        "secret": "小程序密钥：appsecret",        "js_code": "前端传递的code",        "grant_type":"authorization_code"    })# 返回数据示例：{"session_key":"***..***","openid":"user_123"}

开发者服务器基于session_key和openid生成自定义Token（如JWT），用于后续身份校验。

注意：禁止将session_key返回前端，仅限后端存储。

产品后台服务将Token返回小程序，通过wx.setStorageSync保存至本地，后续请求携带Token验证身份。

code 是通过在微信小程序前端调用 wx.login() 接口获得的临时登录凭证。

特点：生命周期短、一次性使用的特性。

主要作用：作为小程序向开发者后端服务器请求用户身份信息的凭据，换取 openid 和 session_key 的临时凭证。

session_key 是微信服务器在验证了前端传递的 code 后，返回给开发者后端服务器的一个会话密钥。

主要作用：在后端服务器解密由小程序前端加密的用户敏感数据（例如用户授权后的个人信息或手机号），以及验证小程序前端发起的请求的完整性和真实性。

openid 是微信用户在当前小程序内的唯一标识符

主要作用：开发者通常会将 openid 作为用户在其后端系统中的唯一ID，用于关联用户的其他业务数据。同一个微信用户在不同的小程序中拥有不同的 openid。

appsecret 是在微信公众平台注册小程序后生成的一个非常重要的密钥.

主要作用：开发者后端服务器向微信服务器请求验证 code 并换取 openid 和 session_key，用于验证开发者的身份。

session_key是业务系统与微信服务器的 “桥梁”，一旦泄露，攻击者可伪造合法请求（如解密用户手机号、生成虚假登录态）。

绝对禁止将其返回给小程序前端，且后端需通过 HTTPS 传输、内存级安全存储（避免落盘）和会话过期机制（如 30 分钟失效）降低风险。

appsecret等同于小程序的 “root 密码”，泄露后攻击者可直接调用微信接口（如获取用户列表、发送模板消息）。需通过密钥管理服务（而非明文配置）存储，同时限制其访问权限（仅认证接口可调用）。

code虽为一次性凭证，但传输过程必须全程加密（HTTPS），且后端需在接收后立即销毁内存中的临时存储，避免被未授权进程读取。

开发/生产环境密钥混用本质是环境配置安全边界失效，常见于以下场景：

1、代码泄露：开发人员将包含生产环境appsecret的配置文件（如application.properties）提交到 GitHub 等公开仓库，攻击者直接获取密钥并调用微信接口（如伪造登录、获取用户信息）。

2、配置错误：线上服务器误加载开发环境配置，导致攻击者通过开发阶段预留的调试接口（如未认证的/dev/auth）泄露的开发密钥入侵。

3、权限混淆：开发环境服务器与生产环境共享密钥存储，一旦开发机被植入恶意软件，生产密钥可能被窃取。

联想GIC全球安全实验室（中国）

[email protected]