OAuth 2.0详解（Google api示例）
OAuth 2.0详解（Google api示例）
流程
Google Workspace API 的身份验证和授权的简要步骤：
- 配置您的 Google Cloud 项目和应用程序：在开发期间，您在 Google Cloud Console 中注册您的应用程序，定义授权范围和访问凭据，以使用 API 密钥、最终用户凭据或服务帐户凭据对您的应用程序进行身份验证。
- 验证您的应用程序的访问权限：当您的应用程序运行时，将评估注册的访问凭据。如果您的应用程序正在以最终用户身份进行身份验证，则可能会显示登录提示。
- 请求资源：当您的应用需要访问 Google 资源时，它会使用您之前注册的相关访问范围向 Google 询问。
- 征求用户同意：如果您的应用作为最终用户进行身份验证，Google 会显示 OAuth 同意屏幕，以便用户决定是否授予您的应用访问所请求数据的权限。
- 发送已批准的资源请求：如果用户同意访问范围，您的应用会将凭据和用户批准的访问范围捆绑到请求中。该请求被发送到 Google 授权服务器以获取访问令牌。
- Google 返回访问令牌：访问令牌包含授予的访问范围列表。如果返回的范围列表比请求的访问范围更受限制，您的应用程序将禁用令牌限制的任何功能。
- 访问请求的资源：您的应用使用来自 Google 的访问令牌来调用相关 API 并访问资源。
- 获取刷新令牌（可选）：如果您的应用需要在单个访问令牌的生命周期之外访问 Google API，则可以获取刷新令牌。
- 请求更多资源：如果需要额外的访问权限，您的应用会要求用户授予新的访问范围，从而产生获取访问令牌的新请求（步骤 3-6）。
术语解释
1. 验证（authentication）
确保委托人（principal）（可以是用户或代表用户行事的应用程序）与他们所说的一样的行为。在编写 Google Workspace 应用程序时，您应该注意以下类型的身份验证：
1.1 用户认证（user authentication）
用户对您的应用进行身份验证（登录）的行为。用户身份验证通常通过登录过程执行，在该过程中，用户使用用户名和密码组合向应用程序验证其身份。可以使用Sign In With Google将用户身份验证合并到应用程序中 。
1.2 应用认证（app authentication）
应用代表运行应用的用户直接向 Google 服务进行身份验证的行为。应用程序身份验证通常使用应用程序代码中预先创建的凭据来执行。
2. 授权（authorization）
主体必须访问数据或执行操作的权限或“权限”。授权行为是通过您在应用程序中编写的代码执行的。此代码通知用户该应用希望代表他们执行操作，如果允许，它会使用您应用的唯一凭据 从 Google 获取用于访问数据或执行操作的访问令牌。
3. 凭据（credentials）
用于软件安全的一种标识形式。在身份验证方面，凭据通常是用户名/密码组合。就 Google Workspace API 的授权而言，凭据通常是某种形式的标识，例如唯一的秘密字符串，只有在应用开发者和身份验证服务器之间才知道。Google 支持以下身份验证凭据：API 密钥、OAuth 2.0 客户端 ID 和服务帐户。
3.1 API 密钥（API Key）
用于请求访问公共数据的凭据，例如使用 Maps API 提供的数据或使用 Google Workspace 共享设置中的“互联网上知道此链接的任何人”设置共享的 Google Workspace 文件。
3.2 OAuth 2.0 客户端 ID（OAuth 2 client ID）
用于请求访问用户拥有的数据的凭据。这是使用 Google Workspace API 请求访问数据时使用的主要凭据。此凭据需要用户同意。
3.3 client secret
只有您的应用程序和授权服务器才应该知道的字符串。客户端密钥通过仅将令牌授予授权请求者来保护用户的数据。你永远不应该在你的应用程序中包含你的客户端密码。
3.4 service account keys
服务帐户用于获得对 Google 服务的授权。
3.5 服务帐户（service account）
用于服务器到服务器交互的凭据，例如作为进程运行以访问某些数据或执行某些操作的匿名应用程序。服务帐户通常用于访问基于云的数据和操作。但是，当与域范围的授权一起使用时，它们可用于访问用户数据。
整体思路
OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。
"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。
授权模式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
授权码模式操作步骤（重点）
接下来用Google api官方的操作步骤来讲解刚刚说到的9个流程（这里只重点说前七个）
配置 Google Cloud 项目和应用程序
也就是在 Google控制台去添加一个oauth2.0凭证（credential）
填写好必要的资料之后（注意这里有一个 redirect_url 的设置，这里要配置之后我们参数里面的 redirect_url，不然无法访问，当然随便一个都行）
创建完毕之后可以下载到本地下来，里面的内容就是我们后续获取token的根据，格式是：
{
"web":{
"client_id":"YOUR_CLIENT_ID",
"project_id":"PROJECT_ID",
"auth_uri":"https://accounts.google.com/o/oauth2/auth",
"token_uri":"https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url":"https://www.googleapis.com/oauth2/v1/certs",
"client_secret":"YOUR_CLIENT_SECRET"
}
}
验证您的应用程序的访问权限
这个阶段，客户端会向认证服务器（注意不是用户）发送请求，地址就是刚刚的 auth_url，方式为get，有以下几个params：
- response_type：表示授权类型，此处的值固定为"code"；
- client_id：表示客户端的ID；
- redirect_uri：表示重定向URI（注意要是刚刚在Google console配置过的）
- scope：表示申请的权限范围（这里我要使用gmail api，去看官网发现是以上的地址）
- access_type。
用postman来看看：
用浏览器访问之后可以看到如下认证页面，用户点击认证之后就会从服务器返回数据中得到一个code（这里有个比较容易遇到的问题，就是由于我们的应用还没有Google授权，所以要将用户添加到后台的测试名单里 项目主持人也不例外）：
客户端向认证服务器申请令牌的HTTP请求
就是向 token_url 发送post请求，参数要带上刚刚的 code（这个code只能用一次，用多次会出现 invalid_grant 的错误） ：
- grant_type：表示使用的授权模式，此处的值固定为"authorization_code"；
- code：表示上一步获得的授权码；
- redirect_uri：表示重定向URI，且必须与上面中的该参数值保持一致。
- client_id：表示客户端ID；
- client_secret：表示客户端secret。
expires_in：表示过期时间，单位为秒；
- refresh_token：表示更新令牌，用来获取下一次的访问令牌；
- scope：表示权限范围。
访问请求的资源
好啦，现在我们终于拿到token了，带上这个token，就能使用相关 Google api了。
如，我这里是要使用 gmail 的api，刚刚也申请了相关权限范围（https://mail.google.com/），参照官网的格式发送请求（设置好 OAuth 的验证）：
刷新token
如果刚刚获取的token过期了（Google的是一个小时），我们可以用刚刚拿到的refresh_token去token_url请求更新token，当然，如果refresh_token也过期了，就只能重新让用户授权了（一般过期时间会选得长一点）。
请求的url为token_url，方式为post，参数如下：
- grant_type：表示使用的是授权模式，此处值固定为refresh_token；
- refresh_token：表示早前收到的更新令牌；
- scope：表示申请的授权范围，不可以超出上一次申请的范围；
- client_id和client_secret同上。
