OAuth 2.0 密码授权类型是一种在给定用户名和密码的情况下获取访问令牌的方法。它通常仅由服务自己的移动应用程序使用,通常不提供给第三方开发人员。
这篇文章是我们探索常用的 OAuth 2.0 授权类型系列文章的第三篇。之前我们介绍了授权代码和隐式授权类型。如果您想在我们开始之前稍微回顾一下并了解有关 OAuth 2.0 的更多信息,请查看OAuth 到底是什么?.
在 OAuth 2.0 中,术语“授权类型”是指应用程序获取访问令牌的方式。OAuth 2.0 定义了几种授权类型,包括密码授权。OAuth 2.0 扩展还可以定义新的授权类型。
每种授权类型都针对特定用例而设计,无论是网络应用程序、移动或桌面应用程序,还是服务器到服务器应用程序。
密码授权是最简单的 OAuth 授权之一,只涉及一个步骤:应用程序提供一个传统的用户名和密码登录表单来收集用户的凭据,并向服务器发出 POST 请求以将密码交换为访问令牌。应用程序发出的 POST 请求如下例所示。
POST /oauth/token HTTP/1.1
Host: authorization-server.com
Content-type: application/x-www-form-urlencoded
grant_type=password
&username=exampleuser
&password=1234luggage
&client_id=xxxxxxxxxx
此请求中的 POST 参数解释如下。
grant_type=password
- 这告诉服务器我们正在使用密码授予类型username=
- 他们在应用程序中输入的用户名password=
- 他们在应用程序中输入的用户密码client_id=
- 开发者在注册时获得的应用的公共标识符client_secret=
-(可选)- 如果应用程序是“机密客户端”(不是移动或 JavaScript 应用程序),那么秘密也包括在内。scope=
- (可选)- 如果应用程序请求范围有限的令牌,它应该在此处提供请求的范围。服务器以与其他授权类型相同的格式回复访问令牌。
{
"access_token": "MTQ0NjOkZmQ5OTM5NDE9ZTZjNGZmZjI3",
"token_type": "bearer",
"expires_in": 3600,
"scope": "create"
}
密码授权要求应用程序收集用户的密码。这当然正是创建 OAuth 时首先要避免的问题。那么为什么将密码授予作为 OAuth 的一部分包含在内呢?
将密码授予添加到 OAuth 的最初原因是允许 OAuth 之前的应用程序无需任何用户交互即可升级到 OAuth。当 HTTP Basic Auth 被普遍使用时,工作的方式是浏览器会询问用户的密码并将其存储在内部,然后在每次请求时将其呈现给 Web 服务器。这种方法有很多局限性,这就是为什么十多年来它一直没有得到普遍使用的原因。密码授予的理论是允许浏览器通过将用户密码交换为访问令牌,然后在将来继续使用访问令牌来无缝升级到 OAuth。实际上,情况并非如此,许多应用程序开发人员将密码授予误解为从移动应用程序使用 OAuth 的可接受方式。今天,OAuth 2.0 安全最佳当前实践有效地从 OAuth 中删除了密码授予。