浅谈认证和鉴权

注：转摘自原文链接：https://blog.csdn.net/liu4461431/article/details/124973707

一、认证

1.什么是认证

认证一般用于对用户身份进行鉴别，判断其是否允许进行系统后续的操作。

2.认证的实现方式

----【OAuth2】

OAUth2就是一套广泛流行的认证授权协议，大白话说呢OAuth2这套协议中有两个核心的角色，认证服务器和资源服务器。
用户不能直接去访问资源服务器（网关），必须先到认证服务器认证，通过后颁发一个token令牌给你，你只有拿着token访问资源服务器才能通过，令牌token是有时间限制的，到时间了就无效。

这个模式相信经常到甲方爸爸的地方做驻场的小伙伴深有体会，一般人家可不会给你一个正式员工工牌，要么拿身份证抵押换个临时访问牌，隔天就失效，这样人家才有安全感嘛~

其中网关为什么能作为“资源服务器”呢？ 网关是作为各个微服务（会员服务、商品服务、订单服务等）统一入口，也就是这些资源服务的统一门面，在这里可以对JWT验签、JWT有效期判断、JWT携带角色权限判断。

----【JWT】

JWT(JSON Web Token)它没啥悬乎的，就是一个特殊的token，最大的特性就是无状态，因为它本身可以携带用户的信息(用户ID、用户名、用户的角色集合等)，我们先看下一个解析过后的JWT是什么样子的。

JWT字符串由Header(头部)、Payload(负载)、Signature(签名)三部分组成。

Header: JSON对象，用来描述JWT的元数据,alg属性表示签名的算法,typ标识token的类型

Payload: JSON对象，重要部分，除了默认的字段，还可以扩展自定义字段，比如用户ID、姓名、角色等等

Signature: 对Header、Payload这两部分进行签名，认证服务器使用私钥签名，然后在资源服务器使用公钥验签，防止数据被人动了手脚

JWT和传统的Cookie/Session会话管理相比较有着多方面的优势，因为Cookie/Session需要在服务器Session存用户信息，然后拿客户端Cookie存储的SessionId获取用户信息，这个过程需要消耗服务器的内存和对客户端的要求比较严格（需支持Cookie），而JWT最大的特性在于就是无状态、去中心化，所以JWT更适用分布式的场景，不需要在多台服务器做会话同步这种消耗服务器性能的操作。
另外JWT和Redis+Token这两种会话管理小伙伴们看项目情况选择，别有用了JWT还使用Redis存储的，因为你这种做法对JWT来说就是“伤害不大,但侮辱性极强”的做法，就当着它的面说我就看不上你的最自以为是的“无状态”特性。

----【OAuth2和JWT关系？】

OAuth2是一种认证授权的协议规范。
JWT是基于token的安全认证协议的实现。
OAuth2的认证服务器签发的token可以使用JWT实现,JWT轻量且安全。

二、鉴权

1.什么是鉴权

鉴权（authentication）是指验证用户是否拥有访问系统的权利。传统的鉴权是通过密码来验证的。这种方式的前提是，每个获得密码的用户都已经被授权。在建立用户时，就为此用户分配一个密码，用户的密码可以由管理员指定，也可以由用户自行申请。这种方式的弱点十分明显：一旦密码被偷或用户遗失密码，情况就会十分麻烦，需要管理员对用户密码进行重新修改，而修改密码之前还要人工验证用户的合法身份。
为了克服这种鉴权方式的缺点，需要一个更加可靠的鉴权方式。主流鉴权方式是利用认证授权来验证数字签名的正确与否。
逻辑上，授权发生在鉴权之后，而实际上，这两者常常是一个过程。

2.鉴权方式

一、HTTP Basic Authentication

二、session-cookie

1、服务器在接受客户端首次访问时在服务器端创建seesion，然后保存seesion(我们可以将seesion保存在内存中，也可以保存在redis中，推荐使用后者)，然后给这个session生成一个唯一的标识字符串,然后在响应头中种下这个唯一标识字符串。
2、签名。这一步只是对sid进行加密处理，服务端会根据这个secret密钥进行解密。（非必需步骤）
3、浏览器中收到请求响应的时候会解析响应头，然后将sid保存在本地cookie中，浏览器在下次http请求de 请求头中会带上该域名下的cookie信息。
4、服务器在接受客户端请求时会去解析请求头cookie中的sid，然后根据这个sid去找服务器端保存的该客户端的session，然后判断该请求是否合法。
5、一旦用户登出，服务端和客户端同时销毁该会话在后续请求中，服务器会根据数据库验证会话id，如果验证通过，则继续处理；

三、Token 验证

用户输入登陆凭据；
服务器验证凭据是否正确，然后返回一个经过签名的token；
客户端负责存储token，可以存在localstorage，或者cookie中
对服务器的请求带上这个token；
服务器对JWT进行解码，如果token有效，则处理该请求；
一旦用户登出，客户端销毁token。

四、OAuth(开放授权)

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。同时，任何第三方都可以使用OAUTH认证服务，任何服务提供商都可以实现自身的OAUTH认证服务，因而OAUTH是开放的。
我们常见的提供OAuth认证服务的厂商有支付宝，QQ，微信。
OAuth协议又有1.0和2.0两个版本。相比较1.0版，2.0版整个授权验证流程更简单更安全，也是目前最主要的用户身份验证和授权方式。

在认证和授权的过程中涉及的三方包括：

服务提供方（ServiceProvider），用户使用服务提供方来存储受保护的资源，如照片，视频，联系人列表。

用户（User），存放在服务提供方的受保护的资源的拥有者

客户端（Consumer），要访问服务提供方资源的第三方应用，通常是网站，如提供照片打印服务的网站也可以是桌面或移动应用程序。在认证过程之前，客户端要向服务提供者申请客户端标识。

OAuth相关的三个URL：
- RequestToken URL:获取未授权的RequestToken服务地址；

- UserAuthorization URL:获取用户授权的RequestToken服务地址；

- AccessToken URL:用授权的RequestToken换取AccessToken的服务地址。

OAuth认证和授权过程
- 1、客户端（第三方软件）向OAUTH服务提供商请求未授权的RequestToken。即RequestToken URL发起请求；
- 2、OAUTH服务提供商同意使用者的请求，并向其颁发未经用户授权的oauth_token与对应的oauth_token_secret，并返回给使用者；
- 3、使用者向OAUTH服务提供商请求用户授权的RequestToken。即向UserAuthorization URL发起请求并在请求中携带上一步服务提供商颁发的未授权的token与其密钥；
- 4、OAUTH服务提供商通过网页要求用户登录并引导用户完成授权；
- 5、RequestToken授权后，使用者将向AccessToken URL发起请求，将上步授权RequestToken换取成AccessToken。请求的参数见上图，这个比第一步多了一个参数就是RequestToken；
- 6、OAUTH服务提供商同意使用者的请求，并向其颁发AccessToken与对应的密钥，并返回给使用者；
- 7、使用者以后就可以使用上步返回的AccessToken访问用户授权的资源。