Web认证_介绍Web开发中⼏种常⽤的认证机制
如今web服务随处可见，成千上万的web程序被部署到公⽹上供⽤户访问，有些系统只针对指定⽤户开放，属于安全级别较⾼的web应⽤，他们需要有⼀种认证机制以保护系统资源的安全，本⽂将探讨五种常⽤的认证机制及优缺点。
HTTP基本认证（HTTP Basic Auth）
在HTTP中，HTTP基本认证是⼀种允许Web浏览器或者其他客户端在请求时提供⽤户名和⼝令形式的⾝份凭证的⼀种登录验证⽅式。
简单⽽⾔，HTTP基本认证就是我们平时在⽹站中最常⽤的通过⽤户名和密码登录来认证的机制。
优点:
HTTP 基本认证是基本上所有流⾏的⽹页浏览器都⽀持。但是基本认证很少在可公开访问的互联⽹⽹站上使⽤，有时候会在⼩的私有系统中使⽤。
缺点:
HTTP 基本认证虽然⾜够简单，但是前提是在客户端和服务器主机之间的连接⾜够安全。如果没有使⽤SSL/TLS这样的传输层安全的协议，那么以明⽂传输的密钥和⼝令很容易被拦截。由于现存的浏览器保存认证信息直到标签页或浏览器关闭，或者⽤户清除历史记录。导致了服务器端⽆法主动来当前⽤户登出或者认证失效。
OAuth（开放授权）
OAuth（开放授权）是⼀个开放的授权标准，允许⽤户让第三⽅应⽤访问该⽤户在某⼀web服务上存储的私密的资源（如照⽚，视频，联系⼈列表），⽽⽆需将⽤户名和密码提供给第三⽅应⽤。
OAuth允许⽤户提供⼀个令牌，⽽不是⽤户名和密码来访问他们存放在特定服务提供者的数据。每⼀个令牌授权⼀个特定的第三⽅系统（例如，视频编辑⽹站)在特定的时段（例如，接下来的2⼩时内）内访问特定的资源（例如仅仅是某⼀相册中的视频）。这样，OAuth让⽤户可以授权第三⽅⽹站访问他们存储在另外服务提供者的某些特定信息，⽽⾮所有内容
下⾯是OAuth2.0的流程：
（1）客户端（Client）向资源拥有者（Resource Owner）发送授权请求（Authorization Request）
sessionstorage和localstorage（2）资源拥有者授权许可（Authorization Grant）
（3）客户端向验证服务器（Authorization Server）发送通过（2）获取的授权许可
（4）验证服务器验证授权许可，通过的话，则返回Access Token给客户端
（5）客户端通过Access Token 访问资源服务器（Resource Server）
（6）资源服务器返回受保护的资源（Protected Resource）
这种基于OAuth的认证机制适⽤于个⼈消费者类的互联⽹产品，如社交类APP、⾖瓣、js-SDK等应⽤，但是不太适合拥有⾃有认证权限管理的企业应⽤；
Cookie/Session
Cookie 是由客户端保存的⼩型⽂本⽂件，其内容为⼀系列的键值对。Cookie 是由 HTTP 服务器设置的，保存在浏览器中。Cookie会随着HTTP请求⼀起发送。
Session 是存储在服务器端的，避免在客户端 Cookie 中存储敏感数据。Session 可以存储在 HTTP 服务器的内存中，也可以存在内存数据库（如redis）中。
Cookie/Session认证机制就是为⼀次请求认证在服务端创建⼀个Session对象，同时在客户端的浏览器
端创建了⼀个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在⼀定时间内有效。
Token认证
基于 Token的认证机制，有着⽆需长期保存⽤户名和密码，服务器端能主动让token失效等诸多好处，⾮常实⽤于 Web 应⽤和 App 已经被很多⼤型⽹站采⽤，⽐如Facebook、Github、Google+等。
其流程如下：
1. 客户端使⽤⽤户名和密码请求登录
2. 服务端收到请求，去验证⽤户名与密码
3. 验证成功后，服务器会签发⼀个 Token，再把这个 Token 发送给客户端
4. 客户端收到 Token 以后可以把它存储起来，如Cookie或者Web Storage
5. 客户单每次向服务端请求资源的时候，都需要带着服务器端签发的 Token
6. 服务器端收到请求，验证客户端请求⾥⾯带着的 Token，如果验证成功，就向客户端返回请求的数据；否的话，则返回对应的
错误信息。
Token认证的优点：
⽀持跨域访问: Cookie是不允许垮域访问的，这⼀点对Token机制是不存在的，前提是传输的⽤户认证信息通过HTTP头传输.
⽆状态(也称：服务端可扩展⾏):Token机制在服务端不需要存储session信息，因为Token ⾃⾝包含了所有登录⽤户的信息，只需要在客户端的cookie或本地介质存储状态信息.
更适⽤CDN: 可以通过内容分发⽹络请求你服务端的所有资料（如：JavaScript，html，图⽚等），⽽你的服务端只要提供API即可.
去耦: 不需要绑定到⼀个特定的⾝份验证⽅案。Token可以在任何地⽅⽣成，只要在你的API被调⽤的时候，你可以进⾏Token⽣成调⽤即可.
更适⽤于移动应⽤: 当你的客户端是⼀个原⽣平台（iOS, Android，Windows 8等）时，Cookie是不被⽀持的（你需要通过Cookie容器进⾏处理），这时采⽤Token认证机制就会简单得多。
CSRF：因为不再依赖于Cookie，所以你就不需要考虑对CSRF（跨站请求伪造）的防范。
性能: ⼀次⽹络往返时间（通过数据库查询session信息）总⽐做⼀次HMACSHA256计算的Token验证和解析要费时得多.
不需要为登录页⾯做特殊处理: 如果你使⽤Protractor 做功能测试的时候，不再需要为登录页⾯做特殊处理.
基于标准化：你的API可以采⽤标准化的 jsON Web
但是存储在客户端的 Token 存在⼏个问题：
1. 存在泄露的风险。如果别⼈拿到你的 Token，在 Token过期之前，都可以以你的⾝份在别的地⽅登录
2. 如果存在 Web Storage（指sessionStorage和localStorage）。由于Web Storage 可以被同源下的JavaScript直接获取到，这
也就意味着⽹站下所有的JavaScript代码都可以获取到web Storage，这就给了XSS机会
3. 如果存在Cookie中。虽然存在Cookie可以使⽤HttpOnly来防⽌XSS，但是使⽤ Cookie 却⼜引发了CSRF
对于泄露的风险，可以采取对Token进⾏对称加密，⽤时再解密。对于XSS⽽⾔，在处理数据时，都应该 escape and encode 所有不信任的数据。与CSRF相⽐，XSS更加容易防范和意识到，因此并不建议将Token存在Cookie中。
最后，⽹站或者应⽤⼀定要使⽤HTTPS。毕竟在⽹络层⾯上 Token 明⽂传输的话，还是⾮常的危险。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。