5 ms·

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

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.

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.