很多人乍一听“小程序登录”,以为只是用户输个账号密码,但微信生态的登录逻辑是依托微信身份+自定义业务逻辑来实现的,核心流程可以拆成这几步:
用户触发登录操作(比如点“微信快捷登录”按钮);
前端调用微信提供的
wx.login()
API,从微信服务器拿到一个临时code(相当于用户的“临时身份凭证”);前端把这个code传给自己的后端服务器;
后端拿着code,再带上小程序的
appid
、appsecret
,调用微信的auth.code2Session
接口,换取用户的openid
(用户在当前小程序的唯一标识)、session_key
(加密密钥,用来解密用户授权信息);(可选环节)如果需要用户头像、手机号等信息,前端还要引导用户授权,拿到授权凭证后传给后端,后端用
session_key
解密出真实信息;后端生成自定义登录态(比如token),返回给前端;前端把登录态存在本地(如
wx.setStorage
),后续接口请求时带上这个登录态,证明用户已登录。
前端第一步“调用wx.login”要做啥?
问:前端调用 wx.login()
具体实现啥功能?要注意啥?
wx.login()
是微信开放给小程序的“登录入口”,调用后微信服务器会返回一个临时code,这个code有两个关键特点:
时效性短:只有5分钟有效期,所以前端拿到code后得立刻传给后端,别存着等过期了再用;
一次性:同一个code只能换一次
openid
和session_key
,重复调用会失效。
实操时,前端一般这么做:
在登录按钮的点击事件里写
wx.login()
,Page({ handleLogin() { wx.login({ success(res) { if (res.code) { // 把code传给后端 wx.request({ url: 'https://你的后端域名/Login', method: 'POST', data: { code: res.code }, success: (res) => { /* 处理后端返回的登录态 */ } }) } else { console.error('登录失败!' + res.errMsg) } } }) } })
要注意:
wx.login()
不需要用户授权(用户无感知),所以哪怕用户没点“授权手机号”,也能调用它拿到code,实现“静默识别用户”。
后端拿到code后咋和微信交互?
问:后端接收到code后,怎么拿到用户的openid和session_key?
后端需要主动调用微信官方的 auth.code2Session
接口,请求格式是这样的:GET https://api.weixin.qq.com/sns/jscode2session?appid=APPID&secret=SECRET&js_code=CODE&grant_type=authorization_code
参数里:
appid
和secret
是你小程序在微信公众平台的“身份证”(登录公众平台→开发→开发设置里找);js_code
就是前端传过来的临时code;grant_type
固定填authorization_code
。
调用成功后,微信会返回这几个关键信息:
openid
:用户在当前小程序的唯一标识(不同小程序的openid不一样);session_key
:加密密钥,后续解密用户授权的手机号、头像等信息必须用它;unionid
:如果你的小程序和公众号、APP等绑定在同一个微信开放平台账号下,unionid是用户在开放平台的唯一标识(多端打通登录的关键)。
这里必须注意:session_key
是后端的“秘密武器”,绝对不能传给前端!因为它能解密用户信息,一旦泄露,用户隐私就危险了,所以后端拿到 session_key
后,要安全存储(比如存在数据库或缓存里,关联用户openid)。
用户授权环节(如头像昵称、手机号)咋整合进登录?
问:想让用户授权手机号、头像,这部分流程咋和登录串起来?
微信小程序的用户授权分两种常见场景:用户信息授权(头像、昵称)和手机号授权,流程逻辑类似,都是“前端触发授权→拿授权凭证→后端解密”。
用户信息授权(以头像、昵称为例)
早年用 wx.getUserInfo
直接拿信息,现在微信要求必须用户主动点击授权按钮,所以得用 wx.getUserProfile
:
前端做个“授权头像昵称”按钮,绑定点击事件;
点击时调用
wx.getUserProfile
,用户确认授权后,返回包含encryptedData
(加密后的用户信息)、iv
(加密偏移量)的对象;前端把
encryptedData
、iv
还有之前拿到的code
一起传给后端;后端用
session_key
+iv
+encryptedData
解密,就能拿到用户的头像URL、昵称等信息。
代码示例(前端):
Page({ handleAuthUserInfo() { wx.getUserProfile({ desc: '用于完善会员资料', // 必须填,说明授权用途 success: (res) => { // res包含encryptedData、iv等 wx.request({ url: 'https://你的后端域名/AuthUserInfo', method: 'POST', data: { code: 前端保存的code, encryptedData: res.encryptedData, iv: res.iv }, success: (res) => { /* 处理授权结果 */ } }) } }) } })
手机号授权
如果业务需要用户手机号(比如电商下单、社交私信),得用 getPhoneNumber
接口:
前端放个“授权手机号”按钮,按钮开放能力设为
getPhoneNumber
;用户点击后,微信会返回
code
(手机号授权的临时凭证,注意和wx.login
的code区分开);前端把这个手机号code、还有
wx.login
拿到的code一起传给后端;后端先拿
wx.login
的code换session_key
,再用session_key
+ 手机号code 调用微信的phoneNumber.getPhoneNumber
接口,解密出真实手机号。
关键点:手机号授权的code只有5分钟有效期,而且必须和对应的 session_key
匹配,所以前后端要配合好时效~
登录态该咋设计和维护?
问:后端返回的登录态(比如token),前端咋存?过期了咋处理?
登录态是用户后续访问业务接口的“通行证”,常见方案是后端生成 JWT
(JSON Web Token)或自定义的 token
,返回给前端后:
前端存储:用
wx.setStorageSync
存在本地缓存,下次请求接口时,在请求头里带上token
(Authorization: Bearer xxx
);过期处理:给token设个有效期(比如2小时),过期后前端要么跳转到登录页重新走流程,要么用“刷新token”机制(后端生成两个token:access_token和refresh_token,access_token过期后用refresh_token换新的);
安全兜底:如果用户清除了缓存,或换设备登录,本地token丢失,就得重新触发
wx.login
流程。
举个实际场景:用户打开小程序,前端先检查缓存里有没有有效的token,如果有,直接用token请求接口;如果没有,自动触发 wx.login
走登录流程,这样用户感知不到“重新登录”,体验更丝滑~
静默登录和主动授权登录有啥区别?
问:经常听到“静默登录”,和需要用户点授权的登录有啥不一样?
简单说,静默登录不需要用户主动点授权,能快速识别用户;主动授权需要用户确认,能拿到更多信息。
类型 | 静默登录 | 主动授权登录 |
---|---|---|
触发条件 | 调用 wx.login() 即可 | 用户点击授权按钮(如授权手机号) |
用户感知 | 无弹窗,全自动 | 有授权弹窗,用户需点击确认 |
能拿到的信息 | openid(小程序内唯一标识) | openid + 手机号/头像/昵称等 |
适用场景 | 内容推荐、轻互动(如看资讯) | 电商下单、社交绑定、会员体系 |
比如新闻类小程序,用户打开就能看内容,用静默登录识别用户,记录浏览偏好;而外卖小程序必须要手机号下单,就得引导用户主动授权~
登录流程里的安全风险咋防范?
问:听说登录环节容易被攻击,咋保障安全?
微信小程序登录涉及用户隐私和业务数据,得从传输、存储、逻辑三方面防风险:
传输层:后端接口必须用
HTTPS
,防止中间人截获code、token等信息;存储层:
session_key
绝对不能存在前端(localStorage),必须由后端加密存储;前端存的token要设置合理有效期,别太长;逻辑层:
code
时效性短(5分钟),前端拿到后立即传后端,别在前端停留;授权信息解密必须在后端做(前端解密太危险,容易被逆向工程破解);
多设备登录要做限制(比如同一账号同时只能在1台设备登录,后端检测到新设备登录时踢掉旧设备)。
举个反面案例:如果后端把 session_key
传给前端,黑客抓包拿到后,就能解密用户的手机号、头像,直接侵犯隐私!
常见登录问题咋排查?
问:开发时遇到登录失败,咋快速定位问题?
这几个高频坑要优先检查:
code无效:
检查
appid
、appsecret
是否和小程序对应(开发版、体验版、正式版的appid不一样!);确认code是不是过期了(超过5分钟),或者被重复使用了;
后端调用
auth.code2Session
时,参数拼写别错(比如把js_code
写成code
)。授权失败:
用户拒绝授权后,前端要做友好提示(需要授权手机号才能下单哦~”),并提供重新授权的按钮;
检查授权API是否用对(比如手机号授权要用
getPhoneNumber
,而不是旧版接口)。登录态失效:
检查token有效期是不是设太短(比如设成1分钟,用户还没操作就过期了);
后端验证token的逻辑是否正确(比如JWT签名是否匹配)。
unionid拿不到:
确认小程序和其他应用(如公众号)是否绑定到同一个微信开放平台账号;
只有用户授权过(比如关注公众号、登录过APP),小程序里才能拿到unionid。
多端(小程序+公众号+APP)打通登录咋做?
问:公司有小程序、公众号、APP,想让用户一次登录多端通用,咋实现?
核心是利用微信的 unionid
机制:
把小程序、公众号、APP都绑定到同一个微信开放平台账号下;
用户在小程序里登录时,后端拿到
unionid
;在公众号里登录时,通过OAuth2.0也能拿到unionid
;在APP里登录时,用微信登录SDK也能拿到unionid
;后端把同一个用户的
unionid
和各端的账号体系关联起来(比如用户在小程序的openid、公众号的openid、APP的用户ID都绑定到unionid下);后续用户不管从哪个端登录,后端通过unionid识别是同一个用户,实现“一次授权,多端通用”。
比如用户在小程序里授权过手机号,之后用公众号登录时,后端通过unionid找到关联的手机号,直接免密登录,体验拉满~
登录流程的设计思路
微信小程序登录不是单一功能,而是“微信身份验证 + 业务身份绑定 + 登录态管理” 的组合拳,开发时要记住:
前端聚焦“用户交互+凭证传递”,后端聚焦“微信接口对接+安全存储+业务逻辑”;
优先保障安全(session_key别外传、HTTPS必须开);
结合业务场景选登录方式(静默/主动授权);
多端打通靠unionid,别重复造轮子。
现在再回头看登录按钮,是不是觉得背后的逻辑清晰多了?下次开发时,从用户点按钮的瞬间,到后端存好session_key,每个环节都知道该咋处理啦~
网友回答文明上网理性发言 已有0人参与
发表评论: