什么是OAuth（开放授权）？
什么是OAuth（开放授权）？
我从中收集了一些信息
- OAuth的
- Twitter教程：什么是OAuth及其对您意味着什么
- 什么是OAuth
- 什么是OAuth，你为什么要关心
但我想学习和了解更多。 我正在寻找生命周期的信息。 为什么大部分社交networking都依赖这个开放协议？
它将在不久的将来成为事实上的各种技术（如ASP.NET）？
什么是OAuth（开放授权）？
OAuth允许通知资源提供者 （例如Facebook） 资源所有者 （例如你）允许第三方 （例如Facebook应用程序）访问他们的信息 （例如你的朋友的列表）。
如果你读得清楚，我会理解你的困惑。 那么让我们来举一个具体的例子：join另一个社交networking！
假设你有一个现有的GMail帐户。 你决定joinLinkedIn。 手动添加所有你的许多朋友很烦人，而且容易出错。 您可能会半途而废，或者在电子邮件地址中插入错别字以获得邀请。 所以你可能会试图不要创build一个帐户。
面对这种情况，LinkedIn有Good Idea（TM）来编写一个程序，自动添加你的朋友列表，因为计算机在烦人和容易出错的任务中效率和效率要高得多。 既然现在joinnetworking很容易，那么你拒绝这样的提议是不可能的，现在呢？
如果没有用于交换此联系人列表的API，则必须将LinkedIn用户名和密码提供给您的GMail帐户，从而为其提供太多的权力 。
这就是OAuth所在的地方。如果你的GMail支持OAuth协议，那么LinkedIn可以要求你授权他们访问GMail的联系人列表。
OAuth允许：
- 不同的访问级别：只读VS读写。 这使您可以授予访问您的用户列表或双向访问权限，以自动将您的新LinkedIn领域的朋友同步到您的GMail联系人。
- 访问粒度：您可以决定只允许访问您的联系信息（用户名，电子邮件，出生date等）或您的整个朋友列表，日历和什么不是。
- 它允许您从资源提供者的应用程序pipe理访问。 如果第三方应用程序不提供取消访问的机制，则您将被禁止访问您的信息。 使用OAuth，可以随时撤销访问权限。
它会在不久的将来成为事实上的（标准？）吗？
那么，虽然OAuth是一个重大的进步，但如果人们不正确地使用它，它并不能解决问题。 例如，如果一个资源提供者一次只给你所有的资源一个读写访问级别，而不提供pipe理访问的机制，那么就毫无意义。 换句话说，OAuth是一个提供授权function而不仅仅是validation的框架。
实际上，它非常适合社交networking模型。 对于那些希望允许第三方“插件”的社交networking来说，它尤其受欢迎。 在这个领域，资源的获取本质上是必要的，并且本质上也是不可靠的（即，对这些应用程序的质量控制很less或根本没有）。
我在野外还没有见过这么多的其他用途。 我的意思是，我不知道有一家在线财务咨询公司能够自动访问您的银行logging，尽pipe它在技术上可以以这种方式使用。
oAuth是什么？
OAuth只是一个安全的授权协议，处理第三方应用程序授权访问用户数据而不暴露他们的密码。 例如。 （在许多网站上用fb，gPlus，twitterlogin..）都在这个协议下工作。
有关各方
当你了解有关各方时，议定书就变得容易了。 基本上有三方参与：oAuth提供者，oAuth客户端和所有者。
- oAuth客户端（希望访问您的凭证的应用程序）
- oAuth提供者（例如facebook，twitter …）
- 所有者（有facebook，twitter ..帐户的人）
怎么运行的？
我曾经假设一个网站（计算器）需要添加loginFacebookfunction的情况。 因此，Facebook是oAuth提供者，而且计算器是oAuth客户端。
-
这一步是由应用程序开发人员完成的 。 在开始的时候，facebook（oAuth Provider）不知道关于stackoverflow（oAuth客户端），因为它们之间没有链接。 所以第一步是注册Facebook 开发人员站点的 stackoverflow。 这是手动完成的，开发人员需要将应用程序的信息提供给Facebook，如应用程序名称，网站，徽标，redirectURL（重要的一个）。 然后，stackoverflow被成功注册，从facebook获得客户端ID，客户端密码等，并与OAUTH运行。
2. 现在当stackoverflow的用户点击用fbbuttonlogin 。 Stackoverflow请求Facebook与ClientId（fb用它来识别客户端）和redirectUrl（fb将在成功后返回到这个URL）。因此，用户被redirect到Facebooklogin页面。 这是最好的部分用户（所有者）不给他们的Facebook的证书到计算器。
- 所有者允许Stackoverflow访问信息 。 然后Facebookredirect回到stackoverflow，以及authcode使用第2步提供的redirectUrl。
- 然后，Stackoverflow与Facebook以及获得的授权码进行联系，确保一切正常。
- 只有这样facebook才能将访问令牌赋予给stackoverflow。 然后访问令牌被stackoverflow使用来检索所有者的信息，而不使用密码。 这是oAuth的动机，那里的credentails从未暴露在第三方的应用程序。
更多：
快速video
网站链接
简单地说，OAuth是应用程序获取信息凭据的一种方式，无需直接将您的用户login信息发送到某个网站。 例如，如果您在自己的网站上编写应用程序，并希望使用用户的Facebook帐户中的数据，则可以使用OAuth通过callbackURL获取令牌，然后使用该令牌调用Facebook API以获取他们的直到令牌过期才使用数据。 网站依赖于它，因为它允许程序员访问他们的数据，用户不必直接透露他们的信息，并在网上传播他们的凭据，但仍然提供一定程度的数据保护。 它会成为事实上的授权方法吗？ 也许，最近从Twitter，Facebook以及其他程序员想要在用户数据周围构build应用程序的喜好获得了很多支持。
Oauth正在获得势头，并在企业级API中stream行起来。 在应用程序和数据驱动的世界中，企业越来越多地将API暴露在外部，与Google，Facebook，Twitter一致。 随着这一发展，一个三方authentication的三angular形形成
1）API提供者 – 通过API公开其资产的任何企业，例如Amazon，Target等2）开发者 – 通过该API构build移动/其他应用程序的人3）最终用户 – 说亚马逊的注册/访客用户
现在，这就形成了一个与安全相关的情况 – （我列举了其中一些复杂性）1）作为最终用户，您希望允许开发人员代表您访问API。 2）API提供者必须authentication开发者和最终用户3）最终用户应该能够授予和撤销授予他们的同意权限4）开发者可以对API提供者具有不同级别的信任，其中给予她的权限级别是不同的
Oauth是一个授权框架，试图以标准的方式解决上述问题。 随着API和应用程序的突出，这个问题将变得越来越相关，任何试图解决它的标准（无论是其他标准）都将作为API提供者/开发者甚至最终用户来关注。
当我们使用Facebook / Googlebutton注册SO账户时，
OAuth发生了。
- 应用程序（SO）将用户redirect到提供者的授权URL。 （显示一个网页，询问用户是否希望授予应用程序访问权限以读取和更新其数据）。
- 用户同意授予申请程序。
- 服务提供商将用户redirect回应用程序（SO），传递授权码作为参数。
- SO交换访问授权的代码。
来源： OAuth1服务提供商
OAuth是一个开放的授权标准，通常用于互联网用户使用他们的微软，Google，Facebook或Twitter账号login第三方网站而不暴露他们的密码。
