前言

通常说到授权，就会想到登录授权、token令牌、JWT等概念，授权。顾名思义就是服务器授予了客户端访问资源的权益，那么要实现授权有几种方案呢，三种授权方式在公司项目中我都遇到过，在这里我浅谈一二。

自定义授权

自定义授权，也就是自己完成授权相关的工作，包括登录身份验证、加密、令牌发放、令牌校验、访问资源权限校验等工作。

自定义授权在我看来就是自由发挥，自己升级，结构定义超级自由，但是缺点也很明显，容易出现出现漏洞或者在不严谨的情况下可能出现后台人员可以盗取用户信息的问题，比如明文密码。

我这里举例一下场景：基于jwt令牌的自定义授权。关键的步骤有两个，一是发放令牌，二是令牌验证。大概的流程如下

spring security授权

spring security授权，其实就是使用spring提供的安全框架依赖spring-cloud-starter-security，如果是单体服务换成可换成单体服务可以换成spring-boot-starter-security依赖。

spring security做了什么呢，其实就是将授权这件事做成一个模式并简化了使用，一个注解@EnableWebSecurity就能把一堆可能需要考虑的东西都给你考虑了，比如加密方式、跨域、请求校验、默认登录页等等问题，在使用的时候，只需要按照定好的框架里加对应的东西即可，比如BCryptPasswordEncoder加密。如果使用最新版本的security，其实这些都不用考虑，配置好UserDetailService，开箱即用。

使用spring security的好处在于降低风险，而且spring security是跟着版本升级的，可以不断享受可能的隐藏福利。如果有人想问，这个与自定义的授权，有什么根本上的区别吗，答案是没有，security只是默默在后面奉献。

oauth2授权

oauth2之所以加一个数字，是因为之前有一个oauth，这个是升级版本，都是免费的，当然用oauth2啦。说到oauth2，就不得不说oauth2与spring的关系，oauth2是在spring security基础上搭建的一套授权方案，spring也是非常欢迎oauth2的加入，只要引入spring-cloud-starter-oauth2即可使用，但是只更新到2021年，因为spring认为spring security只做基础框架，不参与授权方案的具体实现，结果网上一阵沸腾，不过新版的spring又拥抱了oauth2，那就是spring-boot-starter-oauth2-authorization-server。

spring security虽然默认支持密码登录，但是远远不满足需求，oauth2就是在spring security的做一些授权补充，支持四种授权模式：密码模式、客户端模式、授权码模式、隐藏式模式，不过oauth不建议使用隐藏式模式，风险比较大。如果使用过oauth2的小伙伴会发现刷新token也是一种授权模式，但其实这只是密码模式的一种叠加，实现客户端永不掉线。

概述

不管是自定义授权还是基于spring security授权，都没有授权服务和资源服务的区分，但是oauth2是有这个概念的，单从依赖就可以看出分为server、client、resource，三者各司其职，但是实际使用也可以打破这个概念。按照oauth2的设计，微服务中需要独立一个服务作为授权服务，假设有需要将用户服务与授权服务当做一个服务，其实也可以将授权服务当做一个资源，但是这个时候需要自己稍做自定义。

关于技术选型，我建议先看公司项目的方向，如果每个项目相互独立，并且没有第三方访问资源的场景，那么直接使用spring security即可，oauth2会显得太臃肿。假设公司想做一个独立的授权中心，或者有给第三方授权的需求，或者是项目之间对接的场景，就可以采用oauth2。如果说不确定未来的发展方向，要么先用spring security，后续无法满足的话再使用oauth2，要么一开始就使用oauth2，秉承“可以不用但不能没有”的精髓。