OAuth 2.0 四种授权模式

OAuth 2.0定义了四种授权模式（Authorization Grant Types），用于在客户端和服务提供者之间进行身份验证和授权。这些授权模式针对不同的应用场景和安全需求。

客户端凭证模式（Client Credentials Grant）

• 适用于客户端自身是资源所有者，并且客户端可以直接和资源服务器交互，而无需用户参与的情况。
• 流程：
  1. 客户端向认证服务器提供自身的凭证（客户端ID和客户端密钥）。
  2. 认证服务器验证客户端凭证，并颁发访问令牌给客户端。

虽然这种模式比较简便，但是已经失去了用户验证的意义，更适用于服务内部调用的场景。

密码模式（Resource Owner Password Credentials Grant）：

• 适用于客户端是用户的信任应用，并且用户信任客户端，同时用户能够安全地将自己的凭证（用户名和密码）提供给客户端的情况。
• 流程：
  1. 客户端请求用户提供用户名和密码。
  2. 客户端使用用户名和密码向认证服务器请求访问令牌。
  3. 认证服务器验证凭证并颁发访问令牌给客户端。

密码模式看起来比较合理，但是会直接将账号和密码泄露给客户端，需要后台完全信任客户端，所以这也不是常见的模式。

隐式授权模式（Implicit Grant）：

• 适用于客户端无法安全地保护客户端密钥的情况，例如通过浏览器端应用程序。
• 流程：
  1. 客户端重定向用户到认证服务器，请求授权。
  2. 用户登录并授权客户端。
  3. 认证服务器将访问令牌直接返回给客户端。

它适用于没有服务端的第三方应用页面，并且相比前面一种形式，验证都是在验证服务器进行的，敏感信息不会轻易泄露，但是Token依然存在泄露的风险。

授权码模式（Authorization Code Grant）：

• 适用于客户端能够安全地保护客户端密钥的情况，例如通过服务器端应用程序。
• 流程：
  1. 客户端重定向用户到认证服务器，请求授权。
  2. 用户登录并授权客户端。
  3. 认证服务器将授权码重定向回客户端。
  4. 客户端使用授权码向认证服务器请求访问令牌。
  5. 认证服务器验证授权码并颁发访问令牌给客户端。

这种模式是最安全的一种模式，也是推荐使用的一种，相比隐式授权模式，它并不会直接返回Token，而是返回授权码，真正的Token是通过应用服务器访问验证服务器获得的。在一开始的时候，应用服务器（客户端通过访问自己的应用服务器来进而访问其他服务）和验证服务器之间会共享一个secret，这个东西没有其他人知道，而验证服务器在用户验证完成之后，会返回一个授权码，应用服务器最后将授权码和secret 一起交给验证服务器进行验证，并且Token也是在服务端之间传递，不会直接给到客户端。这样就算有人中途窃取了授权码，也毫无意义，因为，Token的获取必须同时携带授权码和secret，但是secret 第三方是无法得知的，并且Token不会直接丢给客户端，大大减少了泄露的风险。