标签：用户名 HTTP 登录 方式 认证 密码 客户端

HTTP认证方式

2021-01-13T20:23:43+08:00

HTTP认证方式

本节参考： https://zhuanlan.zhihu.com/p/64584734 https://www.loginradius.com/blog/async/everything-you-want-to-know-about-authorization-headers/ https://www.cnblogs.com/xiongmaomengnan/p/6671206.html https://www.jianshu.com/p/cf5a900d4ef7

B/S和C/S形式的远程通信，一般都是基于HTTP和RFC的方式进行的。今天说一下HTTP通信过程中的身份认证。

服务器上的资源，并不都是公开的。某些资源的访问需要具有一定的权限才可以。

HTTP/1.0中在http头中引入了权限（Authorization）字段。

Basic Auth

最初的认证是简单认证，在HTTP报文（头部）中是这样的

Authorization: Basic <username:password的base64加密结果>

像这样：

Authorization: Basic AXVubzpwQDU1dzByYM==

但是HTTP报文在网络上是有可能被截获的，而base64加密过的结果，也很容易解密，从而导致用户名和密码被其他人获取。

Bearer Token

为了减少（加密过的）用户名和密码在网络上传递的次数，降低被盗用的风险， 可在简单认证通过后，服务器返回一个token。之后访问服务器需要权限的资源就不再使用（加密过的）用户名和密码，而是使用token。

可以把这个token放到HTTP报文头部，像这样的形式：

Authorization: Bearer <token>

API Key

类似于Bearer Token，客户端调用服务器API时，常常需要携带token，一般叫做API Key。

常见的调用形式：

GET /endpoint?api_key=abcdefgh123456789

也常常将API Key放置到HTTP头部：

X-API-Key: abcdefgh123456789

Digest Auth

Digest认证试图解决Basic认证的缺陷而设计，用户密码并没有在网络上传递，传递的是密码（和账号等其他几个参数）的hash值。而通过hash值破解出密码一般认为是不现实的。

摘要认证的一个改进之处是用摘要代替密码的传输，遵循的基本原则是“绝对不通过网络发送明文密码”，而是发送一个密码的摘要信息，并且这摘要信息是不可逆的，即无法通 过摘要信息反推出密码信息

客户端向服务器请求认证的过程：

• 客户端发起请求
• 服务返回401未认证， 并要求使用Digest认证， 并提供一个随机串nonce，以及支持的hash算法
• 客户端计算： hash(nonce+账号+密码)， 并将hash结果和账号名发送给服务器
• 服务器根据账号名，找到对应的账户信息， 同样计算hash(nonce+账号+密码)， 对比计算的hash值与客户端传回的hash值， 对比通过即可将原来客户端请求的资源发送给客户

摘要认证的一个改进之处可以防止重放攻击。摘要被截获也可能跟密码一起好用，为了防止重放攻击的发送，服务器可以向客户端发送一个称为随机数nonce的特殊令牌，这个数会经常发生变化(可能是每毫秒，或者每次认证都发生变化，具体由服务器控制)，客户端在计算摘要之前要先将这个随机数附加到密码上去。这样，在密码中加入随机数就会使得摘要随着随机数的每次变化而变化，记录下的密码摘要只对特定的随机数有效，而没有密码的话，攻击者就无法计算出正确的摘要，这样就可以防止重放攻击的发生。

但是，摘要认证并不能防止中间人攻击。即客户端的请求直接被中间人拦截，中间人拿着客户端的请求信息去请求服务器。实际上HTTP都不能解决中间人攻击问题，需要HTTPS才可以解决。

当前常用的认证方式（会话级别：登录认证）

本章节非原创，转载来源：https://www.cnblogs.com/fengzheng/p/8416393.html

场景说明

以一个电商系统，假设淘宝为例，如果我们想要下单，首先需要注册一个账号。拥有了账号之后，我们需要输入用户名（比如手机号或邮箱）、密码完成登录过程。之后如果你在一段时间内再次进入系统，是不需要输入用户名和密码的，只有在连续长时间不登录的情况下（例如一个月没登录过）访问系统，再次需要输入用户名和密码。如果使用频率很频繁，通常是一年都不用再输一次密码，所以经常在换了一台电脑或者一部手机之后，一些经常使用的网站或 APP 不记得密码了。

提炼出来整个过程大概就是如下几步：

1. 首次使用，需要通过邮箱或手机号注册；
2. 注册完成后，需要提供用户名和密码完成登录；
3. 下次再使用，通常不会再次输入用户名和密码即可直接进入系统并使用其功能（除非连续长时间未使用）；

OAuth 认证

OAuth 认证比较常见的就是微信登录、微博登录、qq登录等，简单来说就是利用这些比较权威的网站或应用开放的 API 来实现用户登录，用户可以不用在你的网站或应用上注册账号，直接用已有的微信、微博、qq 等账号登录。

这一样一来，即省了用户注册的时间，又简化了你的系统的账号体系。从而既可以提高用户注册率可以节省开发时间，同时，安全性也有了保障。

维基百科对它的解释摘要如下：

OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

假设我们开发了一个电商平台，并集成了微信登录，以这个场景为例，说一下 OAuth 的工作原理。

讲之前需要了解其中涉及到的几个角色：

• 用户：即使用我们平台的用户
• 用户终端：即最终用户使用的 APP 端或 web 端
• 应用服务器端：即我们的服务器端
• 授权服务器端：这里就是微信处理授权请求的服务器

好的，接下来开始在我们的电商平台web端实现微信登录功能。微信网页授权是授权码模式（authorization code）的 OAuth 授权模式。

1. 我们电商平台的用户过来登录，常用场景是点击“微信登录”按钮；
2. 接下来，用户终端将用户引导到微信授权页面；
3. 用户同意授权，应用服务器重定向到之前设置好的 redirect_uri （应用服务器所在的地址），并附带上授权码（code）;
4. 应用服务器用上一步获取的 code 向微信授权服务器发送请求，获取 access_token，也就是上面说的令牌；
5. 之后应用服务器用上一步获取的 access_token 去请求微信授权服务器获取用户的基本信息，例如头像、昵称等；

Cookie-Session 认证

早期互联网以 web 为主，客户端是浏览器，所以 Cookie-Session 方式最那时候最常用的方式，直到现在，一些 web 网站依然用这种方式做认证。

认证过程大致如下：

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端验证后，创建一个 Session 信息，并且将 SessionID 存到 cookie，发送回浏览器；
3. 下次客户端再发起请求，自动带上 cookie 信息，服务端通过 cookie 获取 Session 信息进行校验；

弊端

• 只能在 web 场景下使用，如果是 APP 中，不能使用 cookie 的情况下就不能用了；
• 即使能在 web 场景下使用，也要考虑跨域问题，因为 cookie 不能跨域；
• cookie 存在 CSRF（跨站请求伪造）的风险；
• 如果是分布式服务，需要考虑 Session 同步问题；

Cookie-Session 改造版

由于传统的 Cookie-Session 认证存在诸多问题，可以把上面的方案改造一下。改动的地方如下：

• 不用 cookie 做客户端存储，改用其他方式，web 下使用 local storage，APP 中使用客户端数据库，这样就实现了跨域，并且避免了 CSRF ;
• 服务端也不存 Session 了，把 Session 信息拿出来存到 Redis 等内存数据库中，这样即提高了速度，又避免了 Session 同步问题；

经过改造之后变成了如下的认证过程：

1. 用户输入用户名、密码或者用短信验证码方式登录系统；
2. 服务端经过验证，将认证信息构造好的数据结构存储到 Redis 中，并将 key 值返回给客户端；
3. 客户端拿到返回的 key，存储到 local storage 或本地数据库；
4. 下次客户端再次请求，把 key 值附加到 header 或者 请求体中；
5. 服务端根据获取的 key，到 Redis 中获取认证信息；

基于JWT的Token认证

上面的方案虽然经过了改版，但还是需要客户端和服务器端维持一个状态信息，比如用 cookie 换 session ,或者用 key 换 Redis 的 value 信息，基于 JWT 的 Token 认证方案可以省去这个过程。

JSON Web Token（JWT）是一个非常轻巧的规范。这个规范允许我们使用JWT在用户和服务器之间传递安全可靠的信息。

认证过程

1. 依然是用户登录系统；
2. 服务端验证，将认证信息通过指定的算法（例如HS256）进行加密，例如对用户名和用户所属角色进行加密，加密私钥是保存在服务器端的，将加密后的结果发送给客户端，加密的字符串格式为三个”.” 分隔的字符串 Token，分别对应头部、载荷与签名，头部和载荷都可以通过 base64 解码出来，签名部分不可以；
3. 客户端拿到返回的 Token，存储到 local storage 或本地数据库；
4. 下次客户端再次发起请求，将 Token 附加到 header 中；
5. 服务端获取 header 中的 Token ，通过相同的算法对 Token 中的用户名和所属角色进行相同的加密验证，如果验证结果相同，则说明这个请求是正常的，没有被篡改。这个过程可以完全不涉及到查询 Redis 或其他存储；

优点

• 使用 json 作为数据传输，有广泛的通用型，并且体积小，便于传输；
• 不需要在服务器端保存相关信息；
• jwt 载荷部分可以存储业务相关的信息（非敏感的），例如用户信息、角色等；

总结

综上所述，JWT 可以作为首选的认证方案。当然，具体的情况具体分析，还要看是不是适合真实的应用场景。除了上述的这些，涉及到信息安全的，建议全部采用 https 方式部署，采用 https 方式，信息很难被嗅探破解，对应用的安全性很重要。

参考信息：

OAuth: http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

JWT：https://jwt.io/introduction/ http://blog.leapoahead.com/2015/09/06/understanding-jwt/

JWT Java 库: https://github.com/jwtk/jjwt

标签：用户名,HTTP,登录,方式,认证,密码,客户端
From： https://www.cnblogs.com/w784319947/p/16856194.html