身份验证允许进入系统，而授权允许访问同一系统内的特定功能。安全断言标记语言 (SAML) 是一种开放标准，它试图弥合身份验证和授权之间的鸿沟。
OAuth 是一个开放的授权标准。OpenID Connect 是在 OAuth 2.0 之上运行的身份验证标准。下面详细介绍这些标准的差异及其在身份验证和授权中的作用。

Spring基于OAuth2协议编写的spring-oauth2实现，是行业级的接口资源安全解决方案，我们可以基于该依赖配置不同客户端的不同权限来访问接口数据。

Spring所提供的OAuth2集成策略，支持多种方式存储认证信息以及客户端信息，由于在之前的文章中讲解使用时把知识点进行了拆分，有很多同学不太会组合使用，很多单独问我ApiBoot所提供的OAuth2的整合后，多个客户端该怎么配置？

使用Redis来存储OAuth2相关的客户端信息以及生成的AccessToken是一个不错的选择，Redis与生俱来的的高效率、集群部署是比较出色的功能，如果用来作为服务认证中心的数据存储，可以大大的提高响应效率。

Redis还支持超时自动删除功能，OAuth2所生成的AccessToken相关的数据在超过配置的有效时间后就会自动被清除，这样也隐形的提高了接口的安全性。

既然Redis可以做到这么好，我们该怎么实现代码逻辑呢？

OAuth2所生成的AccessToken以及RefreshToken都存在过期时间，当在有效期内才可以拿来作为会话身份发起请求，否者认证中心会直接拦截无效请求提示已过期，那么我们怎么修改这个过期时间来满足我们的业务场景呢？

OAuth2默认的AccessToken是由DefaultAccessTokenConverter生成，是具有唯一性的UUID随机字符串，我们如果想要使用JWT来格式化AccessToken就需要使用JwtAccessTokenConverter来进行格式化，当然如果你有自己独特的业务可以自己实现AccessTokenConverter接口，并将实现类交付给IOC托管即可。

当我们整合了Spring Security以及OAuth2后发现，有一些业务请求是需要开放的，因为种种原因这时访问者还没有身份标识（比如：用户刚来，还没有注册，需要进行新用户注册，这时注册业务相关的接口都应该是开放的），下面我们来看看ApiBoot是怎么排除路径不进行权限拦截的。

Spring提供的原生的OAuth2依赖内置了几种比较常用的授权方式：password、authorization-code、client_credentials、refresh_token、implicit等，虽然可以满足我们日常的需求，不过针对一些特殊的需求还是捉襟见肘，有点无奈，比如：微信登录、短信登录…，针对这一点ApiBoot通过修改Spring OAuth2依赖的源码，可以根据业务进行自定义添加grantType。