6.网络编程-OAuth 2.0

os-lee

已于 2024-04-09 10:07:05 修改

阅读量1k

点赞数 27

分类专栏：网络编程文章标签：网络

于 2024-04-08 14:15:34 首次发布

本文链接：https://blog.csdn.net/qq_22321199/article/details/137503676

版权

网络编程专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1. Authorization Code（授权码模式）

2. Impliclt Grant（隐式授权模式）

3. Resource Owner Password Credentials Grant（密码模式）

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

网络

OAuth 2.0是什么

OAuth 2.0（Open Authorization version 2.0）是一种授权框架，用于授权第三方应用访问用户在某一服务提供者（如社交媒体平台、云服务等）上的受保护资源，而无需直接共享用户的账户密码。OAuth 2.0协议允许用户安全地授权第三方应用在特定范围内访问其个人资源，同时保持对授权范围和期限的控制。

OAuth 2.0的核心理念是通过一个授权服务器（Authorization Server）作为中介，使得用户可以授权第三方应用访问其资源，而无需向第三方应用提供直接访问账户的权限。以下是OAuth 2.0协议的主要特点和工作流程：

主要特点：

授权委托：用户通过OAuth 2.0授权第三方应用访问其在资源服务器（Resource Server）上的资源，而无需向第三方应用提供直接访问账户的权限。
安全：用户凭据（如密码）不直接传递给第三方应用，而是通过授权服务器进行验证和授权。
灵活：OAuth 2.0定义了多种授权类型（Grant Types），以适应不同类型的客户端（如web应用、移动应用、命令行工具等）和使用场景。
可撤销：用户可以随时撤销对第三方应用的授权，使其无法继续访问其资源。

工作流程（以最常见的授权码授权（Authorization Code Grant）为例）：

用户授权：用户在第三方应用中选择使用OAuth登录，被重定向到授权服务器，用户在授权服务器的页面上确认授权请求，并通过授权服务器返回一个授权码（Authorization Code）给第三方应用。
获取访问令牌：第三方应用使用授权码和自己的客户端凭据（客户端ID和客户端密钥），向授权服务器发起请求，换取访问令牌（Access Token）和可选的刷新令牌（Refresh Token）。
访问资源：第三方应用持有访问令牌，向资源服务器发起请求时，将访问令牌放入请求的Authorization header中。资源服务器验证访问令牌的有效性后，允许第三方应用访问用户授权范围内的资源。
令牌刷新（可选）：访问令牌通常有有效期，到期后需要刷新。第三方应用使用刷新令牌向授权服务器请求新的访问令牌，无需用户再次授权，以保持对资源的长期访问权限。

OAuth 2.0协议广泛应用于各种互联网服务中，如社交平台的第三方登录、云服务API的访问控制、企业内部系统的跨域授权等场景，为用户提供了一种安全、可控的方式来授权第三方应用使用其账户资源。

OAuth2.0中的四个重要角色

OAauth2.0包括的角色	说明
资源拥有者	通常为用户，也可以是应用程序，即该资源的拥有者。
客户端	本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。
授权服务器（也称认证服务器）	用于服务提供商对资源拥有者的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌（access_token），作为客户端访问资源服务器的凭据。
资源服务器	存储资源的服务器。

OAuth2 四种认证模式

1. Authorization Code（授权码模式）

第三方应用先申请一个授权码code，然后通过code获取令牌Access Token

授权码模式是功能最完全，流程最严密安全的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动，access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减小了令牌泄漏的风险

说明：

【步骤1，2】用户访问客户端，需要使用服务提供商的数据（用户信息），客户端通过重定向跳转到服务提供商的页面。
【步骤3】用户选择是否给予客户端授权访问服务提供商（用户信息）数据的权限。
【步骤4】用户给与授权。授权系统通过重定向（redirect_uri）并携带授权凭证（code）跳转回客户端。
【步骤5，6】客户端将授权凭证（code）发送给客服端服务器，客户端服务器携带授权码（code）、客户端id（client_id）和秘钥（client_secret）向认证服务器请求访问令牌（access_token）。
【步骤7，8】认证服务器核对授权码等信息，确认无误后，向客户端服务器发送访问令牌（access_token）和更新令牌（refresh_token），然后客户端服务器再发送给客户端。
【步骤9，10】客户端持有访问令牌（access_token）和需要请求的参数向客户端服务器发起资源请求，然后客户端服务器再向服务提供商的资源服务器请求资源（web API）。
【步骤11，12，13】服务提供商的资源服务器返回数据给客户端服务器，然后再回传给客户端使用。

上述流程，只有第二步需要用户手动进行授权，之后的流程都是客户端的后台和认证服务器后台之前进行"静默"操作，对于用户来说是无感知的。

2. Impliclt Grant（隐式授权模式）

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）

说明：

【步骤1，2】用户访问客户端，需要使用服务提供商的数据（用户信息），客户端通过重定向跳转到服务提供商的页面。
【步骤3】用户选择是否给予客户端授权访问服务提供商（用户信息）数据的权限。
【步骤4】用户给与授权。授权系统通过重定向（redirect_uri）并携带访问令牌（access_token）跳转回客户端。
【步骤5】客户端向资源服务器发出请求资源的请求。
【步骤6，7】服务提供商的资源服务器返回数据给客户端使用。

3. Resource Owner Password Credentials Grant（密码模式）

如果你高度信任某个应用，RFC 6749也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）

使用用户名/密码作为授权方式从授权服务器上获取令牌，一般不支持刷新令牌。这种方式风险很大，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下

说明：

【步骤1，2】用户向第三方客户端提供，其在服务提供商那里注册的用户名和密码。
【步骤3】客户端将用户名和密码发给认证服务器，向后者请求访问令牌（access_token）。
【步骤4】授权认证服务器确认身份无误后，向客户端提供访问令牌（access_token）。
【步骤5】客户端向资源服务器发出请求资源的请求。
【步骤6，7】服务提供商的资源服务器返回数据给客户端使用。