Oauth and enterprise auth has to be the worst thing ever made, it might be the most confusing and frustrating part of dealing with the cloud. Even the AI tools took a year to just get basic Oauth working on headless systems without assuming you could open a browser. If they're going to go down the auth rabbit hole with RBAC/IAM/Workload identities?/service accounts and all the trash the big cloud providers have, I just hope to god they leave in the simple shit for personal use. I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform.

OAuth2 is complex and often not the right tool. I wrote Ory Hydra and also a blog post when OAuth2 is/is not a good idea: https://www.ory.com/blog/oauth2-openid-connect-do-you-need-u...

For API Keys we just launched Ory Talos (https://github.com/ory/talos) - a perfect alternative for when OAuth2 is too much for the use case.

There are use cases and security concerns that legitimize using OAuth2 - with specs like DPoP you can make these flows more secure. In my view the use cases presented here is a good one for OAuth2, but it certainly doesn’t make sense everywhere - complexity makes system harder to secure.

What I don't understand is why OAuth is rarely talked about in a privacy context, however your OAuth provider knows all the sites you log into and when.

It's a privacy nightmare.

Don't get me wrong but data shows that you will likely fail to keep that api key a as secret and you will also fail to revoke when it becomes necessary. You will definately not going to rotate it frequently as you should.

Good thing about the OAuth2/OIDC is these things will not put the trust on the bearer of the api key, but on actual identity that needs to have the access.

It's the worst delegated authorisation system except for all the others that have been tried from time to time.

> I just want a damn API key, I keep it a secret and revoke if necessary and don't need 10000 layers of auth bullshit tangled up in every layer of every platform

Then implement that on your app... You are just generating a random key and storing a hash + salt.

Auth is hard only applies to auth for many users. For your own auth this is dead simple and made even simpler if you use a half decent framework...

If you are really worried about the implementation being insecure throw one of the many moderately frontier models at it, they are really not bad at finding issues in an auth system that simple.

We had a security report for a oauth vuln and it was the worst thing I have ever read, the whole thing is like spaghetti that "just works" until it doesn't because you feed it something similar.

Never want to touch oauth, it's a fucked spec.

I am tempted to agree with you because I could never quite wrap up my head around it, but I never had to implement OAuth beyond a brief skim through the doc for my own understanding. I always thought this complexity was there for some good reason (security?).

Oauth is fine if you need the complexity, that is a lot of apps sharing common identity information. Then it certainly is superior to the classic workflow.

I agree that it is too complex though and app to app auth is certainly not a focus. I often still use static common secrets and see no problem with that.

I hate for apps needing to save passwords themselves, even if we have good tools today and the standard bcrypt call is reasonably safe. But then you need to reimplement password reset flows and all that ugly shit. Having that centralised is often

I would recommend self-hosting an OIDC service for that matter. The control you get also allows you to easily comply with some laws like GDPR and cousins, because you need to just purge a user in a single system.

Otherwise I thoroughly feel the frustration with IAM and the big providers. Ain't nobody got time for that and it is never a good and efficient solution.

I run Codex in multiple disposable sandboxes and OAuth is such a fucking pain. I vibe-coded a project which just stores/allocates/shuffles codex auth.json files around. I have a codex instance that I manually authenticate multiple times with browser OAuth, then copy that auth.json in a store from where it's distributed to the sandboxes. And sandbox codex sometimes refreshes the authorization, so when that happens I need to send that auth.json back to the central store. Madness.

One good thing GitHub Copilot has it that you can just give it a GH_TOKEN that is valid for 6 months and stop this browser login nonsense.