161–170 of 174 posts
> After investigation, we discovered that there was an issue in one of the Hydra migrations that corrupted the state of certain valid OAuth sessions, which resulted in the migration marking them as invalid.
Was this one of the open source migration files? While I'm no longer involved in the project, I'd be curious to know if it's been addressed upstream.
Earlier quoted context omitted.
IndieAuth is fine (but I’ve yet to see an implementation out in the wild). Tailscale’s implementation of OIDC is nice: https://tailscale.com/docs/integrations/identity/custom-oidc But all that only makes sense if you own a domain name.
> But all that only makes sense if you own a domain name. I have a hard time believing the venn diagram of "has a need for an auth provider" and "has at least one domain name" isn't just a a small circle almost entirely inside a large one, and the sliver on the outside is not for any reason other than stubborn refusal.
My point was basically: OpenID 1 tried to let people log into websites using domain names. This is still possible to implement (and easier than OpenID, IMO), but people just don’t want to bother with domains.
I used to manage a self hosted instance of the identity server framework for dotnet that ran several billions of requests per month, my experience managing OAuth and OpenID Connect at that scale was that it was pretty much a solved problem with relatively low maintenance *(it was a critical core service at our org, with heavy compliance, but our team was maybe 3 people taking care of it? it is still up and well to th…
Is that the identity server for dotnet that has been converted into a commercial product and costs a huge pile of money to use (lite starts at almost 6000$ per year): https://duendesoftware.com/pricing
Earlier quoted context omitted.
AWS do exactly this. An example use-case is IAM can grant permission to update a Lambda to a Github action running in a given repository.
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 clien…
To achieve the task, i.e: a GitHub being able to update an AWS Lambda without storing a secret/key/certificate you minimally need:
1. A way for GitHub to sign a request before calling AWS with it.
2. A way for AWS to verify this request was signed with GitHub.
3. A way to tell AWS what actions a valid GitHub request is authorized to do.
#1 is very easy with a public/private key signature. For #2 OIDC standardizes this part. Every IdP publishes their public keys in a standardized way. For #3 AWS already has a full permissions/roles system, so it makes sense to use that for this. Then you can get a GitHub action to do anything an AWS account can.
To string 1, 2, and 3 together you end up with the confusing flow you described.
Earlier quoted context omitted.
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
OAuth is pretty simple, just read the spec. Your go to a third party web site. They send you to your OAuth provider, like cloudflare. Cloudflare asks you to login if you’re not logged in, then asks if you want to give that party certain permissions. You say yes or no and then click approve and then you get redirected back to the third party site. They get a secure token and can use that to access the services with pe…
You picked probably the only semi-straightforward thing about part of one of the OAuth specs, then hand-waved away the other 95% of the necessary related specs, knowledge, and experience for getting an implementation working robustly and securely for a non-trivial use case.
Earlier quoted context omitted.
Is that the identity server for dotnet that has been converted into a commercial product and costs a huge pile of money to use (lite starts at almost 6000$ per year): https://duendesoftware.com/pricing
Yes, we started using it on version 3 and ejected from it with self hosting prior to it becoming a commercial product.
Mixed fealings cause the full context should include plans on both Authorization and Authentication flows at least withing Cloudflare ecosystem. No github examples Anyway good start in the right direction from Cloudflare, yet still long way to go especially compare to the full Ory's offering its built on. Ory's Kratos handles identity, login, registration, recovery, MFA... https://github.com/ory IMHO full scope shoul…
Having recently gone through this exercise with our IAM vendor to secure our MCP service, OAuth DCR scares me in that context. With redirect flows, which are usually what you're using when you're plugging your MCP into an agent, the spec says nothing about how to secure that. I really don't want to allow just anybody to register a client with an arbitrary callback. That's opening us up to phishing. Register your clie…
Earlier quoted context omitted.
Do you remember when people had to "remember" a password for every service they use? It is better to use a trusted third party. Sure these third parties are big corporations, but its safer for most people to have a login that just works, even at the cost of some privacy. People trying to remember passwords is a pretty bad security situation. I'm not an expert but so often folks on here throw criticisms without giving…
> its safer for most people to have a login that just works, even at the cost of some privacy. Respectfully, I disagree in a time when all your data is being slurped up and resold constantly I hate any additional costs to my privacy. > People trying to remember passwords is a pretty bad security situation. But that's their problem, not mine. I'm an adult and I use a password manager.
One issue I see all the time (for consumer level password managers) is that, for example, their browser has a password manager, but keychain interjects often. Then they don't know where their password was saved. On top of that, Keychain does some magic stuff to pair URLs to passwords, and then there's "Passkeys" built in. When it remembers password(s), passkeys, different URLs (not very human-readable), automatically remembers stuff, injects things: it's a tangled mess.
Go to a coffee shop and ask 20 people of different demographics whether they would prefer to use a password manager app or to log into sites using an existing social or email account. We have to protect the lowest-common-denominator in terms of technical literacy. Scammers are going after elderly, so unless you have a solution to protect them, it's not THE solution.
Earlier quoted context omitted.
Nah, you don't get to claim they don't work on improving their products, and then handwave away actual updates to it with "yeah but those aren't the improvements I wanted". That's just life and priorities. Abandoning something, and not making the changes you want to see are entirely different things.
You're arguing against a point I did not make. I observed that Cloudflare prioritizes expanding to new products over making improvements to existing ones. I did not claim they do not improve their products. There are numerous examples, such as Cloudflare claiming Workflows had reached "GA" status before offering a way to delete workflows... not via wrangler, not the dashboard, not the API. They eventually added this…
Apologies that I didn't notice you weren't CommonGuy, who said "improving them in the future is not really their style". Consider my reply aimed at them. The two of you seem to be saying something quite different. I don't think I necessarily disagree with you