# 云托管小程序登录流程优化

微信云托管提供的是后端云服务，从一定程度上来说，和你之前使用的服务器一样，都是为小程序的运行提供后端支撑的。

微信云托管有很多优势，除了容器化之外，最核心的，就是其强大的微信生态属性。

## 小程序原始登录

如果你用的是服务器，要判定一个小程序用户到底是谁，你可以通过两种形式：

第一种，按照一个 WEB 网页的思维来解决，不管是谁，直接先用户名密码登录，或者手机号发送短信登录，握手验证之后下发一个 token 令牌或者 cookie，后续就直接按照这个令牌来标识，失效了就重新登录。

第二种，通过微信小程序的 `wx.login` 方法，获取一个 code，然后拿着这个 code 在后端向微信服务器寻求认证，最终得到这个用户的身份 ID，一般叫做 openid（一个微信用户和一个小程序的关系称为 openid，不同用户不同小程序的 openid 都不一样），由此我们可以判定身份，然后通过其他的登录附加（手机号认证、三要素、四要素认证，内部密码登录）将自己业务的用户库和微信的用户体系关联起来。这么做的好处就是，一经关联，后续就不需要再进行附加认证了，直接判定关系就可以确定用户身份和权限。这是典型的[SSO 单点登录](https://zh.wikipedia.org/wiki/%E5%96%AE%E4%B8%80%E7%99%BB%E5%85%A5)。

![](https://res8.wxqcloud.qq.com.cn/wxdoc/50038c53-68fa-4e95-8de6-f2fd270cdd01.jpg)

但无论如何，最终后端服务都需要根据用户标识来生成自定义登录态，用于后续业务逻辑中前后端交互时识别用户身份。

在文档中明确表示，[wx.login](/miniprogram/dev/api/open-api/login/wx.login.md)后，通过[auth.code2Session 接口](/miniprogram/dev/server/API/user-login/api_code2session.md)获取的会话密钥 `session_key` 是对用户数据进行加密签名的密钥。为了应用自身的数据安全，不应该把会话密钥下发到小程序，也不应该对外提供这个密钥。

## 微信云托管优化

当你的项目从服务器迁移到云托管中时，上述的 wx.login 获取 code 置换登录的流程就没有存在的必要了。

在小程序端，通过 [wx.cloud.callContainer](/minigame/dev/wxcloudrun/src/development/call/mini) 向你的云托管服务发起请求时，你的服务会在 header 中获得该请求用户的全部信息。

| header | 说明 |
| ---- | ---- |
| X-WX-OPENID  | 小程序用户 openid |
| X-WX-APPID  | 小程序 AppID |
| X-WX-UNIONID  | 小程序用户 unionid，并且[满足 unionid 获取条件](/miniprogram/dev/framework/open-ability/union-id.md)时有 |
| X-WX-FROM-OPENID  | 资源复用情况下，小程序用户 openid |
| X-WX-FROM-APPID  | 资源复用情况下，使用方小程序 AppID |
| X-WX-FROM-UNIONID  | 资源复用情况下，小程序用户 unionid，并且[满足 unionid 获取条件](/miniprogram/dev/framework/open-ability/union-id.md)时有 |
| X-WX-ENV  | 所在云环境 ID |
| X-WX-SOURCE  | 调用来源（本次运行是被什么触发） |
| X-Forwarded-For  | 客户端 IPv4 或IPv6 地址 |

你可以直接从 header 中拿到信息后做业务判定，然后进行业务正常服务。**不需要 wx.login 登录，也不需要 code 换 session**

这个能力是不带任何条件的，小程序只要使用[wx.cloud.callContainer](/minigame/dev/wxcloudrun/src/development/call/mini)，云托管服务收到这个请求，信息就自然而然带入进来了。

而且云托管免登录验证的这些信息，是由微信团队保证的，全程进行了加密处理，防刷防攻击。

不仅省去了 code 转换的步骤，而且还不需要自己做登录态了，因为你在任意请求中都可以拿到用户的身份信息。

如果你坚持使用原本的[auth.code2Session 接口](/miniprogram/dev/server/API/user-login/api_code2session.md)置换 code 登录这个流程，也没有什么问题，云托管并不会阻碍你这么用，但需要明确的是，这种情况并不会有任何安全、防刷的能力提升，完全是无视了微信云托管的生态属性，当成一个普通服务器来用。

## 总结

我们目睹了很多开发者因为接入的不严谨，导致各种信息泄漏和握手漏洞问题频发。我们也清楚的理解，并不是所有开发者都有大团队那么丰富的安全经验和高防配置，也无法自我发现和解决一些看起来非常常见的漏洞和泄漏风险。

微信云托管从一定程度上缩短了开发者之间服务安全的差距，全力保证服务可信性，深度和微信生态融合。在这一基础上，开发者只需要专注自身业务，省心省力。

公众号的授权登录流程原理以及云托管优化和小程序一样，具体可以看[直播回放](https://developers.weixin.qq.com/community/business/doc/00022e381fca906f39ed8747f56c0d)。