用户身份认证
用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问。常见的用户身份认证表现形式有:用户名密码登录,指纹打卡等方式
用户授权
用户认证通过后去访问系统的资源,系统会判断用户是否拥有访问资源的权限,只允许访问有权限的系统资源,没有权限的资源将无法访问
五种认证机制
HTTP Basic Auth
HTTP Basic Auth简单点说明就是每次请求API时都提供用户的username和password,简言之,Basic Auth是配合RESTful API 使用的最简单的认证方式,只需提供用户名密码即可,但由于有把用户名密码暴露给第三方客户端的风险,在生产环境下被使用的越来越少。因此,在开发对外开放的RESTful API时,尽量避免采用HTTP Basic Auth
OAuth
OAuth允许用户提供一个令牌,而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的第三方系统(例如,视频编辑网站)在特定的时段(例如,接下来的2小时内)内访问特定的资源(例如仅仅是某一相册中的视频)。这样,OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息,而非所有内容
Cookie-session Auth
Cookie-session 认证机制就是为一次请求认证在服务端创建一个Session对象,同时在客户端的浏览器端创建了一个Cookie对象;通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的,当我们关闭浏览器的时候,cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效;
但是这种基于cookie-session的认证使应用本身很难得到扩展,随着不同客户端用户的增加,独立的服务器已无法承载更多的用户,而这时候基于session认证应用的问题就会暴露出来。
Token Auth
基于token的鉴权机制类似于http协议也是无状态的,它不需要在服务端去保留用户的认证信息或者会话信息。这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利。
JWT Auth
Token Auth的进化版本。由于Token Auth不包含用户信息,无法确定用户的请求的访问权限范围,即可以访问哪些数据。JWT作为一种可以转载数据的token,可以把用户权限信息放入token中,服务端不必再保存用户和权限的状态信息。
适用于分布式服务。
用户身份认证
用户去访问系统资源时系统要求验证用户的身份信息,身份合法方可继续访问。常见的用户身份认证表现形式有:用户名密码登录,指纹打卡等方式
http 3xx 重定向状态码
重定向状态码用来告诉浏览器客户端,它们访问的资源已被移动, Web服务器发送一个重定向状态码, 告诉客户端新的资源地址在哪。浏览器客户端会根据提供的地址,重新发送新的Request。
301表示资源不在旧位置,永久移动到新位置。新位置的URL信息在response中的Location中;302同301类似,区别在于目标资源只是临时移动到新位置;
浏览器在获取到302的响应值后,会拿到响应头中的Location中的URL,并跳转到该URL
登录
用户登录系统,请求各种资源。
单点登录(Single Sign On)
简称为 SSO,用于企业业务整合的解决方案之一,是在多个应用系统中,用户只需要登录一次就可以访问所有相互信任的应用系统
第三方认证
当需要访问第三方系统的资源时需要首先通过第三方系统的认证(例如:微信认证),由第三方系统对s用户认证通过,并授权资源的访问权限(一般访问用户信息)。
OAuth2 认证的好处就是你只需要一个账号密码,就能在各个网站进行访问,而面去了在每个网站都进行注册的繁琐过程,如:很多网站都可以使用微信登录,网站作为第三方服务、微信作为服务提供商。
OAuth2是一个关于授权的开放标准,核心思路是通过各类认证手段(具体什么手段OAuth2不关心)认证用户身份,并颁发token(令牌),使得第三方应用可以使用该令牌在限定时间、限定范围访问指定资源。
假设张三使用微信登录微博的场景 ,
上面过程的最后一步的概要目标是,微博后台想要拿到微信服务器中张三的用户信息,首先需要获得张三的授权(一般是弹出页面点击同意即可),然后微信授权服务器会给微博后台发放一个access_token,微博后台拿着这个access_token就可以去访问微信资源服务器中的张三用户信息。
特别强调的是,此处的授权指的是 在用户的参与下,一个授权服务器(管理一堆资源服务)给另一个应用(第三方应用)颁发一个访问令牌,颗粒度比较大,是应用或服务级的授权。
OAuth2一般多采用授权码方式,完成两个服务之间的授权。此处
spring security是一个安全管理框架,主要核心功能
其核心就是一组过滤器链,添加依赖之后,项目启动后将会自动配置。最核心的就是 Basic Authentication Filter 用来认证用户的身份,一个在spring security中一种过滤器处理一种认证方式。
spring security和shiro都是安全管理框架,后者使用简单功能稍弱,一般和ssm配合构建项目。 spring security功能强大,但是操作复杂,一般配合springboot/cloud(自动化配置)一起使用。
特别强调的是,spring security侧重用户和系统之间的请求管理,即某一个用户是否可以访问系统,可以访问系统哪些资源。
有了 OAuth2和spring security 就可以一个安全管理框架,其操作流程如下
问题出来第4步,普通的oauth2颁发的就是一串随机hash字符串,本身无意义。OAuth2的token技术最大的问题是不携带用户信息,且资源服务器无法进行本地验证,每次对于资源的访问,资源服务器都需要向认证服务器发起请求,一是验证token的有效性,二是获取token对应的用户信息。如果有大量的此类请求,无疑处理效率是很低的,且认证服务器会变成一个中心节点,对于SLA和处理性能等均有很高的要求,这在分布式架构下是很要命的。
JWT就是在这样的背景下诞生的,从本质上来说,jwt就是一种特殊格式的token。而jwt格式的token是有特定含义的,它包含了yoghurt信息,分为三部分:
Header
Payload
Signature
这三部分均用base64进行编码,当中用.
进行分隔,一个典型的jwt格式的token类似xxxxx.yyyyy.zzzzz
。
认证服务器通过对称或非对称的加密方式利用payload
生成signature
,并在header
中申明签名方式,仅此而已。通过这种本质上极其传统的方式,jwt可以实现分布式的token验证功能,即资源服务器通过事先维护好的对称或者非对称密钥(非对称的话就是认证服务器提供的公钥),直接在本地验证token,这种去中心化的验证机制无疑很对现在分布式架构的胃口。jwt相对于传统的token来说,解决以下两个痛点:
在上面的那个资源服务器和认证服务器分离的例子中,如果认证服务器颁发的是jwt格式的token,那么资源服务器就可以直接自己验证token的有效性并绑定用户,这无疑大大提升了处理效率且减少了单点隐患。