I ran into this trying to log in with an account on my own self-hosted PDS, and I think the problem is on the PDSls side rather than mine. Correct me if I'm wrong.
When I sign in, the flow fails at the PAR step with this:
OAuth "invalid_client_metadata" error: Unable to obtain client metadata for "https://pdsls.dev/oauth-client-metadata.json": Forbidden
Here's what I think is going on. Per the atproto OAuth spec, my PDS has to fetch the client metadata server-side. The trouble is that this file is sitting behind a Cloudflare managed challenge. From my PDS's box, when I run curl https://pdsls.dev/oauth-client-metadata.json it comes back as HTTP 403 with cf-mitigated: challenge and the "Just a moment…" page (cZone: pdsls.dev, cType: managed). From my persona machine it returns 200 just fine. A server can't solve a JS challenge, so OAuth breaks for any PDS whose host IP Cloudflare decides to challenge.
(Of note: I get the exact same result starting from pds.ls)
I checked the rest of the chain to be sure it wasn't me. Handle/DID/PLC resolution and my PDS's own OAuth metadata all resolve correctly; the only request that fails is Cloudflare blocking the client-metadata fetch.
A fix that should do it: add a Cloudflare WAF Configuration/Custom Skip rule for URI Path = /oauth-client-metadata.json (and probably /.well-known/* and the /resolve-handle-http route too) that disables Bot Fight Mode / Managed Challenge / Browser Integrity Check, so this public, spec-mandated document is fetchable by any PDS server.
Let me know if you'd like more details, happy to dig further. 😃
Thanks for all your work with pds.ls!
I'm afraid the problem is still there with
pdsls.dev, but I was able to log in withpds.lswith no issues, thank you!😦