认证鉴权的几种方式

╰半橙微兮° 2024-03-31 10:17 37阅读 0赞

**1.HTTP Basic Authentication**：用的比较少，平常FTP登录是用的这种方式吗？感觉可以用在内部网系统。  
**2.session-cookie**：这个在老的系统见得多，只适用于web系统。以前用java servlet写服务端时候，都会自动维护session，会在cookie写一个JSESSIONID的值。  
**3.Token**：现在主流都是用这个，适用于app鉴权，微信开发平台access token也是差不多这种思路。  
**4.OAuth**：这个是趋势吧，现在想要推广自己的应用都先接入微信 QQ等登录，降低用户使用门槛。特别是微信渠道的手游，都是接入了微信开发授权登录。

**三种鉴权方式：**  
http是一个无状态协议  
这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具  
**1、session-cookie**  
利用服务器端的session（会话）和浏览器端的cookie来实现前后端的认证，由于http请求时是无状态的，服务器正常情况下是不知道当前请求之前有没有来过，这个时候我们如果要记录状态，就需要在服务器端创建一个会话(seesion),将同一个客户端的请求都维护在各自得会会话中，每当请求到达服务器端的时候，先去查一下该客户端有没有在服务器端创建seesion，如果有则已经认证成功了，否则就没有认证。  
session-cookie认证主要分四步：  
1.服务器在接受客户端首次访问时在服务器端创建seesion，然后保存seesion(我们可以将seesion保存在内存中，也可以保存在redis中，推荐使用后者)，然后给这个session生成一个唯一的标识字符串,然后在响应头中种下这个唯一标识字符串。  
2.签名。这一步只是对sessionId进行加密处理，服务端会根据这个secret密钥进行解密。（非必需步骤）  
3.浏览器中收到请求响应的时候会解析响应头，然后将sessionId保存在本地cookie中，浏览器在下次http请求的请求头中会带上该域名下的cookie信息  
4.服务器在接受客户端请求时会去解析请求头cookie中的sessionId，然后根据这个sessionId去找服务器端保存的该客户端的session，然后判断该请求是否合法。

**2、Token 验证**  
token 也称作令牌，由uid+time+sign\[+固定参数\]  
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景。 所谓无状态就是服务端并不会保存身份认证相关的数据。  
组成  
uid: 用户唯一身份标识  
time: 当前时间的时间戳  
sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接  
固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

使用基于 Token 的身份验证方法，大概的流程是这样的：

1.  客户端使用用户名跟密码请求登录
2.  服务端收到请求，去验证用户名与密码
3.  验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
4.  客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage，sessionStorage里
5.  客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
6.  服务端收到请求，服务器端采用filter过滤器校验，然后去验证客户端请求里面带着的Token，如果验证成功，就向客户端返回请求的数据，校验失败则返回错误码

总的来说就是客户端在首次登陆以后，服务端再次接收http请求的时候，就只认token了，请求只要每次把token带上就行了，服务器端会拦截所有的请求，然后校验token的合法性，合法就放行，不合法就返回401（鉴权失败）。

乍的一看好像和前面的seesion-cookie有点像，seesion-cookie是通过seesionid来作为浏览器和服务端的链接桥梁，而token验证方式貌似是token来起到seesionId的角色。其实这两者差别是很大的。

1.  sessionId 他只是一个唯一标识的字符串，服务端是根据这个字符串，来查询在服务器端保持的seesion，这里面才保存着用户的登陆状态。但是token本身就是一种登陆成功凭证，他是在登陆成功后根据某种规则生成的一种信息凭证，他里面本身就保存着用户的登陆状态。服务器端只需要根据定义的规则校验这个token是否合法就行。
2.  session-cookie是需要cookie配合的，居然要cookie，那么在http代理客户端的选择上就是只有浏览器了，因为只有浏览器才会去解析请求响应头里面的cookie,然后每次请求再默认带上该域名下的cookie。 但是token 就不一样，他是登陆请求在登陆成功后再请求响应体中返回的信息，客户端在收到响应的时候，可以把他存在本地的cookie,storage，或者内存中，然后再下一次请求的请求头重带上这个token就行了。简单点来说cookie-session机制他限制了客户端的类型，而token验证机制丰富了客户端类型。
3.  时效性。session-cookie的sessionid是在登陆的时候生成的而且在登出时一直不变的，在一定程度上安全就会低，而token是可以在一段时间内动态改变的。
4.  可扩展性。token验证本身是比较灵活的，一是token的解决方案有许多，常用的是JWT,二来我们可以基于token验证机制，专门做一个鉴权服务，用它向多个服务的请求进行统一鉴权。

JWT（JSON WEB TOKEN）：  
JWT是Auth0提出的通过对JSON进行加密签名来实现授权验证的方案，就是登陆成功后将相关信息组成json对象，然后对这个对象进行某中方式的加密，返回给客户端，客户端在下次请求时带上这个token，服务端再收到请求时校验token合法性，其实也就是在校验请求的合法性。  
JWT对象通常由三部分构成：  
Headers： 包括类别（typ）、加密算法（alg）

2.   Claims ：包括需要传递的用户信息
            { 
               "sub": "1234567890",
               "name": "John Doe",
               "admin": true
            }
      3.   Signature： 根据alg算法与私有秘钥进行加密得到的签名字串， 这一段是最重要的敏感信息，只能在服务端解密；
       HMACSHA256( 
                  base64UrlEncode(Headers) + "." +
                  base64UrlEncode(Claims),
                  SECREATE_KEY 
            )

编码之后的JWT看起来是这样的一串字符：  
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

CSRF (Cross Site Request Forgery)攻击，中文名：跨站请求伪造。其原理是攻击者构造网站后台某个功能接口的请求地址，诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击，对于 POST 形式的接口地址也不是百分百安全，攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。  
token可以抵抗csrf（跨站请求伪造攻击），cookie+session不行  
假如用户正在登陆银行网页，同时登陆了攻击者的网页，并且银行网页未对csrf攻击进行防护。攻击者就可以在网页放一个表单，该表单提交src为http://www.bank.com/api/transfer，body为count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了.因为form 发起的 POST 请求并不受到浏览器同源策略的限制，因此可以任意地使用其他域的 Cookie 向其他域发送 POST 请求，形成 CSRF 攻击。在post请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，token是开发者为了防范csrf而特别设计的令牌，浏览器不会自动添加到headers里，攻击者也无法访问用户的token，所以提交的表单无法通过服务器过滤，也就无法形成攻击。

分布式情况下的session和token  
我们已经知道session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。  
负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。当今的几种解决session负载均衡的方法。（我们采用会话共享的方法，共享同一个Redis）  
而token是无状态的，token字符串里就保存了所有的用户信息  
客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)  
总结  
session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie  
cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。  
token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。  
jwt只是一个跨域认证的方案

**3、OAuth(开放授权)**  
OAuth（开放授权）是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容，为了保护用户数据的安全和隐私，第三方网站访问用户数据前都需要显式的向用户征求授权。我们常见的提供OAuth认证服务的厂商有支付宝，QQ,微信。  
OAuth协议又有1.0和2.0两个版本。相比较1.0版，2.0版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。  
下面是一张auth2.0的流程图：

从图中我们可以看出，auth2.0流程分为六布（我们就以csdn登陆为例）：  
第一步. 向用户请求授权，现在很多的网站在登陆的时候都有第三方登陆的入口，当我们点击等第三方入口时，第三方授权服务会引导我们进入第三方登陆授权页面。

通过第三方请求授权页面的浏览器地址栏地址可以看出:  
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response\_type=code&client\_id=100270989&redirect\_uri=https%3A%2F%2Fpassport.csdn.net%2Faccount%2Flogin%3Foauth\_provider%3DQQProvider&state=test  
这里的地址里面的%是浏览器强制编码后的显示我们可以使用decodeURIComponent进行解码，解码后是这样：  
https://graph.qq.com/oauth2.0/show?which=Login&display=pc&response\_type=code&client\_id=100270989&redirect\_uri=https://passport.csdn.net/account/login?oauth\_provider=QQProvider&state=test  
这个url地址我们可以看见Auth2.0常见的几个参数：  
response\_type，返回类型  
client\_id，第三方应用id,由授权服务器（qq）在第三方应用提交时颁发给第三方应用。  
redirect\_uri，登陆成功重定向页面  
oauth\_provider，第三方授权提供方  
state，由第三方应用给出的随机码  
第二步. 返回用户凭证（code），并返回一个凭证（code），当用户点击授权并登陆后，授权服务器将生成一个用户凭证（code）。这个用户凭证会附加在重定向的地址redirect\_uri的后面  
https://passport.csdn.net/account/login?code=9e3efa6cea739f9aaab2&state=XXX  
第三步. 请求授权服务器授权:

经过第二步获取code后后面的工作就可以交给后台去处理的，和用户的交互就结束了。接下来我的需要获取Access Token，我们需要用他来向授权服务器获取用户信息等资源。  
第三方应用后台通过第二步的凭证（code）向授权服务器请求Access Token，这时候需要以下几个信息：

client\_id 标识第三方应用的id，由授权服务器（Github）在第三方应用提交时颁发给第三方应用  
client\_secret 第三方应用和授权服务器之间的安全凭证，由授权服务器（Github）在第三方应用提交时颁发给第三方应用  
code 第一步中返回的用户凭证redirect\_uri 第一步生成用户凭证后跳转到第二步时的地址  
state 由第三方应用给出的随机码  
第四步. 授权服务器同意授权后，返回一个资源访问的凭证（Access Token）。

第五步. 第三方应用通过第四步的凭证（Access Token）向资源服务器请求相关资源。

第六步. 资源服务器验证凭证（Access Token）通过后，将第三方应用请求的资源返回。

从用户角度来说，第三方授权可以让我们快速的登陆应用，无需进行繁琐的注册,同时不用记住各种账号密码。只需要记住自己常用的几个账号就ok了。  
从产品经理的角度来所，这种授权方式提高用户的体验满意度。另一方面可以获取更多的用户。