29 ms·

Why is OAuth still hard in 2023?

• deleted 3y ago
  [deleted]
• jamietanna 3y ago
  On point 1, that's why https://oauth.net/2.1/ https://oauth.net/2.1/ is in the works, to make a smaller, clearer subset of things that folks need to read and implement
• welder 3y ago
  Because it's too flexible, and allows the OAuth provider to choose which features they support. That puts all the complexity on the client to support every possible implementation.
• 6510 3y ago
  It's a turd, if you want poor security you should make things so complicated that half the implementers have no idea what they are doing. We should have a kind of LD50 for specs: How much feature cruft do you need for 50% of the test subjects to die.
  • tboyd47 3y ago
    Exactly right answer. It's a turd.
• wslh 3y ago
  Thank you for "asking" and have the luck of appearing in the first page in HN. I am sure many here wonder why. There are more complex pieces of software that find a way to abstract the problem in a nice interface.
• lakomen 3y ago
  [flagged]
• Analemma_ 3y ago
  Because "OAuth" is not a thing, it's a label you can glue on any wild-and-wacky authentication mechanism someone hacks together. It is structurally impossible for OAuth to ever become "easy".
  • noughtme 3y ago
    Yes, I’ve noticed that a lot of companies implement “OAuth” differently. I’ve found the only way to reliably implement it is to read each company’s docs and also test their API. Once you implement their flow and signing (or not signing) method, it’s really not that complicated.
  • icedchai 3y ago
    Yep. OAuth is more of a concept than a standard. There are common patterns, and you might get lucky and find 2 integrations that handle it the same way... but I wouldn't bet on it. I worked on a system that OAuth'd with about 5 different 3rd party systems and each one was a little bit different.
    • haswell 3y ago
      I agree and disagree. The OAuth 2 spec is pretty explicit. People do not follow it. The industry has played fast and loose with the spec because too many people implementing OAuth support in their app do not understand OAuth and/or insist on bleeding application or architecture-specific behavior into their authentication flow. The end result is what you describe: a proliferation of approaches that roughly follow the spec. But this should not be mistaken for the spec being loose IMO. Rather that the state of auth is abysmally non-standard and homegrown. I owned the authentication stack for a large enterprise platform company, and worked directly with the biggest players on ensuring compatibility between our platform and their auth flows, and the typical deviations from spec are almost always unnecessary and duplicate something that was already possible. To be fair, Auth Code flow gets pretty funky with browser redirects + backend calls and can be hard to grok at first. The other major issue is that once some custom auth thing exists in production, it's never going away if there are enterprise customers relying on the behavior. I suspect that a lot of customized implementations were never meant to be long term solutions.
• mikeknoop 3y ago
  We have a joke about this at Zapier -- don't be an oauth butt! "We support standard oauth butttt..."
• chowells 3y ago
  OAuth is easy in 2023. The problem is that OAuth does essentially nothing of interest by itself. It's a way to pass scoped access tokens. That's it. That's the end of the spec. If you want to do anything with those tokens, you need to implement against other APIs the provider makes available. Unless all of those APIs are also standardized, it means implementing a bunch of stuff for each integration. And now things are no longer easy.
  • paulddraper 3y ago
    OAuth is a way to obtain scoped access tokens. And if you read the article, you would have something of substance to contribute on that topic, whether it is easy or hard or otherwise.
• paulddraper 3y ago
  Example: What is the purpose of OAuth having specifications for redirect URI allowlist AND PKCE? None. They are entirely duplicative features. But ... reason, reason, reason ... they both exist, and are going to exist, forever. EDIT: I should say, PKCE is a functional superset of redirect URI allowlist.
  • akira2501 3y ago
    My understanding is that PKCE allows you to more safely operate a client that does not have a client secret.
    • maxwellg 3y ago
      The React Native docs have a good writeup on how PKCE reduces vulnerabilities with deep linking & session hijacking - https://reactnative.dev/docs/security#authentication-and-deep-linking https://reactnative.dev/docs/security#authentication-and-dee... PKCE also gives you nice assurances that the device finishing the flow is the same as the device that started it. Without PKCE, the classic client credentials flow risks login CSRF - https://support.detectify.com/support/solutions/articles/48001048951-login-csrf https://support.detectify.com/support/solutions/articles/480... - which may or may not be an attack vector you care about.
      • deleted 3y ago
        [deleted]
      • dwaite 3y ago
        > well yeah, but there was already state, but nobody used it for that state was meant to be application state. The problem is that there _wasn't_ anything like PKCE in vanilla OAuth 2, so the client was told to overload state with protocol state with particular processing rules, rather than just its own application state. With PKCE, the AS can see whether it is the same client instance and reject the request. The state workarounds meant the client had to implement the rejection, which many did not do.
  • dwaite 3y ago
• throwawaaarrgh 3y ago
  It was designed by committee, and the internet adopts any shitty technology that a big player pushes.
• remus 3y ago
  It'd be interesting to hear about people who have had a good time implementing OAuth, as my experience is similar to that in the article. I've played with adding it to a few side projects and the process usually goes: 1. Read loads of docs, end up pretty confused 2. Find a library that seems to do what I want 3. Install this huge library full of opaque code doing...things 4. Have an impossible time troubleshooting issues 5. Get scared ("I'm almost certainly doing something wrong here") and give up I find it hard to have much faith in security standards like this. I want them small, well defined and understandable and OAuth does not meet any of these criteria in my experience.
  • zippergz 3y ago
    3b. realize that library is deprecated or hasn't been updated in many years and is either totally broken, or incompatible with something else you're using.
    • Spivak 3y ago
      3c. Write your own "library" which encompasses the the 50 lines of code. Adding the oauth calls into your app that already has a web server, job processing, and a db is way easier than integrating what ever weird stuff some random library does.
  • btilly 3y ago
    I have read many docs. The one that I find easiest to understanding is still the one that I wrote about a decade ago when I first had to work with OAuth 2. All others I understanding by mapping what they said to concepts in mine, and that seems to work pretty well. My document is available at https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Authen/OAuth2/Overview.pod https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut.... Even though you're unlikely to ever use that library or language, you may find it worthwhile.
    • sebmellen 3y ago
      I'm pretty astounded, because this is by far the best OAuth 2 doc I've ever read, and that's after reading and watching many hours of content from leaders and companies in the space.
• mkl95 3y ago
  OAuth sucks. It's one of the worst abstractions of our time. It's incredibly easy to implement some half assed spaghetti and call it "standard OAuth".
  • lloydatkinson 3y ago
    I suspect it’s either by design that it is this terrible and hard to deal with or larger auth companies have a vested interest in keeping it this terrible.
    • haswell 3y ago
      There is no grand conspiracy here, and the problems OAuth is trying to solve can be pretty messy regardless of the approach. When the environment involves delegating authentication across service providers, dealing with browsers and native clients, mobile apps, etc, there will not be a simple solution. This is made even more challenging by constantly evolving application and edge deployment architectures, each bringing with it a new element of complexity. OAuth sucks, and I’m sure it could be replaced with something better, but that replacement will also suck and bear a passing resemblance to OAuth, because the underlying problem is a messy one that isn’t going away soon.
  • zmxz 3y ago
    It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token. It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters. I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in you and not the protocol? Reason I'm asking is because you declare it sucks but you are not providing any kind of alternative of how it would not suck.
    • hyperpape 3y ago
      > and one needs quite literally 10 minutes to read the RFC rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it. Never mind that there are several other OAuth RFCs.
• infogulch 3y ago
  What I don't understand is why all of these complicated SSO technologies like OAuth, OpenID Connect, SAML, LDAP, etc are integrated at the application layer at all. All these web applications should be using something like "Trusted Header SSO" [1], thus completely offloading authentication to the upstream reverse proxy (which does or should exist anyway) and then the whole problem vanishes at the level of the application. It's like the MxN problem that Language Server Protocol addresses, but here "M" is applications and "N" is authentication protocols. The fact that I have to hand over my administrator password to the grubby memory of random shoddy applications as they pass it over LDAP to authenticate me in my corporate "holy grail" SSO-everything environment is insane to me. [1]: https://www.authelia.com/integration/trusted-header-sso/introduction/ https://www.authelia.com/integration/trusted-header-sso/intr...
  • darkr 3y ago
    OAuth isn’t an authentication protocol, it’s authorisation protocol (which attempts to solve nebulous authorisation delegation scenarios in an often overly generic and overly complicated way).
  • mdaniel 3y ago
    For your consideration, centralizing auth like that imposes the requirement of (a) running a second piece of security tech (b) ensuring that all upstream applications are in the same authn/authz domain as the front proxy That's not even getting into the fact that the "SSO technologies" that you listed have vastly different mental models of what inputs and "claims" they support. Maybe you're hinting at https://xkcd.com/927/ https://xkcd.com/927/ but for better or worse I don't believe there is a magic wand authn/authz standard like you want
  • paulddraper 3y ago
    I don't understand. For example: a CI service wants to write to a Slack channel. The CI service produces a request and directs me, the channel owner, to Slack where I confirm the request, and then the CI service obtains the scoped access token. How is this replaced by anything to do with an "upstream reverse proxy"? EDIT: I think you are thinking of OAuth as SSO. It can be used for that, but that's not it's "true" purpose like it is for SAML. --- > The fact that I have to hand over my administrator password as they pass it over LDAP to authenticate me Yes, that is insane and why LDAP is generally no longer used for web applications.
• coderintherye 3y ago
  Related gripe: Your API doesn't always need OAuth. If I'm using your product as your customer and I directly want to leverage my own product data via your API then I shouldn't be forced to have to implement [your almost invariably non-standard and difficult] OAuth implementation. An API key should be an option or HMAC if the extra security is felt to be warranted, but not the absurdity of needing to go through a client flow to check the boxes to say yes I consent to share my own data with my own self for this API use that will never be seen or used by a 3rd-party.
  • paulddraper 3y ago
    > If I'm using your product as your customer and I directly want to leverage my own product data Correct. Fortunately, in my personal experience many services offer exactly this (JIRA, Hubspot, Slack). OAuth is only relevant where the resource owner and client are different parties. I.e. it's for third party clients, not second party clients.
  • justrealist 3y ago
    Not to mention needing to create awkward shared service accounts to impersonate.
  • lll-o-lll 3y ago
    OAuth client credential flow is this easy mode you ask for. It’s one call with a secret in it and back comes a token.
    • sansnom 3y ago
      The problem is "client credential" flow is not always available... And even if it were it might not as easy as you claim. In particular if you want to have an access token working on several instances. Most implementation allows only one access token at once so you need to have a shared storage and synchronization just for that... If you are developing an API please have mercy: provide something other than OAuth. For me, avoid OAuth unless there is 3 distinct parties.
  • andix 3y ago
• nige123 3y ago
  GNAP is coming soon: https://oauth.net/gnap/ https://oauth.net/gnap/
• cco 3y ago
  Love this post by Nango, it's exactly right! Agreed that the biggest reason is that OAuth is a framework and not a protocol. That means different companies can do it ever so slightly differently, and as a dev, you need to understand the differences and normalize it for your use case. At Stytch we've run into the same issues, normalization problems, security implications, flaky IdPs; a hard problem, but one you _have_ to get right!
  • dwaite 3y ago
    > OAuth is a framework and not a protocol Indeed, a lot of people do not realize the difference. Frameworks do not provide interoperability, and at most we can push to try to get people to solve problems the same way. Profiles (such as OpenID Connect or FAPI) constrain frameworks allowing implementations to be interoperable. OAuth is somewhat like the multitude of different dialects in some places like the United Kingdom. The original article was talking about the problems due to trying to support all those different OAuth dialects. I'd argue most developers will never know that degree of pain, because they are only trying to solve problems within their particular application space.
• kayodelycaon 3y ago
  OAuth is such a pain in the ass for small projects. I miss api keys.
• FpUser 3y ago
  I integrated my product using OAuth 2.0 with 3 other systems from 3 different companies. Each one required different code on my side. Not fun at all.
• cornycover 3y ago
  If you're struggling with OAuth I recommend reading this article from Ory: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/ https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
• lukeed 3y ago
  It's easy with https://btn.social/ https://btn.social/ :D I made this because I was tired of asking the same question. There are a bunch of services out there trying to address the same thing, but unfortunately they get wildly expensive and they own/control your user data. Professionally, I've been a consultant and freelance developer for 10+ years. Time and time again I'd see teams start with Auth0/etc, only to eventually: 1. duplicate user data into their own DB/Cache to avoid the latency of asking Auth0 for user data 2. remove Auth0 entirely because having active users !== having paying users... so Auth0's monthly bill of $3000 to $10000+ couldn't be justified 3. #1 then eventually #2 btn.social is just as simple to set up, but has predictable & transparent pricing with volume discounts the more you use it. At its most expensive, it's 100 logins per penny ($0.01), which is to say that "MAUs" are a thing of the past. As quick pricing comparison: - Auth0's (public) pricing calculator [1] shows 10k MAUs for $228/mo. That just means 10k users logged in 1+ time(s) that month. In btn.social terms, that's 10k, 20k, or 30k logins depending on if each of those users logged in 1x, 2x, or 3x (etc). For $5, you get 50k logins with btn.social.... and for $169 you get 2.5M logins... [2] - Supabase charges $25/mo, which includes a lot more than just OAuth(!) but if you look at Auth alone, that $25 includes 100k MAUs and is an additional $0.00325 per MAU thereafter [3]. Assuming 1x login per MAU, that's $2950/mo for 1M users. With btn's "Business" tier, you get 1M logins for $79/mo, but of course there's still the $169 for 2.5M if you don't like the "1x login per MAU" assumption. Another key difference is that btn.social saves nothing about your users. It's your app so you get to keep your data. You'll never need to have to ask btn.social for Alex's profile because we won't have it :D This means we're privacy-first & we don't add/pose a risk for GDPR concerns. btn.social was just launched last week [4], so some additional guides & examples are still underway, but there are already 10+ OAuth providers [5] to choose from & a free/"Hobby" tier so anyone can start playing around in just a few minutes. [1]: https://auth0.com/pricing https://auth0.com/pricing [2]: https://btn.social/#pricing https://btn.social/#pricing [3]: https://supabase.com/pricing#compare-plans https://supabase.com/pricing#compare-plans [4]: https://twitter.com/lukeed05/status/1648751062340501505 https://twitter.com/lukeed05/status/1648751062340501505 [5]: https://docs.btn.social/providers/ https://docs.btn.social/providers/
  • hencq 3y ago
    First off, congratulations on launching! I'm not sure why you're getting downvoted, because it seems quite relevant to the discussion. I'll definitely look at btn.social for my next hobby project. The pricing is super reasonable and the documentation very clear. One question I have around OAuth in general is whether it only applies for SPAs or if I could also use it for more traditional multi-page apps? I guess I could do something similar to what you're doing in your guide [0] and do a POST from the onlogin callback, but how does my backend know that the payload is valid? [0] https://docs.btn.social/guides/#link-a-payload-with-a-db-record https://docs.btn.social/guides/#link-a-payload-with-a-db-rec...
• stcroixx 3y ago
  Probably because the part most of the world is actually interested in was later renamed 'Open ID Connect' and any attempt to research using the term OAuth will bring you nothing but incorrect, old, ad-hoc implementations and presentations by snake oil selling 'personalities' claiming they understand it.
  • 411111111111111 3y ago
    Naw, the same applies to oidc. Especially in the browser. The issue itself also sounds easy enough to implement that you might get suckered into rolling your own (you only need to do a redirect and a request every n-minutes) ... But it's surprisingly hard as there are a lot of edge cases with long running timers and potentially multiple browser tabs/windows etc.
  • bootloop 3y ago
    And once you realize you actually want OpenID Connect and none of the OAuth 2.0 features, you stumble about the fact that OpenID is not what you want because they just share a name... Where was I again ???
• dekhn 3y ago
  because it was a dumb standard with terrible implementations solving a problem that nobody had
  • 9dev 3y ago
    Right. Do all of those dumb dialogs that allow you to sign in using your Google account, import data from one cloud to another, add integrations from third party providers to other apps… they are all solving problems you don’t have? OAuth is one of that pieces of infrastructure that power lots of things without people even noticing them, but don’t bode well with armchair engineers.
    • dekhn 3y ago
      I'm an application develop who uses oauth, but it's only one in many authentication systems I've used, and certainly one of the worst.
      • magicalhippo 3y ago
        Which others have you used which solves similar problems, but better? Genuinely curious.
        • dekhn 3y ago
          Well, I use oauth only for authentication (IE, use it to get a trusted email address for the web user of my app), not authorization. Of all the systems I've used, kerberos has been the best authn solution, then basic auth to log in as a user where authorization is done in another ACL system (FS acls, for example). My complaints are almost entirely about the ergonomics of writing oauth code in a server, provisioning the resources to make it work (like DNS), and then debugging 900 redirect_uri errors.
      • 9dev 3y ago
        Which highlights the very problem I was talking about, considering OAuth is an authorization protocol, not one for authentication…
• agentultra 3y ago
  My favourite are the appendices that amend the protocol to fix security issues that almost no API seems to implement properly. These can get quite long and are frequently amended with new drafts every year or two. For example, most APIs don't implement PKCE in order to prevent injection attacks against the authorization code grant type. Just keeping up with security practices is a full time job for teams.
• harrisonjackson 3y ago
  Nice read from nango team. FWIW we are using nango/nango cloud in prod to support ~15 integrations. We signed up before they had an admin dashboard and did everything over cli. It was easy then and even easier now. We have also contributed a couple of providers when they didn't have apis we wanted to use setup yet (Stripe, Zapier NLA). They have an open slack channel and we were able to get them shipped immediately.
• codingclaws 3y ago
  I am in the middle of implementing an OAuth 2 server for my internet forum [0]. The last 10 or so commits are OAuth related. I read docs for about a month and now I feel like I can code it. One thing that confuses me is how it can work without a client secret (it's recommended to not use a client secret for SPAs and native smart phone apps). [0] https://github.com/ferg1e/comment-castles https://github.com/ferg1e/comment-castles
  • whatusername 3y ago
    So make sure you are doing PKCE for public clients. With that, and the redirect URL (and therefore trusting DNS), and the other browser security model stuff…. You’re in fairly good shape. There’s newer standards coming like DPoP - but it’s probably not worth it yet.
  • ollien 3y ago
    https://archive.is/26yI3 https://archive.is/26yI3 This explainer is pretty good. Sorry for the archive link, the original seems to be down
• davidguetta 3y ago
  Use fief ! By the creator of FastAPI
• rglover 3y ago
  From my experience, the blame lands on documentation and consistency at the implementation level. What should be a fairly simple process (redirect -> receive an HTTP request w/ code to exchange -> perform an HTTP request to exchange code for token) is always made into some esoteric spaghetti. I recently wasted hours implementing OAuth login for Bitbucket because their docs have bad links, bad explanation of params to pass, and bad explanation of endpoints to hit. I implemented Github and Gitlab just before in ~30 minutes total, so it really is a YMMV by provider problem.
• jrm4 3y ago
  I'm not super familiar with all of it on a tech level, but is some of this because individual apps that shouldn't exist hoard it? In my case it's Duo, literally the only 2FA thing I must use that doesn't let me have my dang token so I can use whatever app I want?
• thepasswordis 3y ago
  Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said with a token" Then later on you can take the token and say "Hey google, somebody gave me this token, who is it?" That's pretty much it. You have to trust that google isn't lying to you, but that's kindof the point of oauth. But that's never what the documentation says. It's always 10 pages long and the examples are like "here's a fully functioning python web server using flask and function decorators, oh the actual auth flow, which is really like 3 lines of code, is hidden inside of a library". To people who write documentation: PLEASE for the love of god show me how to talk to your API both using your library, but also using something like urllib2 or requests or something. Ideally the documentation is the absolute most minimal way of making the service work, and then adds more and more usefulness on top of that. I'm not going to judge you for writing bad code in an example. The example could practically be pseudocode for all I care. I just want to see generally how your API is supposed to work. edit: yes, auth0, I am looking at you.
  • garbagecoder 3y ago
    Somebody print this comment out, frame it, and mail it to every major API author.
  • cjbgkagh 3y ago
    Auth0 has a business incentive to have people think their core competency is more difficult than it is.
    • deleted 3y ago
      [deleted]
  • deleted 3y ago
    [deleted]
  • jcranmer 3y ago
• andix 3y ago
  Because most OAuth libraries are very incomplete. They implement a few happy parths of the standard, but a lot of things are just not there.
• idlewords 3y ago
  I never understood how Oauth as a user experience is supposed to be distinguishable from phishing.
  • mdavidn 3y ago
    Password managers mitigate this. If the form doesn't offer to fill my saved password, that immediately raises red flags in my head. I immediately bail out or manually validate domains.
    • idlewords 3y ago
      I've found that if I haven't updated Chrome then my password manager plugin stops working, which happens frequently enough that this would no longer raise red flags for me. Every layer of security conspires to defeat every other one.
  • dwaite 3y ago
    Many authentication systems push all phishing mitigation onto the user, e.g. "check the lock" (doesn't do anything) or "check the address bar" (not realistic for most users, ignores the ability to register official-looking DNS names). So the answer is - OAuth doesn't solve the phishing issues around authentication any more than any other sort of non-curated hyperlink on the web. WebAuthn, mutual TLS and Kerberos are the systems where that authentication is bound to a DNS domain or communications channel. Password managers also can provide this, although there are security considerations there such as competing web extensions, and it is a mechanism that the server cannot vet for risk analysis. Such phishing-resistant mechanisms raise the bar for a successful attack from someone sending out a creative email to something a lot closer to coordinated/state-sponsored attacks on internet infrastructure.
• kierank 3y ago
  Is there any good way to do OAuth on a headless system? I want to be able to run batch jobs without a browser involved. There's OAuth for devices but that has limited real world use.
  • p_l 3y ago
    Yes, multiple. You can implement client credential mode - this means storing a credential and using it to acquire a token from OAuth2/OIDC provider, then using that token as Bearer Token in your API calls. EDIT: I can add that I have implemented client credential mode in what was effectively raw PowerShell and similarly it can be done with curl from any shell script, even pretty dumb ones. Just do a single POST containing the necessary JSON structure to your OAuth2/OIDC provider, parse returned JSON to grab bearer token value, use said token value in header curl -H "Authorization: Bearer ${token}" You can also implement any kind of authentication in your provider (or configure a 3rd party one) and make it accept it - then ensure that this authentication model is supported by your headless program when it receives a redirect to login page. For example I have implemented Kerberos 5 login this way - CLI program would connect to OIDC provider (keycloak), get offered HTTP Negotiate GSSAPI auth, perform it using users kerberos identity, get token, use that token to access AWS STS to acquire AWS token. Completely transparent to end user/service.
    • cryptonector 3y ago
      But let's tell the truth: this is NOT user-friendly. Compare to Negotiate.
      • p_l 3y ago
        Oh boy, Negotiate. The wonderful system that works easily only on Windows. I love it though, I use it as part of OIDC flows, because then I don't need to directly implement it for every application, I just make them call to Keycloak for it.
        • cryptonector 3y ago
• anarchogeek 3y ago
  Because OAuth 2.0 sucks and got all bloated. The 1.0 version worked great for everybody but super big companies like google and facebook. But then big companies came in and made it a bloated standard that doesn't meet the needs of most users.
  • 0x457 3y ago
    That's not entirely true. OAuth 1.0 and 2.0 didn't cover much, and everything was implementation specific. Both standards only cover authorization, while the majority of consumers wanted to use it as authentication. Big companies had to roll out their own authentication layer on top. When OIDC came into play, it was already too late.
• prima-facie 3y ago
  I found this tool useful for debugging Oauth: https://github.com/cloudentity/oauth2c https://github.com/cloudentity/oauth2c
• revel 3y ago
  Authentication is easy and solutions are more or less fungible, but there’s no obvious and easy way to do authorization. OAuth makes authentication pretty easy but all the complexity comes from authorization, which is adjacent to authentication but not directly related to it. Although it’s not OAuth’s job to help you with authorization, it’s an inevitable next step that leads to massively divergent approaches
• dpcx 3y ago
  I don't know why it's still hard, but I can tell you, from the perspective of trying to prototype something, I would love to not have to use it just to find out if this functionality I want to build is worthwhile. I don't want to have to create a client, get some keys, worry about refresh tokens, etc. I want to hit an endpoint with an easily accessible token and get some data. Make it so that the token is only valid for 30 days or something and then it requires moving to OAuth. But for prototyping stuff with curl and bash scripts, it's a giant pain.
  • chasd00 3y ago
    If you’re prototyping use postman to get the tokens for you then copy/paste them into your prototype.
• nullandvoid 3y ago
  As a web dev next auth makes auth a breeze just add a provider and go (unaffiliated, just love how easy its made things).
  • siquick 3y ago
    Next Auth is brilliant. It just works.
• dathinab 3y ago
  1. because it's conceptually not an easy thing 2. because the standard was messed up (instead of specificing a protocol with _at most_ one clearly specified flow per use-case (you can use it for more then SSO/Cross App Auth) they specified something more like a framework to build your own standard, but still pretended it's a single protocol, but if you can't use the standard to "blindly" build a client which works without knowing anything about the vendor then it's not a protocol, at least not a complete one) 3. because the standard covers too much potential use cases 4. because vendors haven't yet converged their implementations enough and might never do so (time for OAuth 3 which just specified on specific OAuth2 flow implementation??) Given that OAuth2 was started with clearly very different goals in mind and the main profiteers of the current situation are a few big companies like Google, Facebook and Microsoft I have heard people stating that OAuth2 being messed up was intentionally. _I don't believe so_, it more looks like a typical case of accidentally over engineering by trying to doing so much. I still don't like the situation as OAuth2 was too some degree a coffin nail to the idea of generic SSO (i.e. you as a customer can freely choose a SSO provider when signing one) and that sucks really hard and if we had generic SSO passwords would be _way_ less of an issue today (imagine _any_ email provider could _easily_ also provide a SSO service for any side you can have an account with).
• znpy 3y ago
  Because authentication and authorization is a hard problem in general. Hard to make it right, hard to make it secure, hard to make it simple. And exponentially harder to make it versatile. And if oauth is "hard", wait until you see OpenID and the myriad of extensions...
• smackeyacky 3y ago
  My various brushes with OAuth and OIDC and FAPI have been horrible. The spec is written poorly, everybody seems to have their own idea of how it should work, nobody seems to implement the same thing. Add to that the various version of OAuth/OIDC/FAPI and no clear migration path laid out to upgrade and it's a basic nightmare. The Australia CDR (Consumer Data Right) notionally supports FAPI but they have their own interpretation of what is right so you simply can't use an off-the-shelf library to do anything. The only way to preserve any kind of inter-operability is to wait for some other sucker to release their interpretation of this standard and everybody else in the eco-system has to test against that and eventually call it good. Add to that - I just can't see why it has to be that complicated. Sometimes you can request signed+encrypted tokens, sometimes not, you can query the provider to ask them what they support but there are holes and gray area defaults for algorithms and encryption schemes and the whole thing needs to be set fire to and abandoned.
• emurlin 3y ago
  I can't seem to find an old article written on the early days of OAuth 2.0, praising OAuth 1.0a, because among other things it signed the URI parameters and because unlike OAuth 2.0 Bearer tokens, OAuth 1.0a didn't require sending credentials in the clear (this was at a time when HTTPS wasn't quite as ubiquitous, and OAuth 2.0 pretty requires TLS to be used securely). As someone often working with OAuth 2.0 flows, I enjoyed the article and think that it raises many good points. I'd also say that many of them come from things that affect _any_ system solving a problem similar to OAuth 2.0, because authorisation is hard to get right, or from extensions to the protocol that really aren't OAuth 2.0's fault (like the `realmID` parameter, obviously added to make the life of those API developers easier at the expense of those actually trying to integrate with their systems). To me though, I wholeheartedly agree with 'Problem 1: The OAuth standard is just too big and complex' and 'Problem 2: Everybody’s OAuth is different in subtle ways'. OAuth 2.0 is more of a framework or metastandard, and no API implementation uses all parts of it because they simply are not relevant to that API or use case. This alone makes it quite hard to 'simply use OAuth' for an integration, because a big part of the job is figuring out which parts are used and in which ways, even if everything is done per the RFCs. By contrast, OAuth 1.0a was comparatively much simpler and focused on a more narrow problem. OAuth 2.0 allows you to convert a SAML claim from one provider into an OAuth 2.0 token for a different provider to then delegate permissions conditionally to another actor for a particular action on yet another API. Are we better off with OAuth 2.0? I say yes, because figuring out the differences between providers is probably easier than realising a hundred completely different implementations that have very different ideas of what an authorisation or delegation flow should look like. I think that one can learn to reason about OAuth 2.0 and then apply this logic to integration jobs with slightly less cognitive load than a completely bespoke solution. At the same time, I think something sorely needed is something like OAuth 2.0 profiles that standardise the features used to integrate with OAuth 2.0. Probably most social media sites have similar requirements, most auth-as-a-service have similar requirements and so on. Having a common subset of features and decisions for common use cases and scenarios would IMO greatly simplify integration tasks and, paired with choosing a good library, make it indeed possible to integrate with a random service in under an hour. The thing is that some of that was the spirit of older standards like OAuth 1.0a and OpenID (not to be confused with the newer OpenID Connect, which is OAuth 2.0-based), and the world seems to have moved away from that, probably because of the flexibility that OAuth 2.0 affords and the want to tightly control authorisation and external integrations.
• littlecranky67 3y ago
  My rant about OAuth: It is overly complex because it has too many features to satisfy each and every enterprise case. For me who runs a simple website (no 3rd party login), I learned that OAuth2 is just not a good choice. JWE/JWT and samesite=strict plus HttpOnly cookies are reasonably simple, yet secure enough.
  • chasd00 3y ago
    A simple website with no third party login nor needing access to a third party API on behalf of the user should never use Oauth to begin with. a standard session cookie works just fine in those situations (as you discovered).
• 29athrowaway 3y ago
  If you use OAuth make sure to use stable sorting.
• deleted 3y ago
  [deleted]
• superkuh 3y ago
  Oauth is simple. OAuth2 is a protocol for making protocols and every mega-corp's implementation is different. It's requirement for email access in the mega-corp walled gardens breaks imap in the sense that just imap doesn't work anymore. And in the pragmatic sense that many smaller email clients don't and won't support all the various idiosyncratic implementations.
• defaultcompany 3y ago
  See "OAuth 2.0 and the Road to Hell" - Eran Hammer's resignation letter from his role as Oauth 2.0 spec lead author and editor: https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
• lukev 3y ago
  Given that this seems to describe a real problem, why hasn't anyone launched a proxy service that normalizes across the varying implementations? Why should tens of thousands of developers have to discover the particular quirks of an implementation instead of doing it once and re-using the results?
  • fordsmith 3y ago
    They have. https://clerk.com/ https://clerk.com/ is an example that I have been looking to use lately
  • bastienbeurier 3y ago
    That's what we do at http://nango.dev http://nango.dev
  • yrro 3y ago
    oauth-proxy?
• bebop 3y ago
  If you want to read the rfc’s I had chatgpt explain the parts of the authorization code flow and link where in the rfc’s the parts are defined. https://bryce.groff.family/oauth-2-1/ https://bryce.groff.family/oauth-2-1/
• 0xbkt 3y ago
  Tangentially related: what do you use today to make authn/z work for your web sites/applications where you only do first party login (i.e. you don't do social login etc.)? Create a `users` table in your database and implement the logic on your own? Or proxy to stuff like Ory Kratos and act as a translation layer through a network call?
  • mparnisari 3y ago
    Auth0.com
• TobyTheDog123 3y ago
  No one implements it the same way. Some require scopes, some don't. Some require comma-separated scopes, some want an array. Some require an HMAC signature, some don't. Some want a JSON body, some want a urlencoded form. Etc. Etc. Etc. You're never implementing OAuth, you're implementing some company's bastardized flavor.
• tommoor 3y ago
  It's not particularly hard, this article is just self-serving content marketing because their product is an OAuth wrapper.
• schlowmo 3y ago
  > OAuth is a standard protocol. Right? And there are client libraries for OAuth 2.0 available in basically every programming language you can imagine. Here lies another pain point of integrating OAuth flows: In my experience those client libraries are a lot better in following the RFCs than the authorization server implementations. It can cause a great deal of pain using such client library with a botched authorization server. If you take a look at the issue trackers of some client libraries you see a lot of "Please make this library work with auth provider XYZ" reports to which the maintainers (rightfully but painfully) respond: "Won't fix! We're following the RFCs here, we can't deal with every crooked authorization server implementation. Get it fixed at the other side." And then you have to take the decision if you want to patch the client library youself to make it work (with the risk that this patches break on updates of the client library) or if you roll your own client for that particular auth provider. This decision gets even more complex if you have to support multiple authorization servers. If it's only one auth provider the third option would be using a vendor specific client library, which may be as botched as the authorization server, but at least they can talk with each other.
• domrdy 3y ago
  I've been using WorkOS for my SaaS products and I'm pretty satisfied with it. It's straightforward to set up Google/Microsoft/MagicLink (free), including staging and production environments. The best part, though, is that it lets my enterprise customers configure their own SAML/OpenID Connect IDPs. I get charged per connection, so I just pass that cost onto my customers. As a solo developer, I'd have a hard time supporting so many IDPs with a unified API without this. They did recently hike up the cost per connection, but they're giving a one-year extension at the old rates, which seems fair.
  • sho 3y ago
    Their product looks great but the price seems insane. $125/m per connection? That's very hard to swallow for a SAAS looking to charge maybe $10-30 per seat. I get it, "enterprise!", but that's a pretty high barrier to entry for a company still establishing itself.
    • domrdy 3y ago
      Absolutely, it's not the most inexpensive option out there. My strategy is, that I only initiate a connection once an agreement with an enterprise client is officially signed. This way, I'm not investing upfront without the assurance of a paying customer. I find this approach works quite well for my situation.
    • lukeed 3y ago
      insane indeed. btn.social is 1 cent for 100 logins. no MAU shenanigans. won't bankrupt/drain most startups
• xyst 3y ago
  Personally, I have transitioned away from these third party IdPs. I have turned to spinning up my own authentication and authorization stack using an open source ecosystem like "Ory". With just a single helmfile, I can deploy the entire application stack on my local machine (authN, authZ, smtp server,app db, application). Gives me ease that I don't have to rely on a third party vendor just for testing simple app flows. Transitioning to production is a simple swap of DSNs (database connection strings, real smtp servers, ...). Also, no more burning money when running simple tests or performing load tests with dummy users when using an external/managed IdP. Still need to experiment with how upgrading will work and migration of user data. But otherwise I am a happy user/developer.
  • ssd532 3y ago
    If you have already evaluated what are your thoughts on Keycloak? How does it compare with your stack?
• StillBored 3y ago
  I don't know, I look at oauth and it seems like its insecurity by design. Huge complex spec, with lots of corner cases, and requires really complex functionality like HTTP and JS. All of which can hide obscure bugs. Its like no one has learned from history. Frankly, I'm not sure what keeps people from simply putting fake Oauth screens on random phishing emails. Figure out what a companies default auth screen looks like, pop up a similar looking web page.. bam plaintext passwords that can be used to authenticate with real services.
• indus 3y ago
  Not one mention of flickr in your post...Would have loved it.
• awill88 3y ago
  It’s hard because the concepts of authentication and authorization are simple to abstract but hard to keep separate at a technical level. It’s actually super powerful once you futilely attempt to craft your own system that keeps the concerns separate. Oauth is authz But do get in “the door” you need OIDC + PKCE auth code grant.. or authn
• firatsarlar 3y ago
  It's some kind of misty cristal, requires high up, high up ... A few could really grasp that
• webjunkie 3y ago
  What I would like to highlight is that it's still quite an achievement to be able at all to authenticate users with dozens of different APIs. Could it be better? Sure. Could it be worse? So much. Just imagine everyone would be cooking completely there own thing, or there being fractions or competing "standards".
• jwr 3y ago
  I wrote my own OAuth2 implementation (OAuth 2.0 Authorization Code Grant, both client and server side). I share many of the frustrations mentioned in the article. That said, my first thoughts when looking at the advertised service is that I would be adding a huge external dependency with all the associated problems. That's a big cost, and I don't mean just in monetary value. I now have to rely on the network, as well as an external company with a business model that might or might not work out for them. Said company is likely to get acquired or shut down, none of these outcomes are good for me. Also, external APIs are a pain to maintain (I found that on average an API gets completely rewritten once every 2-5 years, which if you have 5 external APIs means that you will be rewriting one every year). Also, OAuth has an unpleasantly large interaction surface with the rest of the software. As a counterpoint, if I could buy a good local OAuth2 library for Clojure (subscription is fine), I probably would.
  • gleenn 3y ago
    Does Clojure's "buddy" not work for OAuth2 or something? Last I recall it worked well enough but not sure what your specific requirements are. https://cljdoc.org/d/buddy/buddy-auth/3.0.1/doc/user-guide https://cljdoc.org/d/buddy/buddy-auth/3.0.1/doc/user-guide
• lbriner 3y ago
  As others have said, the main problem is that 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations and 2) It is very hard to distill the relevant parts from the spec which covers all parts with equal vigour! We have the same issue with the UK Wiring Regulations, so they produced an "On Site Guide", which covers only the main parts of the main regulations and is about 10th the size. The same could be true of the OAuth spec. To be fair, OpenId Connect partially addressed both issues by taking a subset of the spec (when used for authentication) and then nailed down what the properties should be and what encryption mechanisms are required to be implemented.
  • jeroenhd 3y ago
    > 1) There is too much flexibility which means that "name" might be "firstname" or "first_name" somewhere, which is why you need so many different implementations Names are funny because many implementations of standards make the mistake of presuming there's such a thing as a "first name" and a "last name" that make up a name. Or that the "last name" is the part you pass down to your family, and so on. If I see "first name" in any spec, I assume the spec is written solely for a small subsection of the population by someone who didn't put all that much thought into the spec. Not every service needs an email address, there's no telling what a valid username may look like, address specifications are basically plaintext strings even though many services pretend there's structure to them, and so on. Hell, most APIs authenticating against OAuth don't even need a username or user ID to function, all they need to provide is an access token. Most fields have no business being standardised because they cannot be. OAuth is not a "log in with Facebook" standard, just like IPv4 isn't an "access Wikipedia" standard. If you host something that people authenticate through OAuth yet, you inevitably need to provide some kind of custom service properties.
• eru 3y ago
  Somewhat offtopic: HN shows me the name of the submitter, bastienbeurier, in the colour #cd6e00. (Not sure what people call that colour in natural language, as i'm colour-blind.) What's up with that? The account was created in 2013.
• jwmoz 3y ago
  I HATED having to do anyting with oauth back when I did more web work. Think it actually gave me PTSD.
• nektro 3y ago
  https://github.com/nektro/zig-oauth2 https://github.com/nektro/zig-oauth2
• NaN1352 3y ago
  OAuth is too abstract and that’s why it’s bad. I’m not a backend guy, for a hobby php site I’m trying to get Oauth2 with gmail free smtp, and the token refresh part to run on its own and even with packages like Phpmailer there’s no simple working copy/paste examples, just loads and loads of bits and pieces and outdated examples and small print about Google changed this or that… I mean wtf is the point of having a package that is supposed to abstract OAuth if you still end up having to dig for hours and having to figure OAuth2’s flow in detail? I’m so disgusted I figured maybe I’ll do the password with 2fa on that email acct and be done with it even though OAuth shpuld be the better option.
• chrishannah 3y ago
  I think sometimes OAuth providers explicitly explain it in a more complex way, just so that you would use their bespoke platform/services to implement it.
• pdobsan 3y ago
  A while ago I wrote a small utility mailctl [1] to provide IMAP/SMTP clients (like msmtp, fdm, isync, mutt, etc.) with the capabilities of renewal and authorization of OAuth2 credentials. mailctl acts as a kind of smart password manager. In particular, access token renewal happens automatically in the background transparent to the user. Since the program written in Haskell I also provided precompiled binaries to spare my potential users, most of them not Haskellers, from the complications of compiling it. The program have become moderately popular. However, little I knew how big can of worms I opened by releasing it to the public. As many others pointed out, the two main reasons for the difficulties with OAuth are 1) the OAuth "standard" is terrible complex 2) the service providers' API documentation is an impenetrable obscure mess, always one step behind of the current working system. I have the feeling that the second one is not just negligence but might also be an intentional hidden lock-in mechanism by forcing the use of the vendors' ever changing API libraries. [1] https://sr.ht/~petrus/mailctl/ https://sr.ht/~petrus/mailctl/ also mirrored at https://github.com/pdobsan/mailctl https://github.com/pdobsan/mailctl
• bullen 3y ago
  https://datatracker.ietf.org/doc/html/rfc2289 https://datatracker.ietf.org/doc/html/rfc2289
• tristor 3y ago
  Because the underlying problem is hard. SAML is difficult too. Identify federation, across the public Internet, between disparate entities is a fundamentally difficult problem with no simple answers.
• glonq 3y ago
  My current project is the first where we decided to use "real proper" authN/authZ instead of a home-brew solution or a minimal solution like asp.net simple auth. I found that all the off-the-shelf solutions were either easy but expensive or cheap/free but difficult. I failed to find that mythical cheap or free and also easy and fabulous. Eventually we settled on self-hosted KeyCloak as the best bang for the buck. It took a bit of effort to get there, but we are happy with the results.