本文正在参加「金石计划 . 瓜分6万现金大奖」。
前端登录有很多种方式，我们来挑一些常见的方案先梳理一下，后续再补充更多的。
账号密码登录
在系统数据库中已经有了账号密码，或者通过注册渠道生成了账号和密码，此时可以直接通过账号密码登录，只要账号密码正确就认为身份合法，可以换到系统访问的 token，用于后续业务鉴权。
验证码登录
比如手机验证码，邮箱验证码等等。用户首先提供手机号/邮箱，后端根据会话信息生成一个特定的码下发到用户的手机或者邮箱（通过运营商提供的能力）。
用户得到这个码后填入登录表单，随手机号/邮箱一并发给后端，后端拿到手机号/邮箱、码后，与会话信息做校验，确认身份信息是否合法。
如果一致就检查数据库中是否有这个手机号/邮箱，有的话就不用创建用户了，直接通过登录；没有的话就说明是新用户，可以先创建用户，绑定好手机号/邮箱，然后通过登录。
第三方授权
比如微信授权，github授权之类的，可以通过OAuth授权得到访问对方开放API的能力。
OAuth 协议读起来很复杂，其实本质上就是：
- 我是开发者，有个自己的业务系统。
- 用户想图方便，希望通过一些常用的平台（比如微信，支付宝等）登录到我的业务系统。
- 但是这也不是你想用就能用的，我首先要去三方平台登记一下我的应用，比如注册一个微信公众号，公众号再绑定我的业务域名（验证所有权），可能还要交个费做微信认证之类的。
- 交了保护费后（经过上面的操作），我的业务系统就是某三方平台的合法应用了，就可以使用某三方平台的开放接口了。
- 此时用户来到我的业务系统客户端，点击微信一键登录。
- 然后我的业务系统就会按照微信的规矩生成一些鉴权需要的信息，拉起微信的中间页（如果是手机客户端，那可能就是通过 SDK 拉起手机微信）让用户授权。
- 用户同意授权，微信的中间页鉴权成功后，就会给我的客户端返回一个 code 之类的回调信息，客户端需要把这个 code 传给后端。
- 后端拿到这个 code 可以去微信服务器换取 access_token，基于这个 access_token，可以获取微信用户基本开放信息和帮助用户实现基础开放功能等。
- 后端也可以基于此封装自定义的登录态返给客户端，如有必要，也可以生成用户表中的记录。
- 此时我就认为这个用户是通过微信合法登录到我的系统中了。
有些字段或者信息之类的可能会描述得不够精确，但是整个鉴权的思路大概就是这样。
微信小程序登录
wx.login + code2Session 无感登录
如果你的业务系统需要鉴权大部分接口，但是又不想让用户一打开小程序就去输入啥或者点啥按钮登录，那么无感登录是比较适合的。
关键是找到能唯一标识用户身份的东西，openid 或者 unionid 就不错。那么怎么无感得到这些？wx.login + code2Session 值得拥有。
小程序前端 wx.login 得到用户登录凭证 code（目前说的有效期是五分钟），然后把 code 传给服务端，服务端调用微信服务的 auth.code2Session，使用 code 换取 openid、unionid、session_key 等信息，session_key 相当于是当前用户在微信的会话标识，我们可以基于此自定义登录态再返回给前端，前端拿着登录态再访问后端的业务接口。
getPhonenumber授权手机号登录
当指定 button 组件的 open-type 为 getPhoneNumber 时，可以拉起手机号授权，手机号某种程度上可以标识用户身份，自然也可以用来做登录。
旧版方案中，getPhonenumber得到的 e 对象中有 encryptedData, iv 字段，传给后端，根据解密算法能得到手机号和区号等信息。手机号也相当于是一种可以唯一标识用户的信息（虽然一个人可以有多个手机号，不过宽松点来说也可以用来标识用户），自然可以用来生成用户表记录，后续再与其他信息做关联即可。
但是旧版方案已经不建议使用了，目前 getPhonenumber得到的 e 对象中有 code 字段，这个 code 和 wx.login 得到的 code 不是同一回事。我们把这个 code 传给后端，后端再调用 phonenumber.getPhoneNumber得到手机号信息。
接着再封装登录态返回给前端即可。
微信公众号登录
首先分析一下渠道，在微信环境中，用户可能会直接通过链接访问 H5，也可能通过公众号菜单进入 H5。
微信公众号网页提供了授权方案，具体可以参考这个网页授权文档。
授权有两种形式，snsapi_base 和 snsapi_userinfo。
这个授权是支持无感的，具体见这个解释。
关于特殊场景下的静默授权
上面已经提到，对于以snsapi_base为 scope 的网页授权，就静默授权的，用户无感知；
对于已关注公众号的用户，如果用户从公众号的会话或者自定义菜单进入本公众号的网页授权页，即使是 scope 为snsapi_userinfo，也是静默授权，用户无感知。
这基本上就是说，如果是 snsapi_base 方式，目的主要是取 token 和 openid，用来做后续业务鉴权，那就是无感的。
如果是 snsapi_userinfo 方式，除了拿鉴权信息，还要要拿头像昵称等信息，可能需要用户授权，不过只要关注了该公众号，也可以不出现授权中间页，也是无感的。
下面说下具体的交互形式。
snsapi_base 场景下，需要绑定一个回调地址，交互形式是：
- 根据标准格式提供链接：
https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=snsapi_base&state=STATE#wechat_redirect
-
你可以在公众号菜单跳转这个标准链接，或者通过其他网页跳转这个链接。这个链接是个微信鉴权的中间页，如果鉴权没问题就会回调到 REDIRECT_URI 对应的业务系统页面，也就是用户真正前往的网页，用户能感知到的就是网页的进度条加载了两次，然后就到目标页面了，基本上是无感的。
-
页面在回调时会在 querystring 上携带 code 参数。前端在这个页面拿到 code 后，可以传给后端，后端就可以调下面这个接口得到 token 信息，然后封装出登录态返给前端。
https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code
具体实现时，不一定要在页面层级上完成 code 换 token 的操作，也可以在应用层级上实现。
- 后续可以根据需要进行 refreshToken。
snsapi_userinfo 场景下，也是跳一个标准链接。与 snsapi_base 场景相比，除了 scope 参数不一样，其他都一样。跳转这个标准链接时会根据有没有关注公众号决定是否要拉起授权中间页面。
https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECT_URI&response_type=code&scope=snsapi_userinfo&state=STATE#wechat_redirect
接着也可以根据 code 换 token，进行必要的 refreshToken。
最重要的是，在 scope=snsapi_userinfo 场景下，还可以发起获取用户信息的请求，这才是它与 snsapi_base 的本质区别。如果 scope 不符合要求，则无法通过调用下面的接口得到用户信息。
https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN
还有一些公告调整内容要注意一下：
结语
好了，前端常见的一些登录方式先整理到这里，实际上还有很多种方案还没提到，比如生物认证登录，运营商验证登录等等，后面再补充，只要是双方互相认可的方案，并且能标识用户身份，不管是严格的还是宽松的，都可以拿来做认证使用，具体还要根据你的业务特性决定。
