Web系统之常用认证方式
重要说明：
这里的Web系统仅针对运行在浏览器上的站点。
1、认证方式分类
常见Web系统的认证方式可分为登录前和登录后认证两大类。登录后的认证方式之所以不同主要在于两点。第一点是方便用户，不可能每次请求都要求用户输入用户名或密码。第二点是安全，每次包含用户名或密码的请求，加大了用户名或密码被窃取的风险。
2、登录前认证
常用的登录身份认证方式如下。
2.1、账号/密码
最常用，简单，成本低的认证方式。
安全小提示：Web站点以HTTP或HTTPS发送。若使用HTTP，浏览器端需对密码进行加密（比如MD5）再传输到服务端，安全性较低。若使用HTTPS，浏览器无需对密码加密就可直接传输，因协议本身提供了极高的安全。
2.2、手机号/短信验证码
步骤引用链接：https://blog.csdn.net/tywei_24/article/details/74129883
1）首先客户端会有一个获取验证码的请求，通过基于SMS Sdk提供的api,去获取验证码，向Mob服务器发送请求 ，并且携带phone电话号码，给Mob短信平台的服务器。
2）Mob官方提供的短信平台收到请求以后，生成一个针对该phone，对应的短信码。例如：1568
3）此时Mob短信平台会把信息发送给客户端，告诉客户端，验证码已经发送给你了。
4）然后客户端会通过集成SMS Sdk的api中EventHandler接口方法，进行处理回馈的结果，拿到验证码。
5）客户端拿到验证码信息后，会继续想Mob平台发送请求，进行短信码的验证（手机号和验证码）。
6）此时Mob官方平台得到请求之后，再次处理并且告诉客户端处理效验码的结果。是正确与否。
7）如果校验结果正确了，会进行本地接口的调用。进行本地登录。请求自己的服务器。
8）本地服务器得到用户信息后，会返回给客户端用户信息。客户端获取用户信息后，会进行持久化用户信息（数据库）
安全小提示：同账号/密码。
2.3、第三方登录
一般使用的第三方登录认证协议都是基于OAuth2。比如简书的四种第三方登录账号（微博、微信、QQ、豆瓣），如下图。
image.png
另外OpenID Connect同样也是基于OAuth2的一个认证协议。
关于OAuth2协议本身，可查阅http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html。
需要指出的是：Oauth2是一个授权协议（Resource owner授权客户端可以访问自己哪些resources）。OpenID Connect是一个利用OAuth2并在此基础上做了扩展，扩展项比如IDToken和获取用户信息端点，获取用户信息端点同样也需要Resource owner授权。
一个安全小问题：为什么用OAuth2协议是安全的呢？
答：以OAuth2授权码流程为例，当resource owner允许客户端访问某些资源后，然后授权服务器会生成responseCode，并重定向到Client1的某个链接中（链接中需要带responseCode）。这里完全不用担心responseCode被泄露，因为其他Client（或恶意Client）无Client1的Secret，所以根本无法使用这个responseCode。另一个安全前提是授权服务需开放HTTPS的接口。
2.4、 二维码扫码
比如天猫站点的登录方式就有二维码方式，使用天猫手机APP扫描二维码并确认登录，天猫站点就可以成功登录。天猫登录截图，如下。
image.png
说明：天猫二维码登录方式并没采用OAuth2，因为不涉及到第三方Client。登录大致原理是APP确认登录后，站点可以获得token和用户Id，根据token和用户Id即可完成登录。
3、登录后认证
3.1、基于Cookie和Session的认证
当登录成功后，保存用户登录成功状态到服务端的用户所属Session中，并将sessionId返回给浏览器，再由浏览器保存sessionId到Cookie中。再次发送请求时（Cookie将会被携带），服务端可从请求中取出sessionId，发现sessionId已存在并session未过期，从而认证通过。Session是有时效性的，从而可以一定防止sessionId泄漏导致的系统数据泄漏。
注意：需要在安全的网络环境中进行请求交互，比如https。
3.2、基于Token的认证
当登录成功后，保存用户信息到一种token中，比如常用的JWT token。再次发送请求时（Token会被携带），服务端可对Token进行验证，验证成功则允许访问特定的资源。
注意：服务端怎么知道请求的客户端是可信的呢？答案是服务端无法知道，只能验证JWT token是否被篡改过。所以需要在一个安全的网络环境中使用token，例如Https。
