Spring

授权服务器产品提供了一个安全、轻量级和可定制的基础。

说白了，Spring

Authorization

支持搭建授权服务器和资源服务器课程：27-微服务安全Spring

Security

Authorization）是一种开放标准的授权协议，允许用户授权第三方应用访问其在某个服务提供者上的受保护资源，而无需将其实际的凭证（如用户名和密码）分享给第三方应用。

这种方式可以增加安全性，同时允许用户更好地控制其数据的访问权限。

OAuth2.0协议：RFC

客户端（client）：使用授权服务器作为认证渠道的平台，一般指的是第三方应用。

例如，微信提供

OAuth

对于微信服务来说就是客户端。

又例如，我们是政府某一平台的服务，我们平台维护的数据代表着足够高的权威，那么其他政府部门或合作方，需要从我们的平台中查询数据，或者利用我们平台的认证进行登录，那么其他部门或合作方的应用就是客户端。

资源服务器（resource

server）：简单的说，就是提供接口给客户端访问的服务器，访问资源服务器上受保护的接口，则需要带上令牌（token）。

例如分布式微服务中的用户服务、订单服务等部署的服务器都属于资源服务器。

资源所有者（resource

owner）：拥有该资源的主体对象，一般指用户。

客户端向资源服务器请求获取用户数据时，资源所有者参与确认授权或拒绝操作。

授权服务器（authorization

server）：对客户端和用户进行身份认证、授权的服务器，认证授权成功，则颁发令牌（token）。

3.2

OAuth

（D）授权服务器对客户端进行认证以后，确认无误，同意发放令牌。

令牌（token）与密码（password）的作用是一样的，都可以进入系统，但是有三点差异。

（1）令牌是短期的，到期会自动失效，用户自己无法修改。

密码一般长期有效，用户不修改，就不会发生变化。

（2）令牌可以被数据所有者撤销，会立即失效。

密码一般不允许被他人撤销。

（3）令牌有权限范围（scope）。

对于网络服务来说，只读令牌就比读写令牌更安全。

密码一般是完整权限。

上面这些设计，保证了令牌既可以让第三方应用获得权限，同时又随时可控，不会危及系统安全。

这就是

OAuth

在许多不同的应用场景中都能够发挥作用，尤其是那些涉及到第三方应用程序访问用户数据或资源的情况。

以下是一些常见的

OAuth

社交媒体登录：许多网站和应用程序允许用户使用其社交媒体账户（如Facebook、Google、Twitter等）进行登录。

OAuth

2.0

可以用于授权第三方应用访问用户的社交媒体数据，如好友列表、社交活动等。

第三方应用集成：用户可能使用多个不同的应用和服务，例如电子邮件、日历、云存储等。

OAuth

2.0

可以用于实现单一的登录授权，使用户能够在多个应用之间共享数据，而无需在每个应用中都输入凭证。

移动应用访问

API：移动应用可能需要访问后端服务器上的受保护资源，例如用户数据或其他服务。

OAuth

2.0

可以确保安全地进行授权和访问控制，同时减少对用户凭证的需求。

授权访问云服务：当用户需要将他们的数据存储在云服务（如Google

2.0

API。

联合身份验证：在不同的身份提供者之间实现联合身份验证，使用户可以使用一个身份提供者的凭证来访问另一个身份提供者的资源。

医疗保健应用：在医疗保健领域，患者的健康数据可能由多个医疗应用和机构共享。

OAuth

2.0

可能应用的一些例子。

基本上，任何需要实现安全的第三方应用程序访问用户数据或资源的情况下，OAuth

2.0

Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行授权。

客户端模式是安全级别最低而且要求授权服务器对客户高度信任的模式，因为客户端向授权服务器请求认证授权的过程中，至始至终都没有用户的参与，未经过用户允许，客户端凭提供自己在授权服务器注册的信息即可在授权服务器完成认证授权，而客户端获得认证授权以后，则拥有从资源服务器操作用户数据的权限，这种模式一般应用于公司内部系统或者有着高度保密责任的合作伙伴之间的对接。

3：客户端带上

client_id、client_secret、grant_type（写死client_credentials）等参数向认证服务器发起获取

token

4：认证服务器校验客户端信息，校验通过，则发放令牌（access_token），校验失败，则返回异常信息。

5：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

https://oauth.b.com/token?grant_type=client_credentialsclient_id=CLIENT_IDclient_secret=CLIENT_SECRET

密码模式

也允许用户把用户名和密码，直接告诉该应用。

该应用就使用你的密码，申请令牌，这种方式称为"密码模式"（password）。

密码模式是一种安全级别较低而且要求资源拥有者（用户）完全信任客户端的模式，该模式可以理解为在客户端模式的基础上增加了对用户的账号、密码在认证服务器进行校验的操作，是客户端代理用户的操作。

在

OAuth

中，密码模式已经被废除，在第三方平台上，使用密码模式，对于用户来说是一种非常不安全的行为，假设某平台客户端支持

登录，用户使用自己

系统，因为都是自己公司的产品，这种情况下就不存在用户提供账号、密码给第三方客户端进行代理登录的情形了。

3：用户提供认证平台的账号、密码给客户端（这里的客户端可以是浏览器、APP、第三方应用的服务器）。

4：客户端带上

client_id、client_secret、grant_type（写死password）、username、password

等参数向认证服务器发起获取

5：认证服务器校验客户端信息，校验失败，则返回异常信息,校验通过，则往下继续校验用户验账号、密码。

6：认证服务器校验用户账号、密码，校验通过，则发放令牌（access_token），校验失败，则返回异常信息。

7：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

https://oauth.b.com/token?grant_type=password

授权方式是"密码模式"username=USERNAMEpassword=PASSWORDclient_id=CLIENT_IDclient_secret=client_secret

网站验证身份通过后，直接给出令牌。

注意，这时不需要跳转，而是把令牌放在

JSON

code）方式，指的是第三方应用先申请一个授权码，然后再用该授权码获取令牌。

OAuth

协议中安全级别最高的一种认证模式，他与密码模式一样，都需要使用到用户的账号信息在认证平台的登录操作，但有所不同的是，密码模式是要求用户直接将自己在认证平台的账号、密码提供给第三方应用（客户端），由第三方平台进行代理用户在认证平台的登录操作；而授权码模式则是用户在认证平台提供的界面进行登录，然后通过用户确认授权后才将一次性授权码提供给第三方应用，第三方应用拿到一次性授权码以后才去认证平台获取

（C）假设用户给予授权，授权服务器将用户导向客户端事先指定的"重定向URI"（redirection

（D）客户端收到授权码，附上早先的"重定向URI"，向授权服务器申请令牌。

这一步是在客户端的后台的服务器上完成的，对用户不可见。

（E）授权服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access

token）和更新令牌（refresh

4：向认证服务器发起认证授权请求，例如http://localhost:9000/auth/oauth/authorize?client_id=xxxresponse_type=codescope=message.readredirect_uri=http://www.baidu.com，注意，此时参数不需要client_secret。

5：认证服务器带上客户端参数，将操作引导至用户授权确认页面，用户在该页面进行授权确认操作。

6：用户在授权页面选择授权范围，点击确认提交，则带上客户端参数和用户授权范围向认证服务器获取授权码。

注意，此处操作已经脱离了客户端。

7：认证服务器校验客户端信息和授权范围（因为客户端在认证平台注册的时候，注册信息包含授权范围，如果用户选择的授权范围不在注册信息包含的范围内，则将因权限不足返回失败）。

8：校验通过，将授权码拼接到客户端注册的回调地址返回给客户端。

9：客户端拿到认证服务器返回的授权码后，带上客户端信息和授权码向认证服务器换取令牌（access_token）。

10：认证服务器校验授权码是否有效，如果有效，则返回令牌（access_token）；如果无效，则返回异常信息。

11：客户端成功获取到令牌（access_token）后，就可以带着令牌去访问资源服务器了。

实现效果

https://b.com/oauth/authorize?response_type=code

#要求返回授权码（code）client_id=CLIENT_ID

URI

response_type：表示授权类型，必选项，此处的值固定为

"code"

state：表示客户端的当前状态，可以指定任意值，授权服务器会原封不动地返回这个值。

用户跳转后，

https://a.com/callback?code=AUTHORIZATION_CODE

https://b.com/oauth/token?client_id=CLIENT_IDclient_secret=CLIENT_SECRET

份,client_secret参数是保密的，因此只能在后端发请求

采用的授权方式是授权码code=AUTHORIZATION_CODE

上一步拿到的授权码redirect_uri=CALLBACK_URL

redirect_uri

"token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":{...}}

简化模式

简化模式（也叫隐式模式）是相对于授权码模式而言的，对授权码模式的交互做了一下简化，省去了

客户端使用授权码去认证服务器换取令牌（access_token）的操作，即用户在代理页面选择授权范围

提交授权确认后，认证服务器通过客户端注册的回调地址直接就给客户端返回令牌（access_token

这种方式把令牌直接传给前端，是很不安全的。

因此，只能用于一些安全要求不高的场景，并且令牌

的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

重定向

http://localhost:9000/auth/oauth/authorize?client_id=xxxre

sponse_type=tokenscope=message.readredirect_uri=http://www.baidu.com

，注意，此时参数不需

：认证服务器带上客户端参数，将操作引导至用户授权确认页面，用户在该页面进行授权确认操作。

：用户在授权页面选择授权范围，点击确认提交，则带上客户端参数和用户授权范围向认证服务器获

取令牌（access_token