Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet

A Truckload of OAuth Issues That Would Make Any Author Quit 86

New submitter DeFender1031 writes "Several months ago, when Eran Hammer ragequit the OAuth project, many people thought he was simply being overly dramatic, given that he gave only vague indications of what went wrong. Since then, and despite that, many companies have been switching to OAuth, citing it as a 'superior form of secure authentication.' But a fresh and objective look at the protocol highlights the significant design flaws in the system and sheds some light on what might have led to its creator's departure."
This discussion has been archived. No new comments can be posted.

A Truckload of OAuth Issues That Would Make Any Author Quit

Comments Filter:
  • *sigh* "conflict between the web and the enterprise worlds." is another way of saying users complained when not given an option to aim at their foot.

    • Re: (Score:2, Interesting)

      by jhoegl ( 638955 )
      I stopped reading at "There is no standard".
      Computers run on standards, there is no excuse for this.
  • Genius (Score:1, Offtopic)

    by Synerg1y ( 2169962 )

    Step one: Make digital card game.
    Step two: Print cards and sell them.
    Step three: Profit more from WOW.

  • OAuth is ugly to implement, no argument there.

    Most of the points made in the article were interesting and seemed valid to me but near the conclusion it felt like the author was reaching bit by ignoring the refresh token concept to make the final point.

    The threat of a hacked browser was a bit of an eye opener for me -- never heard that one brought up as a possibility while working on an OAuth implementation for a client.

    • I agree about the hacked browser. I think one of the main arguments by Eran against OAuth2 is that it is basically broken for mobile applications (non-web) and this is just another of the ways it is broken.
    • If you have hacked the browser or machine you have an issue. For the browser there are a slew of API's dependent on OS that let there be separation so that a browser exploit is limited to allowing authentication while that browser remains open but never exposes the base digital certificates. Smart cards take that further by never exposing the private key to anybody.

      As to AUPI vs API oauth was never meant to be a end all and be all of authentication. Designing something to let arbitrary systems share data

  • by antifoidulus ( 807088 ) on Friday March 22, 2013 @10:50AM (#43247215) Homepage Journal
    The authors biggest complaint about OAuth is that it doesn't do what it was never designed to do....and this is a problem because....? It was never designed for enterprise-level permissions management(there are plenty of other solutions for that). And his solution(copying and pasting tokens) is worse than the disease. It would be easier to go phishing with copied and pasted tokens than it is with OAuth where the login is automatic and tokens/applications can be revoked by the site that manages the account....

    I think someone is just bitter and decided to take it out on a protocol.
    • Re:WTF was that? (Score:4, Interesting)

      by Anonymous Coward on Friday March 22, 2013 @11:13AM (#43247465)

      I think the key point of the article is the first part, the "APUI" section. OAuth is "fine" when used for authentication by a user for a service based on a web browser. However, it is increasingly being applied at the "API" level (where services and applications interact, not users). It doesn't work _at all_ at this level.

      I agree that the enterprise level permissions bit is pushing things, but the rest of the article is spot on.

      • by Anonymous Coward

        wrong api works fine. I use it with google apis. once user grants auth, you can call their apis without any user interaction when their not even logged in. it all depends upon the permissions they grant you.

      • by Trails ( 629752 )

        Actually two-legged OAuth is pretty straightforward and works just fine for me

    • Re: (Score:3, Insightful)

      by Anonymous Coward

      The authors biggest complaint about OAuth is that it doesn't do what it was never designed to do....and this is a problem because....?

      Because people are, with great gusto, actually using it for what it was never designed to do.

  • by jeremylichtman ( 1717920 ) on Friday March 22, 2013 @10:56AM (#43247281) Homepage
    I've implemented sites that use a variety of third party authentication schemes. Its a nuisance for users (multiplicity of accounts, more insecure passwords to remember etc) and a nuisance for developers. Why are we still doing this? Authentication (and user profiles for that matter) belong in the user's browser. I'm not talking about Chrome's password wallet. I'm talking about a certificate-based system that allows the user to control from their end which sites are authenticated, and what data they should have access to. Sites would then implement a simple API (possibly combined with meta data on the front end to let the browser know details) that would allow for login, signing up, or changing particulars. The process could be made completely transparent for users. I have this partially implemented as an insecure proof of concept browser plugin. It wouldn't take too much work to get it running, although it really should be core browser functionality instead.
  • Some guy's rant on Blogspot is news? I guess the "stuff that matters" tagline doesn't apply anymore...
  • The author makes no distinction between OAuth 1.0a and OAuth 2.0. One of the spec leads did rage quit, not because of how bad OAuth is in general but because of all the "enterprise" help in version 2.0. Saying there is no standard is also dumb, yes version 2.0 can suffer from incompatible implementations but version 1.0 is pretty straight forward, the standard is right here: http://tools.ietf.org/html/rfc5849 [ietf.org]. The suggestion that we should just stick to HTTP Basic Authentication over SSL/TLS shows that the

  • I brought this up with the oauth working group and got snarled at by lots of people including Eran Hammer. It's nice to see that other people are noticing the same problems. When you have a native app, you can show the user anything to get their confidence, and with some work get their credentials, including apps with webview's. OAuth's security model was not designed with native apps in mind, it was designed for ~trustable web browsers. This isn't surprising because OAuth was designed before the current fa
    • Exactly. And the people commenting that "you should never have a hacked browser" don't get that it's referring to native apps which embed a browser to mislead you rather than, say, a spyware-infested version of firefox. Of course you shouldn't have the latter, but for the former, anyone can make an app that imitates anything.
  • IMHO, the only legitimate points in this gentleman's post are: (1) a compromised browser defeats OAuth, and (2) OAuth isn't mobile-friendly because it requires browser interaction to gain user consent to grant access.

    While both of these are true, Web browsers are ubiquitous; OAuth is a Web standard. You can abuse it slightly to make it work with mobile devices (see "access code grant") but really, it not was intended to be a be-all end-all authorization mechanism.

    Likewise, claims that the protocol isn't "en

    • If people were only using OAuth for web-to-web communication, I don't think those issues would have been raised. But many of the big players have their "API"s based on it. Take a look at this thread [citrixonline.com] on citrix's development site for example. Here, there's a service which is hardly web-based, pretty much the only thing web-based about it is that you join meetings by browsing to a URL, and yet the only authentication model they provide for their "API" is OAuth. This is wrong. It's not what OAuth was designed f
    • Frankly, anyone who thinks the OAuth draft RFC is complex, should choose a dozen or so documents from the SAML protocol suite, relax in a hot bath, and read through several hundred pages of THAT claptrap.

      Indeed the spec is huge, but it works extremely well. I must confess still do not understand why OAuth exists since we have SAML

Beware the new TTY code!

Working...