跳到主要内容

什么是 OAuth 2.0

OAuth 2.0 是一种授权框架,允许你授权第三方应用程序(比如某个网站)访问你在另一个服务(比如微信)上的受保护信息,而无需提供登录凭据。它以有限的方式允许第三方代表你访问受保护的资源,如照片或个人资料。举个例子,当你用微信扫码登录一个网站时,你授权该网站访问你的个人信息,这即是 OAuth 2.0 的运作方式。OAuth 2.0 的规范在 RFC 6749 中定义了其工作原理和规则。

OAuth 2.0 角色

OAuth 2.0 定义了四种角色,分别是:

  • 资源所有者(Resource Owner):通常是用户,拥有受保护的资源,例如图片、个人资料等。
  • 客户端(Client):第三方应用程序,想要访问资源所有者的受保护资源。
  • 授权服务器(Authorization Server):负责认证资源所有者并授权客户端访问资源的服务器。
  • 资源服务器(Resource Server):托管受保护资源的服务器,提供访问受保护资源的 API。

OAuth 2.0 授权流程

以下所示的 OAuth 2.0 流程描述了四个角色之间的交互:

     +--------+                               +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+

当客户端应用程序需要访问受保护的资源,但又不希望直接向资源所有者索取凭证时,就会使用 OAuth 2.0 框架。以下是每个步骤的具体解释:

  1. Authorization Request (步骤 A)

    • 客户端应用程序向资源所有者发出授权请求,请求访问特定的资源。通常,这是通过用户界面(如登录页面)实现的,用户需要登录并授予访问权限。
  2. Authorization Grant (步骤 B)

    • 资源所有者同意授权请求后,授权服务器将颁发一个授权凭证,即授权码(Authorization Grant),给客户端。这个授权码是客户端用来向授权服务器获取访问令牌的凭据。
  3. Authorization Grant -> Access Token (步骤 C)

    • 客户端应用程序将授权凭证(授权码)发送给授权服务器,并请求访问令牌。
    • 授权服务器验证客户端的身份和授权凭证的有效性。一旦验证通过,授权服务器会颁发一个访问令牌给客户端。
  4. Access Token (步骤 D)

    • 授权服务器发放的访问令牌代表了客户端应用程序被授权访问资源的权限。访问令牌通常具有特定的过期时间,并且可能包含有关访问权限范围的信息。
  5. Access Token -> Protected Resource (步骤 E)

    • 客户端使用获取到的访问令牌向资源服务器发送访问请求。
    • 资源服务器接收到访问请求后,会验证访问令牌的有效性和权限。如果访问令牌有效且具有足够的权限,则资源服务器会提供受保护的资源给客户端。
  6. Protected Resource (步骤 F)

    • 资源服务器根据访问令牌的权限,向客户端提供所请求的受保护资源。这可能是用户的数据、照片、视频或其他类型的资源。

通过这个流程,OAuth 2.0 使得客户端应用程序能够以一种安全且受控的方式访问受保护的资源,同时又不需要用户直接提供他们的凭证。

OAuth 2.0 授权类型

OAuth 2.0 授权框架支持多种不同的授权流程(称为 Authorization Flow 或 Authorization Type),流程(Flow)是获取访问令牌的方式,采用哪种流程主要取决于你的应用程序类型。OAuth 2.0 定义了常见的几种授权类型,它们分别是:

  • 授权码授权类型(Authorization Code Grant Type)
    • 适用场景:用于 Web 应用程序,需要在安全的服务器端存储客户端密钥。
    • 工作原理:客户端重定向用户到授权服务器,用户登录并授权后,授权服务器返回授权码给客户端,客户端使用授权码与客户端凭证交换访问令牌。
  • 授权码授权类型,带有 PKCE (Authorization Code Grant Type,With PKCE)
    • 适用场景:用于公共客户端(如移动应用和单页应用),PKCE 的主要目的是防止授权码被截获并被恶意使用。
    • 工作原理:与标准授权码模式相同,但客户端需要使用 PKCE(Proof Key for Code Exchange)来增强安全性。该类型的规范在 RFC 7636 中定义。
  • 隐式授权类型(Implicit Grant Type)
    • 适用场景:用于无法存储客户端密钥的前端应用程序,如单页应用。
    • 工作原理:客户端直接从授权服务器获取访问令牌,而不是先获取授权码再交换访问令牌。
  • 资源所有者密码凭证授权类型(Resource Owner Password Credentials Grant Type)
    • 适用场景:用于信任客户端并且资源所有者有能力保护其凭据的情况,不建议在公共客户端使用。
    • 工作原理:资源所有者直接将用户名和密码提供给客户端,客户端使用这些凭据向授权服务器请求访问令牌。
  • 客户端凭证授权类型(Client Credentials Grant Type)
    • 适用场景:用于客户端自身作为资源的拥有者,并且无需用户参与授权的情况。
    • 工作原理:客户端使用自身的凭据向授权服务器获取访问令牌,以访问自己拥有的资源。