The requirement for client credentials in implementations of OAuth produces a couple practical problems.
OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC [ietf.org]:
In many cases, the client application will be under the control of potentially untrusted parties. For example, if the client is a desktop application with freely available source code or an executable binary, an attacker may be able to download a copy for analysis. In such cases, attackers will be able to recover the client credentials.
Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.
If a deployed app cannot keep the secret confidential, such as Javascript or native apps, then the secret is not used. [...] mobile apps must also use an OAuth flow that does not require a client secret.
Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public [nelhage.com]. There are two workarounds, both cumbersome:
The first, recommended by OAuth 1 spec author Dick Hardt [stackoverflow.com], is to proxy all API calls through a server that the app developer operates. The API keys then never leave this server. Yet the app developer needs to find some way to recover the cost of operating this proxy server.
The other, as recommended by Raffi Krikorian [google.com] and Chris Steipp [gmane.org], requires each user to register with the service provider as a developer, obtain API credentials through the developer console, and enter those into the user's own copy of the application. Because providers tend to refuse to offer a means of automating application registration, each application has to include a walkthrough for registering a copy of an application and update this walkthrough whenever the service provider changes the design of the developer console. In addition, developer consoles tend to require a minimum age of 18 to rather than 13.
OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.
But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge, no major provider implements it.
It seems like a good way is to simply assume your keys have a short lifetime (perhaps a few days), and obtain new ones on expiry.
Twitter's reply was phrased such that Twitter would ban the developer from creating new keys if it has to expire the new keys because the new keys leaked.
The cost of living is going up, and the chance of living is going down.
Client credentials are a roadblock (Score:5, Informative)
The requirement for client credentials in implementations of OAuth produces a couple practical problems.
OAuth 1 and OAuth 2 are unrelated protocols with similar names. The spec for each discourages servers from requiring client credentials (a client ID and client secret) in an API intended for use in an app that runs on the user's computer, such as a desktop or mobile app. As stated in section 4.6 of the OAuth 1 RFC [ietf.org]:
Likewise section 9 of the OAuth 2 RFC [ietf.org]:
And the article "OAuth 2 Simplified" by Aaron Parecki [aaronparecki.com] states:
Yet several service providers offering APIs built on OAuth 1 or OAuth 2, notably Twitter, require them. Despite it being trivial to pull client credentials out of an executable with tools such as strings, Twitter has been known to disable any client credentials that leak to the public [nelhage.com]. There are two workarounds, both cumbersome:
OpenID 2.0, an authentication protocol, did not require relying parties to obtain client credentials. It was intended that a user would paste his identifier URI into a form on the relying party's web site (or use a browser extension to autofill it), and the user would be briefly redirected to the identity provider's web site for verification. Very few identity providers required relying parties to register; the only one I could think of was PayPal.
But unlike OpenID 2.0, which was open by default, the OAuth 2-based OpenID Connect is closed by default. It requires each relying party to obtain client credentials from each identity provider's developer console, which requires O(n^2) contract executions. There's theoretically a way for a relying party to obtain client credentials automatically, called Dynamic Client Registration (dyn-reg), but to my knowledge, no major provider implements it.
Re: (Score:2)
That's quite sad. It seems like a good way is to simply assume your keys have a short lifetime (perhaps a few days), and obtain new ones on expiry.
Multiple leaks would lead to a ban (Score:3)
It seems like a good way is to simply assume your keys have a short lifetime (perhaps a few days), and obtain new ones on expiry.
Twitter's reply was phrased such that Twitter would ban the developer from creating new keys if it has to expire the new keys because the new keys leaked.