认证和授权，Identity-vs-Authorization

最新推荐文章于 2023-10-31 07:00:00 发布

北京符节科技有限公司

最新推荐文章于 2023-10-31 07:00:00 发布

阅读量372

点赞数

本文链接：https://blog.csdn.net/duuzuu/article/details/119305007

版权

JAI ：Identity vs Authorization 入门指南系列之一

前言

Identity 是识别你是谁，Authorization 是判断你能干什么。Identity vs Authorization 从软件诞生之初在不断进化：

基本口令，
umask ,
X.500,
LDAP ,
SAML ,
CAS ,
OAuth2.0 ,
OPenID …

目前前后端分离已成为互联网项目开发的业界标准，其核心思想是前端页面通过 AJAX 调用后端的 API 接口并使用 JSON 数据进行交互。
通过 Nginx/Apache 代理 + 应用服务器的方式，前后端分离为大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，小程序，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化到人的必经之路。

移动互联网的发展，为前后端分离下的认证，鉴权，访问管理提出了新的挑战。

JAI 致力于让访问管理：简单、安全、高效。

常见认证鉴权方式：

HTTP Basic Authentication
session-cookie
Token 验证
OAuth1.0/2.0

HTTP Basic Authentic

严格说 HTTP Basic 只是一种认证方式。
是浏览器遵守 http 协议实现的基本认证授权方式。

HTTP 协议进行通信的过程中，HTTP 协议定义了基本认证，允许 HTTP 服务器对客户端进行用户身份证的方法。

认证过程

这种认证方式一般多被用在内部安全性要求不高的的系统上，它没有细粒度的鉴权定义，现在使用这种认证比较少。
如果项目需要部署在公网上，这种方式不推荐，同时它需要和 SSL 配合来加密传输，增加安全性。

session-cookie

利用服务器端的 session（会话）和浏览器端的 cookie 来实现前后端的认证.

由于 http 请求时是无状态的，服务器正常情况下是不知道当前请求之前有没有来过，这个时候我们如果要记录状态，就需要在服务器端创建一个会话(seesion),将同一个客户端的请求都维护在各自会话中，每当请求到达服务器端的时候，先去查一下该客户端有没有在服务器端创建seesion，如果有则已经认证成功了，否则就没有认证。

session-cookie认证主要分四步：

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

这种方式在传统的 web 应用中使用比较多，在移动 App 中不适用。

Token 验证

客户端使用用户名跟密码请求登录
服务端收到请求，去验证用户名与密码
验证成功后，服务端会签发一个 Token，再把这个 Token 发送给客户端
客户端收到 Token 以后可以把它存储起来，比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，然后去验证客户端请求里面带着的 Token，如果验证成功，就向客户端返回请求的数据

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

seesion-cookie 和 taoken 认证区别：

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

JWT（JSON WEB TOKEN）：

JWT是 Auth0 提出的通过对 JSON 进行加密签名来实现授权验证的方案，登陆成功后将相关信息组成 json 对象，然后对这个对象进行某中方式的加密，返回给客户端，客户端在下次请求时带上这个token，服务端收到请求时校验 token 合法性。

JWT对象通常由三部分构成：请求头，载荷，签名。

JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期建议设置的相对短一些。对于一些比较重要的权限，使用时可再次对用户进行二次验证。为了减少盗用，JWT 建议使用 HTTPS 协议传输。

JWT 缺陷：由于服务器不保存用户状态，因此无法在使用过程中注销某个 token，或者更改 token 权限。一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。