HTTP协议规范中有两种认证方式，一种是Basic认证，另外一种是Digest认证，这两种方式都属于无状态认证方式，所谓无状态即服务端都不会在会话中记录相关信息，客户端每次访问都需要将用户名和密码放置报文一同发送给服务端，但这并不表示你在浏览器中每次访问都要自己输入用户名和密码，可能是你第一次输入账号后浏览器就保留在内存中供后面的交互使用。
BASIC基本认证
概述
当一个客户端向HTTP服务器进行数据请求时，如果客户端未被认证，则HTTP服务器将通过基本认证过程对客户端的用户名及密码进行验证，以决定用户是否合法。客户端在接收到HTTP服务器的身份认证要求后，会提示用户输入用户名及密码，然后将用户名及密码以BASE64加密，加密后的密文将附加于请求信息中， 如当用户名为chackca，密码为：123456时，客户端将用户名和密码用“：”合并，并将合并后的字符串用BASE64加密为密文，并于每次请求数据时，将密文附加于请求头（Request Header）中。HTTP服务器在每次收到请求包后，根据协议取得客户端附加的用户信息（BASE64加密的用户名和密码），解开请求包，对用户名及密码进行验证，如果用户名及密码正确，则根据客户端请求，返回客户端所需要的数据;否则，返回错误代码或重新要求客户端提供用户名及密码。
BASIC认证的过程
基本认证步骤：
1、客户端访问一个受http基本认证保护的资源。
2、服务器返回401状态，要求客户端提供用户名和密码进行认证。（验证失败的时候，响应头会加上WWW-Authenticate: Basic realm="请求域"。）
401 Unauthorized
WWW-Authenticate： Basic realm="WallyWorld"
3、客户端将输入的用户名密码用Base64进行编码后，采用非加密的明文方式传送给服务器。Authorization: Basic xxxxxxxxxx.
4、服务器将Authorization头中的用户名密码解码并取出，进行验证，如果认证成功，则返回相应的资源。如果认证失败，则仍返回401状态，要求重新进行认证。
服务端返回的认证报文中包含了realm=”myTomcat”，realm的值用于定义保护的区域，在服务端可以通过realm将不同的资源分成不同的域，域的名称即为realm的值，每个域可能会有自己的权限鉴别方案。
Basic认证的一些特点
1、Http是无状态的，同一个客户端对同一个realm内资源的每一个访问会被要求进行认证。
2、客户端通常会缓存用户名和密码，并和authentication realm一起保存，所以，一般不需要你重新输入用户名和密码。
3、以非加密的明文方式传输，虽然转换成了不易被人直接识别的字符串，但是无法防止用户名密码被恶意盗用。虽然用肉眼看不出来，但用程序很容易解密。
优点：
基本认证的一个优点是基本上所有流行的网页浏览器都支持基本认证。基本认证很少在可公开访问的互联网网站上使用，有时候会在小的私有系统中使用（如路由器网页管理接口）。后来的机制HTTP摘要认证是为替代基本认证而开发的，允许密钥以相对安全的方式在不安全的通道上传输。
缺点：
虽然基本认证非常容易实现，但该方案建立在以下的假设的基础上，即：客户端和服务器主机之间的连接是安全可信的。特别是，如果没有使用SSL/TLS这样的传输层安全的协议，那么以明文传输的密钥和口令很容易被拦截。该方案也同样没有对服务器返回的信息提供保护。
现存的浏览器保存认证信息直到标签页或浏览器被关闭，或者用户清除历史记录。HTTP没有为服务器提供一种方法指示客户端丢弃这些被缓存的密钥。这意味着服务器端在用户不关闭浏览器的情况下，并没有一种有效的方法来让用户登出。
什么是Realm
Tomcat提供Realm支持。
Tomcat使用Realm使某些特定的用户组具有访问某些特定的Web应用的权限，而没有权限的用户不能访问这个应用。
Tomcat提供了三种不同Realm对访问某个Web应用程序的用户进行相应的验证。
1、JDBCRealm，这个Realm将用户信息存在数据库里，通过JDBC从数据库中获得用户信息并进行验证。
2、JNDIRealm，将用户信息存在基于LDAP等目录服务的服务器里，通过JNDI技术从LDAP服务器中获取用户信息并进行验证。
3、MemoryRealm，将用户信息存在一个xml文件中，对用户进行验证时，将会从相应的xml文件中提取用户信息。manager(Tomcat提供的一个web应用程序)应用在进行验证时即使用此种Realm。Realm类似于Unix里面的group。在Unix中，一个group对应着系统的一定资源，某个group不能访问不属于它的资源。Tomcat用Realm来对不同的应用(类似系统资源)赋给不同的用户(类似group)。没有权限的用户则不能访问这个应用。
DIGEST摘要认证
https://www.cnblogs.com/huey/p/5490759.html
基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式传送的，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与 SSL 配合使用。
摘要认证是另一种 HTTP 认证协议，它与基本认证兼容，但却更为安全。摘要认证试图修复基本认证协议的严重缺陷。具体来说，摘要认证进行了如下改动：
永远不会以明文方式在网络上发送密码。
可以防止恶意用户捕获并重放认证的握手过程。
可以有选择地防止对报文内容的篡改。
防范其他几种常见的攻击方式。
摘要认证并不是最安全的协议。摘要认证并不能满足安全 HTTP 事务的很多需求。对这些需求来说，使用 TLS 和 HTTPS 协议更为合适一些。但摘要认证比它要取代的基本认证强大很多。
a) 客户端请求了某个受保护文档。
b) 在客户端能够证明其知道密码从而确认其身份之前，服务器拒绝提供文档。服务器向客户端发起质询，询问用户名和摘要形式的密码。
c) 客户端传递了密码的摘要（用户输入实际的密码，客户端再将这个密码转化为摘要后再发送），证明它是知道密码的。服务器知道所有用户的密码，因此可以将客户提供的摘要与服务器自己计算得到的摘要进行比较，以验证用户是否知道密码。另一方在不知道密码的情况下，很难伪造出正确的摘要。
d) 服务器将客户端提供的摘要与服务器内部计算出的摘要进行对比。如果匹配，就说明客户端知道密码（或者很幸运地猜中了！）。可以设置摘要函数，使其产生很多数字，让人不可能幸运地猜中摘要。服务器进行了匹配验证之后，会将文档提供给客户端——整个过程都没有在网络上发送密码。
重放攻击
使用摘要就无需以明文形式发送密码了。可以只发送密码的摘要，而且可以确信，没有哪个恶意用户能轻易地从摘要中解码出原始密码。
但是，仅仅隐藏密码并不能避免危险，因为即便不知道密码，别有用心的人也可以截获摘要，并一遍遍地重放给服务器。摘要和密码一样好用。
为防止此类重放攻击的发生，服务器可以向客户端发送了一个称为随机数 (nonce) 的特殊令牌，这个数会经常发生变化（可能是每毫秒，或者是每次认证都变化）。客户端在计算摘要之前要先将这个随机数令牌附加到密码上去。
在密码中加入随机数就会使摘要随着随机数的每一次变化而变化。记录下的密码摘要只对特定的随机数有效，而没有密码的话，攻击者就无法计算出正确的摘要，这样就可以防止重放攻击的发生。
摘要认证要求使用随机数，因为这个小小的重放弱点会使未随机化的摘要认证变得和基本认证一样脆弱。随机数是在 WWW-Authenticate 质询中从服务器传送给客户端。
摘要认证的握手机制（简化的摘要认证三步握手机制）
(1) 服务器计算出一个随机数。
(2) 服务器将这个随机数放在 WWW-Authenticate 质询报文中，与服务器所支持的算法列表一同发往客户端。
(3) 客户端选择一个算法，计算出密码和其他数据的摘要。
(4) 客户端将摘要放在一条 Authorization 报文中发回服务器。如果客户端要对服务器进行认证，可以发送客户端随机数。
(5) 服务器接收摘要、选中的算法以及支撑数据，计算出与客户端相同的摘要。然后服务器将本地生成的摘要与网络传送过来的摘要进行比较，验证是否匹配。如果客户端反过来用客户端随机数对服务器进行质询，就会创建客户端摘要。服务器可以预先将下一个随机数计算出来，提前将其传递给客户端，这样下一次客户端就可以预先发送正确的摘要了。
Cookie Auth
Cookie认证机制：用户输入用户名和密码发起请求，服务器认证后给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。
当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。默认的，当我们关闭浏览器的时候，客户端cookie会被删除，可以通过修改cookie 的expire time使cookie在一定时间内有效。但是服务器端的session不会被销毁，除非通过invalidate或超时。
Token Auth（JWT）
Token Auth优点：
减轻服务器压力：通过token可以将用户的基本信息(非隐私的，比如UserId，过期时间，生成的随机key等)全部加密签名后放入token中，从而服务器端不需要保存用户登录信息，大大减轻服务器压力。用户认证完全靠token识别，通过签名来保证token没有被修改过（只有服务器才知道秘钥，比如常见的非对称加密算法），是服务器下发的token。
支持跨域访问：因为服务器并没有保存登录状态，完全靠签名的token识别，那么另一个网站只要有对应的私钥，就可以对token验证，前提是传输的用户认证信息通过HTTP头传输；
更适用CDN: 可以通过内容分发网络请求你服务端的所有资料（如：javascript，HTML,图片等），因为不需要同步服务器上的登录状态信息；
性能更好: 因为从token中可以获得userId，不用查询登录状态表；
原文：https://blog.csdn.net/qq_35642036/article/details/82788588