有一个许多关于OAuth的困惑实际上是.
有些人认为OAuth是一个登录流程（例如，当您使用Google login登录到应用程序时），有些人认为OAuth是“安全问题”，我真的不知道更多。
我将向您展示OAuth是什么，解释它是如何工作的，并希望让您了解OAuth如何以及在何处为您的应用程序带来好处。
什么是OAuth？
从高处看，OAuth是不API或服务：这是一个开放的授权标准，任何人都可以实现。
更具体地说，OAuth是一种标准，应用程序可以使用它为客户端应用程序提供“安全委托访问”。OAuth通过HTTPS工作，使用access tokens（访问令牌）而不是凭据来授权设备、API、服务器和应用程序。
OAuth有两个版本：OAuth 1.0a认证和OAuth 2.0。这些规范是完全不同不能一起使用：它们之间并不向后兼容。
哪一个更受欢迎？好问题！如今，OAuth 2.0是OAuth最广泛使用的形式。所以从现在开始，每当我说“OAuth”（OAuth），我指的是OAuth 2.0，因为它很可能是您将要使用的。
为什么选择OAuth？
OAuth是作为对直接身份验证模式的响应而创建的。这种模式因HTTP Basic Authentication而著名，它会提示用户输入用户名和密码。基本身份验证仍然用作服务器端应用程序的API身份验证的基本形式：用户发送API密钥ID和密码，而不是在每次请求时向服务器发送用户名和密码。在OAuth之前，网站会提示您在表单中直接输入用户名和密码，并以您的身份登录您的数据（例如Gmail帐户）。这通常被称为密码反模式.
为了为web创建更好的系统，为单点登录（SSO）创建了federated identity(联合身份)。在这种情况下，最终用户与他们的身份提供者对话，身份提供者生成一个经过加密签名的令牌，并将其传递给应用程序以对用户进行身份验证。应用程序信任身份提供程序。只要该信任关系与签名断言一起工作，就可以继续了。下图显示了其工作原理。
2005年3月15日发布的OASIS标准SAML2.0让federated identity(联邦身份)闻名于世。这是一个很大的规范，但主要的两个组件是它的身份验证请求协议（又称Web SSO），以及它打包身份属性并对其进行签名的方式，称为SAML断言。Okta用它的SSO chiclets做到了这一点。我们发送一条消息，对断言进行签名，在断言中说明用户是谁，并且它来自Okta。在上面打上数字签名，你就可以开始了。
SAML
SAML基本上是浏览器中的一个会话cookie，让您可以访问Web应用程序。它仅限于您可能希望在web浏览器之外执行的设备配置文件和场景的类型。
2005年推出SAML 2.0时，它很有意义。然而，自那以后发生了很大变化。现在我们有了现代的web和本地应用程序开发平台。有Gmail/Google收件箱、Facebook和Twitter等单页应用程序（SPA）。它们的行为与传统web应用程序不同，因为它们对API进行AJAX（后台HTTP调用）。手机也可以进行API调用，电视、游戏控制台和物联网设备也是如此。SAML SSO在这方面并不是特别擅长。
OAuth和API
我们构建API的方式也发生了很大变化。2005年，人们投资WS-*来构建web服务。现在，大多数开发人员已经转向REST和无状态API。简而言之，REST是通过网络推送JSON数据包的HTTP命令。
开发人员构建了许多API。API经济是你今天在董事会会议室可能听到的一个常见的流行词。公司需要以允许许多设备访问的方式保护其REST API。在过去，你需要输入用户名/密码目录，应用程序会以你的身份直接登录。这导致了授权问题。
“我如何允许应用程序访问我的数据而不必为其提供密码？”
如果你看过下面的对话，那就是我们要说的。这是一个应用程序，询问它是否可以代表您访问数据。
这就是OAuth。
OAuth是REST/API的委托授权框架。它使应用程序能够在不泄露用户密码的情况下获得对用户数据的有限访问（范围）。它将身份验证与授权分离，并支持解决不同设备功能的多个用例。它支持服务器到服务器应用程序、基于浏览器的应用程序、移动/本地应用程序和控制台/电视。
你可以把它想象成酒店的钥匙卡，但这只适用于应用程序。如果你有酒店钥匙卡，你可以进入你的房间。你如何获得酒店钥匙卡？你必须在前台进行身份验证才能获得它。在验证并获得钥匙卡后，你可以访问整个酒店的资源。
简单地说，OAuth的作用是：
- 应用程序请求用户授权
- 用户授权应用程序并提供证据
- 应用程序向服务器提供获得令牌的授权证明
- 令牌仅限于访问用户为特定应用程序授权的内容
OAuth中心组件
OAuth基于以下中心组件构建：
- Scopes and Consent 范围和同意
- Actors 参与者
- Clients 客户
- Tokens 代币
- Authorization Server 授权服务器
- Flows 流量
OAuth作用域
作用域是应用程序请求权限时在授权屏幕上看到的内容。它们是客户端在请求令牌时请求的权限束。这些代码是由应用程序开发人员在编写应用程序时编写的。
作用域将 授权策略决策 与 实施 解耦。这是OAuth的第一个关键方面。权限位于前面和中间。它们并没有隐藏在应用层后面，你必须对其进行反向工程。它们通常列在API文档中：以下是此应用程序需要的范围。
你必须获得同意。这称为首次使用时的信任。这是网络用户体验的一个重大变化。OAuth之前的大多数人只是用 姓名和密码 对话框。现在你有了这个新屏幕(指移动端)，你必须训练用户使用。重新培训互联网用户很困难。从技术娴熟的年轻人到祖父母，各种各样的用户都不熟悉这种流程。这是网络上的一个新概念，现在是前沿和中心。现在你必须授权并征得同意。
许可可能因不同应用程序申请而异。它可以是一个时间敏感的范围（天、周、月），但并非所有平台都允许您选择持续时间。当你同意时需要注意的一件事是，应用程序可以代表你做一些事情，例如LinkedIn向你网络中的每个人发送垃圾邮件。
OAuth是一种互联网规模的解决方案，因为它是针对每个应用程序的。您通常能够登录到仪表板，查看您授予了哪些应用程序访问权限并撤销同意。
OAuth参与者
OAuth流中的参与者如下：
- 资源所有者：拥有资源服务器中的数据。例如，我是我的Facebook个人资料的资源所有者。
- 资源服务器：存储应用程序要访问的数据的API
- 客户：要访问您的数据的应用程序
- 授权服务器：OAuth的主引擎
资源所有者是可以使用不同凭据更改的角色。它可以是最终用户，也可以是公司。
客户可以公开和保密。在OAuth命名法中，这两者之间存在显著区别。受信任的客户端可以存储机密。它们不是在桌面上运行，也不是通过应用程序商店分发的。人们无法对它们进行反向工程，从而获得密钥。它们在一个受保护的区域内运行，最终用户无法访问它们。
公共客户端是浏览器、移动应用程序和物联网设备。
客户端注册也是OAuth的一个关键组件。这就像OAuth的DMV。你需要申请一个车牌。这是您的应用程序徽标在授权对话框中的显示方式。
OAuth令牌
访问令牌是客户端用于访问资源服务器（API）的令牌。他们注定是短期的。用小时和分钟来思考它们，而不是用天和月。您不需要机密客户端来获取访问令牌。您可以通过公共客户端获得访问令牌。它们旨在优化互联网规模的问题。因为这些令牌可以是短期的，并且可以扩展，所以它们不能被撤销，您只需等待它们超时即可。
另一个token是refresh token刷新令牌。这是长期的；天，月，年。这可以用于获取新令牌。要获得刷新令牌，应用程序通常需要具有身份验证的机密客户端。
可以吊销刷新令牌。在仪表板中撤销应用程序的访问时，您正在终止其刷新令牌。这使您能够强制客户端轮换机密。您正在做的是使用刷新令牌来获取新的访问令牌，而访问令牌正在通过连接来访问所有API资源。每次刷新访问令牌时，都会获得一个新的加密签名令牌。钥匙旋转内置于系统中。
OAuth规范没有定义令牌是什么。它可以是您想要的任何格式。不过，通常您希望这些令牌是JSON Web令牌（标准). 简而言之，JWT（发音为“jot”）是令牌身份验证的安全可靠标准。JWT允许您使用签名对信息（称为索赔）进行数字签名，稍后可以使用秘密签名密钥进行验证。要了解有关JWT的更多信息，请参阅Java JWT入门指南.
令牌是从授权服务器上的端点检索的。两个主要端点是授权端点和令牌端点。对于不同的用例，它们是分开的。授权端点是您从用户那里获得同意和授权的地方。这将返回一个授权授予，表示用户已同意。然后将授权传递给令牌端点。令牌端点处理授权并表示“很好，这是您的刷新令牌和访问令牌”。
您可以使用访问令牌来访问API。一旦它过期，您必须使用刷新令牌返回令牌端点以获取新的访问令牌。
缺点是这会导致开发人员产生很多摩擦。OAuth给开发人员带来的最大痛苦之一是您必须管理刷新令牌。您将状态管理推送到每个客户端开发人员身上。你得到了键轮换的好处，但你给开发人员带来了很多痛苦。这就是为什么开发人员喜欢API密钥。他们只需复制/粘贴它们，将它们放在文本文件中，然后就可以完成了。API密钥对开发人员来说非常方便，但对安全性却非常不利。
这里有一个付费游戏的问题。让开发人员执行OAuth流可以提高安全性，但存在更多摩擦。工具包和平台有机会简化事情并帮助进行令牌管理。幸运的是，OAuth现在已经相当成熟了，您最喜欢的语言或框架很可能有可用的工具来简化事情。
我们已经讨论了客户端类型、令牌类型和授权服务器的端点，以及如何将其传递给资源服务器。我提到了两个不同的流程：获取授权和获取令牌。这些不一定发生在同一频道。前频道是浏览器上的频道。浏览器将用户重定向到授权服务器，用户表示同意。这在用户的浏览器上发生。一旦用户获得授权并将其交给应用程序，客户端应用程序就不再需要使用浏览器来完成OAuth流以获取令牌。
这些令牌将由客户端应用程序使用，以便它可以代表您访问资源。我们称之为反向通道。反向通道是直接从客户端应用程序到资源服务器的HTTP调用，以将授权授予交换为令牌。这些通道用于不同的流，具体取决于您的设备功能。
例如，您通过用户代理授权的前端通道流可能如下所示：
- 资源所有者启动流以委派对受保护资源的访问
- 客户端通过浏览器重定向到授权服务器上的授权端点，发送具有所需范围的授权请求
- 授权服务器返回一个同意对话框，其中显示“您允许此应用程序访问这些作用域吗？”当然，您需要对应用程序进行身份验证，因此，如果您没有通过资源服务器的身份验证，它会要求您登录。如果您已经有一个缓存的会话cookie，则只会看到同意对话框。查看同意对话框并同意。
- 授权授权通过浏览器重定向传递回应用程序。这一切都发生在前频道。
这个流中还有一个变量，称为隐式流。我们马上就要开始了。
这是它在线上的样子。
| 请求 | GET https://accounts.google.com/o/oauth2/auth?scope=gmail.insert gmail.send &redirect_uri=https://app.example.com/oauth2/callback &response_type=code&client_id=812741506391 &state=af0ifjsldkj 这是一个带有一组查询参数的GET请求（例如，不是URL编码的）。范围来自Gmail的API。redirect_uri是授权授予应该返回到的客户端应用程序的URL。这应该与客户端注册过程（在DMV）中的值匹配。您不希望授权被退回到外部应用程序。响应类型改变了OAuth流。客户端ID也来自注册过程。状态是一个安全标志，类似于XRSF。要了解有关XRSF的更多信息，请参阅DZone的“跨站点请求伪造解释”. |
| 响应 | HTTP/1.1 302 Found Location: https://app.example.com/oauth2/callback? code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj 这个 |
完成前通道后，会发生后通道流，交换访问令牌的授权码。
客户端应用程序使用机密客户端凭据和客户端id向授权服务器上的令牌端点发送访问令牌请求。此过程将授权代码授予与访问令牌和（可选）刷新令牌交换。客户端使用访问令牌访问受保护的资源。
下面是它在原始HTTP中的外观。
| 请求 | POST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=MsCeLvIaQm6bTrgtp7&client_id=812741506391&client_secret={client_secret}&redirect_uri=https://app.example.com/oauth2/callback&grant_type=authorization_code grant_type是OAuth的可扩展性部分。从预计算的角度来看，这是一个授权代码。它提供了灵活的方式来描述这些拨款。这是最常见的OAuth流类型。 |
| 响应 | {
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
} 响应返回是JSON类型。您可以被动或主动使用令牌。主动是在你的客户机上设置一个计时器。被动响应是捕获错误并尝试获取新令牌。 |
拥有访问令牌后，可以在Authentication头中使用访问令牌（使用标记类型作为前缀）发出受保护的资源请求。
curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \
https://www.googleapis.com/gmail/v1/users/1444587525/messages现在您有了一个前端通道、一个后端通道、不同的节点和不同的客户端。您必须为不同的使用场景混合和匹配这些内容。这提高了OAuth的复杂性，可能会让人感到困惑。
OAuth流
第一个流程就是我们所说的隐式流它之所以被称为隐式流，是因为所有的通信都是通过浏览器进行的。没有后端服务器为访问令牌兑换授权授予。SPA就是一个很好的例子。此流也称为双腿OAuth。
隐式流针对仅浏览器的公共客户端进行了优化。访问令牌直接从授权请求返回（仅限前端通道）。它通常不支持刷新令牌。它假定资源所有者和公共客户端位于同一设备上。由于一切都发生在浏览器上，因此它最容易受到安全威胁。
最标准的是授权代码流(Authorization Code Flow)，也称为3条腿，使用前端通道和后端通道。这就是我们在这篇文章中谈论最多的内容。客户端应用程序使用前端通道流来获得授权代码。客户端应用程序使用后端通道来交换访问令牌（以及可选的刷新令牌）的授权代码。它假定资源所有者和客户端应用程序位于不同的设备上。这是最安全的流，因为您可以对客户端进行身份验证以兑换授权授予，并且令牌永远不会通过用户代理传递。不仅有隐式和授权代码流，还可以使用OAuth进行其他流。同样，OAuth更像是一个框架。
对于服务器到服务器场景，您可能希望使用客户端凭据流(Client Credential Flow)。在这种情况下，客户端应用程序是一个秘密客户端，它自己操作，而不是代表用户。这更像是一种服务帐户类型的场景。您只需要客户的凭据即可完成整个流程。使用客户端凭据获取访问令牌是一个仅支持后端通道的流。它支持将共享机密或断言作为使用对称或非对称密钥签名的客户端凭据。
对称密钥算法是一种加密算法，它允许您解密任何内容，只要您有密码。保护PDF或.zip文件时经常会出现这种情况。
公钥密码术或非对称密码术是使用密钥对（公钥和私钥）的任何密码系统。任何人都可以读取公钥，私钥对所有者来说是神圣的。这样可以确保数据的安全，而无需共享密码。
还有一种传统模式称为资源所有者密码流(Resource Owner Password Flow)。这与使用用户名和密码进行直接身份验证的情况非常类似，不建议使用。它是本地用户名/密码应用程序（如桌面应用程序）的传统授权类型。在此流中，您向客户端应用程序发送用户名和密码，它将从授权服务器返回访问令牌。它通常不支持刷新令牌，并假定资源所有者和公共客户端位于同一设备上。当你想用OAuth的API，但有老的客户需要兼容处理的时候。
OAuth的最新添加是断言流(Assertion Flow)，类似于客户端凭据流。这是为了打开联邦的概念。此流允许授权服务器信任来自第三方（如SAML IdP）的授权授予。授权服务器信任身份提供程序。断言用于从令牌端点获取访问令牌。这对于已经使用SAML或SAML相关技术并允许其与OAuth集成的公司来说非常有用。因为SAML断言是短期的，所以此流中没有刷新令牌，您必须在每次断言过期时继续检索访问令牌。
另外不在OAuth规范中，有一个是设备流量(Device Flow)。没有网络浏览器，只有电视等设备的控制器。授权请求返回用户代码，必须通过访问设备上的URL进行授权才能兑现。客户端应用程序使用后端通道流轮询访问令牌和刷新令牌（可选）的授权批准。在CLI客户端也很流行。
我们使用不同的参与者和标记类型介绍了六种不同的流。它们之所以必要，是因为客户机的功能、我们需要如何获得客户机的同意、谁在进行同意，这给OAuth增加了很多复杂性。
当人们问你是否支持OAuth时，你必须弄清他们的要求。他们是在问你是否支持所有六种流，还是只支持主要流？在所有不同的流之间有很多可用的粒度。
安全与企业
OAuth概念有很大的范围。使用隐式流，有很多重定向和错误空间。有很多人试图在应用程序之间利用OAuth，如果您不遵循推荐的Web Security 101准则，这很容易做到。例如：
- 始终将CSRF令牌与
状态一起使用,确保完整性的参数 - 始终使用白名单重定向URI以确保正确的URI验证
- 使用客户端ID将同一客户端绑定到授权授予和令牌请求
- 对于机密客户，确保客户机密不会泄露。不要在通过应用商店分发的应用程序中添加客户端机密！
一般来说，对OAuth最大的投诉来自安全人员。这是关于持有者令牌的，它们可以像会话cookie一样传递。你可以把它传来传去，这样就很方便了，它不受用户的加密约束。使用JWT很有帮助，因为它们不能被篡改。然而，最后，JWT只是一个字符串，因此可以很容易地被拷贝和使用在Authorization header中。
企业OAuth 2.0用例
OAuth将授权策略决策与身份验证解耦。它支持细粒度和粗粒度授权的正确混合。它可以取代传统的Web访问管理（WAM）策略。在构建可以访问特定API的应用程序时，它还可以限制和撤销权限。它确保只有受管理和/或兼容的设备才能访问特定的API。它与身份取消配置工作流进行了深度集成，以从用户或设备中吊销所有令牌。最后，它支持与身份提供者的联合。
OAuth不是身份验证协议
总结一下OAuth 2.0的一些误解：它与OAuth 1.0不向后兼容。它用HTTPS替换所有通信的签名。当人们今天谈论OAuth时，他们谈论的是OAuth 2.0。
因为OAuth是一个授权框架而不是协议，所以您可能会遇到互操作性问题。团队如何实现OAuth存在很多差异，您可能需要自定义代码来与供应商集成。
OAuth 2.0不是身份验证协议。它甚至在其文档中已经说明.
我们一直在讨论委托授权。这与认证用户无关，这是关键。光是OAuth 2.0一点也不涉及用户。您只有一个令牌来访问资源。
在过去几年中，OAuth发生了大量的添加。这些增加了OAuth之上的复杂性，以完成各种企业场景。例如，JWT可以用作可签名和加密的互操作令牌。
OAuth 2.0的伪身份验证
使用OAuth登录因脸书连接和推特而闻名。在此流中，客户端访问 /me 具有访问令牌的端点。它所说的只是客户端可以使用令牌访问资源。人们创造了这个假端点，作为使用访问令牌获取用户配置文件的方法。这是获取用户信息的非标准方式。标准中没有规定每个人都必须实现这个端点。访问令牌是不透明的。它们是为API设计的，不是为包含用户信息而设计的。
您真正想通过身份验证回答的是 用户是谁，用户什么时候进行了身份验证，以及用户怎样进行了身份验证。您通常可以使用SAML断言来回答这些问题，而不是使用访问令牌和授权授予。这就是为什么我们称之为伪身份验证。
输入OpenID Connect
为了解决伪身份验证问题，将OAuth 2.0、Facebook Connect和SAML 2.0的最佳部分组合在一起，以创建OpenID连接.OpenID Connect（OIDC）使用新的签名id_token扩展了OAuth 2.0, 对于客户和UserInfo获取用户属性的端点。与SAML不同，OIDC为身份提供了一组标准的范围和声明。示例包括：profile, email, address, and phone.
OIDC通过使事物完全动态化而被创建为可扩展的互联网。不再像SAML要求的那样下载元数据和联合。动态联合体有内置的注册、发现和元数据。你可以输入你的电子邮件地址，然后它会动态发现你的OIDC提供者，动态下载元数据，动态知道要使用什么证书，并允许BYOI（带上你自己的身份,Bring Your Own Identity）。它支持企业的高保证级别和关键SAML用例。
OIDC因谷歌和微软这两公司早期大范围采用者而闻名。Okta也对OIDC进行了大量投入。
初始请求中的所有更改都是它包含标准作用域（如openid和email):
| 请求 | GET https://accounts.google.com/o/oauth2/auth? scope=openid email& redirect_uri=https://app.example.com/oauth2/callback& response_type=code& client_id=812741506391& state=af0ifjsldkj |
| 响应 | HTTP/1.1 302 Found Location: https://app.example.com/oauth2/callback? code=MsCeLvIaQm6bTrgtp7&state=af0ifjsldkj 这个返回的是授权code和 |
令牌的授权授予响应包含一个ID令牌。
| 请求 | POST /oauth2/v3/token HTTP/1.1
Host: www.googleapis.com
Content-Type: application/x-www-form-urlencoded
code=MsCeLvIaQm6bTrgtp7&client_id=812741506391&
client_secret={client_secret}&
redirect_uri=https://app.example.com/oauth2/callback&
grant_type=authorization_code |
| 响应 | {
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ..."
} |
您可以看到，这是在OAuth之上很好地分层的，以将ID令牌作为结构化令牌返回。ID令牌是JSON Web令牌（JWT）。JWT（又名“jot”）比基于XML的大型SAML断言小得多，可以在不同设备之间高效传递。JWT由三部分组成：header标题、body正文和signature签名。标题header说明了签名时使用的算法algorithm，声明claims在正文body中，签名在signature中。
Open ID Connect流包括以下步骤：
- 发现OIDC元数据
- 执行OAuth流以获取id令牌和访问令牌
- 获取JWT签名密钥并可选地动态注册客户端应用程序
- 根据内置日期和签名在本地验证JWT ID令牌
- 根据需要使用访问令牌获取其他用户属性
OAuth+Okta
Okta最著名的是它的单点登录服务，它允许您对每天使用的应用程序进行无缝身份验证。但是你知道Okta也有一个很棒的开发平台吗？安全单点登录通常使用SAML作为首选协议，但Okta还提供了几个其他选项，包括登录小部件、Auth-SDK（基于JavaScript的库）、社交登录和任何客户端的身份验证API。
请参见Okta的OIDC/OAuth 2.0 API有关我们如何支持OAuth的具体信息。
SAML由Okta及其SSO芯片实现。如果你像我一样是Okta的客户，你可能会使用以下内容与大多数应用程序交互https://okta.okta.com/app/UserHome。当你点击一个chiclet时，我们会发送一条消息，对断言进行签名，在断言中会显示用户是谁，以及它来自Okta。在上面打上数字签名，你就可以开始了。
OAuth 2.0摘要
OAuth 2.0是一个授权框架，用于委托访问API。它涉及请求资源所有者授权/同意的作用域的客户端。授权授予被交换为访问令牌和刷新令牌（取决于流）。有多个流来处理不同的客户端和授权场景。JWT可用于授权服务器和资源服务器之间的结构化令牌。
OAuth具有非常大的security surface area。确保使用安全的工具箱并验证所有输入！
OAuth不是身份验证协议。OpenID Connect为身份验证场景扩展了OAuth 2.0，通常称为“带花括号的SAML”。如果您希望深入了解OAuth 2.0，我建议您查看OAuth.com网站，以Okta的AuthSDK为例，自己尝试OAuth流。
4万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
