oauth oauth2(OAuth2.0),本文通过数据整理汇集了oauth oauth2(OAuth2.0)相关信息，下面一起看看。

结论如果OAuth2对您来说仍然是一个模糊的概念，或者您只是想确保您理解它的行为，那么这篇文章应该会让您感兴趣。

什么是OAuth2？你猜对了，OAuth2是OAuth协议的第二版(也叫框架)。

该协议允许第三方应用程序代表资源所有者或通过允许第三方应用程序代表自己获得访问权限来授予对超文本传送协议服务的有限访问权限。客户端请求访问，例如，它可以是网站或移动应用程序。

版本2有望简化前一版本的协议，并促进不同应用程序之间的互操作性。

规范仍在起草中，协议也在不断发展，但这并不妨碍它被几个互联网巨头如谷歌或脸书所实施和称赞。

基础知识角色授权2定义了4个角色：

资源拥有者：一般是你自己。资源服务器：托管受保护数据的服务器(例如，谷歌托管您的个人资料和个人信息)。客户端：请求访问资源服务器的应用程序(可以是您的服务器端编程语言（Professional Hypertext Preprocessor的缩写）网站、Javascript应用程序或移动应用程序)。授权服务器：向客户端发布访问令牌的服务器。这个令牌将用于客户端请求资源服务器。这个服务器可以与授权服务器相同(相同的物理服务器和相同的应用程序),这种情况经常发生。令牌是由授权服务器生成的随机字符串，在客户端请求时发出。

有两种类型的令牌：

访问令牌：这是最重要的，因为它允许第三方应用程序访问用户数据。客户机将这个令牌作为参数或请求中的头发送给资源服务器。它有一个有限的生命周期，由授权服务器定义。它必须尽可能地保密，但是我们将会看到这并不总是可能的，特别是当客户端是通过java描述语言向资源服务器发送请求的网浏览器时。刷新令牌：这个令牌是与访问令牌一起发出的，但与后者不同的是，它不是在从客户机到资源服务器的每个请求中发送的。它仅用于在访问令牌到期时被发送到授权服务器以更新访问令牌。出于安全原因，并不总是能够获得这个令牌。我们稍后会看到在什么情况下。访问令牌范围范围是用于限制访问令牌权限的参数。这是定义可用作用域列表的授权服务器。然后，客户端必须在请求授权服务器的过程中发送他希望应用程序使用的范围。范围缩小得越多，资源所有者授权访问的机会就越大。

更多信息：#第3.3节。

HTTPSOAuth2要求使用HTTPS在客户端和授权服务器之间进行通信，因为敏感数据在两者之间传递(令牌和可能的资源所有者凭证)。事实上，如果您实现了自己的授权服务器，您并不一定要这样做，但是您必须知道这样做会打开一个很大的安全漏洞。

注册为客户端因为您希望使用OAuth2从资源服务器检索数据，所以您必须注册为授权服务器的客户端。

每个提供者可以通过自己选择的方法自由地允许这样做。该协议只定义了必须由客户端指定的参数和授权服务器返回的参数。

以下是参数(可能因提供商而异):

客户端注册应用程序名称：应用程序名称重定向网址：用于接收授权代码和访问令牌的客户端的统一资源定位器授权类型：客户端将使用的授权类型java描述语言源(可选):将被允许通过XMLHttpRequestAuthorization服务器响应客户端Id:唯一随机字符串客户端机密：必须保密的密钥更多信息：RFC 6749 —客户端注册。

授权授权类型根据获取访问令牌所涉及的客户端的位置和性质，Auth2定义了4种授权类型。

授权码应该在什么时候使用？只要客户端是网服务器，就应该使用它。它允许您获得一个长期的访问令牌，因为它可以用一个刷新令牌来更新(如果授权服务器允许的话)。

示例：资源所有者：您的资源服务器：谷歌服务器客户端：任何网站授权服务器：谷歌服务器场景：某个网站想要获取有关您的谷歌个人资料的信息。客户端(网站)会将您重定向到授权服务器(谷歌).如果您授权访问，授权服务器会在回调响应中向客户端(网站)发送一个授权码。然后，根据客户端和授权服务器之间的访问令牌交换该代码。网站现在可以使用这个访问令牌来查询资源服务器(再次使用谷歌)并检索您的个人资料数据。您永远看不到访问令牌，它将由网站存储(例如在会话中)。谷歌还随访问令牌发送其他信息，比如令牌生命周期和最终的刷新令牌。

这是理想的场景，也是更安全的场景，因为访问令牌不在客户端传递(在我们的例子中是网浏览器)。

更多信息：RFC 6749 —授权码授权。

序列图：

什么时候应该使用隐式授权？当客户端在使用脚本语言(如Javascript)的浏览器中运行时，通常会使用它。此授权类型不允许发行刷新令牌。

示例：资源所有者：您的资源服务器：脸书服务器客户端：例如使用安古拉吉斯的网站授权服务器：脸书服务器场景：客户端(角度)想要获取有关您的脸书配置文件的信息。浏览器会将您重定向到授权服务器(脸书)。如果您授权访问，授权服务器会使用上呼吸道感染片段中的访问令牌将您重定向到网站(不会发送到网服务器)。回调示例：/oauthcallback # access _ token=mzjmndc 3m 2 vjmmqzn .客户端(角度)现在可以检索并使用这个访问令牌来查询资源服务器(脸书)。查询示例：/我？access_token=MzJmNDc3M2VjMmQzN .也许您想知道客户端如何用java描述语言调用脸书应用程序界面而不会因为同源策略而被阻止？这个跨域请求是可能的，因为脸书通过响应中的一个名为访问控制允许来源的头对它进行了授权。

关于跨源资源共享的更多信息(CORS):https://开发商。Mozilla。org/en-US/docs/HTTP/Access _ control _ CORS # The _ HTTP _ response _ headers .

立正!只有在没有其他类型的授权可用时，才应该使用这种类型的授权。事实上，它是最不安全的，因为访问令牌暴露在客户端(因此容易受到攻击)。

更多信息：RFC 6749 —隐式授权。

序列图：

应该在何时使用授予的资源所有者密码凭据？使用这种类型的授权，凭证(以及密码)被发送到客户端，然后发送到授权服务器。因此，这两个实体之间必须有绝对的信任。它主要用于客户端由与授权服务器相同的授权机构开发的情况。例如，我们可以想象一个名为的网站寻求访问其自己的子域美国石油学会(American Petroleum Institute)的受保护资源.用户在网站上键入他的登录名/密码不会感到惊讶，因为他的帐户是在网站上创建的。

示例：资源所有者：您在Acme公司的acme.com网站上有一个帐户资源服务器：Acme公司在API。极致。com上公开其应用程序界面客户端：Acme公司的acme.com网站授权服务器：极致服务器场景：Acme公司做得很好，被认为向第三方应用程序提供了RESTful API .这家公司认为使用自己的应用程序界面可以避免重复劳动。公司需要一个访问令牌来调用它自己的应用程序界面的方法。为此，公司要求您像往常一样通过标准超文本标记语言表单输入您的登录凭据。服务器端应用程序(网站acme.com)将根据来自授权服务器的访问令牌交换您的凭据(当然，前提是您的凭据有效)。这个应用程序现在可以使用访问令牌来查询它自己的资源服务器(api.acme.com).更多信息：RFC 6749 —资源所有者密码凭证授权。

序列图：

客户端凭据授予应该在何时使用？当客户端本身是资源所有者时，使用这种类型的授权。没有从最终用户处获得的授权。

示例：资源所有者：任何网站资源服务器：谷歌云存储客户端：资源所有者授权服务器：谷歌服务器场景：网站将其任何类型的文件存储在谷歌云存储中。网站必须通过谷歌应用编程接口来检索或修改文件，并且必须通过授权服务器的认证。通过身份验证后，网站将获得一个访问令牌，现在可以使用它来查询资源服务器(谷歌云存储)。在这里，最终用户不必授权访问资源服务器。

更多信息：RFC 6749 —客户端凭证授权。

序列图：

访问令牌用法访问令牌可以通过多种方式发送到资源服务器。

使用得到的请求参数(获取或帖子)示例：https://api ./个人资料？access_token=MzJmNDc3M2VjMmQzN

这并不理想，因为令牌可以在网服务器的访问日志中找到。

授权头GET /profile HTTP/1.1Host: api .授权：无记名MzJmNDc3M2VjMmQzN

这很优雅，但是所有的资源服务器都不允许这样做。

安全性授权2有时因其渗透性而受到批评，但这通常是由于协议的糟糕实现。使用它时有一些大错误要避免，这里有一些例子。

授权代码授予中的漏洞此流中存在一个漏洞，使得攻击者能够在特定条件下窃取用户的帐户。这个漏洞是经常遇到的，也是很多已知的网站(比如Pinterest，SoundCloud，Digg，…)没有正确实现这个流程。

示例：您的受害者在一个名为英语字母表中第一个字母的网站上拥有一个有效帐户A网站允许用户登录或注册脸书，并且之前在脸书OAuth2授权服务器中注册为客户端。你点击网站英语字母表中第一个字母的脸书连接按钮，但由于Firefox NoRedirect插件或使用打嗝，你没有跟随重定向(回调看起来像这样：/facebook/login？code=ogi 2 nmy 2 njyx N2 4 yze 3).您将获得将被重定向到的网址(包含授权代码)(在萤火虫中可见)。现在，你必须迫使受害者通过网站上隐藏的内联框架或电子邮件中的图片来访问这个url .如果受害者登录网站一，头奖!现在，您可以使用您的脸书帐户访问受害者在网站英语字母表中第一个字母中的帐户。你只需点击脸书连接按钮，你将与受害者的帐户连接。解决方法：有一种方法可以通过添加“国家”参数来防止这种情况。规范中仅推荐而非要求后者。如果客户端在请求授权码时发送此参数，则授权服务器将在响应中不加更改地返回此参数，并且在授权码与访问令牌交换之前，客户端将对此参数进行比较。该参数通常与存储在用户会话中的随机数的唯一散列相匹配。比如PHP: sha1(uniqid(mt_rand()，true)).

在我们的示例中，如果网站英语字母表中第一个字母使用参数“国家”，他将在回调中意识到哈希与受害者会话中存储的哈希不匹配，从而防止受害者帐户被盗。

更多信息：RFC 6749跨站点请求伪造。

隐式授权中的漏洞这种类型的授权是所有授权中最不安全的，因为它将访问令牌暴露给客户端(大多数情况下是Javascript).有一个普遍存在的漏洞，它源于客户端不知道访问令牌是否是为他生成的(混淆的代理问题)。这使得攻击者能够窃取用户帐户。

示例：攻击者旨在窃取受害者在网站一上的帐户。该网站允许您通过您的脸书帐户连接，并使用隐式授权。攻击者创建了一个网站b，也允许通过脸书登录。受害者用他的脸书账户登录到网站b，因此隐含地授权为此生成访问令牌。攻击者通过他的网站英语字母表的第2个字母获得访问令牌，并通过修改上呼吸道感染片段中的访问令牌在网站英语字母表中第一个字母上使用它。如果网站英语字母表中第一个字母无法抵御这种攻击，受害者的帐户就会受到威胁，攻击者现在就可以访问它。解决方法：为了避免这种情况，授权服务器必须在其应用程序界面中提供一种检索访问令牌信息的方法。因此，网站英语字母表中第一个字母能够将攻击者的访问令牌的客户端身份证明（identification）与其自己的客户端身份证明（identification）进行比较。由于被盗的访问令牌是为网站英语字母表的第2个字母生成的，因此客户端id将不同于网站英语字母表中第一个字母的客户端id，并且连接将被拒绝。

谷歌在其应用程序界面文档中对此进行了描述：https://开发者。谷歌。com/accounts/docs/oauth 2登录#验证令牌.

请求评论中的更多信息：

点击劫持这种技术允许攻击者通过将授权页面隐藏在透明的内联框架中，并让受害者单击授权页面"允许"按钮上方的链接来进行欺骗。

示例：

解决方法：为了避免这种情况，授权服务器必须在授权页面上返回一个名为x-框架-选项的头，其值为否认或同源.这可以防止授权页面显示在内联框架中(否认)，或者要求主页的域名与iframe"src "属性(同源)中指定的域名保持一致。

这个标头不是标准的，但在以下浏览器中受支持：IE8、Firefox3.6.9、Opera10.5、Safari4、Chrome 4.1.249.1042。

更多信息：https://developer . Mozilla . org/en-US/docs/HTTP/X-Frame-Options。

这里是RFC，列出了协议实现中的潜在漏洞和对策：

结论不管你喜不喜欢，OAuth2似乎多年来一直是不同应用程序之间授权的标准解决方案。

无论如何，我希望我已经帮助您理解了它的工作方式。我们将在另一篇文章中看到如何用Symfony2创建自己的OAuth2授权服务器。

抱歉，我的英语很糟糕。

本站是提供个人知识管理的网络存储空间，所有内容均由用户发布，不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息，谨防诈骗。如发现有害或侵权内容，请点击一键举报。

更多oauth oauth2(OAuth2.0)相关信息请关注本站，本文仅仅做为展示！