[HN Gopher] Why is OAuth still hard in 2023?
___________________________________________________________________
Why is OAuth still hard in 2023?
Author : bastienbeurier
Score : 224 points
Date : 2023-04-26 13:41 UTC (9 hours ago)
(HTM) web link (www.nango.dev)
(TXT) w3m dump (www.nango.dev)
| codingclaws wrote:
| 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
| whatusername wrote:
| 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 wrote:
| https://archive.is/26yI3
|
| This explainer is pretty good. Sorry for the archive link, the
| original seems to be down
| wooptoo wrote:
| I found this tool useful for debugging Oauth:
| https://github.com/cloudentity/oauth2c
| agentultra wrote:
| 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.
| mikeknoop wrote:
| We have a joke about this at Zapier -- don't be an oauth butt!
|
| "We support standard oauth butttt..."
| davidguetta wrote:
| Use fief ! By the creator of FastAPI
| cornycover wrote:
| 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...
| smackeyacky wrote:
| 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.
| remus wrote:
| 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.
| missingdays wrote:
| OAuth specification was the best source for me. All provider
| docs are simplified and usually specific to the provider
| zippergz wrote:
| 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.
| butisaidsudo wrote:
| I read so many docs when I was trying to implement OAuth and
| got more and more confused. This video was a huge help though
| for explaining all of the concepts:
|
| https://www.youtube.com/watch?v=996OiexHze0
| btilly wrote:
| 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/Aut.... Even though you're unlikely
| to ever use that library or language, you may find it
| worthwhile.
| sebmellen wrote:
| 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.
| btilly wrote:
| Thank you.
|
| It summarized my understanding after a month of reading
| documentation, doing experiments, and generally banging my
| head against the wall.
| count wrote:
| Please publish this on its own somewhere! This is fantastic.
| interroboink wrote:
| As a fan of Perl, this situation of having an obscure,
| meticulously-documented CPAN module to not only explain but
| implement some common-but-surprisingly-hard pattern is just
| so ... Perl-y (:
|
| Perhaps it's a semi-consequence of Perl being perceived as
| old and crusty, and popular with old crusty people who are
| merely trying to get things done without fluff (at least
| speaking for myself).
|
| Reminds me of Data::Manip, another favorite of mine.
|
| Thanks for taking the time to write this (and implement all
| that nonsense).
| btilly wrote:
| Thanks.
|
| The crustiness in this case was enhanced by my grumpiness
| over some frustrating debugging sessions, and having to go
| through a lot of very confusing documentation to get there.
| That grumpiness shows through in a couple of places.
|
| For example I understand why Google decided that I was
| asking for the same permission too often, and began handing
| me codes that would not work. And also wouldn't explain
| what was wrong with the code that I just got.
| jkubicek wrote:
| Your documentation is amongst the best I've seen on OAuth,
| but it suffers from the same naming confusion I _always_ run
| into when I 'm reading OAuth docs.
|
| > OAuth 2 makes it easy for large _service providers_ to
| write many APIs that _users_ can securely authorize third
| party _consumers_
|
| If I'm trying to write a Mastodon client, I'm reading this
| line piece by piece:
|
| > OAuth 2 makes it easy for large _service providers_
|
| "service providers" OK, that must be the Mastodon service.
|
| > ... to write many APIs that _users_
|
| "users" That must be me
|
| > ... can securely authorize third party _consumers_
|
| "consumers" OK... that's also me?
| Operyl wrote:
| Users are your users shared with the users of that API
| service (which may include you if you use your own
| service), consumer in this case is you (the application
| you're running).
| btilly wrote:
| That is why there is a terminology section:
| https://metacpan.org/dist/LWP-Authen-
| OAuth2/view/lib/LWP/Aut...
|
| If you're trying to write a Mastadon client, then the
| Mastadon service is the service provider, you are the
| consumer, and the people who wish to use your client are
| the users.
| adammarples wrote:
| I'm bookmarking this to go through the next time I need to
| bang my head against this wall, thanks
| mixmastamyk wrote:
| Looks great, taking a look and favoriting.
|
| (Only feedback I can think of is that it would be great to
| have a few diagrams... like from excalidraw or something. Am
| largely a visual learner.)
| tarsinge wrote:
| I found doing a custom (without a library) OAuth integration
| for only one service relatively straightforward, i.e. when it's
| not treated as a standard. For example for a plug-in
| exclusively for Shopify (random example, didn't try it) you
| would just treat it as the rest of their API and write custom
| code.
|
| In short it works when you can see it as a guideline instead of
| a standard.
| klabb3 wrote:
| We really deserve a less over-engineered actual standard that
| has a very restricted feature set.
|
| In practice, isn't OAuth predominantly used to verify proof of
| email ownership? If so, why not just use magic links as sign up
| & sign in?
|
| 1. Sign in/up: Enter email (can be pre-filled by browser/app)
|
| 2. Click the email verification link or enter code if on
| different device.
|
| 3. Profit. No manual typing necessary, only clicks.
|
| This is trivial to implement, and can be extended in the future
| with a simple standard for browsers/apps to automatically
| verify in the background (to avoid the tab-switching
| inconvenience in step 2). On iOS they auto-populate SMS codes
| in a similar fashion.
|
| 2FA can be out of scope, (many times not needed because email
| providers already have it). But if needed, it can be added as a
| second step after the email proof.
|
| Please tell me what I'm missing. This seems, to me, like an
| excellent trade off between implementation simplicity,
| extensibility, user convenience and security.
| p_l wrote:
| It would simply not handle pretty much any case that I have
| used OAuth2 to implement so far.
|
| For example - login system that merged LDAP/Kerberos/client
| cert/long-lived application token authentication into single
| system, that also linked said authentication system into all
| applications in the network, including making it possible to
| login to AWS Console using Kerberos (that one was twisty to
| get running, not because of OAuth2 but because of how it is
| handled by AWS IAM).
|
| Also, I have used it to link in MFA systems of different
| kinds (it was definitely easier side than industry standard
| of using Radius)
|
| In addition, this proposed system requires that every app has
| ability to send emails, which honestly is less simple than it
| sounds, especially today when sending to arbitrary public
| emails.
| klabb3 wrote:
| For service accounts, email is clearly not the right
| choice. I don't have experience with enterprise auth, are
| Kerberos etc not using company email for human identity?
|
| > this proposed system requires that every app has ability
| to send emails, which honestly is less simple than it
| sounds
|
| For humans and especially end-users of consumer services,
| my observation is that the elaborate auth dances are using
| email ownership as last resort anyway, ie for account
| recovery and/or a trusted 3p that has verified the email.
| So the thought is simply to make that flow more convenient.
| Perhaps this is misguided.
| titaniczero wrote:
| My experience is similar but tbh I feel it's mainly due to the
| fact that oauth is implementing an important security layer
| (authentication/authorization) and that's hard by definition.
| There are lots of steps and things you can't afford to overlook
| or you'll be vulnerable to multiple different attacks
| rglover wrote:
| 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 wrote:
| 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?
| revel wrote:
| 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
| thepasswordis wrote:
| 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.
| cjbgkagh wrote:
| Auth0 has a business incentive to have people think their core
| competency is more difficult than it is.
| [deleted]
| [deleted]
| jcranmer wrote:
| In my experience with OAuth, one of the principle issues is
| that it's less a protocol and more a skeleton of a protocol.
| Actually go to the core RFCs for OAuth, and you realize that
| basically everything is implementation-dependent. You somehow
| register with the provider as a client (out of band and
| completely implementation-dependent).
|
| Then you ask them to log you in by sending a request to an
| implementation-dependent webpage, with implementation-dependent
| parameters (which ones are required are--you guessed it--
| implementation-dependent), telling them to redirect you to your
| page when you're done. Well, actually, that assumes you're
| building a website. If you're a desktop application, you'll do
| something else. If you're on an embedded system that can't open
| up a webpage, there's another option. And there's yet more
| flows. Which ones are supported by the provider? You guessed
| it, it's all implementation-dependent. Oh, and maybe you need
| to refresh tokens to login the future. When? If? You guessed
| it, implementation-dependent!
|
| It makes writing a generic OAuth client library hard because
| there's basically no commonality there. Really, it makes me
| long for Kerberos as a much saner SSO system than OAuth.
| znpy wrote:
| > In my experience with OAuth, one of the principle issues is
| that it's less a protocol and more a skeleton of a protocol.
|
| Because it is, really.
|
| OAuth (2.0) is really the backbone for OpenID.
| TallGuyShort wrote:
| OpenID Connect, specifically, where a lot of people mix
| those up and start looking at using OAuth for
| authentication. And if I'm not mistaken, logging out is
| implementation-dependent in OpenID Connect. There's some
| pseudo-standards but implementations vary in my experience.
| And OpenID Connect also has multiple flows for different
| kinds of applications. There's still a lot of confusion and
| complexity here.
| majormajor wrote:
| This is my experience. It's hard because it's very complex.
| As a non-domain-expert it's hard to separate necessary
| complexity from unnecessary complexity, but it feels like
| there's a lot of the latter, plus enough gotchas in the
| former ("oh, you didn't specify an encryption algorithm that
| we support in your request, and our logs are terribly
| unhelpful for realizing that") to make it a giant pain.
| gigatexal wrote:
| Is Webauthn a better standard?
| paulddraper wrote:
| One reason is that the protocol itself is more complicated than
| you've described.
|
| For example, Google won't give you a long-lived access token.
| You need a refresh token, and then you use that to retrieve
| access tokens, and continue doing that as they expire.
|
| Why? I have not a flipping idea. Please, HN enlighten me how
| refresh/access token dichotomy improves the API.
| znpy wrote:
| > Why? I have not a flipping idea.
|
| https://www.rfc-editor.org/rfc/rfc6749.html contains
| everything you might want to know about OAuth in great detail
| :)
| dflock wrote:
| It's really trying to solve a problem they created by
| statlessly handing out tokens instead of keeping session
| state on the backend - they have no way to revoke a token
| once issued, so long lived tokens are a liability. Solution?
| More complexity! Hand out very short lived tokens, along with
| a slightly longer lived refresh token, which only allows you
| get a new bearer/access token.
| rad_gruchalski wrote:
| Don't they still require some state to be able t invalidate
| refresh tokens?
| johnmaguire wrote:
| Yes, but checking refresh tokens will occur much less
| frequently than checking access tokens. So you can
| imagine, for example, access tokens being JWT, so they
| are cheap to check. But every so often you have to
| validate the refresh token against MySQL (or BigQuery or
| what-have-you), which is more expensive.
| rad_gruchalski wrote:
| That's all clear to me. But technically there exists a
| method to revoke an issued token. It's just that long
| lived tokens mean potentially lots of them == increased
| storage cost. It would be pretty silly not to check for
| revocation. How would one implement logout otherwise?
|
| The purpose of a refresh token to allow the app to short
| circuit the login process. Regardless of how long the
| token is. It's perfectly okay to ignore refresh tokens
| altogether, if one wants to.
| 0x457 wrote:
| Very simple, actually. Access tokens are short-lived and are
| irrevocable - google services only check validity and
| expiration of those tokens.
|
| Refresh tokens are more like session tokens/cookies - those
| get checked every time. At Google scale, checking it probably
| expensive, so they are using refresh tokens.
|
| These aren't for end-user or development experience, those
| are for AS performance.
| garbagecoder wrote:
| Somebody print this comment out, frame it, and mail it to every
| major API author.
| izacus wrote:
| That drove me up the wall in Python so much - ALL the
| documentation just described how to put a massive library into
| a cookie cutter example and never explained how it's supposed
| to work so I could debug the darn thing.
| znpy wrote:
| when it comes to this kind of things there's really no way
| around it: you're supposed to read the RFCs:
|
| - https://www.rfc-editor.org/rfc/rfc6749.html: The OAuth 2.0
| Authorization Framework
|
| - https://www.rfc-editor.org/rfc/rfc6750.html: The OAuth 2.0
| Authorization Framework: Bearer Token Usage
| chowells wrote:
| 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 wrote:
| 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.
| harrisonjackson wrote:
| 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.
| paulddraper wrote:
| 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.
| cellularmitosis wrote:
| On iOS, two applications can register as handling the same
| callback URI scheme. Which one gets the callback is non-
| deterministic. Thus, it is possible for some other app to get
| the token. I don't see how an allowlist would mitigate this.
|
| With PKCE, the other app can still intercept the token, but the
| token is incomplete and useless.
| akira2501 wrote:
| My understanding is that PKCE allows you to more safely operate
| a client that does not have a client secret.
| maxwellg wrote:
| 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-
| 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/480.
| .. - which may or may not be an attack vector you care about.
| dwaite wrote:
| > 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.
| [deleted]
| zmxz wrote:
| Correct me if I'm wrong, but what you're implying here is that
| PKCE and URI allowlist are the same feature because if you
| specify URI allowlist while initializing the flow - it somehow
| helps public clients to prove they're the apps that initialized
| the flow and are the ones who are finalizing it?
|
| Could you please expand on that thought, I'm genuinely curious
| if you actually might be right or whether this assumption of
| yours is how we get security holes.
| dwaite wrote:
| 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-channel authorization request and
| back-channel token request together as being by the same
| client. There is otherwise no evidence that the two parts are
| by the same software instance, which causes other security
| issues.
| paulddraper wrote:
| 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
| dwaite wrote:
| right. I was speaking to registration of redirect URIs -
| most clients should only register one, because they have
| only one endpoint (for that AS at least) for handling
| authorization responses. You should not use redirect URI
| for deep links, for example - you should capture pending
| actions to take after authorization separately.
|
| You could hypothetically register redirect URI for the DNS
| names of your individual client cluster nodes, but there's
| no guarantee an AS will let you register as many URI as you
| have cluster nodes - and you will have a failure case to
| handle if the cluster node goes down mid-authorization, and
| coordination if you need to grow said cluster.
| mkl95 wrote:
| 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".
| zmxz wrote:
| 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 wrote:
| > 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.
| zmxz wrote:
| You need 10 minutes of focused reading to understand what
| the purpose of the protocol is and you don't need all of
| the OAuth RFCs to implement the bare-minimum nor do you
| have to support all the grants available.
|
| Most people I worked with don't understand the purpose of
| OAuth and that's what the 10 minutes should be invested
| into.
|
| Or, you can, you know - nitpick and live in the world of
| gloom and doom where everything sucks.
| haswell wrote:
| For what it's worth, I taught a series of classes/labs
| intended to help developers within my former employer's
| ecosystem understand OAuth.
|
| What I learned after delivering the content to hundreds
| of devs over the years: OAuth confuses people, and for
| completely understandable reasons. Most people think
| about auth in terms of usernames/passwords or API keys.
| The mental models associated with these do not transfer
| to OAuth, and there are enough moving parts with client
| and server-side interactions that someone not already
| steeped in the authn/authz space will have some catching
| up to do.
|
| Forming an understanding of the basic concepts rarely
| happens in 10 minutes, and if that's your experience,
| good on you. Most of us bang our head against the wall
| for a bit and some of us go on to teach classes about it.
|
| Bottom line: OAuth is hard. That is not the same thing as
| the general concept being simple.
| lloydatkinson wrote:
| 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 wrote:
| 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.
| dpcx wrote:
| 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.
| andix wrote:
| 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.
| stcroixx wrote:
| 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.
| bootloop wrote:
| 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 ???
| 411111111111111 wrote:
| 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.
| lukeed wrote:
| It'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
|
| [5]: https://docs.btn.social/providers/
| kayodelycaon wrote:
| OAuth is such a pain in the ass for small projects. I miss api
| keys.
| emurlin wrote:
| 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.
| FpUser wrote:
| 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.
| littlecranky67 wrote:
| 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.
| wslh wrote:
| 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.
| infogulch wrote:
| 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/intr...
| mdaniel wrote:
| 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
| darkr wrote:
| 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).
| paulddraper wrote:
| 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.
| welder wrote:
| 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.
| nullandvoid wrote:
| 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 wrote:
| Next Auth is brilliant. It just works.
| idlewords wrote:
| I never understood how Oauth as a user experience is supposed to
| be distinguishable from phishing.
| nige123 wrote:
| GNAP is coming soon: https://oauth.net/gnap/
| kierank wrote:
| 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.
| lll-o-lll wrote:
| Client credential flow. It's one call with a secret in it, and
| back comes the Access Token. If you want better security, it's
| one call with a JWT signed by a private key. No browser, really
| easy to implement.
| p_l wrote:
| 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.
|
| 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.
| throwawaaarrgh wrote:
| It was designed by committee, and the internet adopts any shitty
| technology that a big player pushes.
| lakomen wrote:
| [flagged]
| 6510 wrote:
| 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.
| coderintherye wrote:
| 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 wrote:
| > 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.
| lll-o-lll wrote:
| 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.
| andix wrote:
| If you want to have password reset, OTP, 2FA, webauthn and so
| on, you probably want to use an external authentication
| provider. Integrating it with oidc/oauth is much easier, than
| doing all that stuff by yourself.
| justrealist wrote:
| Not to mention needing to create awkward shared service
| accounts to impersonate.
| TRiG_Ireland wrote:
| I ran into that recently trying to connect a web shop we've
| built to an accounting platform. The web shop handles the
| entire checkout flow, but the owners also want a copy of the
| invoice stored in their accounting platform. The platform has
| an API. So our web shop can ping the accounting platform after
| an order is placed, and sent them a record of what was
| purchased? No. Because the API requires authorization. So the
| admin has to occasionally log into our website and hit a button
| to send invoices to the accounting platform. (At least we can
| send multiple invoices at once, so it doesn't require them to
| hit a button on each individual one.)
| dathinab wrote:
| 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).
| cco wrote:
| 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 wrote:
| > 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.
| anarchogeek wrote:
| 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 wrote:
| 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.
| dekhn wrote:
| because it was a dumb standard with terrible implementations
| solving a problem that nobody had
| 9dev wrote:
| 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 wrote:
| 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.
| znpy wrote:
| 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...
| Analemma_ wrote:
| 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".
| icedchai wrote:
| 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 wrote:
| 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.
| noughtme wrote:
| 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.
___________________________________________________________________
(page generated 2023-04-26 23:00 UTC)