by bastienbeurier on 4/26/23, 1:41 PM with 282 comments
by remus on 4/26/23, 7:04 PM
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.
by thepasswordis on 4/26/23, 9:06 PM
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.
by dathinab on 4/26/23, 10:05 PM
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).
by coderintherye on 4/26/23, 7:15 PM
by stcroixx on 4/26/23, 8:08 PM
by schlowmo on 4/27/23, 1:39 AM
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.
by mkl95 on 4/26/23, 7:07 PM
by welder on 4/26/23, 6:10 PM
by idlewords on 4/26/23, 9:39 PM
by mikeknoop on 4/26/23, 6:40 PM
"We support standard oauth butttt..."
by defaultcompany on 4/26/23, 11:26 PM
https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a...
by paulddraper on 4/26/23, 6:45 PM
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.
by tommoor on 4/27/23, 1:36 AM
by kierank on 4/26/23, 9:39 PM
by pdobsan on 4/27/23, 11:34 AM
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/ also mirrored at https://github.com/pdobsan/mailctl
by cco on 4/26/23, 7:18 PM
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!
by kayodelycaon on 4/26/23, 7:31 PM
by Analemma_ on 4/26/23, 6:38 PM
by dpcx on 4/26/23, 9:55 PM
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.
by glonq on 4/27/23, 6:22 PM
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.
by codingclaws on 4/26/23, 9:00 PM
by harrisonjackson on 4/26/23, 8:46 PM
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.
by FpUser on 4/26/23, 7:32 PM
by smackeyacky on 4/26/23, 10:17 PM
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.
by agentultra on 4/26/23, 8:23 PM
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.
by jwr on 4/27/23, 8:11 AM
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.
by littlecranky67 on 4/26/23, 10:58 PM
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.
by xyst on 4/27/23, 2:06 AM
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.
by lbriner on 4/27/23, 9:01 AM
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.
by throwawaaarrgh on 4/26/23, 6:53 PM
by cornycover on 4/26/23, 7:45 PM
https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
by NaN1352 on 4/27/23, 10:09 AM
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.
by rglover on 4/26/23, 9:05 PM
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.
by chowells on 4/26/23, 6:45 PM
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.
by revel on 4/26/23, 9:51 PM
by nige123 on 4/26/23, 7:14 PM
by 0xbkt on 4/27/23, 12:55 AM
by webjunkie on 4/27/23, 7:48 AM
by nullandvoid on 4/26/23, 10:01 PM
by awill88 on 4/27/23, 5:35 AM
Oauth is authz
But do get in “the door” you need OIDC + PKCE auth code grant.. or authn
by infogulch on 4/26/23, 7:11 PM
[1]: https://www.authelia.com/integration/trusted-header-sso/intr...
by lukev on 4/26/23, 11:48 PM
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?
by jrm4 on 4/26/23, 9:06 PM
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?
by bebop on 4/27/23, 12:31 AM
by davidguetta on 4/26/23, 9:04 PM
by 6510 on 4/26/23, 6:33 PM
by znpy on 4/26/23, 10:11 PM
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...
by jamietanna on 4/29/23, 7:01 AM
by eru on 4/27/23, 9:10 AM
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.
by TobyTheDog123 on 4/27/23, 1:09 AM
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.
by tristor on 4/27/23, 1:15 PM
by wooptoo on 4/26/23, 9:46 PM
by bullen on 4/27/23, 11:37 AM
by domrdy on 4/27/23, 1:41 AM
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.
by chrishannah on 4/27/23, 10:15 AM
by StillBored on 4/27/23, 2:27 AM
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.
by nektro on 4/27/23, 10:08 AM
by andix on 4/26/23, 9:33 PM
They implement a few happy parths of the standard, but a lot of things are just not there.
by superkuh on 4/26/23, 11:19 PM
by jwmoz on 4/27/23, 9:42 AM
by dekhn on 4/26/23, 8:20 PM
by anarchogeek on 4/26/23, 9:44 PM
by indus on 4/27/23, 3:22 AM
by wslh on 4/26/23, 6:28 PM
by 29athrowaway on 4/26/23, 11:04 PM
by emurlin on 4/26/23, 10:58 PM
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.
by lukeed on 4/26/23, 7:51 PM
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
[2]: https://btn.social/#pricing
[3]: https://supabase.com/pricing#compare-plans
[4]: https://twitter.com/lukeed05/status/1648751062340501505
by firatsarlar on 4/27/23, 6:04 AM