oauth0 oauth2_OAuth需要死于大火

oauth0 oauth2

As a personal project I’ve recently been looking into creating a small Twitter client in Objective-C/Cocoa. This is largely because I quite like Objective-C as a language and haven’t had the chance to write anything significant in it, but also partly because Twitter have made the news recently with their API nuttiness and I wanted to play around with it.

作为个人项目，我最近一直在寻求在Objective-C / Cocoa中创建一个小型Twitter客户端。 这主要是因为我非常喜欢Objective-C作为一种语言，并且没有机会编写任何重要的语言，而且部分原因是Twitter最近以其API特有的方式发布了新闻 ，并且我想尝试使用它。

So, I surfed over to the Twitter API docs to take a look at how to implement the API. After reading and playing with the API for a few days I’ve got some quite strong opinions on various parts of it (few of them good), but far and away the defining characteristic of my investigation of the API is OAuth.

因此，我浏览了Twitter API文档 ，以了解如何实现API。 在阅读并使用API​​几天后，我对API的各个部分都有了很强的见解（很少有好的），但是我对API进行研究的定义特征无疑是OAuth。

OAuth背景 (OAuth Background)

Of course, I’ve read stuff about OAuth before, so I knew before I got started that it was highly controversial. As a result, my natural reflex was to avoid OAuth if possible. A cursory reading of the API docs, however, shows that Twitter pretty aggressively rate-limit calls to the API: 100 requests per hour for non-authenticated users, 350 for authenticated ones. As a result, I was definitely going to have to authenticate, and OAuth is their authentication of choice.

当然，我之前已经阅读过有关OAuth的文章，所以在开始之前我就知道这是有争议的。 结果，我的自然React是尽可能避免使用OAuth。 但是，粗略地阅读API文档会显示Twitter非常激进地限制对API的调用：未经身份验证的用户每小时100个请求，经过身份验证的用户每小时350个请求。 结果，我肯定要进行身份验证，而OAuth是他们选择的身份验证。

This meant I’d have to use OAuth. Here, my problems began.

这意味着我必须使用OAuth。 在这里，我的问题开始了。

我讨厌OAuth (I Hate OAuth)

Firstly, I had to familiarise myself with the OAuth authentication flow. It turns out that this is nothing like as simple as I’d like it to be. To explain why, I need to make sure you’re familiar with the niche OAuth is intended to fill.

首先，我必须熟悉OAuth身份验证流程。 事实证明，这并不像我希望的那么简单。 为了解释原因，我需要确保您熟悉OAuth旨在填补的空白。

The purpose of OAuth is to be able to provide applications with access to your account without giving them your password. This apparently simple notion ends up being really quite complicated. In short, to achieve this, OAuth requires that you perform the following steps.

OAuth的目的是能够为应用程序提供对您帐户的访问权限，而无需提供密码。 这个看似简单的概念最终变得非常复杂。 简而言之，要实现此目的，OAuth要求您执行以下步骤。

1. Register your application with your OAuth provider (in this case Twitter), and obtain from them your Consumer Key and Consumer Secret.
2. When the customer starts up your application for the first time, send a request to a URL provided by the OAuth provider with various OAuth headers set in the HTTP, including your consumer key and secret. Some providers (hello again Twitter!) also require you to set custom headers. This caused me some unrelated difficulty. This procedure should return an OAuth response that provides a ‘request token’.
3. Send your user to a URL, along with the request token, to ask the user to authenticate your application. For desktop applications, this involves some bizarre out-of-band procedure involving PINs. At least Cocoa makes this part easy. The user is required to log in.
4. This will either cause a callback to a different URL, or the user will return to your application to input the PIN (or whatever out-of-band weirdness your OAuth provider uses).
5. Now you need to make another web request (yes, really) to the OAuth provider, this time to get an authorisation token. This token can be stored away (e.g. in the OS X keychain), and has to be used to sign all subsequent requests to the API.

1. 向OAuth提供商（在本例中为Twitter）注册您的应用程序，并从他们那里获取您的使用者密钥和使用者密钥。
2. 客户首次启动您的应用程序时，将请求发送到OAuth提供程序提供的URL，该URL具有HTTP中设置的各种OAuth标头，包括您的使用者密钥和机密。 某些提供程序（再次为Twitter，您好！）也要求您设置自定义标头。 这给我带来了一些无关的困难 。 此过程应返回提供“请求令牌”的OAuth响应。
3. 将您的用户与请求令牌一起发送到URL，以要求用户对您的应用程序进行身份验证。 对于桌面应用程序，这涉及一些涉及PIN的奇怪的带外过程。 至少可可使这部分变得容易。 要求用户登录。
4. 这将导致回调到另一个URL，或者用户将返回到您的应用程序以输入PIN（或您的OAuth提供程序使用的任何带外怪异）。
5. 现在，您需要向OAuth提供者提出另一个Web请求（是的），这是一次获取授权令牌。 该令牌可以存储起来（例如，在OS X钥匙串中），并且必须用于对API的所有后续请求进行签名。

Keeping track, that’s three web requests to obtain an authorisation token. Additionally, for desktop apps, the user is required to context shift to a web browser in order to authorise the application. This is a serious set of disadvantages.

跟踪，这是三个Web请求以获取授权令牌。 此外，对于桌面应用程序，要求用户上下文切换到Web浏览器以授权该应用程序。 这是一系列严重的缺点。

Here’s the thing: it’s really not worth it. Yes, we don’t have to put password security in the hands of application developers, which is a huge advantage. Yes, we don’t transfer the password information with each request, which is an advantage.

事情是这样的：这真的不值得。 是的，我们不必将密码安全性交给应用程序开发人员，这是一个巨大的优势。 是的，我们不会在每次请求时都传送密码信息，这是一个优势。

Here’s the thing: it’s way too hard to get working. OAuth libraries are a pain in the ass to write, and I don’t think I’ve encountered one yet that functions perfectly. Additionally, the standard is a nightmare. The RFC for OAuth 1 is 35 pages long, and the lead author on the OAuth 2 standard has actually withdrawn his name from the spec. This complexity makes it almost impossible to guarantee how any single OAuth implementation will behave, which makes very close reading of the relevant API docs a must. Indeed, a subtle mis-reading of Twitter’s API documentation cost me nearly a day of work single-stepping through code execution when the error turned out to be in one of the HTTP headers instead.

事情就是这样：工作太困难了。 OAuth库编写起来很麻烦，我想我还没有遇到过功能完善的库。 此外，标准是一场噩梦。 OAuth 1的RFC 长35页 ，OAuth 2标准的主要作者实际上已经从规范中撤回了他的名字 。 这种复杂性使得几乎不可能保证任何单个OAuth实现的行为方式，这使得必须非常仔细地阅读相关的API文档。 确实，对Twitter API文档的细微误读使我花了整整一天的时间单步执行代码，而错误却出在了HTTP标头之一中。

It seems as though the complexity associated with OAuth must be unnecessary. I am not a serious big-time web developer, and one of those people might be better placed to judge the difficulty of the task, but I can’t help but feel that there must be an easier way to achieve this. Certainly OAuth adds a number of points of failure and a stunning quantity of boilerplate code.

似乎与OAuth相关的复杂性一定是不必要的。 我不是一个认真的大型Web开发人员，也许其中一个人可以更好地判断任务的难度，但是我不禁感到必须有一种更简单的方法来实现这一目标。 当然，OAuth增加了许多故障点和大量的样板代码。

It also discourages casual API exploration. When deciding whether or not I am going to use an API for the first time, I usually fire up a Python shell, import requests and start wandering through the API. OAuth adds some significant hurdles to this process. I need to work out how to obtain my authorised token with which I will sign my subsequent requests, and there are some bugs present in the OAuth implementation in Requests that have not yet been ironed out. (Shameless plug: do you know lots about OAuth? If so, come help us out!)

它还不鼓励随意的API探索。 在决定是否初次使用API​​时，通常会启动Python Shell， import requests并开始在API中徘徊。 OAuth为该过程增加了一些重要的障碍。 我需要弄清楚如何获取我的授权令牌，以便使用它来签名后续的请求，并且OAuth实施中的一些错误尚未解决。 （无耻的插件：您对OAuth了解很多吗？如果是，请帮助我们 ！）

All of this means that I am less inclined to use your API. I can’t be the only person who thinks this when they encounter an OAuth-based API, and as a result it is certainly possible that many developers who could have written killer apps for a service have called it quits early. This is a terrible shame.

所有这些意味着我不太愿意使用您的API。 当遇到基于OAuth的API时，我不是唯一想到这一点的人，因此，肯定有很多本可以为服务编写杀手级应用程序的开发人员称其过早退出。 这真是太可惜了。

修理它 (Fix It)

翻译自: https://www.pybloggers.com/2012/08/oauth-needs-to-die-in-a-fire/

oauth0 oauth2