3 ms·

To quote Destroy All Software: wat. Instagram uses OAuth2. It's right there in their doc: http://instagram.com/developer/authentication/ http://instagram.com/

by cheald 14y ago

To quote Destroy All Software: wat. Instagram uses OAuth2. It's right there in their doc: http://instagram.com/developer/authentication/ http://instagram.com/developer/authentication/ Second: OAuth uses access tokens, just like OAuth2. It also imposes request digests including a timestamp parameter, which prevents replays and doesn't permit forged requests if you manage to intercept an unencrypted request. OAuth2 is arguably less secure than OAuth, because as it's being used by Instagram, the whole kit and kaboodle is wrapped up in the bearer token, which is wholly reliant on TLS for its secrecy. Corporate network with a custom CA installed? Your account is theirs (seriously, your employer doesn't have to ask for your Facebook password to spy on you, they just have to make sure their proxy's CA is installed on your work-issued machine, and they can crack your Facebook account open like a pinata). Cert issued from a bad CA anywhere between you and the target server? Your account is theirs. Any breach in the host's enforcing of TLS? you've just leaked full access to your account to anyone that's listening. Hell, even an XSS breach can result in a leaked bearer token. Oh, and guess what? You can still suck an auth token out of memory and use it to forge requests. And you can still suck the OAuth2 keys out of the package or memory or whatever and use them to forge authentication requests. The exact same issue exists for OAuth2 (and Instagram's usage of it) that exists for OAuth. Implicit authentication flow is great, but the core problem of "I can crack open your app, take your client ID, and use it to create authentication requests for my app while masquerading as you" still exists. With OAuth, you also have to steal a client secret in addition to a client ID, but the end result is the same. OAuth2 is a lot more friendly than OAuth for client developers, I'll grant that, but it's just flat wrong to argue that it has some mystical protections against the problem that aren't present in OAuth.

AshFurrow 14y ago
To quote from the page you linked to: > If you’re building an app that does not have a server component (a purely javascript app, for instance), you’ll notice that it’s impossible to complete step three above to receive your access_token without also having to ship your client secret. I guess I've misspoken here. Instagram uses OAuth for authentication, but actual calls to API endpoints are sugned by appending your access_token, not signing each request with OAuth.
- ceejayoz 14y ago
  > actual calls to API endpoints are sugned by appending your access_token, not signing each request with OAuth That's... how OAuth works. Plus, later on in the same paragraph you quoted from, that alternate flow is described as being part of the OAuth spec. Might want to understand the system before bashing it.
  - AshFurrow 14y ago
    Thanks for your snarky comment; I've updated the post.
    - ceejayoz 14y ago
      You're really going to claim you were bashing OAuth1 now? When the article that you say prompted the post is talking about ripping OAuth2 stuff out of clients?
- cheald 14y ago
  OAuth (1) requests are signed with a combination of access token and shared secret. I can't impersonate you (as a user) just by sucking the OAuth secrets out of the app. OAuth 2 requests are identified by a bearer token, and have no shared secret signing.
  - AshFurrow 14y ago
    Thanks for the info - I've updated the post according to your feedback. I think this is more an article discussing why you shouldn't use OAuth 1 when OAuth 2 is available.
    - cheald 14y ago
      With all due respect, it needs some work, then. You've framed it in the context of security, and there's been no compelling reason presented for as to why OAuth 1 is an inferior solution to OAuth 2 from a security perspective. Both use access tokens. OAuth2 has implicit flow, which serves to keep my server-side client secret out of the hands of mobile users, and which I can achieve in OAuth 1 by using a separate client secret for my mobile distribution than I do for my server distribution. At the end of the day, all information on the client is subject to compromise. Period, paragraph, end of story. Any identification system that relies on a shared secret is subject to compromise as long as that shared secret is stored on a client-controlled device or ever entered into memory. That's true for OAuth, OAuth2, basic auth, pubkey authentication, passwords, biometrics, and literally every other single-factor identification scheme on the planet.
shubber 14y ago
To be fair, Bearer Token is only one option for credentialing under Oauth2 (which also includes e.g. MAC, which is as good a authentication token as you could ask for). And: Bearer Token is as good as the session cookies that are used in every app everywhere. There's a valid criticism of OAuth2, and that's that there are lots of decisions that are left up to the Authorization server implementer, and they need to know what they're doing. And this is security: no one knows what they're doing well enough.
- cheald 14y ago
  Absolutely; however, the example given was Instagram, though, who uses bearer tokens, which are at once the easiest and least secure option. Since people tend to take the path of least resistance, they also seem to be the most popular option by a wide margin. I use and enjoy OAuth2, and I'm not trying to bag on it; you're absolutely right in that it's up to the server to do things Right (and few people do; the fact that nearly nobody uses the state parameter is evidence enough of that!). However, I do think it's ridiculously faulty to hold Instagram's bearer token authorization up as the "secure way" to do things in contrast to OAuth1. I think that both OAuth and OAuth2 are plenty secure in most use cases. TLS provides Good Enough(tm) protection for the vast majority of bearer token transactions, and as you point out, there's always MAC if you don't trust the integrity of the transport. But I do think it's ignorant to claim that OAuth 1 is insecure because you can pull the secrets out of a client app, while somehow claiming that OAuth 2 is secure against such attacks.

by cheald 14y ago

AshFurrow 14y ago

To quote from the page you linked to: > If you’re building an app that does not have a server component (a purely javascript app, for instance), you’ll notice that it’s impossible to complete step three above to receive your access_token without also having to ship your client secret. I guess I've misspoken here. Instagram uses OAuth for authentication, but actual calls to API endpoints are sugned by appending your access_token, not signing each request with OAuth.

ceejayoz 14y ago
> actual calls to API endpoints are sugned by appending your access_token, not signing each request with OAuth That's... how OAuth works. Plus, later on in the same paragraph you quoted from, that alternate flow is described as being part of the OAuth spec. Might want to understand the system before bashing it.
- AshFurrow 14y ago
  Thanks for your snarky comment; I've updated the post.
  - ceejayoz 14y ago
    You're really going to claim you were bashing OAuth1 now? When the article that you say prompted the post is talking about ripping OAuth2 stuff out of clients?
cheald 14y ago
OAuth (1) requests are signed with a combination of access token and shared secret. I can't impersonate you (as a user) just by sucking the OAuth secrets out of the app. OAuth 2 requests are identified by a bearer token, and have no shared secret signing.
- AshFurrow 14y ago
  Thanks for the info - I've updated the post according to your feedback. I think this is more an article discussing why you shouldn't use OAuth 1 when OAuth 2 is available.
  - cheald 14y ago
    With all due respect, it needs some work, then. You've framed it in the context of security, and there's been no compelling reason presented for as to why OAuth 1 is an inferior solution to OAuth 2 from a security perspective. Both use access tokens. OAuth2 has implicit flow, which serves to keep my server-side client secret out of the hands of mobile users, and which I can achieve in OAuth 1 by using a separate client secret for my mobile distribution than I do for my server distribution. At the end of the day, all information on the client is subject to compromise. Period, paragraph, end of story. Any identification system that relies on a shared secret is subject to compromise as long as that shared secret is stored on a client-controlled device or ever entered into memory. That's true for OAuth, OAuth2, basic auth, pubkey authentication, passwords, biometrics, and literally every other single-factor identification scheme on the planet.

shubber 14y ago

To be fair, Bearer Token is only one option for credentialing under Oauth2 (which also includes e.g. MAC, which is as good a authentication token as you could ask for). And: Bearer Token is as good as the session cookies that are used in every app everywhere. There's a valid criticism of OAuth2, and that's that there are lots of decisions that are left up to the Authorization server implementer, and they need to know what they're doing. And this is security: no one knows what they're doing well enough.

cheald 14y ago
Absolutely; however, the example given was Instagram, though, who uses bearer tokens, which are at once the easiest and least secure option. Since people tend to take the path of least resistance, they also seem to be the most popular option by a wide margin. I use and enjoy OAuth2, and I'm not trying to bag on it; you're absolutely right in that it's up to the server to do things Right (and few people do; the fact that nearly nobody uses the state parameter is evidence enough of that!). However, I do think it's ridiculously faulty to hold Instagram's bearer token authorization up as the "secure way" to do things in contrast to OAuth1. I think that both OAuth and OAuth2 are plenty secure in most use cases. TLS provides Good Enough(tm) protection for the vast majority of bearer token transactions, and as you point out, there's always MAC if you don't trust the integrity of the transport. But I do think it's ignorant to claim that OAuth 1 is insecure because you can pull the secrets out of a client app, while somehow claiming that OAuth 2 is secure against such attacks.