Authentication Authorization

文章目录一、Authentication1.HTTP基本认证2.Cookie Session3.Session共享4.JWT5.Access Token Refresh Token6.总结二、Authorization一、Authentication账户安全和用户体验不能两全其美往往折中。即没有100%安全。API是服务端提供给客户端的接口通过调用API我们能使用功能。但API的调用需要认证即Authentication只有授权的客户端才能访问。往往结合HTTPS使用。HTTP请求是明文的不安全。HTTPS HTTP TLS。HTTPS保证的是数据传输过程中的安全性。但是 HTTPS 不能保证客户端本身安全比如电脑中病毒、浏览器插件恶意、手机 App 被逆向等都有可能导致凭证泄露。此外不论何种方式都应尽量避免将敏感信息存入认证信息中。一旦泄露非常危险。比如账密泄露除了获取永久认证之外可能其它平台密码相同也被登入。好比银行办业务时每次给的是临时凭证只能到规定业务窗口以及规定时间内办理。如果用身份证就能获取永久凭证那别人拿着凭证也可以办理。只用临时凭证。让攻击造成的损失尽可能小。因此我们要做的是即使凭证泄露也尽量降低损失。1.HTTP基本认证客户端登陆后服务端把用户名和密码用Base64编码后返回给客户端保存客户端之后的请求携带账密。缺点1.请求包含敏感信息不安全。2.这种携带账密的请求一直有效除非改密码一旦泄露风险巨大因此凭证往往要求设置有效期。2.Cookie Session由于早期互联网以浏览器为主为了解决上述缺点有了Cookie-Session机制。Cookie就是一种数据载体登陆后客户端将Session ID和Cookie过期时间等返回交由浏览器存储Cookie之后浏览器发起请求请求头都会携带Cookie。浏览器自动维护了Cookie管理机制使用非常方便。缺点1.随着互联网发展当前客户端已不止浏览器例如Web、App、小程序、第三方客户端等。其它客户端需要像浏览器一样建立完善的Cookie管理机制。2.随着用户增多单个服务器存储Session有限需要扩展服务器同时Session也需同步维护成本高。3.Session共享为了解决分布式环境Session共享问题需将Session存入数据库来供服务器集群访问。比如放入Redis。缺点访问量大时增加redis宕机风险。4.JWT为了解决上述问题转化思路让用户信息由存入服务端改为存入客户端。这就是Token。JWT全名JSON Web Token。是token机制的一种具体实现因其规范而被广泛使用。客户端登录成功服务端生成JWT返回给客户端之后客户端请求头部都会携带token。服务端收到请求会对token认证认证通过才会放行。JWT结构header.payload.signature。header包含加密方式payload包含数据signature代表签名。示例JWTeyJhbGciOiJIUzI1NiJ9.eyJlbXBJZCI6MSwiZXhwIjoxNzg4MjQ5NzY4fQ.ENN2w20hNDHMeclySd7CxA8ufyZd-P0YSmk-78F7rpQ headereyJhbGciOiJIUzI1NiJ9 payloadeyJlbXBJZCI6MSwiZXhwIjoxNzg4MjQ5NzY4fQ signatureENN2w20hNDHMeclySd7CxA8ufyZd-P0YSmk-78F7rpQ secret-keyGG Bond // secret-key保存在服务端JWT生成过程JWT验证通过JWT的header和payload部分与服务端的secret-key再次加密运算得到签名与JWT的signature部分比对若一致则代表该token有效。JWT缺点无法主动失效。由于token存储在客户端服务端不能主动踢除token。token有效期较长期间可以一直访问服务端无法管理会话比如账号退出登录、管理员强制下线、权限变动等都需要废弃token。且一旦泄露token风控期太长。解决1.服务端手动维护token黑名单。用于管理会话。2.使用Access Token Refresh Token。用于缩小token有效期。5.Access Token Refresh Token由于上述Access Token有效期长泄露后风控时间太长为了缩短风控时间在JWT基础上加入Refresh Token。相当于在“有状态”和“无状态”之间的折中方案。流程客户端登录成功服务端生成 Access Token 和 Refresh Token 并设置有效期比如15min和7天服务端存储 Refresh Token 到Redis然后将这两个token一并返回交由客户端存储。客户端之后发起请求都会携带Access Token跟上面的JWT流程一样。当Access Token失效时客户端会携带Refresh Token发起请求获取新的Access Token。Refresh Token 失效时服务端删除Refresh Token。之后用户需重新登录。与Session区别Session每次请求都会查询服务端来认证而这种方式只需刷新token时才会查询服务端大大减小Redis压力。Session可主动管理会话但是token需要添加黑名单等方式来管理会话。6.总结将登录信息由服务端存储管理称为“有状态认证”比如Cookie-Session将登录信息由客户端存储管理称为“无状态认证”比如token。“有状态认证”的优点是服务端随时控制会话但随着用户量增大影响服务端性能扩展起来成本高。适合用户量小的场景。“无状态认证”的优点是认证无需查询数据库但不能立即控制会话失效。适合用户量大、微服务、三方客户端访问API等场景。实际使用时往往折中因为部分业务需要管理会话使用Access Token Refresh Token。二、Authorization上述Authentication代表认证登陆后给你发个身份找。此处Authorization代表权限每个账号的权限不同。比如一个应用分为管理员、VIP用户、SVIP用户、非VIP用户等每个角色的权限不同。再比如A网站想访问B网站的头像若将B网站的密码给A网站这样A网站能访问所有资源不可控。若将Token给A访问哪儿给你哪儿的凭证验证通过了只能访问该资源实现细粒度授权风险大大减小。