Your OAuth provider can also vouch for anyone who pretends to be you, if they so desire. They can give access to anyone, including themselves.

I've done a bit of experimentation in this area. Check out https://lastlogin.net/.

You may also be interested in the FedCM protocol Google is working on.

Slight tangent.

The only way to preserve privacy while having a central and easy authentication mechanism I can think of is to use IndieAuth[0] which is built on top of OAuth 2.0.

Of course, you will need to be your own provider, using an IndieAuth provider service defeats the purpose, which is what I see most IndieWeb devs are doing.

You will need to own a (sub)domain though.

[0] https://indieweb.org/IndieAuth?redirected=IndieAuth

Corporations aren't interested in preserving privacy, quite the opposite. If you need OAuth for private use you'd have to roll out your own centralised directory.

Though given most people use gmail or outlook, the two main oauth providers (Google and Microsoft) will know anyway

Centralised identity is basically the government... and having some other entity behave the same way is not good.

there are some emerging mechanisms for offline verification that don't require AS in the OAuth WG. (I'm working on one of them)

Ory Hydra was one of the few tools I remember being actually good and lightweight and useable. Tried setting up and using KeyCloak for a while, absolute nightmare

My data shows that zaptheimpaler has above average likelihood to keep their secret secret.

> 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.

And... you do not see the myriad of problems with that? What about the OIDC provider going rogue or getting compromised? How do you ensure whatever you use to authenticate with your OIDC isn't compromised? Many identity providers and identity bearers have terrible security practices. "Add a backup email in case you lose your 2FA. Nevermind it's the same email we use for password reset."

Again, I trust zaptheimpaler to keep their secret much better than this whole pretend security theater.

> but on actual identity that needs to have the access.

Not quite. You shift the trust from the key bearer (the most interested party in all of this) to the identity provider.

Can you share source of this data? I have my doubts about the quality of the data, since OAuth2 is such a complex system with so many footguns.

In the end there is always some long lived secret. What changes is just where and how it is stored, secured and used.

I bet we can generalize to say that data shows that you will likely fail to properly secure any secret (including the ones used in OAuth2).

EDIT: An example: https://news.ycombinator.com/item?id=37973937

The original OpenID was fine.

OAuth is designed so that an end-user never needs to see an API key (OAuth refresh/access token) or even know what one is. When it is implemented to the spec, that happens well.

I think that most of the "just give me an API key" comments are from a <1% of end-users (developers) that know what an API key is, and are facing a broken OAuth implementation.

> I always thought this complexity was there for some good reason (security?).

It's just design by committee.

> was there for some good reason (security?).

To cover the myriad of (sometimes downright stupid) requirements that large enterprises have.

far from it! it was just designed by comitee who both future proofed it and made sure it worked on low powered devices from 1971.

i make a point to implement oauth from scratch, because using the overly complex libraries expose you to bugs such as attacker sending a token which the metadata just says "no encryption or signature. trust me bro", which is actually part of the spec if you combine some options.

while in the real world, if google or apple sends you a token that is not always the same signature cypher (one of a dozen by the spec) you are better of threating as malicious, because it pretty much is. a manual implementation of a token consumer is about 20 lines... including downloading the provider keys and checking it (which most startups never do! allowing anyone to just sign a token as anyone)

> I would recommend self-hosting an OIDC service for that matter.

Seconded. It is fairly easy to set up, and so much easier than the cloud IAM things.

The only catch is, make sure you have some backup access to your OIDC provider in case it goes down. E.g. don’t host it on a server with SSH only accessible through VPN that is authorised using your OIDC provider, etc.

What does codex's auth.json file have to do with OAuth?

Truly appreciated, thank you :)

Valid points (although Keycloak was Redhat not IBM and then donated by them to CNCF), but should "security SLAs for CVEs" be listed as a premium feature?

Looked at the case study, uses Cockroach which is now commercial, so potentially with the dual costs of Ory and Cockroach licenses, unless you need massive scale, would be too expensive for small/medium and also startups? Unless your sole focus is on enterprises?

And Keycloak also has such a implementation https://www.cockroachlabs.com/blog/deploying-keycloak-on-coc...

I don't think that's necessarily true. Certainly the video streaming is expensive, but other things like workers and KV store are quite cheap and performant and powerful _if you structure your access patterns accordingly_ .

Cloudflare pricing introduces an additional dimension for when you're architecting software on top of them, but if you do it correctly, your product has the potential to be faster, cheaper, and easier to run than traditional solutions running on multiple geographically distributed VMs. You just can't approach them as if they're just another VM instance provider and expect a similar experience and pricing. What they do and price for is fundamentally different from that.

Maybe it depends on product offering. WAF + CDN was competitive with Akamai (through a VAR) and AWS and came with free Zero Trust seats.

Iirc Argo and some other routing products are quite expensive.

I cannot agree more. Cloudflare has some services that are really cheap (r2) to lure you into their worker "ecosystem", which is just serverless. Once you are vendor locked into their absolute garbage custom JavaScript runtime, you are pretty much forced to use their distributed database Cloudflare KV if you want good performance. Cloudflare KV is so extremely ridiculously absurdly expensive that make predatory pricing of vercel that HN likes to complain about feel like child play.

It's a good move for them but it's problematic for anybody who cares about a decentralized Internet.

Personally I dont like the way they do it, its hard to understand, if anything its convoluted.

In case of AWS, you add Github as an IDP (OIDC provider) and associate a role to it.

Github is now authenticating into AWS, scoped to the github repository where its configured and the AWS role it can assume

Its not really a typical OAuth2 or OIDC flow. And yes its better than storing the keys.

Github is not the OAuth client here.

I really feel sad about the state of security and its bit hard to unwrap in one paragraph which makes it more challenging. Let me try to be bit more verbose

Cloudflare API Keys - You create them and then use those keys directly against cloudflare API's to manage services/infrastructure in your account. How you create the keys is may be a different kind of challenge.

OAuth flow in discussion here - You are using a third party service (which registers themselves as a the client application with cloudflare), this service is going to prompt you for OAuth flow and redirect to Cloudflare, not (only) to authenticate you but it will get a access token on your behalf (your cloudflare account) from Cloudflare. Whatever this THIRD PARTY service uses this token for your behalf is going to incur infrastructure cost for your account.

Maybe he doesn't. And I know that I don't (at least not in depth). And that's the frightening thing here. Using a protocol that many don't understand for access to valuable resources

OAuth2, to be more precise, is a protocol which can be used both for authentication (verifying the user) and authorization (accessing resources on behalf of that user).

Most people in CIAM (customer identity, individuals owing their account instead of representing a company) only interact with OAuth client for authentication. They do not give access of their google account to some THIRD PARTY COMPANY.

If you carefully read the article, it just explain how it is an economic decision, and one which sooner or later will be no longer the case once they can capitalise on with anything above free, which is the lowest of the lowest bars.

But even to entertain this is crazy, not because of decades of history of capitalist and market enterprise in general, but very specific cases of Technology Companies starting with these kind of feel good ideas and declaring "Don't be evil" or things like " access, safety, and shared prosperity" as their core ideals, turn into absolute panopticon and collaborate with unjust killing of women and children in less than a decade.

The market isn't for free.

Man-in-the-middle everything.

DDoS Protection?

Usually I expect an eng blog post to be a recruitment vehicle, wherein the authors articulate a really hard problem they solved, or some novel approach they took, or the cool new open source project they released (for their future SaaS play).

But this is so mundane it bothers me in a way I find surprising. It's more about how they made some questionable choices in the past and how they finally paid off that technical debt. Is it interesting? Perhaps I am just getting old and jaded.

What I find odd is how light TFA is on actual details as to what it is they shipped.

This is the kind of thing I'd ship internally to the org as part of a weekly update or something, but not what I'd expect on a public-facing corporate blog.