OAuth: is it a bad idea to serve the authorization endpoint from the same domain as the PDS?

[DavidBuchanan314]

With the "entryway" system, bsky.social users authenticate via a page on the bsky.social domain, even though their specific PDS is elsewhere. This seems good - I think it's generally good practice to keep your "backend API" (which the PDS effectively is) separate from auth.

However, the entryway system is optional. For a self-hosted PDS, the authorization endpoint is typically hosted on the same domain as the PDS itself.

RFC6749 does say "The authorization server may be the same server as the resource server or a separate entity." but just because you can, doesn't necessarily mean it's a good idea!

PDSes host user-generated content, as we are reminded of by https://danielmangum.com/posts/this-website-is-hosted-on-bluesky/ - if it weren't for those HTTP security headers, it would be possible to set up a convincing fake oauth login page, served from the "correct" domain name. I believe it's secure in practice, as-is, but it does make me nervous how "load bearing" those headers are.

I'm currently weighing up my options for what to do in millipds. I'm leaning towards keeping it simple, because I can't think of any specific issues with using the same domain - but maybe there are some other reasons I haven't even considered yet. Hence I'm opening this discussion - does anyone have solid reasons I should do auth on a separate (sub)domain?

[ThisIsMissEm]

The "entryway" system in bsky.social is almost certainly an example of a first-party oauth application: https://www.ietf.org/archive/id/draft-ietf-oauth-first-party-apps-00.html — that is, bsky.social acts as the first-party oauth application but ultimately is interacting with the PDS behind the scenes.

The content-type of blobs should probably be explicitly not allowing text/html or similar, converting those instead to text/plain. We had a similar problem in Solid with PODS (their version of PDS's), where you could host an application within your pod, I argued hard that this was a bad idea, if memory serves.

[DavidBuchanan314]

In millipds I serve all blobs with application/octet-stream, so I'm already defended from that angle (and I've previously proposed that the reference PDS impl should do something similar: #1213 )

[ThisIsMissEm]

You certainly could serve auth from like auth.<instance>, but that'd require vhosting in the application & additional nginx setup.