OAuth是Resource Owner(facebook，谷歌，tweeter, microsoft live等)使用的协议，用于提供所需的信息，或为第三方系统(例如您的站点)提供写入成功的许可。最有可能的是，如果没有OAuth协议，第三方系统应该可以使用凭据，这将是这些系统之间不合适的通信方式。

究竟什么是OAuth(开放授权)?

OAuth允许通知资源提供者(例如Facebook)，资源所有者(例如您)授予第三方(例如Facebook应用程序)访问他们的信息(例如您的朋友列表)的权限。

如果你看清楚了，我就能理解你的困惑了。让我们举一个具体的例子:加入另一个社交网络!

假设您有一个现有的Gmail帐户。你决定加入领英。手动添加你所有的朋友是很烦人的，而且容易出错。你可能中途就厌倦了，或者在邀请函的电子邮件地址中插入了错别字。所以你可能会忍不住不去创建一个账户。

面对这种情况，LinkedIn™有一个好主意，写了一个程序，自动添加你的朋友名单，因为电脑在无聊和容易出错的任务上要有效率得多。既然现在加入网络是如此容易，你不可能拒绝这样的提议，对吧?

如果没有API来交换这个联系人列表，你将不得不把你的Gmail帐户的用户名和密码交给领英，从而给了他们太多的权力。

这就是OAuth的用武之地。如果您的GMail支持OAuth协议，那么LinkedIn可以要求您授权他们访问您的GMail联系人列表。

OAuth允许:

Different access levels: read-only VS read-write. This allows you to grant access to your user list or bi-directional access to automatically synchronize your new LinkedIn friends to your Gmail contacts. Access granularity: you can decide to grant access to only your contact information (username, e-mail, date of birth, etc.) or to your entire list of friends, calendar and whatnot. It allows you to manage access from the resource provider's application. If the third-party application does not provide a mechanism for canceling access, you would be stuck with them having access to your information. With OAuth, there is a provision for revoking access at any time.

在不久的将来，它会成为事实上的标准吗?

虽然OAuth是向前迈出的重要一步，但如果人们不正确使用它，它就不能解决问题。例如，如果资源提供者一次只对所有资源提供一个读写访问级别，而不提供管理访问的机制，那么就没有指向它的点。换句话说，OAuth是一个提供授权功能而不仅仅是身份验证的框架。

在实践中，它非常符合社会网络模型。对于那些希望允许第三方“插件”的社交网络来说，它尤其受欢迎。在这个领域中，访问资源本身是必要的，同时也是不可靠的(例如，您对这些应用程序几乎或根本没有质量控制)。

我在野外还没见过这么多其他用途。我的意思是，我不知道有哪家在线金融咨询公司会自动访问你的银行记录，尽管技术上可以这样使用。

OAuth是一种开放的授权标准，通常用于互联网用户使用微软、谷歌、Facebook或Twitter账户登录第三方网站而不暴露密码。

OAuth发生时，我们注册SO帐户与Facebook/谷歌 按钮。

应用程序(SO)将用户重定向到提供者的授权URL。(显示一个网页，询问用户是否希望授予应用程序读取和更新数据的访问权限)。 用户同意授予应用程序。 服务提供者将用户重定向回应用程序(SO)，将授权代码作为参数传递。 SO用代码交换访问权限。

来源:OAuth1服务提供者

Oauth无疑正在获得动力，并在企业api中变得流行起来。 在应用程序和数据驱动的世界里，企业越来越多地向外部世界公开api，就像谷歌、Facebook、twitter一样。 随着这种发展，身份验证的三向三角就形成了

1) API提供商——任何通过API公开其资产的企业，比如亚马逊、Target等 2)开发人员-通过此api构建移动/其他应用程序的人 3)最终用户-由亚马逊的注册用户/客座用户提供的服务的最终用户

现在这发展了一个与安全相关的情况-(我列出了这些复杂性中的一些) 1)作为终端用户，您希望允许开发人员代表您访问api。 2) API提供者必须验证开发人员和最终用户 3)最终用户应该能够授予和撤销他们所给予的同意的权限 4)开发人员可以对API提供者有不同的信任级别，其中给予她的权限级别是不同的

Oauth是一个试图以标准的方式解决上述问题的授权框架。随着API和应用程序的突出，这个问题将变得越来越重要，任何试图解决这个问题的标准——无论是外部的还是其他的——都将成为API提供商/开发人员甚至最终用户所关心的事情!

OAuth是什么?

OAuth只是一个安全的授权协议，用于处理第三方应用程序的授权，以便在不暴露用户密码的情况下访问用户数据。(例如，在许多网站上登录Facebook, gPlus, Twitter)都在此协议下工作。

各方

当你了解有关各方时，议定书就变得更容易了。基本上，涉及到三个方面:OAuth提供者、OAuth客户端和所有者。

OAuth客户端(想要访问您的凭据的应用程序) OAuth提供者(例如;Facebook, Twitter等) 所有者(拥有Facebook、Twitter等账户的人)

工作原理

我假设了一个场景，一个网站(Stack Overflow)需要添加一个登录与Facebook功能。因此，Facebook是OAuth提供者，Stack Overflow是OAuth客户端。

This step is done by the app's developer. At the very beginning, Facebook (OAuth Provider) has no idea about the Stack Overflow (OAuth Client) because there is no link between them. So the very first step is to register Stack Overflow with Facebook developers site. This is done manually where developers need to give the app's information to Facebook like the app's name, website, logo, redirectUrl (important one). Then Stack Overflow is successfully registered, has got client Id, client secret, etc from Facebook, and is up and running with OAuth.

现在当Stack Overflow的用户点击登录Facebook按钮。Stack Overflow请求Facebook使用ClientId (Facebook使用它来识别客户端)和redirectUrl(成功后Facebook将返回此URL)。因此，用户被重定向到Facebook登录页面。这是最好的部分，用户(所有者)不会把他们的Facebook凭证给Stack Overflow。

After Owner allows Stack Overflow to access the information. Then Facebook redirects back to Stack Overflow, along with authcode using the redirectUrl provided at step 2. Then Stack Overflow contacts Facebook along with the obtained authcode to make sure everything is okay. Only then Facebook will give access token to Stack Overflow. Then access token is used by Stack Overflow to retrieve the owner's information without using a password. This is the whole motive of OAuth, where actual credentials are never exposed to third-party applications.

更多信息:

快速视频

网页链接