ATProto: indicate that we don't serve OAuth

[QuinnyPig]

According to the AT Protocol OAuth spec, every PDS (Personal Data Server) must implement OAuth endpoints at /.well-known/oauth-protected-resource. However, atproto.brid.gy currently does not implement these endpoints.

This is causing issues with OAuth clients that try to authenticate with Bridgy-federated handles. For example:

1. A handle like cowperthwait.sfba.social.ap.brid.gy correctly points to a DID (did:plc:3rdqbdhx5ksan4ehd7ddw7rs)
2. That DID document has its PDS set to https://atproto.brid.gy
3. OAuth clients then try to fetch /.well-known/oauth-protected-resource from atproto.brid.gy to find the OAuth server
4. This fails because the endpoint doesn't exist

According to the spec at https://atproto.com/specs/auth#authorization-servers, every PDS must:

• Implement /.well-known/oauth-protected-resource endpoint
• Return a 200 (not any other 2xx or redirect)
• Return a JSON object with authorization_servers array pointing to the OAuth server (in this case, probably https://bsky.social)

From where I sit, I think are two ways to fix this:

1. Implement the OAuth endpoints at atproto.brid.gy (recommended if you want to eventually support your own OAuth server)
2. Change the PDS URL in the DID document to point to bsky.social since that's where the auth happens--at least until ATproto federation kicks into gear.

[snarfed]

Hi @QuinnyPig! I'm a big fan of your work!

This is a funny one. In some ways, eg in that it hosts user repos, Bridgy Fed is a Bluesky PDS...but in many other ways, like this one, it's not. I don't support users OAuthing or otherwise logging into clients with bridged accounts because those accounts really are not normal accounts. They don't support direct usage or writing arbitrary records like normal PDSes do. Bridged accounts are only intended for Bridgy Fed itselt to drive them, strictly mirroring whatever the "original" (eg fediverse) account does. https://fed.brid.gy/docs#use-like-normal

[QuinnyPig]

Ah, I got you. Now the challenge becomes "how do we communicate that in an error message so that the errors in client logs don't drive every BlueSky developer down the same insanity-inducing rabbit hole that I just spent two hours in?"

[snarfed]

Ugh, yes, definitely agreed. If you find a programmatic way for Bridgy Fed to communicate to clients, "yes, this is an ATProto PDS, but no, you can't log into your account here," I'll happily implement it!

[Tamschi]

HTTP 405 Method Not Allowed with empty Allow header in the response, in my opinion.

You could serve a plaintext body that says "Bridgy Fed intentionally cannot be used as identity provider." to clarify further.

[Tamschi]

Or alternatively, you could implement the entire flow and then present the user who tries to log in with a message that this is not supported instead of a login form. That would require no special handling at all on the part of app developers and likely wouldn't generate logged errors at all (but wouldn't be programmatically detectable).

[snarfed]

Both true! But if we're expecting clients to add support for whatever scheme we come up with, I'd think our current status quo of returning 404 for /.well-known/oauth-protected-resource (and /.well-known/oauth-authorization-server) would already work, as is.