If you're struggling with OAuth I recommend reading this article from Ory:
https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
Why is OAuth still hard in 2023?
31–40 of 290 posts
Re: Why is OAuth still hard in 2023?
#32It's easy with 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
[2]: https://btn.social/#pricing
[3]: https://supabase.com/pricing#compare-plans
[4]: https://twitter.com/lukeed05/status/1648751062340501505
Re: Why is OAuth still hard in 2023?
#33What 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 applica…
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).
Re: Why is OAuth still hard in 2023?
#34Example: 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.
If one uses a redirect_uri with PKCE parameters to send a response a non-oauth endpoint, the AS is still acting as a redirector. It's typically not a list. You typically will have one redirect uri (at least, one per AS), because thats the communication endpoint defined by your client. There are other parameters like state to remember what you wanted to do after you had an access token. PKCE exists to bind the front-c…
The redirect_uri parameter is not a list.
I am referring to the redirect allowlist registered out-of-band by the client: https://datatracker.ietf.org/doc/html/rfc6749#section-2
Re: Why is OAuth still hard in 2023?
#35Related 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 clie…
> 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.
Re: Why is OAuth still hard in 2023?
#36What 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 applica…
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/ but for better or worse I don't believe there is a magic wand authn/authz standard like you want
Re: Why is OAuth still hard in 2023?
#37Because "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".
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.
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.
Re: Why is OAuth still hard in 2023?
#38Probably 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.
Re: Why is OAuth still hard in 2023?
#39What 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 applica…
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.
Re: Why is OAuth still hard in 2023?
#40OAuth 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".
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.
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.